Dos poderosas razones por las cuales la productividad en equipos Scrum depende más del Product Owner que del Equipo de Desarrollo

Hola a todos

Muchos equipos ágiles y organizaciones siguen viendo la productividad como:

• cantidad de historias por sprint
• puntos por sprint
• horas por sprint

y parte de este malentendido que arrastramos en la construcción de productos viene del enfoque basado en manufactura, donde eres más productivo entre más unidades por fracción de tiempo seas capaz de construir.

Considerando que en Scrum tienes Product Owner (PO), Equipo de Desarrollo y Scrum Master (SM), correctos y competentes, quisiera compartirte dos razones por las que considero que en un PO es la clave de la productividad de todo el Equipo Scrum, apartando la idea que esta es responsabilidad del Equipo de Desarrollo, veamos:

Por el Enfoque en el Valor

En el Mundo del Desarrollo Ágil, es decir, de Creación de Productos de Software, hacer más por unidad de tiempo no implica que estés generando más valor por unidad de tiempo, es posible que estés generando una buena cantidad desperdicio a muy buen ritmo, y ninguno de tus usuarios estén usando la solución creada o el producto construido generando el retorno de la inversión esperado.

En el Mundo Ágil, Productividad es construir el producto correcto

Y como muchos agilistas y textos dicen:

Es mejor poca velocidad en la dirección correcta, que mucha velocidad en la dirección incorrecta

En el primer escenario te estarás acercando a tu objetivo y en el segundo escenario cada vez te alejarás más, por más rápido que vayas.

Ahora, dentro de un equipo Scrum, el rol responsable de determinar "el qué" es el PO, por lo tanto, él es el encargado de definir que cualquier cosa que se construya sea de altísimo valor y cumpla con las expectativas de la comunidad de usuarios y de los interesados, indistintamente si se construye o no a alto ritmo.

Por el Tamaño en los Ítems de Backlog (Historias de Usuario)

Ahora, partamos de la base que tenemos un grupo de profesionales del mundo del desarrollo de software, un equipo multidisciplinario, con buenas prácticas de desarrollo de software, y un PO, que prioriza constantemente su producto orientado al valor.

¿el generar rápidamente resultados de valor de forma incremental dependerá del Equipo de Desarrollo?

En esencia, ¡NO! la respuesta depende más de del tamaño de los ítems que van a construir, 

Veamos,

• si los ítems o historias de usuario son muy grandes les tomará mucho esfuerzo transformarlas en incrementos de valor, muchas veces hasta varios sprints, generando inconformidad, pues "ese equipo trabaja y trabaja y nada que entrega". Un ejemplo de esto son historias de tamaño superior a 10 días-persona para alcanzar la definition of done.
• un tamaño óptimo fluirá apropiadamente a través del equipo de desarrollo, ejemplo: historias de usuario de 2 a 3 días-persona para alcanzar la definition of done (esto es fruto de la experiencia, me encantaría que lo validaras). En DevOps esto se llama trabajar en Lotes Pequeños o Small-Batches. (Visita este ejemplo si quieres ver un tamaño de historia de usuario razonable -clic aquí-)
• un ítem de backlog demasiado pequeño implicará que el equipo de desarrollo será altamente eficiente construyendo piezas de valor muy pequeñas con alto esfuerzo de manipulación (imagínate escribir una historia de usuario por cada campo de un formulario o de un reporte, desgastante, ¿No cierto?)

Esto es representado en la siguiente gráfica de Donald Reinersten

En el siguiente video, se puede visualizar cómo tener un lote grande - de 10 ítems - (podría asimilarse a una historia de usuario con muchas funcionalidades) es más lento de transportar que un lote pequeño - de 1 ítem - (podría a asimilarse a una historia de usuario, pequeña y de tamaño óptimo)

Al reducir el tamaño de los lotes, una empresa mejoró la eficiencia de las pruebas de sus productos en un 220% y redujo los defectos en un 33%.(2)

Unos Consejos 

