El problema con las estimaciones no son las estimaciones

Captura de pantalla 2016-06-15 a las 6.35.01 p.m.

“La propia palabra ‘estimación’ deja en claro que no calculamos un valor exacto, determinístico. De hecho, toda estimación tiene supuestos, y estos supuestos suman incertidumbres.” – Carlos Fontela, Estimaciones y Estadística, CyS Ingeniería de Software (2007)

Hola! Por favor permítame expresar mi opinión con respecto al tema de las estimaciones, y #NoEstimaciones. El problema con las estimaciones no son las estimaciones. Las estimaciones son sólo eso, aproximaciones sobre la magnitud de algo. No son valores determinísticos que buscan exactitud sobre el sujeto de la estimación. Bajo este contexto, no existen “estimaciones equivocadas”.

El problema con las estimaciones (Estimates) -sobre todo en el ámbito del desarrollo de software- es que se usan como fechas de finalización de los proyectos (deadlines), sobre las cuales se asocian costos y se asignan equipos para lograr cumplir un alcance que por naturaleza es variable, en un entorno complejo completamente alterable en función de los cientos de factores que provienen de la misma naturaleza del desarrollo de software y de la naturaleza de lo que queremos construir. Complejidad.

Sin embargo, el proceso de estimación (Estimating) desde mi punto de vista es útil. Y aquí hago una pequeña pausa para resaltar la diferencia entre Estimating (la dinámica de estimación) y Estimates (los valores resultantes de la dinámica de estimación). Quizás tengamos un problema en castellano, ya que ambas tienden a traducirse como lo mismo: “estimación” o “estimaciones”.

Desde mi punto de vista, el proceso de estimación es un ejercicio de entendimiento compartido durante el cual los participantes descubren y discuten aspectos que les permite comprender en mayor medida los desafíos de la construcción de lo que estén estimando. Por ejemplo -muy popular dentro del contexto Scrum-, cuando Usted observa a los equipos en una dinámica de Planning Poker, lo valioso es la discusión que se genera frente a la percepción de la complejidad de la cosa a construir y no por el número en sí mismo. Las estimaciones (estimates) pueden ser útiles o no, más el proceso de estimación es valioso.

“Una buena estimación es aquella que provee una visión de la realidad del proyecto suficientemente clara como para permitir a un equipo decidir correctamente cómo controlar el proyecto de modo tal de cumplir sus objetivos”. – Steve McConnell, Software Estimation: Demystifying the Black Art

Las estimaciones (Estimates) pueden ser expresadas en la unidad que el equipo acuerde: pueden ser horas, pueden ser puntos de historia o pueden ser bananas. Más adelante veremos cuántas bananas nos comimos en una unidad de tiempo. Son simplemente etiquetas de equipo que nos facilitan el proceso mental de comprender qué significa una banana.

El verdadero problema es enfrentar la necesidad de “predictibilidad”

Imagine que Usted llega a la cola en una oficina de su banco (a veces es necesario ir allí hasta que tengamos una banca totalmente digital). Entonces Usted llega a la cola y puede apreciar que hay varias personas antes que Usted. En ese momento le llama su esposa y le pregunta: “¿En qué tiempo te desocupas? Mira que tenemos que ir a donde mi mamá.”; Usted responde: “Okay amor, en esto momento no puedo hablar porque estoy en el Banco, pero ya te escribo por Whatsapp o algo.”

Cuelga y se dice a así mismo: “Vamos; soy ingeniero, trabajo en proyectos, también sé algo de ágil…esto no debería ser un reto para mí…” y comienza. Recordará sus años de Teoría de Colas y dirá: “Ley de Little!!…claro”. El tiempo promedio de espera en la cola es igual al número promedio de personas en la cola dividido para el tiempo promedio de atención. Ya está! Cuenta: hay 20 personas antes que Usted, toma el tiempo desde que una persona llega a la caja hasta que sale (digamos 3 minutos) y listo, matemática simple: 20 personas + Usted (21 personas) / (1 persona cada 3 minutos) = 63 minutos, aproximadamente.

Pero espere, antes de que escriba a su esposa por la respuesta recuerde algo; el señor Little decía antes: “En un sistema estable el tiempo promedio de espera es….blah, blah.”. Un sistema estable, ¿qué significa? Serían 63 minutos si todas las personas realizarían el mismo tipo de transacción exactamente, y que la persona en la caja se demore exactamente ese tiempo de atención por cada transacción sin cansarse. Además, pasan cosas: “se fue el sistema!” (muy típico al menos en mi país), es el descanso de la persona en la caja, lo reemplaza otra persona que está aprendiendo a usar el sistema, una persona se cuela por la parte de adelante, se va la energía eléctrica, habilitan una nueva caja, etcétera.

En otras palabras: Variabilidad. Variabilidad interna y externa al sistema. Estos y otros posibles cientos de factores que influyen en el comportamiento general del sistema. Con los equipos ágiles es muy similar, la diferencia es que estos factores pueden ser muchos pero en verdad muchos más.

Imagine que el siguiente gráfico representa la Velocidad de un equipo ágil en el tiempo:

Captura de pantalla 2016-06-15 a las 6.14.54 p.m.

Fíjese que en los primeros sprints la distancia entre su mejor velocidad histórica (la línea superior del rango) y su peor velocidad histórica (la línea inferior del rango) es más ancha; y a medida que el equipo corre sprints, esta distancia tiende a estrecharse. Esto es gracias a varios motivos, pero obviemos eso por ahora. Estamos tranquilos allí en la oficina y nos hacen la pregunta típica: ¿y en cuánto tiempo estará la feature X si trabajamos con el Equipo 1? Vale, hagamos el ejercicio de proyección:

Captura de pantalla 2016-06-15 a las 6.23.03 p.m.

