Espacios de Trabajo para Equipos Ágiles

Este es un tema recurrente con muchas organizaciones a las que ayudo. Como el foco principal del paradigma ágil es la colaboración, muchas veces llega un momento en que ellos notan que sus espacio de trabajo no son ideales para lo que intentan lograr.

 

Espacios frágiles

Los espacios de trabajo más nocivos que me encuentro suelen incluir desde cubículos hasta oficinas individuales a puerta cerrada. Y aclaro que he trabajado en lugares así, aunque nunca fue mi preferencia. Durante un tiempo -hace muchos años- me tocó una oficina privada, alejada por un pasillo largo del equipo que me tocaba liderar. Al principio me sentí inocentemente importante, pero pronto me di cuenta de que esa distancia no nos beneficiaba en nada.

Algunas variantes de los cubículos son los espacios semi-abiertos con escritorios con divisiones más bajas, que permiten verle los ojos a la persona de enfrente, aunque no alientan una colaboración más allá e una pregunta o conversación esporádica.

Y no sólo los espacios físicos generan fricción. Muchos espacios virtuales también lo son. Muchas de las llamadas "herramientas de colaboración" me resultan consistentemente un impedimento a la conversación cara a cara. A riesgo de controversia, no he visto nunca un equipo que mejore su comunicación (pero si montones que definitivamente empeoraron) por usar Jira, Sharepoint u otras monstruosidades que están más diseñadas para calmar al management que para que la gente se auto-organice.

 

Espacios con "Onda Ágil"

Muchas organizaciones, al sentir que la gente se entusiasma con la agilidad, quieren crear lugares atractivos para atraer talento que espera determinadas características laborales que no son tan fáciles de transmitir a simple vista. Así que recurren al folklore y no muy extrañamente, atraen a los estereotipos a los que se dirigen, lo que no siempre da resultado.

Clásicos de ese estilo son las metegoles (o futbolines, según la región), las paredes ploteadas con íconos y slogans sobre creatividad, innovación y talento, aunque frecuentemente esos y otros valores están en las paredes pero no se sienten en el día a día. En algunos extremos (que creo bien intencionados) se ven exaltaciones a los super-héroes, los rock-stars o ninjas. Como si colaborar fuese tratar de ir solo contra todo, inmolándose por alguna causa esquiva.

 

¿Espacios realmente ágiles?

Mis consejos para quienes quieren realmente generar un ambiente de colaboración y dinamismo van siempre en el mismo sentido: empezar por no definir todo, sino dejar lo máximo posible a criterio de los equipos que usarán el lugar.

Para eso, realmente suele ser preferible contar con espacios abiertos, pero como pueden ser ruidosos, se puede recurrir a elementos que la gente pueda usar para crear sub-espacios flexibles y reconfigurables.

Algunos de los elementos que prefiero (por experiencia, como materia mínima para que los equipos decidan después):

• Mesas pequeñas, con patas no intrusivas, donde al menos se pueda trabajar de a dos. O livianas o con rueditas.
  
  
• Tomas de corriente a granel, sobre las paredes. Y que los equipos puedan poner sus (inevitables) extensiones por donde quieran. Si los cables se tornan molestos o peligrosos, ellos deberían encontrar la mejor solución, no un "arquitecto".
  
  
• Pizarras o bastidores fáciles de mover (con rueditas o livianos) pueden servir como separadores, aislantes acústicos y también como soporte para radiadores visuales.
  
  
• Paredes libres (también pueden ser ventanas o paneles de vidrio), sin inscripciones, emblemas ni slogans previos. El uso de las paredes para pegar tableros, indicadores, información necesaria para el equipo, es vital para la comunicación osmótica. Los pizarrones de diferente tipo, sobre todo si son móviles, son un buen recurso para discusiones y diagramas efímeros.
  
  
• Buenas sillas. Pensando que los trabajadores del conocimiento usamos sobre todos nuestro cerebro y nuestro trasero, tener buenas sillas (de nuevo, móviles) es una excelente inversión para cuidar la salud y comodidad de los equipos.

Sobre todo, si queremos promover un ambiente de autonomía y creatividad, demos los elementos básicos y dejemos que los equipos se apropien. Lo que no significa dejarlos a la deriva. Se puede explícitamente pedirles que determinen un plan, tal vez con un presupuesto básico y posibles extensiones iterativas.

Varias veces vi que se diseñan espacios incluyendo áreas de "esparcimiento" para los equipos, donde se incluyen equipos de videojuegos, mesas de ping-pong o instrumentos musicales. Pero este nuevamente es per-determinar qué es lo que ellos querrán, en lugar de preguntarles. Tal vez terminen poniendo la consola de juegos, pero ellos elegirán cuál prefieren y cómo instalarla. O tal vez prefieran otra cosa, como un espacio para cocinar o para hacer yoga.

En definitiva, al pensar espacios ágiles, tenemos que mantener sus principios: flexibilidad, transparencia, diversidad.

Si alguno tiene interés en compartir los espacios que generaron, pueden mandarme fotos, y veo cómo compartirlas.

 

Cómo escribir tu propio intérprete (o compilador)

Suelo escuchar varios podcast mientras me muevo por Buenos Aires u otras ciudades en mi trabajo. Uno de los que sigo desde hace años es el de Scott Hanselman, que es quizá una de las personas que más me impactó dentro de lo que se conoce como la "comunidad Microsoft".

Scott, más allá de seguir trabajando para Microsoft en el grupo de ASP.NET y herramientas de Azure, es un tipo inquieto que mantiene varios podcasts e iniciativas, y sobre todo valoro su constante esfuerzo por lograr una industria más inclusiva, recibiendo a a gente de toda edad, raza, identidad u orientación sexual, religión o ideario.

Pero basta de elogios al amigo Scott. El tema que me atrajo especialmente en éste último podcast fue que entrevistaba a Thorsten Ball, quien auto-publicó el libro "Writing An Interpreter In Go", que trata básicamente de eso: recorre todos los pasos de escritura de un intérprete. En su caso del lenguaje Monkey que él diseñó para el libro mismo, y que es bastante similar a JavaScript o un montón de otros lenguajes de la familia de las llaves {}.

Más allá de que es un tema interesante, me gustó que la manera en que lo hace es utilizando lo más básico de Go, sin más que la librería standard, construyendo desde cero el parser y el lexer, y sin usar ninguna librería particular. Y por supuesto, utilizando TDD.

Es un libro que recorre en mayor detalle el camino constante del Maestro Ángel Java López, que como puede verse en su cuenta de GitHub escribe este tipo de intérpretes o compiladores todo el tiempo.

¿Por qué escribir un intérprete a esta altura? Básicamente porque las capacidades y el entendimiento de sus partes nos ayudan a ser mejores programadores en general, como llegado cierto punto un buen automovilista tiene que aprender de mecánica, o un rocker necesita aprender sobre ingeniería de sonido.

Codewars: jugar, practicar, codear

Hace unos días recordé este sitio que conocí hace unos años, al verlo mencionado en un tweet de mi amigo el Maestro.

A raíz de esa mención volví a visitarlo y me alegró ver cuánto progreso mientras yo no estaba mirando.