A continuación, unos consejos para cerrar:

• La priorización por valor y la construcción de un producto que genere valor es la clave del enfoque ágil. Como lo he compartido antes: 
• "Ágil es sobre gestión de valor y no gestión de alcance"
• "El alcance es un medio para generar valor"
• un buen tamaño de historia de usuario permitirá la fluencia del equipo y entregar funcionalidades de forma continua 
• mi experiencia me ha demostrado que un buen tamaño es de 2 a 3 días-persona en alcanzar la Definition of  Done, sugiero lo experimentes y lo compartas en la zona de comentarios.
• la división, refinamiento o "splitting" de historias de usuario es una excelente práctica requerida ya que permite a los equipos alcanzar buena velocidad en la construcción del producto (1)
• Un buen sprint backlog debe contar aproximadamente con 6 a 10 historias de tamaño similar (1)

Unas Preguntas que Invitan a la Acción

• Como PO
• ¿sabes cuál es el producto correcto?
• ¿sabes cuándo estás construyendo el producto incorrecto? ¿tienes poder para corregir el camino?
• ¿sabes hacer división o refinamiento de historias de usuario?
• ¿logras que las historias de usuario queden de tamaño pequeño para el sprint planning de modo que al equipo le tome 2 a 3 dias-persona lograr la definition of done?
• Como SM
• ¿sabes guiar a tu PO en los aspectos mencionados anteriormente?

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario (clic aquí)
2. Six Myths of Product Development by Stefan Thomke and Donald Reinertsen. https://hbr.org/2012/05/six-myths-of-product-development

Leído y Recomendo: 14 cosas ridículas que las personas exitosas hacen a diario

Excelente post para poner en práctica

14 cosas ridículas que las personas exitosas hacen a diario (clic aquí)

Scrum: Comprometiéndonos un poco más allá en el planning

Hola a todos

Aunque existen estrategias para mejorar la velocidad de un equipo (ver algunas aquí) y como lo he expresado es mejor ser más productivos que más veloces (clic aquí), les comparto un pequeño tip para que el equipo vaya ganando velocidad en su construcción de producto.

Por lo general, cuando los equipos comienzan o fallan son temerosos escogiendo la cantidad de historias a implementar que harán parte del sprint backlog. Una buena forma de alejar el temor y lograr la confianza (basándonos obvio en el principio) de transparencia es:

"Ok, comprometámonos con lo que nos sentimos seguros (15 puntos por ejemplo) y dejemos esta historia como opcional (ej:3 puntos), y si alcanzamos a hacerla, pues ¡Genial!"

Si el equipo compra la idea, al final pueden darse las siguientes situaciones:

1. Se logré solo lo inicialmente comprometido (cero líos, no hay ningún problema)
2. Logren hacer lo adicional, en este caso 18 puntos (excelente)
3. Si el equipo nota que después de varios sprints cumple el reto adicional, ellos mismos, el Product Owner o el Scrum Master pueden considerar que se puede aumentar la velocidad para el siguiente sprint, en este caso 16, 17 ó hasta los mismos 18 puntos, lo que decidan en consenso.

Saludos ágiles

Jorge Abad

Productividad mejor que Velocidad.

-

Qué es mejor ir a 200 km/hora en la dirección equivocada, implicando que entre más avanzas más lejos estás.
o
Ir a 80 km/hora en la dirección de la visión - dirección correcta -.

-

• Productividad ( me lo recordaba Jorge Johnson @jorge_johnson) es dar valor de negocio.
• Velocidad es construir software, útil o no útil pero software al fin al cabo.

Bajo estas definiciones entonces:

1. Hacer mucho software pero no generarle valor al cliente
• mucha velocidad y poca productividad
• ejemplo:
• hacer funcionalidades que serán poco usadas y que corresponden al "nice to have" y que no están alineadas con la visión del producto.
2. Hacer poco software pero generarle valor al cliente. 
• poca velocidad pero alta productividad 
• ejemplos
• cuando estamos haciendo refactor que nos permitirá tener una mejor aplicación
• cuando estamos haciendo componentes complejos pero que requieren gran esfuerzo en su construcción.
3. Hacer mucho software y generar mucho valor
• mucha velocidad y alta productividad
• ejemplo:
• construyendo funcionalidades de valor para el cliente de complejidad normal.
4. Hacer poco software y poco valor
• poca velocidad y poca productividad
• ejemplo
• Construir un componente muy complejo que requiere mucho esfuerzo, que no será muy usado. - por lo general un capricho funcional de algún interesado con poder -, y que no se encuentra alineado con la visión del producto.

En síntesis, nuestro esfuerzo como Equipo o como Scrum Masters es guiar al Product Owner a que solicite las funcionalidades del producto que le proporcionen valor, sea que estas se hagan o no con velocidad, pues estamos bajo el principio de transparencia y sabemos que estaremos con nuestro equipo trabajando comprometidamente en el backlog priorizado, en el 20% de las características que dan el 80% de beneficio (ley de pareto para el agilismo).



Por lo tanto, siempre preguntemos:

• ¿es necesario?
• ¿le agrega valor al producto?
• ¿cuantos lo van a usar?
• ¿ese uso lo pueden hacer en una herramienta externa? (informes que perfectamente pueden manipular mejor en excel)
• y volver a preguntar ¿es realmente  necesario?
• ¿prefieres nuestro tiempo en esta funcionalidad a esta otra?
• ¿si se acabará el dinero preferirías esto o aquello?
• ¿prefieres esta validación supercruzada entre estos 8 campos o que entreguemos esta historia que te saca el total de ventas del día? (por ejemplo)

Nota: 
Aunque esta nota aplica para el agilismo, también es valida para el esquema tradicional.



--

Seis (6) estrategias para lograr mayor velocidad de los equipos en Scrum

Hace unos días en Ceiba (empresa donde trabajo como Scrum Master)  filosofábamos en equipo la siguiente pregunta:

¿qué era necesario hacer para lograr mayor velocidad (puntos por sprint)?

Nota aclaratoria: no fue presión mía como Scrum Master hacia el equipo, pero si es cierto que yo lancé la inquietud (realizando la Inception :-) como en la película el Origen, de Nolan y Di Caprio)


La respuesta a esta inquietud ha llegado gradualmente, y pienso que es  uno de los interrogantes obligatorios que tiene que plantearse un Scrum Master y que debe plantearle al equipo.

Dentro de las responsabilidades del SM están:

• el seguimiento del proceso
• el coach al equipo
• y dentro de ese coach llevarlo a una productividad mayor (a un doble de productividad según Sutherland - padre de scrum-  [1] )

Hay que reconocer que Scrum nos ha permitido ser muchos más veloces y productivos debido a:

• Involucramiento y compromiso del dueño del producto, que permite resolver inquietudes rápido
• Visibilidad y resolución rápida de impedimentos
• Retrospectivas bien hechas, que nos llevan a la mejora continua
• Empoderamiento del equipo, de forma que este por si mismo se auto-organiza y encuentra la mejor forma de entregar el producto
• Los valores de coraje y compromiso, que han permitido querer ir más allá y poder enfocarnos mucho más en como ser mejores
• Atención a la excelencia técnica, que ha hecho que nuestra deuda técnica cada vez sea menor, lo cual mejora nuestra velocidad. "La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad" [2] (principio del manifiesto ágil). (este punto lo retomaré más adelante)
• Teniendo el equipo motivado y feliz,  equipos motivados son más ágiles "Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo." [2] (principio del manifiesto ágil).

Pero luego de estar allí, es necesario plantearse ¿es posible ser mejores? a continuación entonces, enumero en orden de importancia (según mi criterio) las formas en las que considero y he encontrado que podemos ser más veloces:

1. Seguir el patrón Scrumming the Scrum 