En función de su desempeño histórico, podemos deducir un rango de fechas en el que equipo puede entregar la feature: entre la fecha X y Z; y podemos contemplar escenarios: en un mejor escenario la fecha X, en un escenario esperado la fecha Y, y en un escenario pesimista la fecha Z. El rango de fechas será más grande mientras más temprano en el tiempo tome su desempeño para proyectar (más alta es la varianza). Entre más estrecho el rango, la probabilidad de entrega es mejor.

Pero no se olvide, complejidad y variabilidad: ¿este equipo conoce el dominio y las tecnologías de implementación?, ¿ha trabajado antes sobre esto?, te comento que la mitad del equipo se va de vacaciones por esa época, etcétera. Variabilidad externa e interna. No hay ciencia exacta.

Entonces, ¿qué le decimos a la esposa?: “Amor, ve avanzando…allá te veo.” 🙂

¿Quiere ser predecible? Reduzca la variabilidad

Hay que reconocerlo: no se puede ser predecible en contextos complejos y sujetos a variabilidad como el desarrollo de software; entre más complejo el sistema y más elementos que añadan variabilidad menos preciso seremos. Es la realidad.

Si queremos lograr un mejor nivel de predictibilidad debemos trabajar sobre la variabilidad. La variabilidad interna (al alcance del equipo):

  • Reducir el batch size (reduzca el tamaño de los ítems de trabajo o Historias)
  • Revise el tamaño de la cola (ítems en el backlog)
  • Clasifique el trabajo (tipos de ítems de trabajo)
  • Establezca restricciones WIP (en cuántos ítems podemos trabajar en función de nuestra capacidad)
  • Enfocarse en generar flujo
  • Identificar cuellos de botella y supeditar el flujo a las restricciones
  • Equipo cohesionado trabajando junto durante un tiempo, no lo desarme
  • Otros.

La variabilidad externa (más difícil y a veces fuera del alcance del equipo):

  • Evitar distracciones organizacionales
  • Evitar multi-tasking o trabajar en varios proyectos al mismo tiempo
  • Contar con ceremonias de sincronización y alineamiento
  • Mucho feedback con Clientes y Stakeholders, entre otros.

Y nada, las cosas pasan…no se puede contener todo y no sabemos lo que sucederá hasta que pasa.

Con respecto a #NoEstimates

#NoEstimates es una perspectiva -y movimiento- que se enfoca en medir la entrega real de valor, por sobre obtener “medidas” a piori para saber cuánto trabajo se puede realizar y en qué tiempo. Es decir, en lugar de ponernos a obtener estas medidas (estimates), mejor hagamos el trabajo, entreguemos y luego sabremos realmente cuánto hicimos. En este contexto, las estimaciones (estimates) son desperdicio (“waste” desde el punto de vista Lean). De acuerdo, como mencioné: el número en sí mismo no es lo importante; más no así el proceso de estimación. Para #NoEstimates tanto el proceso y el resultados son desperdicio; yo simplemente discrepo con respecto al proceso. El proceso de estimación -independientemente del número obtenido- puede ser valioso para los equipos.

Pensamientos finales

A modo de resumen:

  • Las estimaciones (Estimates) pueden ser útiles, pero es mucho más útil contar con la información histórica de entrega real.
  • El proceso de estimación es un proceso de entendimiento compartido, ayuda a comprender la magnitud del problema, identificar riesgos y llegar a consensos.
  • El problema no son las estimaciones, es problema es enfrentar la necesidad de predictibilidad.
  • Los sistemas complejos poseen variabilidad, a mayor variabilidad peor predictibilidad. Nunca será 100% predecible, abrace la variabilidad.
  • Si desea ser predecible -en la medida de lo que eso signifique- entienda y trabaje con la variabilidad interna y externa.
  • #NoEstimates en un enfoque hacia medir el valor real logrado en lugar de obtener cosas medidas a priori, no podría estar más de acuerdo.
  • Nunca deje esperando a su esposa…o a su suegra 🙂

 

Gracias por leer y por sus comentarios.

Johnny

Referencias

Anuncios

Ecos del Scrum Coaching Retreat Latinoamérica 2016

13147521_10155371117948084_7847866123802406753_o

Durante el fin de semana anterior tuve el privilegio de participar del Scrum Coaching Retreat Latin-American 2016 que se llevó a cabo en Cartagena de Indias, en el que un grupo de apasionados Agile Coaches de México, Costa Rica, Panamá, Venezuela, Colombia, Ecuador, Chile y Argentina; nos juntamos para aprender y compartir, en busca de continuar creciendo como mejores Coaches. Fue un tiempo fantástico de discusión, aportes, risas y descubrimiento personal junto al mar.

Al ser la primera vez que participaba, tenía mucha expectativa sobre el formato y sobre el objetivo general. Tras la bienvenida del Equipo organizador, arrancamos con una primera dinámica muy divertida facilitada por Luis Mulato, en verdad no sé si tenga nombre; pero tenías que construir una casa junto con un compañero, donde un tercero se albergaría, a la voz de “¡terremoto!!” se tendría que reconstruir casas con otro compañero y albergar a una persona diferente. Linda dinámica, muchas risas; excelente para romper el hielo.

13174076_10155371114323084_5573825229406206359_n

Después una presentación cruzada entre nosotros, para conocernos y saber de dónde veníamos. A continuación, la siguiente dinámica facilitada por el Hada de la Facilitación Gráfica, Claudia Sandoval; el Café del Mundo (World Coffee). Primicia para mí, no lo había escuchado antes, estaba emocionado. Claudia nos llevó en un viaje de reflexión y de propuesta a través de varias preguntas poderosas; que poco a poco me fueron aclarando sobre el propósito de las actividades que vendrían, básicamente: “¿Cómo podemos ayudar a los Coaches Ágiles de la Comunidad Latinoamericana en los desafíos de su labor y al mismo tiempo ayudarnos en ser mejores coaches?”. Me conmovió y me enganchó.

Luego de esta concientización, comenzamos con un Market Place de aquellos tópicos que quisiéramos abordar para ayudar a los Coaches Ágiles tomando en cuenta los desafíos a los cuáles nos estamos enfrentando y hacia dónde está yendo la Agilidad.

