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?