Este blog comparte estrategias y aprendizajes sobre desarrollo de software, marcos, métodos y metodologías ágiles como Scrum, Kanban y XP, con un enfoque en escalamiento ágil y Business Agility. Su propósito es ayudar a profesionales de la gerencia de proyectos, productos, scrum masters, agile coaches, agentes de cambio, y líderes a mejorar sus procesos y promover la experimentación como motor de innovación, facilitando su adaptación en entornos empresariales cambiantes.
Constantemente en procesos de Transformación Agile-DevOps me encuentro con lo que he llamado: “La Excusa SOX*”, es decir, me objetan alivianar los procesos diciendo: - “el proceso no puede ser más liviano porque SOX no lo permite”, a lo que respondo:
“Si tu freno para tener procesos más livianos (LEAN-Agile-DevOps) son todos los formatos de SOX ¿Cómo hacen en AMAZON, NETFLIX, etc., para salir a producción CIENTOS de veces al día, sabiendo que son empresas mucho más reguladas, tienen SOX y están en la bolsa de Nueva York?”
Siempre concluyo que el problema no es la regulación, sino la mentalidad en áreas de riesgos y procesos al implementarla; y su falta de mejora continua buscando simplificar y automatizar cada vez más el proceso.
Hace poco un amigo me preguntó ¿Qué métricas usaría evaluar a un Líder de Transformación Ágil? o ¿Cómo le evaluaría? A continuación, les comparto mi respuesta.
En mi criterio se deben evaluar tres dimensiones:
Mejora de la agilidad de los equipos a cargo
Madurez ágil.:¿Qué tanto han madurado los equipos ágiles a cargo respecto al último periodo? Para esta métrica se requiere un modelo de madurez instaurado en la organización para evaluación de la agilidad de equipos ágiles, y como se puede observar la idea es que es líder mejore la agilidad de esos equipos, es decir, su madurez en términos de uso de principios, marcos ágiles, prácticas ágiles de desarrollo y DevOps.
Número de releases:Incremento del número de releases respecto al último periodo. Esta métrica tiene como propósito determinar si el líder ha incrementado la cantidad de salidas a producción, lo que implica, que hay uso de conceptos de Mínimo Producto Viable, y salidas a producción incrementales. Otra métrica posible a adicionar de este mismo tipo sobre la cual el líder tiene influencia directa es el Time to Market, medido desde que nace la inciativa hasta el primer release.
Resultados de Negocio
Satisfacción del cliente:¿Qué tanto ha mejorado la satisfacción del cliente desde el último periodo?, El propósito de esta métrica es hacer al líder responsable de lograr que se mueva esta importante métrica de negocio, de forma que se haga cargo de que los releases a producción sean de valor y se esté evaluando constantemente la satisfacción del cliente, ya sea con métricas directas como el NPS o encuestas, o indirectas derivadas del uso del sistema, tales como recomendación de las soluciones hacia otros usuarios, incremento de intalaciones, aumento de uso de las plataformas, tiempo de uso la solución más altos, entre otras.
Agente de Cambio
Calidad de sus interacciones: Evaluación 360 de las personas con las que interactúa. El propósito de esta métrica es identificar cómo es la relación con su entorno y cómo ejerce su liderazgo de agente de cambio.
Notas Finales
El peso de cada medida lo decidirá el contexto, yo recomiendo el mismo para las tres dimensiones.
Este tipo de evaluaciones también servirían para un Agile Coach
Estas dimensiones son las que usamos para evaluar Agile Coaches y Líderes de Transformación en mi entorno y nos han dado buenos resultados, es decir, hablo de ellas con conocimiento de causa.
"No se puede pensar en Agilidad Empresarial sin tener Agilidad Operativa, pero de nada sirve tener Agilidad Operativa si el resto de la organización no es Ágil." - Jorge Abad
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
Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo
Dividir una Historia de Usuario
(clic aquí)
Veo con frecuencia tantas implementaciones cojas de Agile y DevOps, que en vez de burlarme de ellas y de los implementadores - como lamentablemente lo observo en las redes - quiero hacerle estas dos preguntas a los que son clientes:
Pregunta 1: ¿Cuando #Agile y #DevOps sean el estado del arte en tu organización y de la industria, es decir un commodity, por fin te vas a decidir a innovar y a poner realmente al negocio liderando equipos agiles enfocados en generarle valor al cliente? ¿No crees que será muy tarde?
Pregunta 2: ¿Basado en lo anterior, para cuándo te vas a decidir a hacer #Agile y #DevOps en serio, o vas a dejar que tu competencia te tome ventaja en ello?
Abro la discusión, si lo deseas en la zona de comentarios, o en mis redes sociales:
La búsqueda de la Excelencia Técnica debe ser la obsesión de toda empresa, área y equipo que trabaje con tecnología, obvio de nada sirve la excelencia técnica sino hay personas trabajando en equipo, empoderadas y con seguridad sicológica (recordemos soy agilista y este tipo de empoderamiento da resultado y ha sido demostrado miles de veces en la industria), pero también es cierto, que sin excelencia técnica no hay agilidad, ni nada. Sin buen software todos estamos perdiendo el tiempo.
"Sin buen software, todos estamos perdiendo el tiempo"
A continuación, les comparto el listado del prácticas técnicas más usadas por los equipos hoy (Julio 26 de 2020) según el 14th State of Agile:
Unit testing
Coding standards
Continuous integration
Refactoring
Continuous delivery
Automated acceptance testing
Continuous deployment
Pair programming
Test-driven development
Collective code ownership
Sustainable pace
Behavior-driven development (bdd)
Emergent design
Y las prácticas usadas por los equipos de élite DORA Reseaarch (2):
Code Maintainability
Continuous Integration
Continuous Testing
Database Change Management
Deployment Automation
Empowered Teams
Loosely Coupled Architecture
Monitoring & Observability
Proactive Notifications
Shift Left on Security
Test Automation
Test Data Management
Trunk-Based Development
Version Control
Marqué en rojo las únicas que están en común, queda en tus manos determinar cuales utilizar en tu equipo, y si es que existe alguna brecha, cómo será tu proyecto de adopción.
Saludos ágiles
Jorge Abad
Notas, Referencias, Aclaraciones, Comentarios y Observaciones
"Lean Manufacturing es un proceso de cinco pasos: definir el valor del cliente, definir el flujo de valor, hacerlo "fluir", tirarlo (pull) desde el final (cliente), perseguir la excelencia"
Uno de los informes que más ha tomado fuerza dentro del mundo Ágil y de DevOps es el elaborado por DORA (DevOps Research and Assessment): "Accelerate: State of DevOps", en la versión de 2018 "Accelerate: State of DevOpsStrategies for a New Economy 2018"(1)(clic aquí), en su capítulo "Influencing culture through learning" se encuentra este interesante texto
"We found that learning reviews help contribute to a climate for learning and also impact organizational culture. It is important to note that this is true when teams conduct them to learn from their mistakes and failures and then turn these into opportunities to improve how they work. In particular, teams that leverage findings from retrospectives to implement changes to tooling, processes, or procedures see the strongest impacts.
Our analysis found that elite performers are 1.5 times more likely to consistently hold retrospectives and use them to improve their work. When we asked respondents about their most recent retrospective, we see common themes around outages, failures, performance, and deployment."
Traducido
"Descubrimos que las revisiones de aprendizaje ayudan a contribuir a un clima para el aprendizaje y también impactan la cultura organizacional. Es importante tener en cuenta que esto es cierto cuando los equipos los conducen para aprender de sus errores y fracasos y luego los convierten en oportunidades para mejorar su funcionamiento. En particular, los equipos que aprovechan los hallazgos de las retrospectivas para implementar cambios en las herramientas, procesos o procedimientos ven los impactos más fuertes.
Nuestro análisis encontró que los Jugadores de Élite tienen 1.5 veces más probabilidades de tener retrospectivas consistentemente y usarlas para mejorar su trabajo. Cuando preguntamos a los encuestados acerca de su retrospectiva más reciente, vemos temas comunes sobre interrupciones, fallas, rendimiento y despliegue."
Luego comparten esta nube de temas que se discuten en los equipos élite en el mundo
Tomado de (1)
El listado de palabras en orden alfabético las encuentras al final del post(3).
Invitación
Una de las recomendaciones e invitaciones que hago a los Scrum Masters, Facilitadores, Líderes Ágiles y Equipos de Desarrollo que tienen cierta madurez haciendo Scrum o cualquier otro marco es:
"tarde o temprano tus retrospectivas tienen que hablar del tema técnico, o ¿vas a seguir perfeccionando la comunicación y el proceso en el sprint 20 y siguientes?, es urgente que veas el elefante en el cuarto si quieres llevar a tu equipo al alto desempeño"
No estoy afirmando que: "no sea necesario mejorar el proceso y el trabajo en equipo", si hay que mejorarlos se hace, pero el tema técnico es un tema obligatorio a tocar en las retrospectivas, y más si deseas alcanzar alto desempeño.
Scrum Master y Equipo evitando hablar del tema técnico
Basado en la sugerencia anterior he escrito y compartido post similares en el pasado:
Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo (clic aquí)
Presentación: Los puntos ciegos del Scrum Master (clic aquí)
Quedan entonces dos preguntas
¿de qué tema hablaron en la última retrospectiva de tu equipo?
¿y tus retrospectivas cuándo van a ser de tipo Élite?
Desde hace un tiempo vengo trabajando, e incluyendo en mis entrenamientos el concepto de Costo del Retraso (Cost of Delay), el cual desarrolló magistralmente Donald Reinertsen en su libro The Principles of Product Development Flow, y una de sus frases más famosas es:
"Si solo puede cuantificar una cosa, cuantifique el Costo del Retraso" -Donald Reinertsen
Algunas definiciones de este concepto son:
Costo del retraso:
El costo del retraso es "una forma de comunicar el impacto del tiempo en los resultados que esperamos lograr". (1)
"¿Cuánto nos costaría si esto se retrasara 1 mes?"(1)
"¿Qué valdría para nosotros si pudiéramos obtener esto 1 mes antes?"(1)
¿Cuánto dejamos de ganar si nos atrasamos un mes?
¿Cuánto le cuesta a la compañía por unidad de tiempo no tener una funcionalidad liberada oportunamente?
Y justo con esta aproximación me encontré en el reporte de DevOps elaborado por DORA en https://devops-research.com/, en este informe, se observa la gráfica elaborada en Maersk por el equipo de desarrollo de un proyecto en donde se representa el costo del retraso/semana vs la cantidad de requisitos liberados en esa unidad de tiempo (del cual se infiere el Lead Time promedio del requisito).
En esta gráfica se visualiza el costo del retraso generado por liberar tres requisitos por semana, sumando aproximadamente 7 millones de dólares, a liberar más de 23 requisitos en ese mismo periodo de tiempo y reduciendo este costo casi a cero.
Esta curva es asombrosa, pues genera consciencia de varios aspectos:
la importancia de estar generando valor de forma continua
el impacto en los ingresos de la organización de una estrategia de liberación pausada o continua
cualquier esfuerzo de mejora en el ciclo de desarrollo de software y en su proceso de liberación, conlleva a un impacto económico que puede llegar a ser exponencial.
la importancia de liberar continuamente para validar hipótesis y adaptarse rápidamente al mercado.
la capacidad de validar hipótesis en un escenario de alto rendimiento es exponencial
Bajo este panorama surgen varias preguntas
¿Su organización mide el costo del retraso de sus proyectos?¿de uno solo? ¿de todo su portafolio?¿la PMO lo hace?
¿Como sería la curva costo del retraso por semana para los requisitos de tu organización o de tu proyecto?
La discusión sobre si Ágil-DevOps es barato desaparece, la pregunta que aparece es
¿qué tan costoso te esta saliendo no ser Ágil-DevOps (Agile-DevOps)?
¿cómo será la curva en los de alto performance, es decir, Google, Facebook, Amazon, Netflix, etc?