Fruto del agrupamiento, las ideas convergieron en cuatro grandes temas y al mismo tiempo en 4 grandes propósitos, donde cada uno sería abordado por un equipo. Así que nos nombramos, creamos nuestra identidad y arrancamos nuestros sprints. Los nombres de los equipos me parecieron sensacionales, comenzaba la aventura.

Yo estaba en el grupo Agile Inc. (cualquier parecido con Monsters Inc. es pura coincidencia 🙂 ). Bajo nuestra responsabilidad: el brindar herramientas a los Agile Coaches para lograr convencer a altos Ejecutivos sobre los beneficios de la Agilidad e involucrarlos activamente en procesos de transformación. Debo reconocer que en nuestro equipo se respiraba mucho amor:

thumb_IMG_7665_1024

Arrancamos. Como era de esperarse, al final del Sprint deberíamos mostrar a los Stakeholders y al resto de los equipos nuestro progreso (Review plenaria) y tendríamos nuestra Retrospectiva individual por equipo. Durante el sprint noté algo interesante y que el gran Ricardo Colusso mencionara al iniciar; estábamos teniendo los problemas y comportamientos que tienen los equipos de desarrollo a los que nosotros acompañamos. Vivíamos las etapas de formación de un equipo y los desafíos que eso conlleva.

Lo que pasaría después me asombraría en una magnitud tal que me costaba creer que lo que estaba viendo haya sido concebido en el tiempo de un sprint. Totalmente sorprendido por la calidad, profundidad y conocimiento demostrados en los productos de cada equipo; de altísimo nivel, impecables, totalmente aplicables y útiles para muchos contextos. El poder de co-creación del grupo no tenía límites. Gratamente sorprendido.

El aporte a la Comunidad Latinoamericana

Nada resume mejor lo logrado en este evento que la siguiente imagen creada por Claudia:

Nuestro aporte a la Comunidad

Brevemente:

Agile Yoda: aportan un lienzo y más herramientas de colaboración en una caja de herramientas para el desarrollo de las competencias de un Agile Coach; enfocado en dos sentidos: el SER y el HACER. Lo que me encantó en este equipo fue que abordaron el lado “soft” que debe desarrollar un coach para su labor, el SER. Me conecté mucho con el trabajo de este equipo.

Ágil Cultores: aportan un framework para medir el nivel de Agilidad dentro una Cultura, basado en el modelo de Schneider; y al mismo tiempo proponer técnicas o herramientas al Coach para guiarlo en cada caso. Me encantó que su enfoque estaba basado en la premisa de que en cualquier tipo de cultura -incluso las más dura de Control- puede existir Agilidad, y que hay potenciarla o mantenerla. Como yo lo veo, este trabajo tiene una potencialidad de poder llevarse a todo el mundo, seguramente asistiré a charlas donde se hablará de este framework.

Agile Inc.: aportamos con el Agile Enterprise Coaching Toolkit Journey, una guía para el Coach ágil que desea llegar a altos Ejecutivos con los argumentos apropiados, en cada etapa existe un grupo de herramientas que pueden usar para prepararse antes o durante de una etapa adecuada. Me gustó mucho el enfoque que tomamos dentro el grupo de hacer empatía con el Directivo de Alto nivel, y modular nuestro lenguaje para ser asertivos; me gustó las discusiones que generamos y cómo complementamos nuestras experiencias empresariales. A partir de mañana, este journey es mi mejor amigo en mi labor del día a día.

Homo Sapiens Sapiens: aportan el Sapiens Sapiens Agile Learning Framework, además de lo fantástico del nombre, esta herramienta propone nuevos niveles y jornadas para lograr aprendizaje de forma efectiva y ágil. Me encantó que posee y demuestra sólidas bases científicas sobre cómo aprendemos los seres humanos, desde el punto de vista de funcionamiento del cerebro, motivación intrínseca basada en el trabajo de Daniel Pink, escenarios para el mejor aprendizaje; es muy visual y basada en tarjetas, es genial….casi un trabajo de doctorado!

Todos los recursos son accesibles aquí. Mi invitación a revisarlos, usarlos y entregar feeback hacia los equipos -y por supuesto sumarse; la idea es que el trabajo pueda evolucionar y refinarse.

Aquí y aquí podrán ver algunas las fotos del evento.

El Cierre

Durante la tarde del tercer día llevamos a cabo un Open Space algo diferente gracias a nuestros compañeros Homo Sapiens Sapiens; quienes la “hackearon” en buena manera para mostrarnos nuevos enfoques de aprendizaje, como bien lo mencionaron: “aprender a aprender”. Armamos varios tracks donde se propusieron temas muy actuales y de atención para coaches ágiles: el uso de Story Telling para influenciar la Cultura, Learning 3.0, escalamiento ágil con SAFe, siguientes pasos en la maduración de los productos generados, Soft Skills para Agile Coaches, entre otros. En este último participamos haciendo juegos de roles, simulando escenarios difíciles a los que se enfrenta un coach y jugando para intentar resolverlos; actuamos un poco y fue una gran experiencia. Recordé que sin importar lo que digan los libros, una cosa es leerlo y otra es vivirlo. Nada fácil ah! Muy divertido y altamente retador.

Lo más lindo del cierre fue hacer “hakas” entre nosotros. Nos creíamos jugadores de rugby antes del partido (estoy con una sonrisa gigante en mi rostro mientras escribo esta parte). Gritamos, hicimos coreografías y demás. En verdad que sentimos de corazón la identidad que generamos durante todo el evento, una relación de integración y colaboración que seguirá por mucho tiempo.

¡Muchas gracias a todos!

WhatsApp-Image-20160509

En lo personal fue una experiencia formidable. Muchos amigos apasionados con la Agilidad y su propósito de llevar bienestar a los equipos y organizaciones. Mucho talento y nuevo conocimiento. Y una introspección personal que me ayuda a reafirmar el rumbo de mi carrera. Muy enriquecedor desde el punto de vista profesional y personal.