En la conferencia de Jeff Sutherland | "Scrum: The Future of Work" [3], presenta este patrón de scrum como una de las formas de llegar "hiper-productividad" en los equipos

Patrón: Scrumming the Scrum [4]

Este patrón se basa en:

• Identificar y priorizar la(s) mejora(s) (kaizen) a realizarle al proceso de Scrum  en la Reunión de Retrospectiva. Recordemos en la retrospecttiva debemos enfocarnos en:
• cómo mejorar el proceso de elaboración del producto,  el cómo que Scrum no resuelve y deja en libertad a los equipos).
• cómo mejorar la calidad y el producto
• cómo mejorar la felicidad del equipo
• Enfocarse  en la(s) mejora(s)  más importante(s) y críticas. He leído por ahí que máximo 3 cosas muy importantes a mejorar (1, 3 ó 4 no recomiendo ningún número en especial - yo prefiero pocas cosas a muchas -  intenten una opción y concluyan - recordemos que lo que funciona en un equipo no tiene por que funcionar en otro)
• Ponga el Kaizen en el primer lugar del sprint backlog con criterios de aceptación cuantitativos.
• Revise la mejora Kaizen en el Sprint Review como si fuera otra historia.

Beneficios:

• terminar antes
• solicitar mas backlog para el sprint
• incrementar la métrica de "el clima de ayer" para el próximo planning.

2. Seguir el patrón de Interrupción 

Otro de los patrones expuestos en esta conferencia Jeff Sutherland | "Scrum: The Future of Work" [3] para llegar a la  "hiper-productividad", es el presentado a continuación:.

Este patrón es útil cuando el producto ya se encuentra en producción y se requiere atención inmediata a temas específicos.

El patrón se basa en:

• Luego del Kaizen determine una cantidad de puntos disponibles para tareas inmediatas que requiere el Product Owner.
• Si identifica que no se van a consumir úselos en más historias.

Beneficios:

• Equipo dispuesto para atender urgencias con un tiempo asignado para ello, sin que les quite velocidad y compromiso..
• Product Owner contento con su equipo, debido a que pueden atender temas urgentes.

3. Hacer Sprints más cortos 

Esta recomendación nos la dió Ricardo Colusso (@rcolusso) de kleer.la en donde nos sugería realizar sprints de 1 semana.


Beneficios:

• Poder fallar más rápido, debido a ciclos de retroalimentación más cortos.
• Despliegue de producto más rápido

Requerimientos

• Más compromiso del Product Owner
• Más historias de usuario refinadas y cumpliendo el criterio de Ready.
• Historias de usuario más pequeñas

Nota: No he intentado esta sugerencia

4. Tener un backlog refinado y con el criterio de ready

Otra de las recomendación que nos la daba Ricardo Colusso (@rcolusso) de kleer.la y que también remarcaba Sutherland era la necesidad de tener un backlog refinado y con el criterio de ready, esto indiscutiblemente proporciona una visión clara hacia donde va el producto.




Beneficios:

• Visión de producto
• equipo enfocado

Requerimientos

• Más compromiso del Product Owner
• Realizar la reunión de refinamiento al la mitad del sprint
• tener al menos 2 sprints más con historias de usuario cumpliendo el criterio de Ready.

5. Resolviendo la deuda técnica

La deuda técnica es uno de los elementos que termina frenando la velocidad de los equipos y va en contra de la atención a la excelencia técnica (que es uno de los principios del manifiesto ágil).  Recomiendo el post de Henrik Kniberg - The Solution to Technical Debt . Aunque pienso que es un tema de estudio y de compromiso con el cliente, producto, product owner y mismo equipo.

Presento dos gráficas de este post, que muestran la necesidad de detener la deuda técnica y comenzar a "pagarla" antes de que la velocidad de nuestro equipo se vea frenada radicalmente.

Efecto de programar con código apestoso (crappy code) (en español no encuentro una palabra polite para crappy) [4] 

Efecto de trabajar con código limpio (clean code) [4]

Beneficios:

• Velocidad
• entendimiento del código
• excelencia técnica

Requerimientos

• Equipo con coraje y conocimiento técnico
• Equipo y Scrum Master que sepan vender la idea de resolver la deuda técnica el Product Owner.
• Hacer la deuda técnica como parte del kaizen y darle prioridad e  importancia en el proyecto.

Recomendación

• Tener lineamientos técnicos que se cumplan desde el inicio del proyecto.

6. Teniendo una holgura (Slack) cada cierto tiempo

Por último, la holgura o Slack es un tiempo intencional dejado entre sprints para cubrir cualquiera de las siguientes tareas:

• Innovación técnica
• transferencia de conocimiento entre equipos
• realizar ajustes pendientes de soporte y mantenimiento

Algunas de las formas de implementar el Slack son:

• dejar un tiempo pequeño entre sprints de 1 a 2 días 
• 6×2 + 1 - despues de 6 sprints de 2 semanas, descansar una.
• El viernes del desarrollador: Cada viernes el desarrollador tiene tiempo para alguna de estas tareas.
• Una carta dorada. Esta carta en el juego del poker le dará al desarrollador un día libre (el que quiera) para usar el slack en lo que el quiera.
• etc..

Recomiendo visitar este post: Cutting Slack in Scrum

En conclusión

Si seguimos estas directrices, no dudo que podremos mostrar gráficas de velocidad similares a la que presenta Jeff Sutherland

Incremento de velocidad aplicando los patrones 1 y 2 [4]

 Y pronto estaremos escribiendo artículos y recomendaciones de como ser mejores en Scrum.

Consideración importante respecto a la puntación de historias

Cuando se mejore la velocidad y encontremos qué cosas que antes nos tomaban más tiempo, pero ahora luego de la mejora nos  toman mucho menos,  debemos de tener una consideración importante respecto a la puntuación:

• si tus puntos fueron diseñados poniendo un pivote de  funcionalidad conocido (ejemplo una pantalla con un formulario de 8 campos), no hay lio, ese pivote y las demás funcionalidades las hará  el equipo más rápido y la puntuación seguirá siendo la misma.
• Si tu pivote esta basado en días felices/productivos (ver [7]) (yo uso esa técnica), considera que si haces algo más rápido debes puntuarlo de la misma forma que usabas al principo del proyecto, como si no tuvieras hiper-velocidad o hiper-productividad, ejemplo:
• si una pantalla tipo a= te tomaba  2 días felices (2 puntos).. .pero luego de la mejora te toma un dia feliz (un punto) síguela puntuando como antes, pues esa es la referencia inicial con la que se dimensionó el proyecto y permitirá visualizar la velocidad y la mejora.

Hasta ahora he encontrado estas 6 formas, talvez hayan más o sean realmente menos, si alguien conoce, aprende, o ensaya más y las puede/quiere compartir bienvenidas sean, es importante todos aprender de todos.


Queda abierto el espacio para sus comentarios y experiencias.


Saludos

Jorge Abad


---
Referencias:

• [1] Video - Jeff Sutherland | "Scrum: The Future of Work" - referencia a la productividad del equipo  https://www.youtube.com/watch?feature=player_detailpage&v=RYIPSPWVc8o&t=1457 
• [2] Principios del manifiesto ágil .http://agilemanifesto.org/iso/es/principles.html
• [3] Video - Jeff Sutherland | "Scrum: The Future of Work" https://www.youtube.com/watch?feature=player_embedded&v=RYIPSPWVc8o
• [4] Diapositivas -Jeff Sutherland | "Scrum: The Future of Work" http://scrumlab.scruminc.com/gallery/album/104-scrum-the-future-of-work/
• [5] Henrik Kniberg - The Solution to Technical Debt  http://blog.crisp.se/2013/07/12/henrikkniberg/the-solution-to-technical-debt
• [6] Cutting Slack in Scrum
• [7] Scrum y XP desde las trincheras. Por Henrik Kniberg. http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf