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
• decide cuales son las acciones de mejora, acuerdos y experimento 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
• 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) 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 5 a 6 días-persona en lograr el DONE (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)

Cómo Contratar, Encontrar o Formar un Scrum Master

Hola a todos

Sigamos con el post anterior: Las habilidades blandas -Soft Skills- de un Scrum Master 

Primero aclaremos algo que siempre es bueno resaltar:

"con dos días de entrenamiento nadie se hace MAESTRO de Scrum o Scrum MASTER"

Estos dos días y el posible examen de certificación que se presente, son el primer paso, y solo se acreditaría el conocer el framework, pero no implican una maestría y el dominio del mismo, esto es importante remarcarlo pues Scrum no es una metodología, es un framework (lo que implica que no es prescriptivo ni detallado) y como tal deja muchas cosas sin definir y según el contexto y la experiencia se adoptarán unas prácticas y otras no.

Volviendo al tema, como se contrataría o formaría un Scrum Master, vamos por partes:

¿Cómo contrataría a un Scrum Master?

Bueno, pues para contratar a alguien como Scrum Master tendría los siguientes pasos

1. validaría el conocimiento del marco de Scrum
2. validaría la experiencia, acá opino que es necesario al menos seis (6) meses de experiencia continuos de haber aplicado el framework para comprenderlo y saber adaptarlo
3. le haría una entrevista similar a esta -http://www.lecciones-aprendidas.info/2016/05/entrevista-para-un-scrum-master.html -
4. y cerraría con un Assesment Center (o centro de evaluación), que es un juego de roles donde las personas muestran su forma de priorizar, interactuar, decidir, etc., buscando identificar las habilidades blandas presentadas en el post anterior - http://www.lecciones-aprendidas.info/2017/03/softskills-scrum-master.html -
5. (para los que tienen equipos avanzados) sugeriría que el candidat@ comparta con el equipo al que llega un día o dos, buscando que  facilite algunas reuniones  para determinar si tanto equipo como Scrum Master se sienten cómodos mutuamente.

Con estos elementos determinaría si se puede contratar o no al Scrum Master candidat@.

¿Cómo formaría un Scrum Master? (aplica en caso de que alguien dentro de la organización se postule a ejercer el rol por primera vez) (1)

En general comenzaría con dos premisas

• validaría conocimiento y dominio del marco de Scrum
• validaría que tenga las habilidades blandas presentadas en el post anterior - http://www.lecciones-aprendidas.info/2017/03/softskills-scrum-master.html con un Assessment Center o con conversaciones con el equipo al que pertenece, sus compañeros o líderes que actualmente trabajen o hayan trabajado con el/ella.

Luego comenzaría el acompañamiento, que puede darse en dos modalidades

• acompañamiento de un  Agile Coach
• Para esto se puede usar el modelo Shu-Ha- Ri de artes marciales

• Shu
• El Agile Coach realizaría y mostraría como realizar al SM las siguientes ceremonias
• Al menos dos planning (esto implica al menos dos sprints)
• Al menos dos dailys (luego los otros dailys dejaría al SM los realice)
• Al menos dos refinamientos  (esto implica al menos dos sprints)
• Al menos dos reviews  (esto implica al menos dos sprints)
• Al menos dos retrospectivas  (esto implica al menos dos sprints)
• Luego el Coach acompañaría al alumno en dos sprints, invitando a que el facilite las ceremonias de modo que observen puntos de mejora y puntos a conservar.
• Luego se le dejaría sol@ con su equipo y se le visitaría esporádicamente o por demanda
• Ha y Ri 
• Se requieren de constante comunicación  (muchas lecturas, mucho aprendizaje ) entre el Scrum Master y el Agile Coach para subir a estos niveles
• Acompañamiento de otro SM con experiencia
• en este sentido se darían los siguientes pasos:
• El SM nuevo acompañaría al SM con experiencia al menos durante dos sprints de forma que vea como este realiza las sesiones con su equipo, resuelve los impedimentos, y se desenvuelve en el día a día.
• Asignar al nuevo SM su nuevo equipo de trabajo
• El SM nuevo acompañado por el experimentado realizaría durante los dos primeros sprints las ceremonias de Scrum, de forma que se se den recomendaciones sobre facilitación y mejores prácticas
• Luego el SM experimentado asistiría por demanda o por iniciativa del SM nuevo al equipo buscando ver puntos de mejora
• Cierre del proceso