Quiero agradecer profundamente al equipo organizador formado por: Lucho Salazar (el Ministro), Ricardo Colusso (El Sensei), Luis Mulato (El Dinamizador), Claudia Sandoval (el Hada de la Facilitación gráfica), Juan Daza (El Señor de los Medios) y Neider Tapia (El Guía). Quiero agradecer a mi equipo Agile Inc.: Víctor, Pedro, Wilmar, Rose, Linette, Andrés, Cris; el espíritu de equipo se mantendrá por mucho tiempo más. Y a todos los asistentes, por sus aportes y argumentos, por las sonrisas, por las cervezas y por ayudarme a crecer.

13040938_10155371123673084_7689850903519929114_o

Gracias, un abrazo gente!!

Johnny

3 razones del por qué sin Agile Testing no está siendo Agile

3_stones_on_wood

Con relativa frecuencia -más de la que me gustaría- observo como las compañías y sus equipos adoptan Scrum para el desarrollo de software excluyendo deliberadamente a las personas de pruebas dentro de los equipos. Ellos consideran aún que el “desarrollo” significa únicamente codificación, manteniendo a las personas de testing alejadas del equipo, sin participar en las ceremonias e incluso en ubicaciones distantes físicamente. Cuando les pregunto sobre las pruebas funcionales durante el sprint, normalmente me responden: “Es que hacemos TDD…las pruebas funcionales las hacen al final y nos reportan los bugs en el sistema de tracking de incidencias.”

Lo que se puede observar es que se conserva el paradigma de que las pruebas es algo que viene después, realizado por un grupo de personas que está más allá, que es responsabilidad de alguien más; y no existe nada más alejado de la Agilidad verdadera.

Ahora quiero sintetizar en tres razones la importancia de comprender y asumir la disciplina de Testing y cómo ésta se evidencia en Agile:

1. Muchas de las promesas de Agile provienen del Agile Testing y de la automatización

El desarrollo ágil habla de mejorar el Time to Market, de aumentar la calidad, de incrementar la productividad y predictibilidad, y mejorar la motivación. Pues bien amigos, les aseguro: mucho de estas promesas provienen del ejercicio consciente del Agile Testing dentro de los equipos, más un nivel decente de automatización de pruebas e integración continua; todo esto en camino hacia habilitar Continuous Delivery. Agile no es magia, sigue siendo software que debe ser diseñado, construido y probado; el cambio está en el enfoque colaborativo y de integración en lapsos cortos a través de un equipo que combina sus disciplinas; es lo que marca la diferencia.

Imaginen el escenario donde se codifican historias en un sprint y luego al final le dan a un Tester o equipo de Testing que las prueben. Probablemente se encontrarán errores que serán reportados y corregidos por los equipos durante el sprint que corre. Al final del segundo sprint la persona o equipo de Testing deberá verificar la corrección de los bugs anteriores más la revisión de las historias del nuevo sprint; y no sólo eso; sino hacer una regresión de los flujos de negocio más importantes que involucra también historias del primer sprint. Ahora imaginen este ritmo para el tercer, cuarto, quinto sprint. Es una bola de nieve, y esto es grave. Las personas de Testing estarán con trabajo acumulado que supera su capacidad, la presión hace que reduzca el ámbito de pruebas y que minimice sus casos tomando en cuenta lo que considera más urgente y no lo más importante, la calidad de los casos de prueba disminuye, los managers estarán encima de ellos porque se evidenciará retrasos al no tener historias probadas; la motivación de este equipo estará por lo suelos. ¿Y los developers, pueden ayudar? No, están ocupados haciendo más historias 😦

Okay, esto no es Ágil. Son como cascaditas más pequeñas, nada cambió a excepción a que ahora generamos más código basura en sprints. Recuerdan aquel principio que dice:

“Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.”

– Principios del Desarrollo de Software Ágil, Manifiesto Ágil

2. Las personas de pruebas no son ciudadanos de segunda clase, son profesionales talentosos

Existe una percepción generalizada en la industria de que los testers son un tipo de profesionales de segunda clase, que no son tan importantes o necesarios o geniales como los desarrolladores, tienen salarios menores, hay una proporción mínima de testers en las empresas comparados con los desarrolladores, hay muy pocas capacitaciones -incluso en la Agilidad- y normalmente están en una sala aparte donde su trabajo se reduce a encontrar bugs. Recuerdo alguna vez que estaba con un equipo de gerentes trabajando en la planificación de un proyecto y decían: “Necesitamos aproximadamente unos 50 developers.”, “Okay ¿y los testers?”, “con dos juniors ya tenemos!”. La disciplina en sí mismo está desvalorizada. Agile es contrario a todo esto, no puede seguir pasando. De hecho, cuando en las organizaciones veo este tipo de escenarios, son para mí olores de que su nivel de Agilidad está lejos de ser verdadero a pesar del uso de Scrum o cualquier framework.

Pues bien, la verdad es que sin nuestros amigos testers no podemos tener buen software ni software de valor. El testing de software es para mí una disciplina que requiere talento, preparación continua y un mindset diferente al de los desarrolladores para diseñar estrategias de mejor cobertura funcional y mejorar el diseño mismo del software. Las empresas y los equipos deben darse cuenta de lo trascendental de este rol.

3. Agile Testing es igual a colaboración

El Agile Testing es el pegamento entre las expectativas de negocio y la construcción. El tester es parte del equipo y es un puente de colaboración y comunicación entre el Product Owner, Stakeholders y developers más gente de operaciones, quienes codifican y mantienen los requerimientos para satisfacer esas necesidades.

Por ejemplo, el Tester trabaja junto con el PO y le apoya en:

  • Mejor comprensión de las necesidades
  • La preparación y revisión de historias
  • La definición de Criterios de Aceptación (a partir de los cuales se pueden generar Escenarios de Prueba)
  • Mejor entendimiento del Dominio de Negocio
  • Identificar dependencias entre Historias

