Tweet sobre DevOps

"Hasta que el código no esté en producción, en realidad no se está generando ningún valor, porque es WIP atrapado en el sistema" #devOps pic.twitter.com/1RwBcvmKYv

— Mauro Strione (@MauroStrione) June 24, 2017

Antipatrón de Scrum : El Scrum Master Dirige la Retrospectiva en Lugar de Facilitarla

Hola a todos

Una de las disfuncionalidades  y punto de mejora que he encontrado en los equipos Scrum, radica en que el Scrum Master  (SM) (ya sea que venga del mundo de la gerencia de proyectos, o acostumbrado a un liderazgo impositivo) al momento de realizar la retrospectiva reúne al equipo (1), y aunque realiza las actividades propias de una retrospectiva (2)(3), cada actividad cierra con sus conclusiones, es decir:

• decide cuales fueron las causas principales de por qué les fue bien o mal durante el sprint
• decide cuales son las acciones de mejora, acuerdos y experimentos a realizar
• el equipo esta allí solo para estar de acuerdo con sus decisiones.

Es decir, dirige la sesión en lugar de facilitara.

Problemas de este enfoque

• no permite la auto-organización
• queda el SM como el único responsable de decidir que se hace, y por ende a quien culpar [les sugiero leer este post de Martín Alaimo sobre la responsabilidad del equipo y el único responsable (4)] de una buena o mala estrategia.
• el equipo solo sirve para hacer lluvia de ideas pero no decide, pues el SM decide por el equi
• el equipo no esta empoderado tiene voz pero no voto
• el equiipo no madurará, pues siempre le dirán que hacer y no asumirá consecuencias.
• El SM no es un facilitador, es más alguien que dirige al equipo y este depende de él para todo (se sigue un esquema de Comando y Control - típico de la gerencia de proyectos - )
• Se esta trabajando con un grupo y no con un equipo (4)

Soluciones

• El SM es realmente un facilitador de la reunión(5), es decir el SM esta ahí, para ayudar al equipo a encontrarse,  ser su espejo, no dirige sino que facilita, es alguien que cuenta con instrumentos y experiencias para facilitar correctamente la sesión de retrospectiva de su equipo (6).
• Al finalizar cada paso de la retrospectiva (3) el SM invita al equipo a que priorice, reflexione y tome decisiones sobre:
• problemas
• oportunidades de mejora
• experimentos
• planes
• acuerdos
• cambios a realizar entre otros.

Beneficios de la Solución Propuesta

• El equipo se empodera de sus problemas y soluciones
• Todos adquieren un compromiso entre pares, nadie les dice que hacer, ellos acuerdan que ahcer.
• El equipo tiene voz y voto
• Si el equipo falla, el equipo aprende y mejora (en el esquema anterior el SM es el culpable de elegir una mala estrategia)
• El equipo comienza a sentirse responsable y emerge la autoorganización
• Si el equipo durante el sprint no esta tomando las acciones que se comprometieron,
• entre ellos pueden llamarse la atención (es más fuerte la presión social que el compromiso ante una orden) o 
• el SM puede interpelarlos con una pregunta poderosa puede hacerlos conscientes de la desviación de lo comprometido por ellos
• El equipo se escucha entre sí (recordemos que las mejores ideas vienen de cualquier parte)

Bueno hasta acá este corto compartir, bienvenido el feedback, los comentarios y las experiencias.

Saludos ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. Recordemos que el equipo Scrum esta constituido por Product Owner, Equipo Desarrollador (el cual es multidisciplinario), y Scrum Master
2. En esta página podrás encontrar cientos de actividades https://plans-for-retrospectives.com/es/
3. Recordemos que un buen guión de retrospectiva (según el libro Agile Retrospectives de Diana Larsen y Ester Derby) cuenta con:
• Armar el escenario
• Recolectar datos
• Indagar
• Decidir que hacer
• Cerrar
4. Compartiendo la responsabilidad. Hacia Un Equipo Real.por Martín Alaimo (clic aquí)
5. Según comparte Martín Alaimo en su libro "Facilitador de Equipos Ágiles: El Camino de un Coach hacia la Agilidad Empresarial" 