Codewars es básicamente un sitio de práctica. Está basado en la idea de Code Katas, pero extendido a formas adicionales como el Kumite (una especie de competencia entre desarrolladores), y todo en un entorno colaborativo donde los participantes mismos son quienes agregan y refinan los ejercicios, también votando y comentando tanto los planteos como las distintas soluciones.

Entre las características que más me gustaron es que hay:

• Diferentes niveles de dificultad
• Tags que agrupan los ejercicios por temas, niveles, foco
• Alto nivel de gamification: los participantes tenemos Kyu (niveles), Honor (puntos acumulados), seguidores, clanes y medallas entre muchas otras característica que generan una comunidad vibrante
• Foros y comentarios bien integrados
• Un gran contenido gratuito soportado por publicidad, pero que está bien integrada y es relevante (son siempre productos o servicios de desarrollo y los avisos no son molestos), más una oferta paga económica y que más allá de ofrecer unas pocas características avanzadas para quienes realmente le dedican mucho tiempo, es casi una membresía a un club de amigos.
• Y sobre todo, la chance de aprender y/o practicar en una variedad enorme de lenguajes:
  (en este momento) C, Clojure, CoffeeScript, C++, Crystal, C#, Dart, Elixir, F#, Go, Haskell, Java, JavaScript, Lua, Objective-C, OCaml, PHP, Python, Ruby, Rust, Shell, SQL, Swift, Typescript, y otros que todavía no tienen Katas, pero están en proceso, como: CSS3, D, Erlang, Groovy, Julia, Kotlin, Liso, Perl, R, Racket, Sass y Scala.

Para los que ya saben que soy un enfermo de los lenguajes de programación, se dan cuenta que esto es un picnic para mi.

Recién retomé, y usualmente esto es para mi un equivalente a mirar series o jugar videojuegos: un pasatiempo estimulante. Los que quieran pueden encontrarme en Codewars y eventualmente podemos hacer un Kumite.

Katas de Arquitectura

Un año atrás mi amiga Rox (¡que viva México!) me hizo una consulta por mail que acordamos compartir. Me demoré un poco, pero aquí va.

Primero copio su consulta:

Mañana tengo una sesión de kata de arquitectura con un equipo.  El objetivo principal no es la arquitectura en sí, sino un problema que tienen en partir en historias de usuario porque la mayoría de sus requerimientos son no-funcionales y dicen que no se puede.

Así que pensé en hacer un experimento: mezclar la kata de arquitectura con una kata de User Story Splitting.

Así que estoy en el sitio, pero veo que faltan los requerimientos no-funcionales que se agregan y recuerdo que tenías unas cartas.

¿Son los "normales" (escalabilidad, performance, mantenibilidad, etc)? o ¿cuáles son?

Y ahora mi respuesta (ampliada con algún material extra que no incluí en el mensaje original, que pongo entre [corchetes]):

---

¡Hola, Rox! 

Te paso el material:

• Las Katas de Arquitectura en español    [y aquí el sitio original en inglés]
  
  
• Y mi Tarot de Arquitectura
  
  
• [agrego también la guía ágil de patrones de slicing - que a su vez tiene el link a las tarjetas con los patrones]

 

Pero... me suena raro que quieran hacer historias de usuario sobre requisitos no funcionales, que es algo que no recomiendo, salvo que esté originado en un problema de negocio concreto (por ejemplo, la App se pone demasiado lenta cuando hay más de N usuarios).

Las cartas de Tarot están pensadas para discutir esos temas con la gente de negocio *en el contexto* de una historia funcional. 

Trataría de que para los atributos que quieren mejorar definan y anoten explícitamente:

Contexto

¿Por qué es importante este tema? Entender la operación detrás de este tema en un proceso concreto. No pensar que la aplicación tiene que escalar a tantos usuarios, sino lo como 'la transacción de pago de una orden' debe poder soportar tantas sesiones concurrentes.

Métrica 

¿Cómo vamos a medir que estamos en el nivel que queremos? Siguiendo el ejemplo anterior, puede ser cuánto tiempo demora para 1, 5, 10 o 30 transacciones concurrentes, y ponerle tiempos JUNTO con la gente de negocio.

Esto luego, idealmente se escribe en pruebas automatizadas que corren al menos en el build nocturno. 

Decisión 

¿Cómo hacemos para lograr esa métrica?

Acá es donde nos concentramos en 'lo técnico'. ¿Hacemos un componente que escale en threads? ¿Usamos una queue? ¿Cuál? Esto se va a convertir en una o más tareas, de una o más historias.

3 dudas sobre Extreme Programming

Esta semana una asistente a uno de mis talleres de Desarrollo Ágil de Software me envío estas consultas, que como acordamos, intento contestar aquí de manera abierta, para ella y para otros que puedan tener esas dudas.

Hola Martín!

Saludos desde Lima.

Disfruté mucho el taller de Desarrollo de software ágil, ya lo estoy recomendando.... al pasar los días me surgieron unas preguntas que cuando tengas oportunidad por fa me escribes...

Vale la pena aclarar que yo voy a dar mi opinión personal. Yo empecé a utilizar ideas de Extreme Programming (XP) a fines de los '90 y a principios de los 2000 me convertí (se ve que no había mucho más para elegir) en XP Coach de varios equipos. En todo ese tiempo he juntado muchas ideas y dudas nuevas, pero trataré de aportar alternativas y vías de exploración, ya que no creo en que haya UNA respuesta para estos temas.

 

1- Una vez que se decide adoptar XP. El pair programming se aplica todo el tiempo? O se da cabida a espacios para programar individualmente y mob programming?  

Aunque en los orígenes de XP esa era la idea, en la práctica y a medida que ha pasado el tiempo la práctica se ha vuelto más pragmática. Recordemos siempre que a pesar del nombre, XP está basado en principios y valores que son los que buscamos, y las prácticas son solo un reflejo adaptable de ellos.

Cuando la solución más sencilla (recordemos que la Simplicidad es primordial en XP) es escribir el código de a uno, no vale la pena buscar un par. Los casos típicos son los que son triviales: construir otra pantalla, adaptador o función que es una variante particular de otras que ya están hechas.

Cuando el desafío es bajo y las tareas son de muy bajo riesgo, podemos obviar el par. Ahora, cuando nos encontramos realizando tareas repetitivas pero que pueden ser críticas, podemos al menos mantener un criterio de revisión de a pares. Lejos de la programación, en Kleer siempre hacemos revisión de a pares para propuestas o presupuestos.

Mob Programming es todavía una técnica relativamente experimental como práctica continua, pero en varias oportunidades en distintos equipos en los que trabajé pasamos de programar de a pares a tríos o cuartetos. Cuando uno pasa ese límite es difícil trabajar con un monitor usual y el salto a un proyector o una pantalla grande  implica un reacomodamiento mayor. Un paso intermedio usual es realizar workshops de diseño en conjunto para definir componentes de arquitectura, refactorizaciones importantes a nivel de framework o para ensayar alternativas de diseño con todo el equipo.

En todos los casos lo que funciona es probar y aprender. Una de las premisas es que si no experimentamos en la búsqueda de mejores maneras de trabajar como equipo, siempre estaremos ocupados pero probablemente desperdiciando esfuerzo.

 

2- Se puede aplicar TDD o BDD a proyectos que ya han empezado de la manera tradicional (sin metodologia de desarrollo agil o casos de prueba?) o tiene que ser proyectos que aún no hayan arrancado?  