El Tester trabaja junto con los Developers y les apoya en:

  • La definición estrategias de prueba para las historias
  • Apoya en la automatización de pruebas funcionales (ATDD)
  • Detecta y notifica bugs
  • Entrega feedback temprano de las historias
  • Sugiere mejoras funcionales y de usabilidad

Por su lado, el Tester trabaja en:

  • Preparación de la estrategia de pruebas del sprint
  • Preparación y mantenimiento del Ambiente de Pruebas
  • Preparación de Casos y Data de Pruebas de las historias del Sprint
  • Validación de “Done” de las Historias
  • Registro y notificación de Bugs
  • Aceptación de la Historia junto con el PO
  • Llevar las métricas de Calidad de Software

El Tester trabaja junto con otros Testers y equipo de operaciones en:

  • Diseñar y preparar la estrategia general de pruebas
  • Colaborar junto con los Stakeholders en las pruebas UAT
  • Identificar los escenarios y flujos de negocio más vitales
  • Difundir el Plan, Casos de Pruebas para Integración
  • Ayuda a conocer la salud del entregable
  • Identifica dependencias
  • Apoya en las pruebas de requerimientos No funcionales
  • Apoya en las pruebas de sistema end-to-end

Como pueden apreciar, son funcionales muy importantes.

Pensamientos finales

Nuevamente, Agile es más que adoptar y adaptar frameworks. Entiendo que existe un frenesí en la industria, pero sin una verdadera comprensión de los valores y principios detrás de las prácticas, sólo son cascarones. El Agile Tester es parte del Scrum y es el mejor amigo de los developers, se comporta como un compañero cuyo objetivo es ayudar a mejorar el software, dar feedback continuo y evitar a aparezcan errores en lugar de ser sólo un filtro para detectarlos, participa activamente en las ceremonias y es parte del éxito del equipo. En mi experiencia, es un rol vital y no puede existir agilidad sin este apoyo.

Gracias por leer y por compartir sus experiencias.

Johnny

El Levantamiento de los Movimientos “#No”

NoMovements

No sé si soy yo, pero siento que en Latinoamérica existe un creciente interés acerca de algo que yo denomino, los “movimientos #No”: #NoEstimates, #NoBacklogs, #NoManagers; que ya tienen un rato dentro de la jerga agilista (yo me encontré con ellos hace unos años). En realidad pienso que es esto es bueno porque demuestra mayor exploración y, en términos generales, mejor entendimiento del pensamiento Lean; y quizás de una transición de enfoques de desarrollo iterativos incrementales (como Scrum) hacia otros donde se habla flujo de entrega de valor (como el método Kanban). Buenísimo!

Pero -desde mi punto de vista- hay que tener cuidado en no caer en enfoques puristas que pueden alejarnos de los beneficios que estos movimientos pueden brindarnos. Mi opinión a continuación:

#NoEstimates

“Una buena estimación es aquella que provee una visión de la realidad del proyecto suficientemente clara como para permitir a un equipo decidir correctamente cómo controlar el proyecto de modo tal de cumplir sus objetivos”. – Steve McConnell, Software Estimation: Demystifying the Black Art

Las estimaciones son inútiles, pero el proceso de estimación es valorable. El proceso de estimación es un proceso de conocimiento compartido, muy valioso para los equipos; no por el valor de estimación obtenido, sino por la discusión alrededor. Si las estimaciones y la dinámica aporta valor para su organización y a sus Clientes, úselos; recuerde también que tiene áreas Comerciales, maneja contratos y departamentos legales; estas cosas siguen existiendo en el mundo real. Si las estimaciones no le aportan valor, deséchelas; pero independientemente, revise su contexto y manténgase enfocado en la entrega de valor: hacia el Cliente y hacia la organización.

#NoBacklogs

“No hay nada derrochador sobre el concepto del backlog. Un backlog en sí mismo no es un desperdicio. Lo que importa es cómo las personas lo usan. Los trabajadores creativos necesitan herramientas para almacenar sus ideas y recordar sus opciones. Sólo de trabajadores de manufactura se debería esperar mantener su inventario bajo y sus máquinas limpias.” – Jurgen Appelo, Backlogs Are Not Waste

No a los backlogs estáticos, esos sí son desperdicio. No a backlogs de cientos de requerimientos que se levantan “up-front” y que cuyo valor se pudre en el tiempo. Si su backlog es un inventario entonces es un despercicio. Pero si su backlog está continuamente cambiando gracias al feedback de sus Clientes o del mercado, adaptándose a las necesidades, mutando continuamente para maximizar la entrega de valor, generando discusión y experimentos; esto es aprendizaje, respuesta al cambio. Sí a estos backlogs. Crear software no es igual al trabajo de manufactura.

#NoManagers

“Cuando la cultura de una organización es mala, no sólo es culpa de los managers. El Management de una organización es responsabilidad de todos. Un mejor management significa “enganchar” a la gente, mejorar el sistema entero e incrementar el valor hacia nuestros Clientes.” – Jurgen Appelo, Management 3.0 Workout

Managers no es igual a Management. El management en una organización -bueno o malo- no es sólo responsabilidad de los managers, es responsabilidad de todos. Es un sistema complejo donde se conjugan principios, comportamientos, reglas “no escritas”, sistemas de recompensas, cultura, diseño organizacional y más. Ver a los managers como la causa de todo mal es sólo ver los árboles, no el bosque; no es sistémico. Sí a la descentralización de decisiones y a la autonomía en los equipos, pero esto no es igual a no tener managers.

Un nuevo movimiento #No

Por favor no interprete que trato de decir que estos movimientos son malos. Lo contrario, mi invitación es a explorarlos, comprenderlos y analizar su aplicabilidad en su contexto; si le aporta valor y le funciona, adelante! Al mismo tiempo, le invito también a no establecerse en una postura purista al respecto; lo que le funcionó a Usted para su contexto, puede que no aplique en otro.