Hasta acá este compartir.

Saludos ágiles

Jorge H. Abad L.

Notas, Aclaraciones, Comentarios y Referencias

1. Un Scrum Master en formación le sugiero seguir las reglas hasta que las domine  y pueda obviar cosas, pero mientras esto llega le sugiero seguir las agendas de scrum  http://www.lecciones-aprendidas.info/search/label/agenda%20scrum

Las habilidades blandas -Soft Skills- de un Scrum Master

Hola a todos:

Quisiera compartir en este post un poco más del entendimiento que he logrado del rol de Scrum Master, este rol tan extraño que hace poco hemos comenzado a emplear en proyectos de desarrollo de software.

Según la Guía Oficial de Scrum (1), el Scrum Master (SM). lo define como:

• es el responsable de asegurar que Scrum se entienda y se adopte
• es un líder que está al servicio del Equipo Scrum (Ojo: Recordemos que el Equipo Scrum esta compuesto por el Equipo Desarrollador (2), Scrum Master y Product Owner)
• ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.
• Facilitar los eventos de Scrum según se requiera o necesite.
• Sirviendo al Product Owner en:
• Encontrar técnicas para gestionar la Lista de Producto de manera efectiva;
• Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos;
• Entender la planificación del producto en un entorno empírico;
• Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto para maximizar el valor;
• Entender y practicar la agilidad; 
• Sirviendo al Equipo Desarrollador (2) en:
• Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional;
• Ayudar al Equipo de Desarrollo a crear productos de alto valor;
• Eliminar impedimentos para el progreso del Equipo de Desarrollo;
• Guiar al Equipo de Desarrollo en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.
• Sirviendo a la Organización en:
• Liderar y guiar a la organización en la adopción de Scrum;
• Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto;
• Motivar cambios que incrementen la productividad del Equipo Scrum; y,
• Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización.

Podríamos parafrasear o abstraer todo esto en

• El Experto y Maestro de Scrum
• Quien enseña al Equipo Scrum a hacer Scrum
• Facilitador de los eventos de Scrum
• Líder Servicial (al servicio del equipo Scrum)
• Agente de cambio
• Coach del Equipo Desarrollador y del Product Owner
• Remueve impedimentos 
• Protege y guía al Equipo Scrum y a la Organización la forma como estos interactuan más efectivamente.

Podríamos decir entonces:

"Wow que rol tan importante dentro del equipo, alguien que lidera y sirve al equipo a la vez", 

Pero el lío viene cuando tenemos que salir a elegir dentro de nuestra organización o contratar Scrum Masters en el mercado, Definitivamente no es fácil, pues a la luz de las definiciones mostradas anteriormente la mayoría son blandas y se podrían resumir en:

• Liderazgo de equipos*
• Liderazgo Servicial (propone y cuestiona, pero no impone) (4)
• Trabajo en equipo
• Don de Maestro
• Proactividad
• Comunicación Asertiva
• Constante autoformación
• Orientación al logro* (o sea, hace que las cosas pasen)

*La orientación al logro y el liderazgo son cruciales para que un Scrum Master sea exitoso, pues no tiene presentación que este sea una víctima:

• del Product Owner, 
• del Equipo Desarrollador 
• o de la organización. 

Un buen Scrum Master logra tener éxito haciendo Scrum en el escenario complejo en el cual se desarrolla la construcción del proyecto, valiéndose de las herramientas que le proporciona Scrum y la agilidad, e insisto no es una víctima del entorno, es un protagonista que energiza al equipo y presenta radiadores de información que ayuda a todos a tomar acciones oportunamente.

"Un buen Scrum Master logra tener éxito haciendo Scrum en el escenario complejo en el cual se desarrolla la construcción del proyecto."

Según el marco solo requiere una competencia cognitiva:

• Maestría en el Framework de Scrum (es importante aclarar que dos días de entrenamiento en scrum no convierten a nadie en MAESTRO), lo que se podría resumir en;
• Saber como facilitar un planning (clic aquí)
• Saber como facilitar un daily (clic aquí)
• Saber como guiar al equipo durante el sprint de manera que se logre la autoorganización
• Saber como facilitar un review (clic aquí)
• Saber como facilitar una retrospectiva (clic aquí)  
• Saber como facilitar un refinamiento (clic aquí)
• Saber como hacer el rol de Product Owner (pues el SM es su coach)
• Saber como se hace planeación de un producto
• Saber como se hace la estimación de un product backlog, un sprint backlog y el seguimiento del mismo
• Saber sobre agilidad
• Saber sobre prácticas técnicas ágiles (para el mundo del software), o las herramientas que hacen a su equipo más eficiente (pensando en la aplicación de scrum en un escenario agnóstico - o fuera del software - ) (recomiendo este post : Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo - Clic aquí- )

Y por último, es requerido que el Scrum Master tenga conocimientos básicos (no es necesario que sean avanzados - pues para eso está el equipo -) del escenario técnico en el cual se desenvuelve el proyecto o la construcción del producto, pues sino el primer impedimento sería el Scrum Master al no tener herramientas suficientes para saber cómo o quién puede ayudar a su equipo.

Bueno, hasta acá este compartir.

Próximo post relacionado con este ¿cómo encontrar, contratar o formar un scrum master? - clic aquí -.

Bienvenido el feedback

Saludos ágiles

Jorge Abad.

Notas, Aclaraciones, Comentarios y Referencias

1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla, encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
2. El nombre del Equipo de Desarrollo crea por lo general confusión en la industria del software, se debería llamar Equipo Solucionador
3. Dos buenos links que me sirvieron de gran utilidad para escribir este post  https://www.scrumalliance.org/community/articles/2013/july/soft-skills-for-scrummasters  -- http://www.yodiz.com/blog/10-essential-skills-every-scrum-master-must-have-infographics/
4. Las Preguntas Poderosas como Herramientas para Generar Autoorganización y Autogéstión - Clic aquí -

[Scrum] El Product Owner "NO" Necesariamente Escribe las Historias de Usuario o Ítems de Backlog

Hola a todos

Como lo había compartido en el post anterior (clic aquí) el Product Owner:

• Es alguien con empoderamiento y capacidad de decisión sobre el producto
• Es el responsable del  ROI -return on investment-
• Es voz del cliente ante el equipo
• Define, refina y prioriza el Product Backlog
• Esta disponible para el equipo
• Hace seguimiento del avance y la construcción del producto
• Decide cuando cancelar el sprint 
• Decide cuando salir a producción.

Pero lo que quiero resaltar en este post es lo que dice la guía(1) dice expresamente acerca del Product Backlog y la Lista de Elementos (o ítems) del Producto y como debería trabajar con ella el Product Owner


"El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto (Product Backlog). La gestión de la Lista del Producto incluye: 

• Expresar claramente los elementos de la Lista del Producto;
• Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
• Optimizar el valor del trabajo que el Equipo de Desarrollo realiza;
• Asegurar que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación; y,
• Asegurar que el Equipo de Desarrollo(2) entiende los elementos de la Lista del Producto al nivel necesario. 

El Dueño de Producto podría hacer el trabajo anterior o delegarlo en el Equipo de Desarrollo*. Sin embargo, en ambos casos el Dueño de Producto sigue siendo el responsable de dicho trabajo."

Cabe aclarar que he estado en proyectos donde las historias de usuario o ítems de backlog son escritas por otra persona diferente al Product Owner que no hace parte del Equipo Scrum(2), pero esto no exime que el Produt Owner siga al frente de este trabajo y de sus responsabilidades frente al Equipo y al Producto.

Por lo tanto, el Product Owner (de un producto de software), respecto a

• los requerimientos en prosa,
• historias de usuario,
• casos de uso, 
• o cualquier forma de expresar la Elementos del Producto o ítems de backlog

 podría de acuerdo a su contexto:

• Elaborar la Lista de Elementos del Producto (Product Backlog) - esta es la práctica más común  -,
• Delegarla o apoyarse en el equipo de desarrollo para su construcción, o
• Delegarla en otros por fuera del equipo de desarrollo - esta es fruto de mi experiencia y de varios coaches en la industria, y nos ha sido bastante útil en contextos donde el Product Owner no tiene tiempo para explicitar reglas de negocio compleas -.

Cada Equipo Scrum debe experimentar y entender cual es la configuración que más le conviene.

Basados en la sorpresa anterior quisiera hacerte una pregunta:

¿Cuándo fue la última vez que leíste la guía de Scrum? 

Es bueno leerla cada cierto tiempo, pues en la medida que ganas conocimiento y destreza con Scrum la lees y la comprendes mejor.

Hasta acá esta pequeña nota curiosa.

Les recomiendo este otro post  Un vistazo a la guía de Scrum - Clic Aquí relacionado con la guía y sus apartes "ocultos a nuestro rapido mirar" de mi estimado amigo Lucho Salazar - @LuchoSalazarC traductor de la versión actual al español.

Saludos Ágiles

Jorge Abad



Notas, Aclaraciones, Comentarios y Referencias

1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
2. Recordemos que el Equipo Scrum esta constituido por: El Product Owner, El Equipo de Desarrollo y el Scrum Master.

[Scrum] El Valioso "NO" del Product Owner

Hola a todos

Según la Guía de Scrum(1), el Dueño de Producto o Product Owner (PO). lo define como:

• El responsable de maximizar el valor del producto y el trabajo del Equipo de Desarrollo (2)
• Es la única persona responsable de gestionar la Lista del Producto (Product Backlog)
• Expresa claramente los elementos de la Lista del Producto;
• Ordena los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
• Optimiza el valor del trabajo que el Equipo de Desarrollo realiza;
• Asegura que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación;
• Asegura que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.
• Es una única persona, no un comité. El Dueño de Producto podría representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran cambiarla prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto.
• Para que  pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones
• Durante el Sprint el alcance puede clarificarse y renegociarse entre el Dueño de Producto y el Equipo de Desarrollo a medida que se va aprendiendo más.
• Solo el Dueño de Producto tiene la autoridad para cancelar el Sprint
• El Dueño de Producto hace seguimiento de este trabajo restante total al menos en cada revisión de Sprint.
• Decide si libera o no el incremento

Lo anterior podríamos parafrasearlo un poco como

• Es alguien con empoderamiento y capacidad de decisión sobre el producto
• Es el responsable del  ROI -return on investment-
• Es voz del cliente ante el equipo
• Define, refina y prioriza el Product Backlog
• Esta disponible para el equipo
• Hace seguimiento del avance y la construcción del producto
• Decide cuando cancelar el sprint 
• Decide cuando salir a producción.

Pero este post se enfoca en que le corresponde Product Owner respecto al producto y al alcance decir

• qué se hace 
• y qué se posterga para próximas versiones (un NO PARCIAL, o sea hoy te digo que NO, mañana tal vez lo hagamos)
• y qué definitivamente NO SE HACE

Esto se alinea perfectamente con el décimo principio ágil (3) en donde se refleja el pensamiento Lean:

la simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial

Decifrando este juego de palabras podemos parafrasearlo diciendo para el mundo del software

Nos esforzaremos al máximo en NO crear ni software, ni alcance, ni trabajo de desperdicio o que no sea necesario (o hacer algo que terminará siendo inútil)

Por lo tanto, es clave que el Product Owner aprenda de a DECIR NO, y al negociar con sus interesados para ciertas funcionalidades les dirá:

• eso NO se puede hacer aún, 
• es que necesitamos generar valor con lo mínimo posible
• eso va para otra versión o release
• eso aun NO tiene prioridad
• eso NO agrega valor
• eso definitivamente NO se hará

Es decir la misión del PO es mantener el Backlog de cada release lo mas pequeño posible de forma que se genere valor con la menor cantidad de alcance requerido y de esa manera se alcance prontamente el máximo ROI.

Cerrando

Un buen PO sabe:

• Que cada sprint tiene software funcionando y potencialmente liberable (punto a favor del PO y de la organización)
• Pero que si se permite decir que SÍ todas las funcionalidades que se le ocurran tanto a el como al negocio, NUNCA va a salir a producción, pues a mayor alcance más cantidad de sprints se van a requerir para salir a producción, y a mayor tiempo menor ROI (un peligroso circulo vicioso)
• Que si se demora mucho en salir a producción el impacto en el ROI y en el negocio puede ser nefasto dado lo disruptivo y cambiante del entorno actual.

Recuerdo mucho una frase que le escuche a Ángel Medinilla.

NUESTRO TRABAJO NO ES HACER SOFTWARE, ES HACER LA MENOR CANTIDAD DE SOFTWARE POSIBLE QUE MAXIMICE EL VALOR DE NEGOCIO DE NUESTROS CLIENTES.

Por lo tanto cuando vayas a escoger a un PO, cerciórate de que el o ella tienen claro los siguientes aspectos respecto al alcance:

1. Que conoce que problema de negocio está resolviendo
2. Que tiene claro cual es la solución que debe entregar al negocio para resolver ese problema
3. Que dice NO, pues esta interesad@ en salir a producción lo antes posible
4. Que comprende que el NO es de las mejores formas de controlar el ROI

Bienvenido el Feeback

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
2. El nombre del Equipo de Desarrollo crea por lo general confusión en la industria del software, se debería llamar Equipo Solucionador
3. Principios ágiles - http://agilemanifesto.org/iso/es/principles.html
4. Este post está altamente relacionado con: La Ilusión del Control o ¿Cómo Hago para Controlar un Proyecto Ágil?

Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo

Hola a todos:

Hace poco en una sesión de acompañamiento a Scrum Master, alguien me preguntó

¿Hacia dónde seguir mejorando el equipo, pues creo que no podemos mejorar más?

Ante esta pregunta, comencé a explicar el Modelo Operativo de Generación de Valor (1) el cual se basa en:

• Personas
• Procesos y
• Herramientas

Por lo tanto, si el Scrum Master se centra solo en personas y procesos "rápidamente" (tal vez en 10 sprints, tal vez muchos más, tal vez menos ) el equipo logrará sinergia y alcanzará la maestría en el manejo de Scrum, sus ceremonias, priorización del backlog, etc.,  y caerán en una "zona cómoda" en la cual la pregunta realizada tiene todo el sentido.

Bajo este contexto la frase de Ken Schwaber - cocreador de Scrum -  toma todo el sentido:

“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”( no dudo que la hubiera querido terminar con otra palabra)

Es necesario entonces, que como Scrum Masters y Coaches adicionemos a los procesos de mejora del equipo las herramientas (2) -o prácticas técnicas- y lograr que los equipos adquieran la maestría en ellas, aun más que sean sanamente insatisfechos y estén siempre buscando una mejor manera de hacer las cosas. De esta forma se genera valor hacia el interior y exterior del equipo estando en constante crecimiento.

Cerrando

A continuación quiero compartirles una pequeño listado de prácticas técnicas con las que pueden y deben retar a sus equipos como Coaches Agiles que son de ellos, la lista en esta en continuo crecimiento, este es el pequeño listado que encontré a la fecha:

Herramientas (Prácticas ágiles) 

Zona 1: Personas y Herramientas

• Inspección o revision por pares

Zona 2: Procesos y Herramientas

• Pruebas unitarias
• Test Driven Development (TDD)
• Aceptance Driven Development (ATDD)
• Refactoring

Zona 3: Personas, Procesos y Herramientas

• Pair Programming
• Mob Programming

Zona 4: Solo Herramientas

• Integración Continua
• Despliegue Continuo
• Revisión de código estática
• Pruebas funcionales Automatizadas
• Principios SOLID de POO (Programación orientada a objetos)
• Clean Code
• Automatizar lo automatizable
• etc, etc, etc.

La reflexión del día, desde "Extreme Programming Explained" : "la labor de un coach agil es hacer su equipo AUN mejor de lo que es"@KentBeck

— Agustin Villena (@agustinvillena) February 16, 2017

El #ScrumMaster es el #AgileCoach de su equipo.

— Jorge Hernán Abad L. (@jorge_abad) February 15, 2017

Para terminar les comparto esta frase que constantemente me inquieta "los pacientes se enferman de lo que el médico sabe (3)", por lo tanto si como Scrum master o Coach no estas en constante aprendizaje de estas tres áreas no podrás ayudar apropiadamente a tu equipo


Bienvenido el feedback


Saludos ágiles
Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Operating model - https://en.wikipedia.org/wiki/Operating_model
2. El tablero Kanban, la Gestión Visual, etc también son herramientas, el objetivo del post es hacer visible el punto de las prácticas técnicas ágiles.
3. "los pacientes se enferman de lo que el médico sabe" - clic aquí para ver post relacionado

[Scrum] Ritmo Sostenible sobre Ritmo Insostenible

Metrónomo: utilizado para indicar tiempo o compás de las composiciones musicales. Produce regularmente una señal, visual y/o acústica, que permite a un músico mantener un pulso constante al ejecutar una obra musical.(1).

Hola a todos:

He escuchado algunas veces decir esta expresión a los Scrum Masters o Product Owners:

"Equipo TENEMOS QUE DARLE A MORIR para que entreguemos todo lo comprometido en este sprint"

[BadSmell-1: Se impone al equipo el sobre-esfuerzo](2)

Desde el punto de vista de Scrum y Agile se ven varios problemas en esta frase.

1. En Scrum los equipos trabajan en hacer la MAYOR y MEJOR cantidad de alcance (o ítems de backlog) que solicite el PO durante la jornada laboral, ni más ni menos.
2. Es posible que durante el sprint se complete o no todo lo propuesto durante el planning, en caso de que se termine antes se solicitará más ítemes, en caso de que no se complete lo planeado se emplea el timebox para identificar en la retrospectiva por qué no se logro lo planteado y las acciones a realizar en el siguiente ciclo.
3. (se que el comentario que sigue le dolerá a los amigos del control) En Scrum los equipos son los que deciden si sobre-esfuerzan o no - ojo, es importante no caer en el otro extremo y creer Scrum significa ser anárquicos, y no cumplir jornada laboral etc, recomiendo estos dos post acerca del tema (7)(8)-,es normal que planteemos el sobre-esfuerzo pero debe ser una decisión de equipo no una imposición, y como principio clave se debe compartir el propósito de este sobre-esfuerzo para comprender la causa y la necesidad del mismo.

Pero no todo termina allí

El problema radica en que la frase del "DARLE A MORIR" no es solo de un sprint, sino que es frecuentemente usada todos los sprints, y allí con seguridad emerge [BadSmell-2] que ni la organización, ni el Product Owner, ni el Scrum Master entienden mucho de Scrum, ni de Ágil, y estan llevando las prácticas de la gestión tradicional al contexto ágil, y pronto veremos al equipo decir:

• "no ganamos nada con Scrum"
• "pensábamos que íbamos a mejorar nuestra forma de trabajo y nuestra vida, y no es cierto"
• "esto no fue lo que nos dijeron en el entrenamiento"
• "antes -en cascada- solo nos esforzábamos al final, ahora cada dos semanas tenemos una semana de martirio"

Lo anterior denota que se olvida el principio ágil de:

"Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida." (3)

Y no estoy afirmando que esporádicamente o muy ocasionalmente no existirá algún sobre-esfuerzo(4) -realmente a veces se requiere- pero es importante comprender que los equipos necesitan cierta cadencia o ritmo para navegar con cierta comodidad - o cuasipredictibilidad - en el mar de la incertidumbre(5).

Por lo tanto este sobre-esforzar al equipo constantemente es indicador de:

1. [BadSmell-3] El Scrum Master no esta empleando la retrospectiva como instrumento para entender por qué el desgaste constante del equipo y como salir de este círculo vicioso.
2. [BadSmell-4] El Product Owner cree que puede pedir y exigir todo lo que quiere sin considerar la capacidad del equipo.
3. [BadSmell-5] El equipo no es protegido por el Scrum Master de las malas prácticas
4. [BadSmell-6] El equipo aun no es consciente de su autoorganización y de su capacidad de decir "NO" ante esta mala práctica continuada

Adicionalmente este sobre-esfuerzo frecuente llevará al desgaste del equipo y con seguridad a la desintegración del mismo o renuncia de alguno o varios de sus miembros (6).

Espero con esto haber aclarado un poco sobre este BadSmell en las organizaciones que comienzan con Scrum o aun no saben como trabajar con el.

Hasta la próxima.

Saludos ágiles
Jorge Abad.

Referencias, Aclaraciones, Comentarios y Notas

1. Ver definición de Metrónomo en Wikipedia - clic aquí.
2. Usaré la etiqueta BadSmell para resaltar lo que son malas prácticas
3. Ver los principios -aquí-.
4. Un post sobre el sobre-esfuerzo que escribí hace un muy buen tiempo - clic aquí -.
5. Principios de Incertidumbre de Requisitos, Procesos y Productos de Software - clic aquí-.
6. Dice Sun Tzu en el arte de la guerra: "Las armas son instrumentos de mala suerte; emplearlas por mucho tiempo producirá calamidades. Como se ha dicho:"Los que a hierro matan, a hierro mueren." Cuando tus tropas están desanimadas, tu espada embotada, agotadas tus fuerzas y tus suministros son escasos, hasta los tuyos se aprovecharán de tu debilidad para sublevarse. Entonces,aunque tengas consejeros sabios,al final no podrás hacer que las cosas salgan bien."
7. ¿Que significa autoorganización en Scrum? (Clic aquí)
8. Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado (Clic aquí)

La Ilusión del Control o ¿Cómo Hago para Controlar un Proyecto Ágil?

Hola a todos

Dentro de las muchas ocasiones en las que comparto con clientes, equipos, product owners, scrum masters o personas que van a comenzar a trabajar en Agile una pregunta recurrente es:

¿Cómo hago para que el proyecto no se salga de control?

Vamos por partes entonces:

¿Qué se quiere decir con la pregunta?

La Rae define control como (Ver definición - clic aquí):

y cuando un cliente o gerente, lider funcional, product owner, o gerente de proyecto pregunta esto se refiere típicamente a esto:

¿Cómo hago para que el proyecto no cueste más, no se demore más, se construya realmente lo que se requiere o no se quede eternamente consumiendo recursos(1)?

Poniendo este tema en blanco y negro, comencemos.

No es que exista mucho control con los proyectos en cascada 