• La facilitación  de grupos: es un proceso por el cual una persona cuya elección es aceptada por todos los miembros del grupo, que es neutral y no tiene autoridad sustancial en la toma de decisiones, diagnostica e interviene para ayudar al grupo a identificar y resolver sus problemas y tomar decisiones y para así, aumentar su efectividad. (Schawarz, 2002)

6. La posible agenda de una retrospectiva puede ser algo como [Agenda Scrum] Pasos para Realizar la Retrospectiva

Nexus y la Deuda Técnica

Les comparto el meetup que se realizó el 8 de Junio en la ciudad de Mexico sobre Nexus (un framework para escalar Scrum) y la Deuda Técnica. https://www.meetup.com/es/Agile-Mexico-Meetup/events/240553474/

Nexus con @jorge_abad https://t.co/zaRqDmeJ8w

— Rox (@jeri4queen) June 9, 2017

---

Dolores de deuda técnica con @jorge_abad https://t.co/ZDcilL3Gxa

— Rox (@jeri4queen) June 9, 2017

---

Nexus y la Deuda Tecnica de Jorge Hernán Abad Londoño

Sobre el Compromiso del Sprint

El Compromiso no es sobre una promesa o sobre firmar con sangre, es sobre hacer todo lo que está en nuestros medios para tener éxito. https://t.co/P6LL1MGX8o

— Jorge Hernán Abad L. (@jorge_abad) June 18, 2017

---

Commitment is neither a promise, nor signing with blood, but trying everything you can to succeed ^ @Koen_V pic.twitter.com/ezz9clu8AG

— AgileFortune (@AgileFortune) June 18, 2016

El Planning, el Tasking, el Tablero Kanban, la Guía de Scrum y un Tip Poderoso para “Oler” Impedimentos

Hola a todos, este es uno de los post que hace tiempo tenía pendiente por escribir y por fin se alinearon los astros y pude escribirlo.

Empecemos, según la Guía Oficial de Scrum (1) el planning consta de dos partes:

• Tema Uno: ¿Qué puede hacerse en este Sprint? (conocido como “El Qué”): El cual consiste en la identificación del Objetivo del Sprint y la lista de ítems de backlog que hacen parte del producto que si se completan lograrían el Objetivo del Sprint

• Tema Dos: ¿Cómo se conseguirá completar el trabajo seleccionado? (conocido como “El Cómo”): El cual consiste  que el Equipo de Desarrollo decide cómo construirá esta funcionalidad para formar un Incremento de producto “Terminado” durante el Sprint que cumpla con el Objetivo y contenga los ítems seleccionados en el paso anterior más el plan para terminarlos.

Adicionalmente, para el tema 2 dice claramente:

“El Equipo de Desarrollo por lo general comienza diseñando el sistema y el trabajo necesario para convertir la Lista de Producto en un Incremento de producto funcional. El trabajo podría ser de tamaño o esfuerzo estimado variables. Sin embargo, durante la Planificación del Sprint se planifica suficiente trabajo como para que el Equipo de Desarrollo pueda hacer una proyección de lo que cree que puede completar en el Sprint que comienza. Para el final de esta reunión, el trabajo planificado por el Equipo de Desarrollo para los primeros días del Sprint es descompuesto en unidades de un día o menos.” (Esto último es conocido en el mundo de Scrum con el Tasking, o la descomposición en tareas de los ítems de backlog - como la palabra misma lo sugiere-)

Aquí vemos dos cosas:

• Se sugiere que el trabajo se descomponga de forma gradual en unidades, o sea, NO SE DESCOMPONGA TODO A PRIORI  en el planning del sprint (ya sea por timebox o conveniencia), sino que se identifique claramente las tareas próximas de lo próximo que se va a hacer y luego se descomponga el resto cuando estemos cercanos a construirlo (esto es conocido en el mundo de gerencia de proyectos como Planeación Gradual o Rolling Wave Planning – la cual empleamos nosotros ampliamente en el mundo ágil –). Acá quiero hacer una precisión, nunca lo he hecho así, siempre sugiero o hago la descomposición de todas las historias de usuario en tareas durante el planning  –y nos ha ido bien –, haré el experimento y lo compartiré.
• Lo segundo que me parece MUY PODEROSO es descomponer el trabajo en unidades de UN DÍA O MENOS.