Yo me atrevo a proponer un nuevo movimiento: #NoDogmas. Podemos sentarnos a discutir por horas sobre cuáles enfoques son conceptualmente mejores y cuáles no. En realidad no importa, todos pueden estar equivocados y algunos pueden servir para un contexto determinado; sólo se sabrá cuando se aplique; pero independientemente de todo, siento que encerrarse en enfoques puristas no es recomendable para las organizaciones y equipos en los que tratamos de llevar agilidad. Agilidad sobre debates metodológicos.

Como siempre, gracias por leer.

Johnny

La Definición de “Ready” es tan importante como la Definición de “Done”

Ready

Usted no puede empujar a nadie a subir la escalera a menos que esté listo para subir por él mismo. – Andrew Carnegie

Uno de los conceptos más importantes y conocidos en el desarrollo de software ágil -utilizando varios sabores como Scrum y Kanban- es la Definición de “Hecho” (o Definition of Done, o DoD). La definición de Done es un acuerdo del equipo, y en muchas ocasiones de la organización. Mediante el criterio de Done se puede conocer cuando una Historia de Usuario se encuentra “Hecha” para ser presentada al Producto Owner o Stakeholders. Brinda una guía al equipo sobre las condiciones necesarias que debe cumplir una historia para ser decentemente terminada presentada durante o al final de la iteración. Es una herramienta que brinda transparencia y permite un entendimiento común de lo que significa “Hecho”.

Ya en la práctica, consiste en una especie de checklist que reúne los criterios acordados por el equipo al que se somete cada historia antes de ser colocada en la preciada columna de Done en el Taskboard. En muchos tableros he visto también la columna “Done Done!” o “Accepted” dando así dos niveles de aprobación de la historia de usuario, Done significa que cumple todos los criterios establecidos por el equipo que normalmente incluyen: el código en el repositorio, todas pruebas unitarias y de aceptación en verde, documentación si fuera necesario, integración en el ambiente de pruebas, revisión por el tester en el ambiente de pruebas, etc.; y “Done Done” o “Accepted” cuando ha sido revisada y “firmada” por el Product Owner.

Varios agilistas sugieren  lo mínimo que debe contener la definición de Done, y les dejo algunos artículos para su revisión un poco más abajo; sin embargo, quiero con este post hablar de otra definición quizás no tan conocida pero desde mi punto de vista bastante útil; la “Definición de Listo”.

La Definición de “Ready” o DoR

Análoga a la Definición de “Hecho”, la definición de “Listo” es un acuerdo entre del equipo, especialmente entre el Product Owner y el equipo de Desarrollo donde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un sprint. Básicamente, es un conjunto de condiciones -y un checklist también- a la cual se somete una historia para ser tomada en un Sprint Planning.

¿Por qué es importante?

Varias razones. Desde la práctica, una historia de usuario no está lista a la primera. El product Backlog es orgánico y necesita un tiempo de maduración. Significa que mientras el equipo de desarrollo está trabajando en las historias comprometidas en el Sprint Planning anterior,  el Product Owner está trabajando en refinar su backlog y poner a punto las historias para la siguiente y subsiguiente iteración (pienso que un buen PO prepara historias para un par de sprints adelante). Esto es, comprender el objetivo y el alcance funcional con los usuarios, expertos del dominio, UX designers, Product Managers; priorizar la historias usando técnicas apropiadas, descomponiendo historias en un tamaño apropiado para el equipo, estableciendo criterios de aceptación, identificando dependencias entre los items de su backlog y otros backlogs, colaborando con otros POs, entendiendo y revisando desafíos de arquitectura o técnicos con el arquitecto o Líder Técnico y trabajando junto con el equipo en el grooming del backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.

Bob Galen habla mucho del “Readiness Criteria” en varios artículos y en su libro Agile Reflections y sugiere una lista de Ready como la siguiente (a estos puntos les daré mi modificación desde mi criterio en paréntesis, pero la lista original la colocaré en las referencias):

  • Historias bien definidas y con al menos 5 criterios de aceptación (este valor es heurístico, igual se puede establecer un número máximo de criterios de aceptación);
  • Historias de un Tamaño apropiado, que entre dentro de un sprint (un tamaño adecuado con que el equipo se sienta cómodo y mejore su throughput, un buen tamaño que permita un mejor entendimiento, mejores criterios de aceptación, más fácil de probar, más fácil revisar, mejora la moral del equipo);
  • Que el equipo haya revisado las historias en una sesión de Grooming, donde se haya comprendido la naturaleza, el valor y desafíos técnicos;
  • De ser necesario, que la historia haya tenido un spike para explorar las implicaciones de diseño, arquitectónicas o tecnológicas (cuando el equipo no tiene mucha incertidumbre sobre lo que implica técnicamente la historia, es apropiado un spike; luego de eso la historia se puede revisar nuevamente, estimar y pasar a la columna de Ready);
  • Que la historia sea transversal, es decir que describa un comportamiento end-to-end (que sea “visible” para le negocio);
  • Que el equipo comprenda el enfoque para las pruebas tomando en cuenta aspectos funcionales y no funcionales;
  • Que se haya identificado dependencias con otras historias dentro del mismo backlog u otros backlogs a los que una historia pueda estar conectada;
  • Que la historia se alinee (y esté “enganchada”) a un objetivo u objetivos del sprint, que sean claramente visibles y demostrables.