En el informe del caos los proyectos en cascada no salen muy bien librados versus los ágiles, los cuales muestran un resultado más satisfactorio en cuanto tiempo y costo.(https://www.infoq.com/articles/standish-chaos-2015 )

Dado esto:

• La probabilidad de cumplir estas expectativas es más alta en Ágil que en Cascada, ahora respecto a que el proyecto se vaya a desbordar el problema existe en cualquiera de los dos enfoques, el problema radica en el mecanismo para estar informados si vamos a lograr o no la meta propuesta y reaccionar a tiempo.
• Los proyectos en cascada cuando se salen de control - de tiempo o costo- (el alcance lo tienen garantizado, tal vez se construya lo que NO se necesita - como ocurre en muchos casos - pero esta garantizado el "qué") o costarán más o nos demoraremos más (ambas son dinero para alguien), el punto clave es que tan diestro es el proveedor para gestionar los cambios:
• si el proveedor es experimentado o tiene un buen gerente de proyectos el sobrecosto lo asume el cliente, sino 
• el sobrecosto lo asume el proveedor, caso más común.
• En cascada (y muchos lo hemos vivido) el proyecto y el cronograma va bien hasta la parte de análisis (como diría un conocido mío: "el papel aguanta todo", todo se complica cuando comienzan las fases de desarrollo, la fase de pruebas con informes de avance que del 90% luego a las tres semanas 90.3% , a las 4 semanas 90.38% y el proyecto se demora un 90% del tiempo cerrando el 10% faltante del alcance (fruto de la procrastinación o postergación del proceso en cascada) y si logramos entregar el proyecto terminamos entregando el producto tardíamente a nuestros clientes o al mercado, tal vez cuando ya no lo necesitan o cuando las condiciones iniciales que dieron origen al proyecto cambiaron.

La verdad, a lo anterior yo no llamaría control

Cómo se "controlaría" un proyecto en ágil

Ahora respecto a la comprobación, inspección, fiscalización, intervención. del cual habla la RAE, se tienen varias soluciones:

1. La Transparencia

En ágile nos enfocamos en valernos de radiadores de información que nos permitan tomar decisiones informadas y todos conocer como está el proyecto y producto en cualquier momento:

• Burndown chart del Sprint
• Burndown o burn up release (clic aquí)
• Flujo Acumulativo
• Velocidad
• entre otros

2. La brújula de la agilidad es la simplicidad

Comencemos recordando el décimo principio del manifiesto ágil:

la simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial

Decifrando este juego de palabras podemos parafrasearlo diciendo

Nuestra mayor prioridad es NO generar ni software ni trabajo de desperdicio (o hacer algo que terminará siendo inutil)

3. En Scrum existen tres roles que te pueden ayudar a tener "control" de tu proyecto / producto, en cuanto tiempo, costo y alcance.

Product Owner (PO)
En primer lugar el PO es quien esta encargado dentro de sus funciones de dos aspectos claves:

• ROI (Return On Investment): Preocupado por salir a producción con la menor cantidad de software posible que solucione el problema de negocio
• DECIR NO (5): El PO al negociar con los stakeholders (interesados) les debe decir para ciertas funcionalidades:
• eso no se puede hacer aún, 
• necesitamos generar valor con lo mínimo posible
• eso va para otra versión o release
• eso aun no tiene prioridad
• entre otras.

Es decir la misión del PO es mantener el Backlog de cada release lo mas pequeño posible de forma que se genere valor con la menor cantidad de software.

Scrum Master (SM)
El otro rol es el Scrum Master, este es el coach del PO y estará atento a que quien esta ejecutando este rol lo haga bien y este preocupado sanamente por mantener un product backlog refinado y priorizado.

El Equipo Desarrollador (Development team, o equipo solucionador)
Y por si fuera poco, es una buena practica que cada Relase tenga un objetivo (3)(4), por lo tanto cuando el PO este "corrompiendo el alcance" - como dicen el el mundo PMBoK - por añadir lo que no es clave para el proyecto, tanto SM como Equipo Desarrollador se lo harán ver.

Adicionalmente existe el Review
Cada sprint (ciclo de trabajo entre 2 y 4 semanas) el equipo Scrum - PO, SM y Equipo Desarrollador -  más los Stakeholders del proyecto se reúnen a ver el demo del sprint -a ver software funcionando cumpliendo la definición de terminado- , ha realizar inspección y adaptación sobre el producto y a decidir como seguir avanzando sobre el mismo, de manera que no hay sorpresas y el progreso o no progreso es evidente para todos.

Y si es que lo anterior no funciona
Ahora si ves que el proyecto no lo va a lograr..

1. Desde las primeras dos semanas tuviste software funcionando 
2. Suspende el proyecto y fin de la historia.

Cerrando

Los proyectos y productos que son construidos con el enfoque ágil pueden darnos suficiente información sobre su estado y nos permitirán tomar decisiones informadas sobre el éxito y fracaso de los mismos,  depende de nosotros emplearlos o no. En cascada si decides interrumpir el proyecto es probable que no tengas al final ni siquiera software funcionando pues depende mucho de la fase en que se interrumpa o finalice abruptamente el proyecto

Hasta acá esta pequeña reflexión, espero sea útil.

Bienvenido el feedback y sus comentarios

Saludos ágiles

Jorge Abad

Referencias, Comentarios, Notas y Aclaraciones

1. Entendiendo recursos como dinero y tiempo invertido por las personas o empresas
2. http://agilemanifesto.org/iso/es/principles.html
3. La "Zona de Valor de Negocio". Una reflexión sobre ¿cuándo termina un release en un proyecto Ágil / Scrum?-  http://www.lecciones-aprendidas.info/2016/04/la-zona-del-valor-de-negocio-una.html 
4. Go Product Map -  http://www.romanpichler.com/tools/product-roadmap/
5. Este post está altamente relacionado con este: El valioso "NO" del Product Owner