Agilidad Empresarial y Agilidad Operativa

 

"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

De qué hablamos cuando hablamos de historias de usuario (Presentación)

Tweet: La Agilidad no se Demuestra con Radares, se Evidencia con Resultados de Negocio

La agilidad no se demuestra con radares, los radares muestran brechas, la agilidad se evidencia con resultados de negocio- Jorge Abadhttps://t.co/HbKogXtxKe#Agile #BusinessAgility #EnterpriseAgility #Agility pic.twitter.com/n6BliRfsyg

— Jorge Hernán Abad L. (@jorge_abad) October 27, 2020

La Necesidad de la Innovación Radical del Liderazgo

Recuerdo mucho una frase que de niño repetían en mi familia:

"Las cosas se parecen a su dueño"

y un patrón que todos hemos visto, es como las organizaciones, las gerencias y los equipos de trabajo, se parecen a quienes los lideran, en últimas, es una tendencia normal y común que los líderes busquen personas de confianza que en últimas tomen decisiones similares a las de ellos o como son ellos.

Lo cierto, es que en este acompañar a organizaciones y grandes áreas en su proceso hacia la agilidad, he observado que el principal obstáculo se encuentra en el liderazgo, pues adoptar marcos y prácticas, aunque es complejo (ver Cynefin(1)), es relativamente fácil, versus el esfuerzo que hay que hacer con los líderes para que no destruyan lo que se está movilizando en la organización, que es un nuevo mindset, que nos permite reaccionar rápido al cambio mientas al mismo tiempo vamos generando valor.

 Es común encontrarse en nuestras organizaciones: directivos que no se hablan entre sí, que se sabotean mutuamente, donde la explotación de los empleados internos y de los proveedores es la regla, donde es común exigir resultados sin proporcionar los suficientes recursos para lograrlos, en las que existe una mentalidad fija y orientada a solo cumplir, con un excesivo control sobre las personas y equipos (ej.: lo que no les permite avanzar debido a estar haciendo excesivos informes que nadie lee), con incapacidad para generar espacios de seguridad sicológica donde se pueda fallar sin temor, donde la innovación es frustrada por la falta de presupuesto o de mindset adecuado, donde no saben o desconocen cómo aplicar las prácticas esenciales de gestión asociadas a Lean, y otras series de disfunciones como las que expone Kofman(2):

• Arrogancia ontológica: “mi verdad es la única”
• Culpa incondicional: “no fue mi culpa, fue de…”, “el comité fue el que decidió”
• Comunicación Manipuladora: ocultar datos, engañar, doble discurso
• Egoísmo esencial: “solo mi bienestar”
• Negociación narcisista: un juego político gobernado por: “vencer al adversario, mostrar “quien manda”
• Coordinación Negligente: promesas sin intención de ser cumplidas, pedidos inefectivos,

que terminan haciéndonos vivir en organizaciones enfermas, donde el ambiente de colaboración, transparencia, hiperproductividad que promueve la Agilidad, es sofocado por el estilo de gestión del siglo pasado que se resiste a morir. Si, debemos reformular el liderazgo, es necesaria una transición hacia entornos de abundancia que tanto leemos en los libros de gerencia, revistas de gestión y financieras; donde se adopten de forma consistente las prácticas que promovieron Deming, Taichii Onho, Drucker, Senge, Blanchard entre otros; si esto hubiese sido así, no estaríamos viendo con ojos de deseo a Google, NuBank, LinkedIn, Toyota, Netflix, Amazon, etc. Como dato curioso, cualquiera que se documente en libros sobre Amazon, pronto verá reflejado los 14 principios de Toyota(3), el Lean Mindset y lo que promovía Onho. Debemos entonces, reformular una INNOVACIÓN RADICAL EN EL LIDERAZGO, o estos gigantes, o cualquier pequeño que lo empiece hacer bien nos quitaran el mercado y desaparecerá nuestra organización.

Hace poco compartía con alguien de una empresa importante: “este estilo de liderazgo disfuncional del siglo pasado está destinado a desaparecer, ya sea porque este estilo destruirá tu empresa y otra rápido los superará, o porque este gerente/director/vicepresidente/presidente aprende una nueva forma de hacer las cosas o en definitiva es reemplazado; pero cada vez más, las personas, organizaciones y clientes toleran menos esta forma de gestión”

 

Necesitamos lideres con:

• Mentes Abiertas a posibilidades, dispuestas a aprender, empoderar y retar
• Que estén en una lucha constante por maximizar la colaboración en la organización, eliminando cualquier fuente de fricción, y generando fluencia
• En el que la transparencia sea radicalmente brutal y no se castigue al mensajero de las malas noticias, toda información sea vista como fuente de aprendizaje y de reacción al entorno.
• Que este en una lucha incondicional contra los 8 desperdicios de lean
• Su compromiso con la mejora continua, la calidad, la reducción del time to market y la generación de valor sean validados frecuentemente con datos y hechos
• Que rete el statu quo y esté abierto a recibir e intentar opciones diversas
• Que sepa priorizar por valor y gestione de forma eficiente la capacidad finita que tiene
• Que tengan visión a largo plazo
• Que sean capaces de hacer de la innovación una capacidad de la empresa
• Que admita estar equivocado y aprender
• Que lidere e inspire con el ejemplo
• Que trate a las personas como personas y no como un "recurso" que debe explotarse al 100%, orientando al logro y que retando a los equipos y colaboradores sin maltratarlos
• Que comprenda, que la responsabilidad del liderazgo le fue conferida para generar bienestar y abundancia
• Que exija hacia el resto de sus colaboradores un estilo de gerencia ejemplar como el que el promueve (3)
• Que tengan las virtudes que promueve Kofman: responsabilidad incondicional, integridad esencial, humildad ontológica, comunicación auténtica, negociación constructiva, coordinación impecable y maestría emocional

Yo estoy en ese viaje de la INNOVACIÓN RADICAL DEL LIDERAZGO ¿y tú?

 

Saludos Ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Cynefin - https://en.wikipedia.org/wiki/Cynefin_framework
2. La Empresa Consciente.Fred Kofman. https://www.amazon.com/-/es/Fredy-Kofman-ebook/dp/B009RWDG3A
3. Toyota Way - https://www.amazon.com/-/es/Toyota-Way-Jeffrey-Liker/dp/0071392319
4. Antipatrón: Solo liderar la primera línea y no gestionar la red - http://www.lecciones-aprendidas.info/2019/08/antipatron-solo-liderar-la-primera-linea-y-no-gestionar-la-red.html
5. Una propuesta de Definición: Gerente de Proyectos Ágil - http://www.lecciones-aprendidas.info/2016/06/una-propuesta-de-definicion-gerente-de.html

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

Hola a todos

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

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

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

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

Por el Enfoque en el Valor

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

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

Y como muchos agilistas y textos dicen:

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

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

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

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

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

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

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

Veamos,

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

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

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

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

Unos Consejos 

A continuación, unos consejos para cerrar:

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

Unas Preguntas que Invitan a la Acción

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

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

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

Varios proyectos a la vez generará más retraso en la generación de valor. Limita el WIP.

Hola a todos

Muchas veces tenemos la sensación de que debemos satisfacer las necesidades de todas las áreas o personas que nos piden tareas, requerimientos o proyectos, esto sucede a nivel:

• individual
• de equipo
• de áreas de construcción o ejecución de proyectos y productos de software,

con la sensación de que debemos atenderlos a todos, ya sea para no generar quejas, o por evitar problemas políticos, pero esto en vez de ayudarnos generará:

• pérdida de foco
• grandes esfuerzos de gestión y pérdida de energía, pues debes estar pendiente de varias cosas a la vez
• retrasos en la entrega, que a su vez generará:
• más inconformidad en las áreas que esperan resultados
• pérdida de valor de las funcionalidades construidas y la necesidad de introducir cambios
• sobrecostos por los cambios introducidos
• pérdida de dinero debido a la no generación oportuna de valor
• poca flexibilidad para reaccionar a los cambios, debido a que debes resolver muchas cosas a la vez y habrá demoras resolviendo un problema puntual.

Por eso, si lideras un equipo, un área de ejecución o aún de forma individual, te sugiero que:

• tengas foco
• hagas una o pocas cosas a la vez
• Limita el Work In Progres (WIP) o trabajo en progreso
• Aprende a decir ¡No!

Sino, tu propias ganas de satisfacer a todos, distruirá tu propósito de generar valor, cayendo en el adagio popular 

"El que mucho abarca, poco aprieta"

Saludos ágiles

Jorge Abad

Cómo Estimar la Capacidad (Velocidad) de tu Equipo Scrum en el Primer Sprint