Esta definición es bastante útil cuando tenemos a un PO que está desarrollando sus skills y su “olfato” para gestionar el trabajo para un equipo ágil. Ahora estoy trabajando con unos 29 equipos y un equipo de 14 POs; y acabamos de introducir esta práctica para lograr que las historias lleguen lo mejor trabajadas a los equipos; y estoy viendo varios beneficios de su aplicación (que espero que se sigan expandiendo):

  • Sprint plannings más rápidos;
  • Involucramiento y conocimiento temprano del equipo sobre los desafíos del siguiente sprint;
  • Gestión colaborativa del backlog;
  • Feedback temprano;
  • Levantamiento temprano de riesgos y necesidades (si se necesita del apoyo de un arquitecto, el SM ya lo puede buscar y planificar para el siguiente sprint);
  • Mayor conciencia del equipo sobre los objetivos de negocio y el alcance;
  • Ayuda al PO a comprender la visión sobre aspectos técnicos que le indica el equipo, y a sensar con qué tamaño de historias se sienten cómodos;
  • Historias mejor trabajadas en las cuales el equipo se siente parte y por ende mejora el compromiso.

Pensamientos finales

Pienso que el uso definiciones DoD y DoR claras y difundidas son herramientas muy útiles para la colaboración , claridad y “fluidez” de los equipos. Haga que el mismo equipo sea quienes revisen y definan estas definiciones, pero si están trabajando con varios equipos colaborando para construir juntos un “big working software” estas definiciones deben ser coherentes a través de todos lo grupos. Se puede crear comités y reuniones de trabajo para afinarlas. Igualmente, están sujetas a revisión y modificación tras cada iteración.

Coloque una columna “In Analysis” o “En Revisión” (o cualquier nombre, sea creativo) donde colocará aquellas historias sobre las que debe trabajar y refinar. Cuando estén listas y se cumpla con la DoR, agréguelas a la columna “Ready” o “Backlog” que son aquellas que se explicarán en el siguiente sprint planning.

Trabajar bajo estas definiciones brindará claridad y fluidez al trabajo de los equipos y aportarán a su crecimiento y madurez. Una vez lo que hagan, por favor compártanme sus experiencias.

Gracias, y que la agilidad esté con Ustedes.

Johnny

Referencias

http://guide.agilealliance.org/guide/definition-of-done.html

http://www.solutionsiq.com/what-is-the-definition-of-done-dod-in-agile/

https://www.scrum.org/Resources/Scrum-Glossary/Definition-of-Done

https://www.scrumalliance.org/community/articles/2008/september/definition-of-done-a-reference

http://www.allaboutagile.com/definition-of-done-10-point-checklist/

https://agilefaq.wordpress.com/2012/12/02/what-is-definition-of-ready/

http://www.batimes.com/robert-galen/user-stories-ready-set-go.html

Tiempo, Esfuerzo, Complejidad; ¿qué mismo es un Story Point?

“La propia palabra ‘estimación’ deja en claro que no calculamos un valor exacto,
determinístico. De hecho, toda estimación tiene supuestos, y estos supuestos suman
incertidumbres.” – Carlos Fontela, Estimaciones y Estadística, CyS Ingeniería de Software (2007)

Los más experimentados en agilismo leerán el título de este post y dirán: “¿y todavía hay dudas sobre esto?”, posiblemente llevarán su cursor hacia la X y cerrarán la ventana. Pues, cuando comienzas una jornada de adopción hacia el mundo de Agile y Scrum con muchas personas que lo están aprendiendo y tratando de hacer match de los conceptos y prácticas sobre la forma tradicional, existen muchas preguntas que considerarías básicas; pero desde mi perspectiva son muy importantes, y pienso muy bien en las respuestas que daré. La importancia radica en que las prácticas, técnicas y artefactos del agilismo reflejan un mindset cuyos valores y principios deben ser comprendidos para encontrar el significado y el beneficio de usarlos; del por qué de la práctica, del por qué es diferente y en qué sentido.

La persona quien me hizo la pregunta había realizado la tarea y me muestra un artículo de Mike Cohn que titula: “Story Points are still about Effort”. Y me escribe un párrafo por mail destacando lo que considera lo más relevante de la lectura:

“En el caso de los story points, se estima el esfuerzo (tiempo) para hacer una cosa – ese esfuerzo puede verse afectado por el riesgo, la incertidumbre o complejidad. Así que permítanme decir tan claramente como puedo: los story points son una estimación del esfuerzo, no de la complejidad.” – Mike Cohn

A línea seguida me escribe diciendo: “Tengo serias dudas de qué realmente es un story point: Complejidad o esfuerzo o tiempo?. Cuando le digo al Gerente de Proyecto que tenemos una desviación de 10 puntos frente a lo planeado, él me pregunta: con cuánta gente y en qué tiempo podemos resolverlo?. No sé qué responder.”

Adicional a esto, puedo agregarle un componente importante de mencionar. Siguiendo el marco de trabajo usado para la adopción en la compañía, en algún momento se dio por sentado en que existe una relación de conversión de Story Points a Horas, básicamente 1 Story Point = 1 día = 8 horas. De tal forma, aritméticamente se puede establecer una traducción que puede simplificar la comprensión de los story points y solucionar el problema mencionado.

Bueno, ahora me toca responder; y pensaba que hacer una precisiones primero.

1. Esfuerzo no es exactamente una unidad tiempo

El esfuerzo es una relación entre la cantidad de tiempo que requiere realizar una tarea en función de un número personas que la van a trabajar, y tradicionalmente se la expresa en personas-horas u horas-hombre o personas-mes. Básicamente, el esfuerzo relaciona tres dimensiones, tiempo, número de personas y la disponibilidad de éstas. De esta forma, si tradicionalmente estimamos una tarea que toma 8 horas para una persona (8 horas-hombre), y agregamos otra persona al 100% de disponibilidad, la tarea se terminaría en 4 horas aproximadamente. En los métodos tradicionales existen varias técnicas para la estimación de esfuerzo y a partir de este los costos: Cocomo, Puntos de función, Puntos de Casos de Uso, Putnam, Juicio experto, Delphi, etc. Todas expresan una relación entre tiempo y número de personas. Esfuerzo no significa tiempo a secas.

2. No existe una relación lineal de Story Points a Horas

