Por qué los Equipos Scrum son más “rápidos” que los tradicionales. Un enfoque desde Lean Software Development

He notado que muchos profesionales de TI (o IT) el concepto de agilidad está asociado a desarrollar a la “Maldita Sea” (1), es decir,  sin cuidado alguno y sin reglas, donde:

• no se hace documentación,
• las pruebas son pocas o nulas
• poco o nada de análisis
• el ciclo de vida de desarrollo es “codificar y corregir” y así infinitamente
• se afirma que “son ágiles” porque “comercialmente es lo que estamos diciendo, pero no sabemos que significa”
• entre muchos otros desaciertos

Y creen que estas malas prácticas que llevan al desastre, es ser ágil.

Afirmación más falsa no puede haber ( ver Ser ágil es y no es...)

Pero también he observado que no tenemos claro por qué los equipos ágiles son más veloces (2) y productivos (3)  (ver Productividad mejor que Velocidad) que la ejecución tradicional, sabiendo que las actividades de desarrollo siguen siendo las mismas:

• requisitos
• análisis y diseño
• implementación
• pruebas 
• despliegue

o incluso pueden ser más actividades (debido a que los equipos ágiles son más  disciplinados y orientados a prácticas técnicas(4)), como por ejemplo :

• requisitos
• análisis 
• implementación empleando pruebas unitarias (TDD)
• pruebas
• automatización de pruebas funcionales
• adicionar pruebas unitarias, funcionales y otras al servidor de integración continua
• despliegue

La razón radica en que las siguientes prácticas de Scrum mitigan bastantes problemas del desarrollo tradicional y aligeran el desarrollo

• eliminando reprocesos
• mitigando riesgos más rápido 
• suprimiendo el desperdicio
• acabando burocracia y
• Maximizando la comunicación

A continuación presento un listado prácticas que desde mi punto de vista alivianan el desarrollo y permiten ser más exitoso, Algunas de esta prácticas las etiquetaré con alguno de los principios de Lean Software Development (5):

Nota: Si aún no has leído sobre Scrum te recomiendo este post (Mi versión de : SCRUM EN POCAS PALABRAS / SCRUM RESUMIDO)

PRÁCTICA CÓMO SE LOGRA VELOCIDAD QUE INYECTA PRINCIPIO LEAN LOS ROLES Los roles adecuados Product Owner Scrum Master Team Members Los tres roles trabajan en sinergia juntos y continuamente sprint, tras sprint. Están los roles requeridos para el éxito trabajando en conjunto. Evitando retrasos por burocracia y falta de disponibilidad. Eliminar los desperdicios Ampliar el aprendizaje Reaccionar tan rápido como sea posible Potenciar el equipo Crear la integridad Véase todo el conjunto Product Owner que resuelve dudas durante el sprint El Product Owner está disponible para responder dudas puntuales del equipo sobre las inquietudes que se presentan La comunicación frecuente con el dueño del producto logra solución de dudas e inquietudes que logran que sea fluido el desarrollo Está práctica mitiga el riesgo asociado a la poca comunicación del cliente con el equipo Crear la integridad Un Scrum Master  que remueve impedimentos El Scrum Master es un líder servicial enfocado en remover los impedimentos, ya sea que los resuelva el mismo o busque la colaboración de otros El equipo mantiene su fluidez en el trabajo. El equipo no se detiene por falta de información y trabajo Se delega la responsabilidad de la fluidez en otro que está enfocado en lograrla Reaccionar tan rápido como sea posible El equipo jala trabajo (pull) en vez de que se le asigne (push) Equipo auto organizado Se posee un sprint backlog que generalmente se encuentra dispuesto en un tablero kanban y el equipo decide la mejor  forma de hacer el trabajo No se depende de la asignación de las tareas a realizar, evitando incurrir en pérdidas de tiempo por falta de direccionamiento Los directos responsables y ejecutores  (el equipo) son los  que deciden cómo reaccionar, construir, interacturar y encuentra la mejor manera de hacerlo. Eliminar los desperdicios Reaccionar tan rápido como sea posible Potenciar el equipo LOS ARTEFACTOS Enfoque en valor Product Backlog priorizado y enfocado en lo que más retorno proporcione al producto Se evita construir desperdicio y funcionalidades poco útiles. Menos funcionalidades que construir Menos funcionalidades que probar Menos bugs a corregir Menos despliegues a realizar Menos software al realizarle mantenimiento Menos problemas en producción que desenfocan al equipo Se posterga el desarrollo de lo incierto. Eliminar el desperdicio Decidir lo más tarde posible Sprint Backlog congelado durante el sprint El compromiso para el sprint es definido y congelado Eliminación de reprocesos (dudas, discusiones, etc.) por requisitos inestables Eliminar el desperdicio LAS REUNIONES / CONVERSACIONES Un Planning que compromete a los directos responsables Al principio del ciclo el equipo se reúne con el Product Owner para definir un compromiso y la forma de lograrlo. El equipo selecciona el compromiso de acuerdo a su capacidad(y el compromiso no es impuesto) El equipo entiende qué va a construir y como. Potenciar el equipo Scrum Diario o Daily que sincroniza al equipo Diariamente todo el equipo se reúne a la misma hora, por un máximo de 15 minutos a contarse, Lo hecho ayer Lo que se hará hoy Y los impedimentos Sincroniza al equipo Evidencia los impedimentos o posibles puntos de freno del equipo, para ser gestionados por el Scrum Master El equipo identifica puntos de colaboración Reaccionar tan rápido como sea posible Eliminar los desperdicios Un Review que permite validar cel producto y compromete más al equipo El equipo muestra el resultado del trabajo hecho durante el Sprint al Product Owner Se comprende cómo está evolucionando el producto Se identifica hacia donde seguir avanzando El equipo recibe feedback sobre su trabajo Ampliar el aprendizaje Reaccionar tan rápido como sea posible Potenciar el equipo Crear la integridad Véase todo el conjunto La retrospectiva que busca la mejora continua Cada ciclo –corto -  de desarrollo el equipo se reúne a reflexionar como mejorar para el siguiente ciclo  El equipo está en constante aprendizaje, eliminando lo que no les sirve, mejorando lo actual e experimentando prácticas que los harán más existosos Eliminar los desperdicios Ampliar el aprendizaje Potenciar el equipo Reaccionar tan rápido como sea posible El refinamiento que da contexto y mitiga riesgos Una reunión donde se contextualiza al equipo sobre el trabajo que se va a realizar el próximo sprinr El equipo se contextualiza Se identifican posibles falencias sobre el próximo sprint Eliminar los desperdicios Ampliar el aprendizaje Reaccionar tan rápido como sea posible LAS PRÁCTICAS O FORMA DE HACERLO Ciclos cortos de desarrollo -  Sprints - que mitigan riesgos Se trabaja en ciclos cortos de trabajo donde se construye un producto de forma incremental y completa cada ciclo Se mitiga grandes ciclos de trabajo sin feedback del cliente Cada ciclo busca entregar un incremente integro (no un pedazo incompleto que no puede ser usado) El equipo se conoce y decide cómo trabajar mejor cada ciclo. Permite reaccionar y remover malas practicas. Eliminar los desperdicios Ampliar el aprendizaje Reaccionar tan rápido como sea posible Potenciar el equipo Crear la integridad Véase todo el conjunto Se trabaja por incrementos Cada ciclo entrega un incremento en el producto, el cual es usable , integro y útil. Nota: en la ejecución tradicional, hasta que no se terminan todas las fases no se posee un producto. El equipo da pasos seguros  Se obtiene feedback sobre el producto logrando una construcción acorde con la necesidad Ampliar el aprendizaje Reaccionar tan rápido como sea posible Crear la integridad Véase todo el conjunto Historias de usuario en Ready para el sprint backlog (6)(7) Las historias de usuario deben ingresar claras y bien definidas, sin ambigüedades, ni dudas  al sprint backlog, tanto por parte del Product Owner como del Equipo El equipo navega con certidumbre en el espacio del sprint, y no se incurre en reprocesos por requisitos incompletos, o mal entendidos Eliminar el desperdicio La definition of done /  DoD/ Definición de Terminado / Realizado Existe un punto indiscutible de cómo deben hacerse las cosas para ser aceptadas. Existe una visión compartida de como el trabajo debe ser realizado y todos se comprometen a lograrlo. Evita ambigüedades Potenciar el equipo Un equipo multidisciplinario que logra el Done Un equipo con todos los roles requeridos para lograr el DONE!! Se evitan burocracias Se tiene una visión compartida sobre la cual trabajan todos No hay fraccionamiento entre el equipo de proyecto cayendo en frases como “los de pruebas” o “los de desarrollo”, todos trabajan juntos con un mismo objetivo Reaccionar tan rápido como sea posible Potenciar el equipo Historias Just in Time – JIT - / Justo a Tiempo El equipo entrega las funcionalidades que cumplen el Done antes del review al Product Owner para su aceptación Se evita que haya reprocesos por funcionalidades mal entendidas Se reduce el tiempo del review Si existe algún mal entendido en alguna funcionalidad, se corrige rápido evitando que se rechace la funcionalidad en el Review Reaccionar tan rápido como sea posible Ampliar el aprendizaje Eliminar los desperdicios Transparencia que permite a todos saber el estado de las cosas Todo el equipo scrum a su alrededor está rodeado de radiadores de información que informa el estado del producto, proyecto, metas, calidad, felicidad entre otros. Todo el equipo scrum ( Product Owner, Scrum Master y Team) conocen el estado del proyecto permitiéndoles reaccionar de forma rápida. El Burndown chart del sprint informa si se va a lograr el objetivo El Burndow o Burn Up Release informa cuando se liberará el producto Gráficas de deuda técnica, errores por sprint, errores en producción dan visibilidad de la salud técnica y de la calidad del proyecto Gráficas de felicidad dan cuenta de como esta el equipo respecto a su entorno entre más herramientas ideadas o identificadas por el equipo Reaccionar tan rápido como sea posible Ampliar el aprendizaje

Bienvenidos los comentarios y/o observaciones.

Saludos ágiles

Jorge Abad

Definiciones y aclaraciones

(1) Hacer las cosas a la maldita sea: expresión colombiana que en muchos casos significa ejecutar con poca atención, descuido, desgano – hasta con disgusto - y alta probabilidad de error,  de forma que las  cosas quedan medio hechas y requiere casi volver a hacerlas para que queden bien. 

(2) Velocidad: cantidad de software producido en una unidad de tiempo

(3) Productividad: construir el producto correcto 

(4) Las prácticas “ágiles” (o técnicas)  no son propiedad de las metodologías ágiles – o marcos ágiles –y pueden ser empleadas en contextos de gestión tradicional con igual éxito

(5) Principios de Lean Software Development (ver más acá):

• Eliminar los desperdicios
• Ampliar el aprendizaje
• Decidir lo más tarde posible
• Reaccionar tan rápido como sea posible
• Potenciar el equipo
• Crear la integridad
• Véase todo el conjunto

(6) Esta práctica no pertenece a Scrum pero es muy empleada con el marco de trabajo.

(7) Aunque Scrum no habla de historia de usuario, si habla de Sprint Backlog con ítems en “ready”, estos ítems, pueden ser historias de usuario, casos de uso, requerimientos en prosa, lo que sea que el equipo determine usar, aunque si es más ampliamente recomendado emplear historias de usuario