Y es en esto último donde uno dice: “Claro, tiene sentido, de esa manera todos los días se finalizará algo y de esa forma se sentirá el progreso y se identificarán fácil los impedimentos y puntos de atasque".

Basado en lo anterior vienen los siguientes puntos

Cómo he trabajado el tasking o cómo lo he visto

Este ejercicio de descomponer las historias de usuario en tareas de un día o menos (léase Tasking), y me he encontrado con equipos que han decidido manejarlo de diferente manera, el punto no es discutir cuál es la mejor, es mejor pensar, con cual se siente más cómodo mi equipo, adicionalmente puede que lo hagan de una forma durante un tiempo y luego cambien a otra (recordemos el principio básico de la gestión empírica “Inspección y Adaptación”), volviendo al tema las formas de tasking que he observado son:

Forma de tasking	Observación
·         Dividir la historia de usuario en tareas de tamaños de unidades entre 1 y 8, así: 1h, 2h, 3h, 4h, 5h, 6h, 7h, 8h	La verdad esta no me gusta, lo que he encontrado es que no somos buenos estimando en esta forma, pues la precisión aun a nivel de tareas aún es baja en desarrollo de software, adicional abre el espacio a la microgestión que limita al equipo y no permite que el equipo aprenda.
·         Dividir historia de usuario en las tareas de tamaños de 2h, 4h, 6h, 8h	Esta forma me gusta, brinda amortiguación si se falla en la estimación.
·         Dividir la historia de usuario en las tareas de tamaños de 2h, 4h, 8h	Esta es la que más me gusta, por la misma razón de la anterior, adicionalmente permite que falles, aprender, mejorar, da más libertad al equipo.
·         Dividir la historia de usuario en tareas sin horas pero garantizando que cada tarea es menor a un día	Esta forma la he visto en equipos muy maduros en los cuales la confianza y transparencia son una constante presente en su día a día.

Ahora el Super Tip

Este tip me lo enseño Silvia Lozano (@sila_zenufana) – y me ha servido montones con los equipos que he tenido la suerte de estar y acompañar –, quien me sugirió en el tablero kanban poner UN PUNTO por cada día que permanece la tarea en la zona del WIP (“Work In Progress” o “Work in Process”) de esta manera se identificará que una tarea requiere ayuda si tiene más de DOS PUNTOS, pues recordemos que como tenemos por regla (o sugerencia) que las tareas no deben durar más de un día, si las tareas en el tablero kanban tienen DOS PUNTOS O MÁS significa que:

• Existe un posible impedimento
• Existe una posible dificultad en desarrollar la tarea
• Existe una posible falta de foco o de habilidad por parte de desarrollador que esta trabajando en ella
• Se estimó de una forma muy optimista o con falta de conocimiento del real tamaño
• Existe un desbordamiento de alcance
• O es un punto de mejora para discutir en la retrospectiva

En cualquiera de los anteriores es un punto donde tanto Scrum Master como Equipo observan un punto en el que hay que hacer intervención.

OJO: Lo anterior funciona muy bien si tenemos la buena práctica que siempre haya en el tablero una tarea por persona del equipo – recordemos que solo somos capaces de hacer una cosa a la vez, o sea en el WIP una persona no puede tener más de dos tareas –  o sea, que en el WIP si el equipo tiene 4 integrantes a lo sumo existirán 4 post-it (o pósit (2)) a la vez que representan una tarea por cada uno de ellos.

Cerrando

Espero que lo compartido sea de utilidad en tu equipo Scrum, y para terminar tres preguntas

• ¿Cuándo fue la última vez que leíste la guía oficial de Scrum?
• ¿Qué descubrimiento has hecho?
• ¿los puedes compartir?

Bienvenida la retroalimentación y sus comentarios.

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1.  La que se encuentra en Scrumguides.org
2.  Es correcta esta forma de escribirlo, la RAE lo permite ver acá  Pósit  http://dle.rae.es/?id=TnfXVsj

Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint

Hola a todos

Continuando con la reflexión acerca del tamaño de las historias de usuario y basado en la retroalimentación de mi estimado y bien ponderado amigo Lucho Salazar - @LuchoSalazarC, quiero compartirles esta tabla de tamaños sugeridos para las historias de usuario.

La siguiente tabla cuenta con las siguientes consideraciones:

1. Es una sugerencia, cada equipo, cada producto tiene su contexto y tendrá sus propios números, prácticas emergentes y conclusiones.
2. Esta basada en el artículo "Patterns for Splitting User Stories" de Agile for All (ver post) (ver los patrones de división en español aquí - http://agileforall.com/wp-content/uploads/2013/06/Story-Splitting-Flowchart-ES.pdf ) donde se sugiere que una buena historia de usuario debe tener entre 1/6 a 1/10 de la velocidad del equipo cada sprint
3. Recordemos que el tiempo requerido para el DONE de una historia de usuario (del mundo del software) debe incluir todas las tareas técnicas que sean relevantes y requeridas, por ejemplo:
• Análisis
• Diseño
• Implementación
• Revisión Par (esta es una buena práctica)
• Despliegue
• Pruebas
• Corrección
• Despliegue
• Pruebas
• Actualización de documentación relevante para el equipo.
4. Por ejemplo si consideramos un sprint de 2 semanas y un equipo de 5 personas, el tamaño promedio sugerido de Historia de Usuario está entre 5 y 8 días persona, por lo tanto, ejemplo si tomamos la de 5 días, le tomará tomará al equipo aproximadamente 5 días-persona, lograr el DONE (o sea, todas las activadades identificadas en el punto anterior)
5. Debemos procurar que los ítemes del sprint backlog (las historias de usuario para el caso del software) sean de similar tamaño, no siempre se logrará, unas veces sí, otras veces no.
6. Sigo considerando que el tamaño razonable de Sprint es de 2 semanas, máximo 3, pero siempre tender al tiempo más corto.
7. Aunque muchas veces la construcción de historias de usuario de sistemas que tienen muchas capas requieren muchos muchos días de esfuerzo para lograr el DONE, si un esfuerzo requerido es superior a 10 días-persona, debe ser revisado cuidadosamente para determinar si es susceptible de ser reducido por técnicas de partición de historias de usuario.
8. Si como Scrum Master estás pensando que tu equipo va solo a trabajar historias de usuario en el sprint, es falso, recuerda que asiste a todas las reuniones de Scrum (Planning, Review, Retrospectiva, Daily, Refinanmiento) y estas toman entre el 10% al 20% del tamaño del Sprint.

Hasta acá este pequeño compartir, espero les sea útil.

Saludos ágiles

Jorge Abad

Es en serio, las historias usuario tienen que ser pequeñas

Hola a todos

Quisiera compartirles hoy una situación que con seguridad les habrá pasado a algunos de ustedes.

Dentro de las primeras recomendaciones que como Agile Coach que se le comparten a un equipo de software que comienza a trabajar con Scrum es que “las historias de usuario tienen que ser pequeñas”, es decir:

• Toman máximo 2 a 3 días en lograr el DONE (4)  (o sea que todas las tareas de ingeniería sumadas toman ese tiempo: análisis + diseño + implementación + prueba par + corrección + despliegue + pruebas + corrección + volver a desplegar, entre otros)
• Tienen aproximadamente 6 a 8 criterios de aceptación cada una (ver post)
• El sprint backlog cuenta con entre 6 a 10 historias de usuario de similar tamaño (ver post), obvio no siempre se cumple esta condición pero debemos procurar de que sea así,
• Que sea tan pequeña que quepa en una tarjeta (media hoja de cuaderno, ojalá menos)

Lamentablemente en ocasiones estas recomendaciones son tomadas a la ligera por el cliente o por los nuevos Scrum Masters, por los Product Owrners y por el equipo desarrollador, teniendo como consecuencia la aceptación de Historias de Usuario que más bien son Épicas, generando:

• Sprint backlogs de 1 historia que sobre vive muchos sprints
• Sprint backlogs de 2 a 3 historias y a duras penas lograron cerrar una
• Entre otros casos

Algunos Pensamientos

Asociado a este antipatrón quisiera compartirles hoy varios pensamientos:

• Si un sprint es de 10 días –por ejemplo - implica que si una historia de usuario toma 8 o más días-persona para lograr el DONE ocasionando que muy probablemente esa historia no se termine y deba ser completada el próximo sprint si el Product Owner la prioriza.
• Si una historia toma más de dos o más sprints en lograr el DONE puede tener como causasNo hubo un correcto refinamiento del backlog y la historia no cumplido el requerimiento de ser pequeña (1)
• Se aceptó una historia de usuario que no tenía sus dependencias resueltas y que otro equipo o alguien externo al equipo de desarrollo le juro y perjuro al Product Owner que las dependencias estarían resueltas durante el sprint, no cumpliendo así la Definition of Ready (verpost) – dependencias que pocas veces se resuelven 
• La historia de usuario realmente es una historia épica (DURA DE MATAR) que sobrevive muchos sprints teniendo como causa la carencia de refinamiento y de partición de historias (ver recomendaciones para partición de historias)
• Los criterios de aceptación están tan amplios que “le cabe un tren de lado” (así decimos en mi tierra – Colombia – ), de nuevo careciendo la historia de usuario de refinamiento y de la correcta partición (ver recomendaciones para particiónde historias)
• Al momento de escribir historias de usuario estas no cumplen dos de los criterios de INVEST (1) – Estimables y Small –, pues realmente no son estimables, (algo que he observado es que las estimaciones se vuelven inexactas más allá de los 10 días-persona) agregando gran incertidumbre a la estimación hecha (ya sea por planning poker u otro método)

Consecuencias

Cuando estas recomendaciones no se siguen ocasionaran:

• Muy probablemente no haya Review (o demo), pues no hay nada que mostrar, se le pregunta al equipo y dicen “hemos hecho mucho, nos hemos esforzado mucho y nada que terminamos”, por lo tanto no hay incremento, por ende no hay generación temprana de valor, lo que nos lleva a que Scrum “no funciona” porque no se cumplió lo que se prometió con el framework.
• Si no hay demo, el Product Owner y Stakeholders sienten que el equipo no avanza
• El equipo encuentra cada vez más y más tareas técnicas que no había identificado y parece esto no tener fin
• Se genera deuda técnica funcional (pues muchas veces dicen entreguemos así y nos queda pendiente, esto, esto, esto y esto.. y ya veremos cuando lo hacemos)
•  En la retrospectivas creen que el equipo está mintiendo, y se comienza a generar desconfianza en el ecosistema ágil que queremos crear.

 Es en serio,

las historias usuario tienen que ser pequeñas

las historias usuario tienen que ser pequeñas

las historias usuario tienen que ser pequeñas

Sino fallará tu implementación de Scrum.

Cerrando

Recuerda:

• Seguir las 3 C´s (2) y el criterio INVEST(1) siempre, 
• Realizar refinamiento de historias en la mitad del sprint de manera que lleguen en ready al planning (ver post de refinamiento)
• Hacer una buena partición (slicing) de las historias de usuario (recuerda la guía)
• Y Si tu Product Owner se aparece en el planning con una historia que toma más de 6 días-persona como Scrum Master o Team Member deberías (según el contexto)
• no aceptarla, o
• hacerle partición y negociación en el planning para lograr generar un entregable en el sprint

Hasta acá este compartir

Saludos ágiles

Jorge Abad

Notas, referencias, comentarios y aclaraciones

1. INVEST
• Independientes
• Negociables
• De Valor
• que se puedan Estimar
• pequeñaS (small)
• que puedan ser Testeables
2. Las 3 C’s
• Card (caber en una tarjeta)
• Conversación
• Confirmación
3. Te recomiendo estos dos excelentes post en esa misma línea:
• Por Lucho Salazar - El Tamaño si importa (clic aquí)
• Por Javier Garzas - ¿Por qué las Historias de Usuario deben ser lo más pequeñas posible? (ver post)
4. Inicialmente  tenía de 5 a 6 días-persona pero mi experiencia ha demostrado que se puede en menos,