Esto es algo que percibo ya en varias adopciones. Siento que existe una necesidad de poder expresar los puntos de historia en un lenguaje más conocido, como las horas-hombre. Algunas personas me dicen que es porque el Cliente así lo exige. En algunas ocasiones, he visto que se estiman las Features en Horas-Hombre y luego se las traduce a Story Points para establecer el número de equipos necesarios en base a su velocidad. Lo cierto es que esto no es posible hacerlo de esta forma y cualquier fórmula que nos creemos nunca nos dará una equivalencia real válida.

El problema con establecer los story points como tiempo es, que las personas tienden a generar una relación automática entre story points y horas; favoreciendo el pensar en horas gracias a la forma tradicional de estimación que nos solicitaban en el pasado. Por ejemplo, establezcamos una relación de 1 story point = 8 horas, como lo menciona SAFe. Cuando se le pide a un miembro del equipo estimar una historia, automáticamente está pensando en “¿cuánto tiempo me tardaré?”, por varios factores agregan normalmente un buffer o colchón; y dicho valor lo dividen para hacer la equivalencia en puntos. “Okay, creo que me tardo 2 días, pero por si acaso voy a decir 3 días…en puntos significan 3 story points.”.

Es volver a la pregunta: “¿cuánto te tardas en realizar esta tarea?”, en lugar de “qué tan compleja consideras esta tarea con las condiciones dadas frente a esta otra historia de referencia ?”.

Mike Cohn escribe un artículo posterior al mencionado arriba describiendo el problema y que básicamente al actuar así se pierden los beneficios de los story points, Don’t Equate Story Points to Hours:

“He sido bastante inflexible últimamente en que los puntos de historia son sobre el tiempo, específicamente esfuerzo. Pero eso no significa que usted debe decir algo así como: ‘Un punto de la historia = ocho horas.’ ” – Mike Cohn

3. Un Story Point es una herramienta de Colaboración

Un Story Point es una medida que engloba: complejidad (inherente y accidental), tamaño, incertidumbre y habilidad/conocimiento sobre el problema planteado (ojo: tamaño y complejidad no son lo mismo).

En otras palabras un Story Point es la medida de esfuerzo mediante la cual un equipo evalúa la complejidad, el tamaño, el nivel de incertidumbre y el riesgo de realizar una historia en base a las destrezas, conocimiento y la información actual que poseen los miembros que conforman ese equipo, entendiendo que esfuerzo no es igual a tiempo.

Debido a la evaluación personal de estas dimensiones, una misma historia puede ser 1 punto para una persona y 8 para otra; un equipo experto trabajando mucho tiempo sobre el mismo módulo puede estimar una historia con un valor relativo menor que otro que nunca ha trabajado en ese módulo, y esto está bien. Los Story Points nos permiten realizar comparaciones relativas para establecer acuerdos sin importar el tiempo de resolución. La duración en tiempo para resolver la tarea es algo que se verá cuando se termine la tarea. Hay historias de 8 puntos que pueden ser terminadas en 2 días o en 4 días, pero para el equipo siguen siendo de 8 puntos, entonces no hay una relación lineal, la relación es una curva (como se muestra en este artículo http://www.targetprocess.com/articles/estimates-software-development.html).

Mi recomendación

En serio, no asocie un Story Point con tiempo. Puede generar disfunciones como: sobre-estimaciones, dificultad de llegar a consensos, dificultad en la comunicación del equipo, estimaciones basadas en tiempo como se hacía tradicionalmente, si lo toma María son 3 puntos, pero si lo toma Juan son 8, proliferación de fórmulas matemáticas de conversión, redondeos de los valores de la fórmula (ejemplo: si la fórmula nos entrega 8,6 el siguiente valor en Fibonacci es 13, entonces son 13 puntos), etc. 

Al usar el story point “puro”, le ayudamos a pensar al equipo en la dificultad propia del problema a resolver, más no en el tiempo ni en quien lo debe resolver. El nivel de incertidumbre estará dado por la misma escala de Fibonacci evitando sobre-estimación para cubrirse, esto a la larga cambia el mindset el equipo enfocándose en la cantidad de complejidad que pueden abarcar en un sprint. La idea es que el equipo vaya afinando sus estimaciones tras cada iteración, el mismo equipo junto trabajando sobre el mismo dominio durante un tiempo.

Referencias

Para más información les dejo estos links:

http://www.infoq.com/news/2009/09/story-points-versus-hours

https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/

https://www.scrumalliance.org/community/spotlight/mike-cohn/june-2014/how-many-hours-is-a-story-point-worth

http://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours

http://www.targetprocess.com/articles/estimates-software-development.html

http://tracer.lcc.uma.es/problems/estimation/estimation.html

http://es.slideshare.net/mstabare/gestion-de-proyectos-estimacin-del-esfuerzo

http://scaledagileframework.com/iteration-planning/

http://www.slideshare.net/JohnnyDark/estimacin-gil-story-points-y-planning-poker

El Product Owner debe ser un arquitecto?

La semana anterior conversaba acerca del tema a través de twitter  con un amigo agilista de Ecuador. Cuando él propuso esto, lo debatí fuertemente; ya que para este momento no concebía que un arquitecto de software pueda llevar la gran responsabilidad del PO. Mi temor estaba orientado a que podría dársele más énfasis a aspectos técnicos y tecnológicos que a satisfacer las necesidades funcionales y expectativas de negocio de nuestro cliente. Al final del día, no importa mucho si lo haces con .NET o Java, 3 capas o cliente-servidor, si el producto no es de calidad (según mi visión de calidad basado en el modelo Kano), sino representa utilidad para el negocio y las funciones diarias del cliente; sino deleita.

Durante esta semana (y mientras escribo este post) tuve la oportunidad de participar en un curso de arquitectura basado en la visión del IASA. He descubierto que estaba muy sesgado acerca del rol de un buen arquitecto de TI y un buen arquitecto de software, comprendiendo que un buen arquitecto buscar solucionar problemas de negocio apalancado en tecnología, algo fácil de decir pero muy complicado