Claro que si. Lo más sencillo es usar TDD para código nuevo aunque la solución sea vieja. Un poco más complejo es construir la infraestructura de pruebas en el código antiguo. Para eso utilizamos una serie de técnicas especiales para romper dependencias fuertes en el código. La referencia canónica para esto es el excelente libro de Michael Feathers, Working Effectively with Legacy Code.

Básicamente, mientras haces TDD para el código nuevo, vas necesitando desacoplar la parte del código viejo con el que hay que interactuar, y para eso hay que ir logrando desarmarlo e ir dejando algunas pruebas que nos ayuden en esa tarea.

Algo que si desaconsejo es generar proyectos de "refactorización pura". Cuando nos ponemos exquisitos en cuanto a la calidad del código sin tener en cuenta las necesidades reales de la organización o sus clientes, nos arriesgamos a entrar en un proyecto con objetivos poco claros. Mejor que eso es comprometernos a usar estas técnicas para mejorar el código relacionado con la funcionalidad que necesitamos modificar, y esa manera, con el pasar del tiempo, las partes del código que requieren más cambios (lo que de alguna manera demuestra que son más valiosas) irán mejorando y serán más fáciles de entender, probar y extender.

 

3- Algunas empresas no les agrada mucho el aplicar Pair Programming porque tienen la idea que es menos productivo y que así los programadores charlarán entre ellos y no programaron. ¿ Qué argumentos se pueden utilizar para cambiar esas ideas? Y Cómo hacer para que los programadores efectivamente no se pongan en ese plan (pudiera pasar)  

Lamentablemente todavía hay organizaciones que dejan pasar las oportunidades de mejorar porque se enfocan en que la gente (a a que suelen llamar recursos) cumple un horario haciendo lo que suponen que es su tarea.

Si pensamos que la tarea de un desarrollador de software es programar, y no hablar, casi seguro obtendremos como resultado código que hace lo que el programador interpreta de un documento, sin entender lo que hace, y sin preocuparse por que lo que hace agregue valor. Para un desarrollador en esas situaciones siempre recomiendo tratar de generar evidencias de que hay maneras mejores de trabajar, y en último lugar recuerdo siempre el dicho "si no puedes cambiar tu trabajo, cambia tu trabajo". No me parece bien tomarse livianamente la ida de que la organización "es así", porque en muchos casos vi gente desde las posiciones más humildes e inesperadas generar una ola de cambio. 

Un buen desarrollador tiene que charlar con el resto del equipo y buscar soluciones apropiadas a las necesidades planteadas, y debe lograr entender el contexto de negocio y aportar su visión. Si limitamos a los desarrolladores a programar lo que otros le indican sin nada más, llegaremos siempre a soluciones mediocres o pobres. De la misma manera, si el equipo no entiende y no está conectado con los problemas que tiene que resolver, su motivación será obviamente más baja, y eso no lo compensa trabajar de a pares o no. 

Al revés, si el equipo está conectado con el negocio, al trabajar de a pares encontrarán mejores soluciones que trabajando solos. El principal problema de trabajar solo para un desarrollador es la facilidad para perder el foco o bloquearse en detalles menores, cosas que casi no suceden al trabajar de a pares.

En resumen, para mi un argumento fundamental es si queremos "cantidad de código" o "buenas soluciones".

El Kyū-Dan de la Integración Continua

En algún momento del 2014, tuve una consulta de mi amigo Sebis Henzenn, que generó (estaba lejos y tenía un rato)  un mail con una explicación bastante larga de lo que se me ocurrió en ese momento como una metáfora aproximada de los pasos de aprendizaje respecto a prácticas relacionadas con Integración Continua y sus derivaciones.

El mensaje quedó guardado unos años, pero lo recordé recién hablando con otro amigo, Edson Chávez, de Kleer Perú, donde estoy en este momento.

Así que aquí va mi elucubración de esa vez, que no sufrió mucho cambios en el ínterin. Sólo aclararía que no es una categorización exhaustiva, sino un recorrido posible, que espero que le sirva a alguien para formular sus planes al respecto.

Aquí el texto original:

Mi recomendación es empezar por el build server, e ir evolucionando. Por ejemplo:

Cinturón blanco:
- instalás Team City (o Jenkins, o el que te guste -salvo TFS que yo no recomendaría).
- empezás haciendo que cada equipo aprenda a configurar su proyecto (es importante que sepan hacerlo ellos)
- lo básico es que en cada commit el proyecto compile, por lo menos
- que se acostumbren a no tener el proyecto en rojo NUNCA. Si queda en rojo, arreglarlo antes de seguir con nada.

Cinturón amarillo:
- pueden empezar a hacer tests (si no los hacen) y correrlos en el build en cada commit.
- de nuevo: nunca dejarlo en rojo, y aprovechar los arreglos para entender más lo que los demás están haciendo y nivelar la calidad de las pruebas.

Cinturón naranja:
- empezar a hacer TDD y ATDD, y elevar el número de pruebas
- seleccionar alguna manera de medir code coverage y hacer que el build falle si ni se alcanza el 1% (pruebas mínimas)
- cada tanto medir el coverage promedio de la solución e ir subiendo el límite casi hasta ahí (incrementalmente)
- cada vez que se reporta un incidente o bug (en testing o producción), no puede arreglarse si no se escribe la prueba primero que demuestra el problema, y se da por resuelto una vez que se corrige la aplicación para que pase ese test

Cinturón verde:
- empezar a ejecutar analizadores estáticos, y que el build server muestre el informe.
- concentrarse en los problemas más importantes; cuando ya no existen en la solución, hacer que rompan el build
- seguir con el problema más importante, y así sucesivamente; alcanza con eliminar un tema o dos por sprint

Cinturón azul:
- empezar a versionar junto al código migraciones de bases de datos, configuraciones y scripts de instalación de componentes o librerías
- hacer que si el build server compiló con éxito y ejecutó todas las pruebas y validaciones, genere desde cero un entorno nuevo de testing

Cinturón marrón:
- trabajar en conjunto con el equipo responsable de despliegue para que valide y adopte los scripts y métodos de generación de ambientes
- lograr que el build server genere en cada commit un ambiente de prueba desde cero, y otro incremental
- lograr que si se detecta un problema en el ambiente incremental, se pueda volver a la versión anterior de la aplicación con el script de reversión

Cinturón negro:
- cada vez que un desarrollador hace un commit que pasa todo el pipeline de pruebas y validaciones en csda uno de los ambientes de prueba, potencialmente puede llegar a producción de manera automática, aunque se opte por decidir manualmente el momento de despliegue
- trabajar en el diseño de la solución para que soporte el desplliegue sin interrupciones de servicio (hot deploy)

Cinturón rojo:
- cada vez que un desarrollador hace un commit, llega a producción sin interrupción de servicio

 

Cada uno de esos saltos puede llevar de 1 a 9 meses, dependiendo del equipo, el proyecto, y de dónde arrancar en cada parte, pero creo que te das una idea. :)

Untrusted: como perder una noche de sueño

Como a todo nerd, me pierden los desafíos de código. :)

Ya perturbé la salud mental de algunas amigas y amigos con Ruby Warrior, pero los amigos de JavaScript Jabber (un podcast sobre JS muy recomendable) me enviciaron con Untrusted, un juego para ir resolviendo pistas en JS, que además tiene un atractivo adicional y es que cada nivel tiene una musiquita sintética muy pegadiza.

Como suele ocurrir en estos casos, Untrusted tiene una pantalla dividida, en este caso con "el juego" a la izquierda, donde tenemos que buscar una salida, y el código a la derecha (el verdadero juego) donde tenemos que ir tocando el código en JS que arma ese nivel para poder superarlo. Lo divertido es que las soluciones son triviales en cuanto a código, pero exigen pensar como hackear la construcción del nivel para poder escaparse.

Si pierden muchas horas de sueño, ¡no digan que no les avisé!

Story Mapping en acción

En el artículo anterior hablamos del objetivo general del Story Mapping, cómo realizar la convocatoria y otras características generales. Como prometí, esta vez voy a entrar en mayor detalle en la mecánica de la construcción.

Aviso: después de facilitar muchos talleres con esta actividad uno desarrolla ideas y tácticas propias, así que es importante destacar que voy a describir la manera en que yo veo el Story Mapping, que puede no coincidir con la de otros. La mayor parte está tomada de Jeff Patton, pero hay agregados personales que surgen de mi aprendizaje continuo practicando esto, sobre todo en América Latina, que puede cambiar el contexto cultural.

Cúentame tu vida

El primer paso de esta actividad es charlar sobre el problema que queremos resolver, pidiendo a los involucrados que cuenten la historia detrás. Usualmente dejo que esta parte sea bastante libre, y a medida que ellos cuentan los detalles, voy anotando en papeles algunos detalles como personajes, acciones, lugares, etc.

Voy a dejar para más adelante el tema de personajes y técnicas específicas para usarlos en el contexto del diseño del producto, y por ahora vamos a concentrarnos en la historia de alto nivel. Como ejemplo, vamos a tomar el clásico sistema de ventas, porque creo que es algo bastante común para todos los que desarrollamos software, y aunque puede haber algunas diferencias menores entre países, es un dominio relativamente conocido y sencillo de entender.

Supongamos entonces que de la narración de los involucrados sobre cómo es el proceso, aprendemos que: "hay un cliente que llega y realiza un pedido, para lo que hay que buscar los productos en el depósito y preparar la entrega mientras se le realiza una factura, que debe pagar."

Podemos preguntar algunos detalles más, y finalmente aislamos ciertas actividades principales a partir de esa historia, y algunos detalles para cada una. No voy a entrar mucho en los detalles del ejemplo, que están elegidos para dar una idea del flujo. Podríamos terminar con una serie de actividades de primer orden y un segundo nivel de actividades como el que se ve aquí:

Algo que tratamos de mantener es que leyendo las notas de más arriba y agregando algunos conectores en el medio, podemos reconstruir la historia original: "llega un pedido, se busca en el inventario, se factura y luego se cobra".

La segunda línea agrega algunos detalles o partes de cada actividad principal. El Pedido, por ejemplo, tiene productos y condiciones, el Inventario requiere chequear si hay suficiente para un pedido, entregarlo, en algún punto requerirá reposición, etc.

El demonio está en los detalles

A partir de este "espinazo", podemos empezar a entrar en los detalles de cada una de esas secciones, hacia abajo, para entender el panorama completo. Eventualmente podemos llegar a algo como:

Como se ve, en un primer nivel tratamos de cubrir todas las características que creemos necesarias, sin importar todavía el orden o valor de cada una.

Entregas y esqueletos caminando

El siguiente paso es -ahora si- comenzar a priorizar. Lo que vamos a tratar de hacer es ver qué es lo imprescindible de cada columna para una primer entrega que sea valiosa, desde el punto de vista de habilitarnos a usar la solución y obtener algún resultado. Es probable que podamos incluso saltear alguna columnas para la primer entrega.

Y como un valor que buscamos siempre con estas técnicas es maximizar el aprendizaje, usualmente buscamos una entrega anterior a la primera "oficial", de carácter interno, que solemos llamar Walking Skeleton (esqueleto caminante), y que debería permitirnos verificar que cumplimos el circuito que queremos recorrer (la solución ya camina) aunque todavía no podríamos exponerlo al público (le falta carne).

Una vez que encontramos ese esqueleto posible, podemos avanzar, agregando lo mínimo indispensable para llegar a la primer entrega que haríamos a nuestro público. Obviamente, esto asume que cuando construyamos realmente el Walking Skeleton lo que aprendamos no nos haga replantear toda la situación. Si es de esperar que comprendamos mejor y tengamos que hacer algunos retoques a nuestro plan.

En la figura se ve un posible Walking Skeleton y una primer entrega (R1 o release 1):

Por supuesto podríamos discutir si en este ejemplo las características elegidas alcanzan o no, pero supongamos que entre todos los involucrados en el ejercicio de Story Mapping (responsables del negocio, roles operativos, gente de tecnología, procesos, etc) nos hemos puesto de acuerdo en que el esqueleto es suficiente para aprender lo que necesitamos y probar el circuito completo, y que agregando lo mínimo podemos tener una primer versión valiosa, que en este caso nos permitirá tomar pedidos para entregar en el momento, facturarlos y cobrar en efectivo y cheque (que por alguna razón es necesario para arrancar).

Como vemos, esta primer entrega es muchísimo más pequeña que lo el alcance total que imaginábamos, pero mediante este ejercicio encontramos qué es lo mínimo que nos permitirá empezar a usar la solución tempranamente, en una fracción de lo que involucraría construir toda la funcionalidad imaginada.

Este es un tema clave en el desarrollo ágil, y como vemos, el Story Map nos permite tener una visión global, para que el foco de corto plazo en el backlog de producto no nos haga perder de vista el objetivo final.

En uno o dos artículos más voy a profundizar en alternativas, el uso del Story Map a lo largo del proyecto y algunos consejos a la hora de facilitar la actividad. Por supuesto, si tienen consultas o comentarios, pueden avisarme a través de Twitter, idealmente con el hashtag #StoryMap. Nos vemos.

Story Mapping: de la Incepción hacia el Backlog de Producto

Tiempo atrás publiqué una serie de artículos sobre la práctica de Incepción Ágil que tuvieron bastante éxito y generaron varios comentarios y preguntas, entre otras, acerca de otra práctica relacionada, que a veces algunos incluyen como parte de la Incepción: User Story Mapping.

Esta técnica para analizar un proyecto (completo o un sub-proyecto) fue nombrada y documentada originalmente por Jeff Patton, primero en un artículo de su blog, y posteriormente en su libro "User Story Mapping" (pueden ver la tapa a la derecha), ambos inmensamente recomendables.

Conocí los detalles de esta práctica por primera vez alrededor de 2008 o 2009, y comencé a usarla en algunos proyectos míos o de organizaciones a las que estaba ayudando, y después de usarla al menos una docena de veces, comprendí mejor cómo aprovecharla y cómo facilitar su construcción, y se convirtió en una pieza clave para mi en el inicio de proyectos ágiles.

Lo que quiero hacer en este artículo es recorrer qué es un Story Map, cómo se genera, cómo se usa posteriormente y cuáles son sus beneficios. En algunos posteriores entraré en detalle sobre la mecánica de la reunión, las alternativas y conceptos subyacentes.

¿Cómo y cuándo?

Como en el caso de la Incepción Ágil, el Story Mapping se realiza al inicio de un proyecto, o una nueva fase, típicamente en formato taller. Algunas veces se realiza como parte final de la Incepción, aunque para mi es bueno entenderlo como momentos diferentes.

La Incepción trata de poner el foco en asegurar que todos los involucrados acuerdan un objetivo común, ciertas características y restricciones del producto, y deciden en conjunto qué van a construir.

Story Mapping es una actividad que nos permite entrar en detalle estratégico sobre cómo construirlo, entender qué es lo fundamental, poner foco en la entrega temprana y entender cómo ir incrementando el valor frecuentemente.

Lo que tienen en común ambas prácticas, que para mi son complementarias, es el tipo de convocatoria: en ambos casos queremos contar durante toda la actividad con gente de negocios a nivel directivo y a nivel operativo, operaciones, procesos, infraestructura, desarrollo, seguridad, etc. Queremos tener representados a la mayor cantidad posible de sectores involucrados en el proyecto del que vamos a hablar, para tener una perspectiva amplia.

También, como en el caso de la Incepción, más allá del entregable (el Story Map) lo más valioso son las conversaciones durante el ejercicio. No deja de sorprenderme al facilitar encuentros de este tipo en diferentes organizaciones (desde micro-emprendimientos hasta corporaciones) cómo surgen discusiones que nunca se habían tocado antes a pesar de estar trabajando en el tema en cuestión durante muchísimo tiempo.

Dependiendo de la complejidad y la importancia del proyecto, la actividad puede durar desde 2 o 3 horas, hasta un día completo. En proyectos críticos he facilitado frecuentemente un día completo de Incepción y otro día completo de Story Mapping.

Entre uno y otro puede pasar un tiempo, porque a veces la Incepción sirve para confirmar qué tipo de proyecto tenemos que realizar (cuanto más temprano la hagamos, mejor, porque tenemos menos cosas decididas de antemano), y podemos tomarnos un tiempo para tener identificado al equipo de trabajo y saber quiénes deberían estar presentes para construir el Story Map.

 

¿Qué queremos lograr?

En los próximos artículos voy a entrar en detalles, pero para cerrar éste, quiero mostrar el resultado final y explicar cuál es la expectativa.

 

La imagen muestra un mapa de un proyecto real. La imagen no tiene nitidez suficiente para leer lo que está escrito en las notas, que es algo específico y particular de este proyecto, pero que no importa para explicar el resultado.

Lo que se ve en la primer fila, en las notas celestes, como cabeceras de cada columna, son las Actividades Principales del proyecto, en el orden en que fluyen en "la historia" contada por los diferentes participantes de la actividad. Hacia abajo de cada Actividad hay Detalles sobre cómo se realiza esa actividad, en muchos casos como alternativas o pasos que pueden ser o no opcionales.

Las líneas azules que cortan transversalmente el mapa (en dos tajadas finas, inicialmente) son las Entregas planificadas, cada una con el mínimo de funcionalidad necesaria para cumplir con el propósito de la solución. Como puede notarse, esas dos primeras entregas son muy pequeñas respecto al total del alcance esperado (el conjunto total de notas debajo de los encabezados celestes). Sin embargo, las dos entregas planificadas concentran el más alto valor de negocio, porque destraban problemas importantes y habilitan nuevas posibilidades. Esto suele suceder en casi todos los proyectos, siguiendo la ley de Pareto: aproximadamente el 20% del alcance da el 80% del valor de negocio de un proyecto.

Utilizando esta práctica, que detallaré más en los próximos artículos, podemos buscar ese mítico 20% y tratar de concentrarnos en tener el más alto valor rápidamente, que además nos permitirá tener un producto real funcionando y poder aprender de la experiencia concreta antes de seguir agregando funcionalidad en abstracto.

Actualización: podés encontrar el siguiente artículo de esta serie aquí.

hack.summit() -> code(4).all

Este evento virtual es imperdible para cualquier nerd que se precie de tal.

Fue una conferencia totalmente en línea con celebridades del ambiente del desarrollo y alrededores, y todas las sesiones están grabadas para verlas cuando uno quiera.

Algunas de la personalidades que me resultan más interesantes (a mi) son:

• Kent Beck, el papá de XP y TDD
• Ward Cunningham, corresponsable de XP e inventor de la Wiki
• Rebecca Parssons, CTO de Thoughtworks
• Scott Hanselman, dando pelea desde dentro de Microsoft
• Bram Cohen, inventor de BitTorrent
• Gilad Bracha, co-autor de la spec de Java y creador de Newspeak
• Scott Chacon, CIO de Github
• Tim O'Reilly, de O'Reilly Media
• Orion Henry, fundador de Heroku

y unos cuantos más.

Espero que lo disfruten.

Incepción Ágil: la pregunta del millón

¡Llegamos a la última actividad de la Incepción!

¿Parece largo? En realidad muchas de las actividades pueden regularse para que avancen rápido ó podemos llegar a saltear algunas si tenemos menos tiempo. Eso es parte de la decisión del facilitador. Mi recomendación es tratar de recorrer las 10 actividades, aunque sea dedicándole 20 a 30 minutos en promedio a cada una, para que entre en una mañana o una tarde.

En la última actividad vamos a tratar de tener una estimación de MUY alto nivel sobre el costo del proyecto. Casi nunca llegamos a un número, sino a un nivel de inversión, como para responder dudas como (dependiendo del tipo de proyecto y organización):

• ¿Podemos encarar esto con el presupuesto que ya teníamos?
• ¿Necesitamos conseguir un inversor?
• ¿Qué chances hay de que el proyecto se auto-financie a partir de X entrega?
• ¿Hace falta conseguir aprobación presupuestaria del Gerente del Área? ¿Del Directorio?

Para poder llegar a alguna conclusión de ese tipo, lo que hacemos en grupos es una "lista de compras", en la que incluimos todos los costos importantes que pueden incidir, como:

• Costo del equipo (si son internos y tenemos que costearlos, o si debemos contratar)
• Equipamiento, espacio físico, licencias de software, suscripciones
• Homologaciones, certificación o auditorías necesarias
• Espacio físico o instalaciones necesarias durante el proyecto

Nuevamente, cada grupo presenta su lista, y se discute en conjunto hasta lograr una versión unificada. No es importante ponerle valores, más allá de una estimación muy gruesa para llegar a entender el nivel de presupuesto, pero esa lista será el punto de partida para empezar a elaborar el presupuesto definitivo cuando el proyecto arranque realmente.

Y con eso finalizamos el proceso de la Incepción. Dejo una foto de otro taller. 

Incepción Ágil: hablemos de prioridades

Como mencionamos antes, sabemos que nuestra Incepción va a darnos una idea general, pero que el proyecto va a ir mutando y adaptándose en el tiempo para lograr el mejor resultado posible.

Si embargo, podemos tratar de seleccionar algunas restricciones tempranas que nos ayuden a pensar si los cambios o novedades que aparezcan nos están alejando o no de la idea inicial. Y podremos en ese momento decidir que no es un problema, o incluso re-evaluar estas prioridades, pero lo bueno es tener más elementos para evaluar esas decisiones.

Para esta actividad los equipos se dividen en grupos nuevamente y piensan en una lista de requisitos no-funcionales o preocupaciones transversales al proyecto, como por ejemplo:

• Costo de operación del producto final
• Mantenibilidad
• Time-to-market (cuanto antes tengamos algo, mejor)
• Interoperabilidad
• Equipo propio (o local)
• Seguridad o Confidencialidad
• Tiempo de respuesta
• Cumplimiento de regulaciones
• Cobertura desde múltiples dispositivos

...o muchos otros, desde características de calidad, temas de mercado, cuestiones internas o lo que nos preocupe.

Lo importante es que cada grupo quede con los 5 a 10 temas que les parecen más importantes tener en cuenta.

El siguiente paso es priorizarlos. Para eso prefiero una variante que aprendí de Alan y Ariel, que es seleccionar entre todos los que queremos priorizar, y a continuación elegir un participante por cada uno de los atributos a priorizar, que se pone de pie con una hoja de papel en la mano con el nombre de ese atributo. Esas personas se ponen en fila, y el resto, mirándolos de lado, de manera de verlos a todos, va intercalando con ellos, haciendo que se muevan hacia adelante o atrás en la fila, hasta que llegamos a un acuerdo.

Idealmente, al llegar al orden final, tomamos una foto de todos sosteniendo su cartel bien visible.

Esta actividad es más divertida con ese componente físico, y tiene también el valor testimonial de la foto con mucha gente involucrada, que perdura y queda para el equipo de proyecto. Muchas veces al ver las personas que participaron en esa priorización el mensaje es reforzado.

Insisto: esas prioridades no son inamovibles, pero tenerlas como filtro nos permite tener las discusiones necesarias a tiempo, y nos da contexto.

Incepción Ágil: estimación global

Ahora que ya tenemos una idea general del alcance, el tipo de solución a construir, y los riesgos principales que anticipamos, podemos empezar a pensar qué tan grande será el proyecto.

Nuevamente dividimos equipos (recordemos que lo ideal es combinar gente diferente a lo largo de la Incepción) y cada grupo hace una estimación de alto nivel, teniendo en cuenta:

• ¿Cuánta gente necesitamos en el equipo? ¿Cómo debería estar compuesto?
• Si vamos a ejecutar con Scrum, podemos pensar quienes serían el Scrum Master y el Product Owner
• Dado ese equipo que imaginamos ¿Cuánto tiempo duraría el proyecto?

Aquí cabe una aclaración: el equipo final deberá revisar la estimación, pero como estamos pensando un proyecto ágil, lo importante es que sabemos que en el tiempo que pensemos no esperamos resolver necesariamente todo el alcance, si no lo más valioso del alcance, por lo que aceptamos que no sabemos el detalle total. Es importante que todos los participantes comprendan que no están tomando una decisión, sino realizando un ejercicio para analizar lo que el proyecto implica. 

• Podemos pensar alternativas de equipos y fases, e incluso alternativas de solución, para diferentes extensiones de proyecto.

Al finalizar, y una vez que cada grupo expuso su estimación, se discuten y seleccionan las mejores alternativas, para usarlas como referencia, y probablemente tomemos un márgen de unas a otras.

El objetivo que buscamos es tener un rango general:

• ¿será un solo equipo de 5~6 personas?
• ¿serán 4 equipos de 8~9?
• ¿podemos tener resultados en 6 semanas, 6 meses, 2 años?
• ¿tenemos una idea al menos general de qué es lo más valioso resolver en cada etapa?

Aunque suene insistente, esto nos sirve para discutir si el proyecto es viable o no según estos parámetros, y eventualmente revisar algunos de los ejercicios anteriores. Como esto es una Incepción Ágil, sabemos que todo va a tener variaciones cuando el proyecto comience, y sobre todo cuando se entreguen los primeros resultados y el proceso de aprendizaje se potencie.

Incepción Ágil: manejo de riesgos

Llegamos a la actividad de la Incepción donde nos dividimos en grupos y nos ponemos todos el sombrero negro, pensando en todo lo que puede salir mal.

Trataremos de discutir todo lo que potencialmente podría quitarnos el sueño durante el proyecto, desde todos los puntos de vista. La gente de tecnología aportará riesgos de conocimiento del equipo, de complejidad tecnológica, de requisitos difíciles por distintos temas; la gente de seguridad pensará en las vulnerabilidades, potenciales brechas, criticidad de datos; la gente de negocio analizará costos, oportunidades, dependencias con otras áreas, necesidad de flexibilidad; y así diferentes actores expondrán miedos respecto al inicio, desarrollo, puesta en marcha, ejecución, mantenimiento y evolución del proyecto.

Al finalizar, cada grupo comparte los resultados y volvemos a tener una discusión abierta en la que tratamos de consensuar cuáles son los principales problema potenciales, y anotamos algunas de las medidas con las que podríamos mitigarlos.

 

Incepción Ágil: ¿y entonces qué hacemos?

Esta actividad de la Incepción se puede realizar en grupos si tenemos gente con buena visión técnica como para ayudar en conceptualizar la solución a desarrollar.

Cuando digo "técnica" me refiero al punto de vista de lo que vamos a construir (si es un sistema, un arquitecto o líder técnico; si es de marketing o publicidad, un diseñador o experto en campañas; si es un proceso, alguien experto en ese área).

Si en la audiencia contamos con una sola persona con esas características, podemos realizar esta actividad todos juntos. La idea es que en grupo, y con la ayuda del experto, analizamos el tipo de solución a construir, a muy alto nivel.

Como la mayoría de los lectores de este blog están vinculados al software, tomemos un ejemplo de ese mundo, y supongamos que el equipo elabora un clásico diagrama de componentes, indicando que va a haber un servidor web, que hablará con una aplicación existente, que conecta con tales bases de datos e integra los servicios X, Y y Z...

Tal vez aparezcan detalles de seguridad, o se sugiera mover algo a una nube, o utilizar algún tipo de tecnología, y lo importante de exponerlo ante todos es que surjan dudas como:

• ¿Y eso funciona en un Iphone?
• No se si conviene conectar con Siebel... eso quiere decir que si el proyecto del CRM se demora, nosotros también
• Antes de poner esos datos en la nube, deberíamos consultar con legales ¿Podemos dejar eso en una base local y mover lo demás?
• Creo que en el proyecto ZYX ya resolvieron esa interconexión ¿podemos pedirles ayuda?

Como antes, no buscamos que este diagrama o visión sea definitiva. Queremos explicar algunos detalles de cómo sería el proyecto para que la gente de otras áreas, técnicas, de negocio o administrativas, vean de qué se trata y comenten cualquier problema o relación que no hayamos tenido en cuenta.

Incepción Ágil: dime con quién andas...

El siguiente paso en nuestra Incepción es trabajar sobre los diferentes involucrados en el proyecto, y su nivel de participación.

Para esto volvemos a dividir en grupos a la audiencia y dejamos que trabajen en establecer su propio mapa. Suelo usar círculos concéntricos y post-its, o pueden utilizar u vector u otra representación.

La idea es que cada grupo piense en los diferentes "stakeholders", ya sean individuos con nombre y apellido, roles, sectores o áreas de una organización, otras organizaciones, instituciones o dependencias gubernamentales.

De alguna manera lo que tratamos de manera es que tanto impacto tienen sobre el proyecto. Este mapa de influencias permitirá que pensemos cada cuánto tiempo el equipo de proyecto tendrá que tener contacto con estos actores, e incluso si necesita convocar a algunos de ellos para alguna actividad posterior a Incepción, pero también fundacional del proyecto, como un taller de Story Mapping (sobre lo que escribiré al terminar esta serie).

Como en los otros casos, al terminar revisamos los diferentes mapas y tratamos de consensuar el o los más representativos.

Recordemos que lo importante es participar activamente. Dejo otra foto de un taller donde estamos haciendo alguna de las actividades. Ese es el tipo de espacio que tratamos de crear (aunque no hace falta que haga frío).

Incepción Ágil: delimitando el alcance

La siguiente actividad en la Incepción es relativamente sencilla de realizar, pero suele generar más discusiones fundamentales, y tiene que ver con limitar ciertas decisiones respecto al alcance.

Como siempre, dividimos en grupos a los participantes, y en cada grupo generamos una lista de características ordenadas en tres grupos:

• Las cosas que definitivamente queremos dentro del alcance
• Las que estamos de acuerdo que quedan fuera
• Las cosas que no podemos decidir (al menos por ahora)

Como siempre, al presentar los resultados parciales de cada equipo aparecerán inconsistencias que resolver.

En general prefiero ir anotando los puntos de conflicto, en lugar de discutirlos en el momento, y seguir avanzando en la comparación. Una vez que comparamos todos los resultados, podemos recorrer la lista de los conflictos y tratar de zanjarlos.

Usualmente algunos de los puntos "indefinidos" para un grupo se logran definir por si o por no entre el resto, pero siempre pueden quedar algunos que específicamente quedarán a profundizar una vez que el proyecto arranque realmente. Lo bueno es que están identificados.

La lista resultante nos sirve de input para poder comenzar a construir el backlog cuando el proyecto comience, y la lista de las cosas que están fuera de alcance nos servirá a lo largo del proyecto como filtro de alerta cuando se quieran agregar cosas al backlog. Por supuesto, no implica un rechazo automático, pero si debería plantearse siempre una discusión al respecto.

Incepción Ágil: manos en la masa

Continuando con nuestra Incepción, en esta actividad vamos a ir más allá de la visión reducida del paso anterior, el Elevator Pitch, y comprobarlo usando una metáfora un poco más arriesgada, pero también mucho más divertida.

Usualmente para esta actividad consigo cajas en blanco, o cajas de un tamaño razonable (desde cereales hasta cajas de zapatos) y las cubro con papel blanco.

Nuevamente generamos grupos de trabajo (que idealmente pueden ir variando entre actividades para maximizar los cruces de opiniones) y le damos a cada uno una caja en blanco, marcadores y lápices de colores, papeles o post-its de colores, cintas, pegamento y otros materiales que sirvan para trabajar. Mis amigos Alan y Ariel suelen darle a la gente pegatinas o stickers con estrellas, animales, letras o cualquier otra cosa que puedan usar.

¿Cuál es el desafío?

Diseñar una caja que represente el proyecto que estamos encarando, como si fuese un producto de supermercado. La caja deberá ser atractiva, destacar las características principales sin apabullarnos, detallar en algún lado los componentes o características en más detalle, y más.

Entre otras cosas, usualmente este ejercicio hace que los equipos pongan un nombre al proyecto/producto, si no lo tiene.

Y es importante destacar que hacemos este ejercicio con portales web, sistemas de seguros, de salud, campañas de marketing, proyectos urbanos y montones de cosas que nada tienen que ver con un producto de consumo de masivo que se vende en caja. Estamos jugando con una metáfora.

¿Para que sirve, entonces? 

Desde mi punto de vista, como muchos de estos ejercicios, nos sacan de nuestra zona de comfort y nos exigen conceptualizar a un nivel diferente del que estamos acostumbrados, desatando más nuestra creatividad. A veces, la exageración aporta más visibilidad a ciertos temas y facilita la discusión.

Por otro lado, el hecho de trabajar en esta etapa temprana en una actividad muy manual, donde todos dibujan, recortan y pegan papeles, lleva a los grupos a un nivel de diversión y colaboración que cambia el tono de la reunión, reduciendo fronteras jerárquicas y de especialidades.

Al terminar sus cajas, como siempre dentro de un timebox (de 15 a 20 minutos), los equipos hacen una recorrida mirando las de los demás, y pueden votar por la más significativa, o dedicarle un rato a producir una con una versión conjunta.

Uno de los secretos de esta actividad es la cantidad de risas y entusiasmo que se genera. Es común que algunos grupos terminen trabajando en el suelo, o que se atrevan a utilizar el humor mucho más allá de otros espacios más formales.

Resultados a largo plazo

Aunque esta actividad parece tan inocente y lúdica, suele ser una de las que tiene enormes efectos a largo plazo.

Como facilitador, muchas veces no lo comento en el momento, pero lo verifico y aprovecho si tengo participación en el proyecto a largo plazo. Alguno efectos interesantes son:

• El nombre que inventan a veces para la caja se convierte en el nombre de código del proyecto. Así, por ejemplo, proyectos como el "nuevo servicio de atención para reclamos de siniestros", termina llamándose "Venecia" (por ejemplo).
• Una o varias de las cajas perduran y terminan colgadas o pegadas en el espacio del equipo. He escuchado comentarios de miembros del equipo explicándole a otra persona, con entusiasmo, por ejemplo: "¡y este dibujo de aquí lo hizo González, el Gerente de Canales!". Conexión del equipo con el negocio: altísima.
  
  
• Es común que los miembros de los equipos, al estar mezclados, hayan generado un lazo diferente en ese lapso tan breve, que les permite comunicarse entre ellos mucho más fácilmente durante el proyecto, porque comparten desde entonces un objetivo común que quedó plasmado en ensuciase juntos los dedos. 

 

Incepción Ágil: Visión de alto nivel

En el segundo paso de nuestra Incepción de Proyectos vamos a tratar de condensar la visión de cómo resolver el problema que nos convocó a muy alto nivel, pero entrando en algunos primeros detalles que podamos discutir abiertamente, y nos sirvan para seguir la conversación.

El "Elevator Pitch" es un término que viene del mundo del marketing de los años 60~70, y la idea es tener un argumento tan bien preparado y condensado, que pueda usarse para "vender" una idea a alguien al encontrarlo en el ascensor, aprovechando el escaso tiempo de un piso al otro.

Aunque es probable que en el caso de nuestro proyecto no necesitemos "vender" la idea más allá del grupo de la Incepción (o si, aún más tarde, cuando queremos enrolar a alguien más en el proyecto), utilizamos su estructura porque destaca una serie de elementos que nos resultan útiles discutir.

Nuevamente, es tarea del facilitador dividir a la audiencia en grupos de tres o cuatro personas, con papel y lápiz, para crear diferentes versiones del "Elevator Pitch" dentro de un time box de 5~10 minutos, que después presentaremos y discutiremos entre todos.

Una ayuda es mostrar un modelo posible, sobre todo para resaltar los componentes que buscamos incluir:

Para [ cliente | público ]
que tiene [ necesidad | oportunidad ]
[ nombre producto ] es un [ tipo de producto ]
que [ beneficio | razón de compra] 
A diferencia de [ principal competidor | alternativa ]
nuestro producto [ diferencial competitivo ]

Como se ve, todavía tiene muchos elementos de marketing, pero los elementos están ahí. Si se trata de un proyecto de desarrollo, podemos pensar quién es nuestra audiencia principal, su necesidad, que categoría de solución vamos a darle, cuál será el principal beneficio, cómo se diferencia de lo que se utiliza actualmente o alternativas que ya existan en el mercado, y así.

Suelo resaltar que no queremos listas de características.Es importante que podamos leer el resultado en 20 a 30 segundos. Los detalles vendrán después. Queremos por ahora sólo lo más importante.

Esta actividad finaliza con la discusión abierta y una reelaboración de la que obtenemos una sola frase consolidada, o unas pocas alternativas principales.

Dejo nuevamente un ejemplo pequeño del taller en al Tech Meetup de Montevideo.

Incepción Ágil: foco

La primer actividad que realizo en un taller de Incepción es una ronda en la cada uno se presenta y comenta para qué cree que está en el taller.

Como en general, el facilitador debería mantener el timebox, es decir, aclarar que cada uno tiene un tiempo acotado (en este caso podría ser uno o dos minutos por persona), y tratar de ser claro en lo que esperamos de cada participante, por ejemplo:

• Nuestro nombre y perfil (rol, área ó especialidad)
• Quién nos convocó
• Lo que creemos que podemos aportar en esta reunión

Al terminar la ronda, podemos hacer que cada uno escriba brevemente en un post-it cuál cree que es el objetivo principal de la Incepción: ¿qué problema queremos resolver?

Nuevamente ponemos un timebox de 2 a 3 minutos, y después pegamos todo en una hoja, agrupamos los que son iguales o similares, y discutimos brevemente las ideas que son muy disimiles.

El objetivo central es que lleguemos a tener claro entre todos el problema que queremos resolver, sin que nadie venga y "se lo comunique" al resto. Queremos que surjan las inconsistencias o diferencias de nivel de abstracción que haya entre los asistentes.

Otro tema importante: si entre la ronda y la definición final del foco descubrimos que alguno de los participantes probablemente no tenga mucho que aportar, ni le podamos aportar el resto, lo liberamos, agradeciéndole haber venido, y manteniendo un contacto por si descubriésemos que hay algún tema puntual para consultarle. Esto es algo que debe manejar el facilitador para que suceda sin conflictos. No queremos que nadie sienta que su participación "no tiene valor" per se, pero tampoco queremos que haya asistentes que no estén realmente involucrados con el foco de esta Incepción.

Incepción Ágil: ¿a los backlogs los trae la cigüeña?

Tanto en el caso de Scrum como XP u otros frameworks ágiles, nos basamos en una lista priorizada de items a implementar. El nombre más común para esta lista es el que se usa en Scrum, que es Product Backlog, o Backlog a secas.

Sacando de lado que los items del Backlog sean historias de usuario, casos de uso, o un híbrido de cualquier tipo, usualmente no está claramente detallado de dónde sale al menos la versión inicial que luego irá evolucionando a través de las iteraciones.

Por otro lado, siempre aparece la duda de cómo podemos hacer dentro del paradigma ágil para mantener la flexibilidad y postergar todo lo posible las decisiones duras respecto al producto, aprovechando a nuestro favor el aprendizaje continuo, pero sin perder de vista la visión general o el objetivo al que queremos llegar.

Una de las prácticas más populares en los últimos años en la comunidad ágil para generar esta visión común y comenzar a definir el backlog, es la Incepción Ágil, documentada inicialmente por Jonathan Rasmusson, alias Agile Warrior, en su libro The Agile Samurai y en su blog.

En este post inicio una serie en la que voy a intentar recorrer cada una de las 10 actividades que yo realizo al facilitar esta actividad, describiendo la manera en que yo (particularmente, y posiblemente a diferencia de otra gente) los oriento, y qué es lo que trato de generar.

¿Cuándo y cómo se realiza una Incepción Ágil?

Para empezar, el formato que recomiendo para esto es el de un taller colaborativo, y el foco es que estén presentes (y en un mismo lugar físico) todas las personas fuertemente involucradas en el problema a discutir (ya que tal vez no esté claro si se convertirá en un proyecto, varios, o nada). 

Lo ideal es lograr un buen nivel de compromiso desde los patrocinadores principales del proyecto potencial, o las personas que tienen responsabilidad sobre el problema que queremos resolver. Esto es importante para poder convocar también a la gente que conoce el problema (tal vez desde un punto más operativo), otros relacionados fuertemente (sectores o áreas relacionadas) o los que estarán potencialmente involucrados en la implementación o soporte (por ejemplo, gente de tecnología, desarrollo, diseño).

Por otro lado, suele ser clave el rol del facilitador del taller, que debe entender bien el formato general y las actividades individuales, poder moderar discusiones que se desborden, mantener el ritmo de la reunión, asistir las necesidades de los equipos, y otras tareas generales. En organizaciones donde ya hay gente que actúa como Scrum Master o Coach ágil, ellos suelen ser los más indicados. Pero también se puede contar con algún entusiasta que idealmente haya participado en una Incepción previa.

La duración también depende del nivel de importancia del proyecto/problema que vamos a tratar. Puede variar entre medio día y dos días completos.

En la práctica he facilitado Incepciones desde medio día con menos de 10 personas, hasta un día y medio con casi 20. No hay una regla muy específica a aplicar, y creo que cada organización y contexto debe encontrar su punto. Yo prefiero reservar más tiempo del esperado, y terminar antes, a quedarse "corto" y que los participantes se dispersen sin haber terminado.

El estilo de la reunión

Algo que para mi es fundamental es el estilo que le damos a este evento. Yo prefiero contar con un espacio abierto para poder moverse, algunas mesas para trabajar en grupos de 4 o 5 personas, y sobre todo muchas paredes para poder ir pegando resultados de las actividades. La mayor parte del tiempo lo que se va generando son  láminas con diferentes visiones del problema/proyecto, usando colores, tijeras, materiales varios, y en general un tipo entrañables livianos, poco formales, y que requieren trabajo manual.

Parte del secreto es que al trabajar con las manos y haciendo dibujos o armando cosas con las manos, generamos un ambiente en el que las jerarquías tienden a borrarse, generando mayor participación y una discusión más abierta, que al contrario de la formalidad excesiva, tiende a sacar a la luz mucho más fácil, pero sin tanto riesgo, montones de temas críticos.

Quedan debajo un par de fotos de un taller en el que practicamos esta técnica en el reciente Tech Meetup en Montevideo, para que tengan una idea del tipo de cosas que tenemos al terminar (teniendo en cuenta que en esta caso trabajamos sobre un proyecto ficticio, y en un tiempo acotado de 90 minutos).

Para los que quieran seguir la serie de artículos, todos los artículos están bajo el tag inception, o pueden utilizar esta guía:

1. ¿Para qué estamos acá?
2. Elevator Pitch
3. Vision Box
4. Qué si, qué no
5. La comunidad
6. La solución
7. Los miedos
8. Tamaño
9. Trade-Off
10. ¿Cuánto cuesta?