Let's talk about Digital Transformation

¿Cuándo podríamos estimar una historia de usuario con mejor certeza? La matriz de Stacey, una técnica a usar en el Refinamiento

Hola a todos

La matriz desarrollada por Ralph Stacey, conocida como la Matriz de Stacey, permite entender cuando de acuerdo con los ejes de Requerimientos y Tecnología, podemos tener una aproximación de gestión simple, complicada, compleja;

Matriz de Stacey. Tomado de (1)

 

y dados estos escenarios, se ha usado en los últimos años, para justificar en que escenarios trabajar con métodos tradicionales y cuando con enfoques ágiles (existen cientos de artículos al respecto).

Matriz de Stacey. Tomado de (2)

Usando este mismo enfoque, podríamos identificar en un taller de Inception o de Refinamiento, cuando una historia de usuario o una épica incluye mucha o poca incertidumbre para ser estimada y, por ende, desarrollada, tanto desde el punto de vista de requerimientos, como de tecnología, proporcionándonos estimaciones indirectas sobre tiempos y esfuerzos requeridos (toda estimación incluye una probabilidad y una incertidumbre asociada).

La zona donde cualquier equipo de desarrollo, ágil o no, estima con confianza, es aquella donde hay alta certeza en los requerimientos y alto certeza en la tecnología y forma de construirlo. Los Product Owners deben procurar que la mayoría de las historias de usuario y épicas que llevan a un equipo se encuentran en esta zona. Ahora, si existe incertidumbre, podríamos hacer uso de técnicas de partición de historias de usuario (3) o de spikes para realizar investigaciones de aquellos elementos que no se encuentran claros al momento de desarrollar.

Los equipos ágiles deben preferir historias en esta zona de confianza, y estos elementos podría hacer parte de una Definición de Ready o Preparado adecuada, para que las historias puedan ser incluidas en el planning. Los siguientes criterios que garantizan esta zona de estimación con certeza: 

• Las historias cumplen cumplen INVEST y las 3C
• Existe un entendimiento consistente de parte del product owner y del equipo acerca de la historia de usuario.
• Las historias cuentan con claros criterios de aceptación 
• Se han resuelto las dependencias técnicas y funcionales
• Las ambigüedades se han resuelto
• El tiempo para construir-probar-desplegar la historia de usuario se encuentra en horizontes de tiempo menor o igual a 4 días-persona (esto es una heurística que he observado en los equipos ágiles, en este número de dias las estimaciones son más certeras y confiables. Habrá que hacer un estudio riguroso para confirmar mi experiencia e hipótesis).

Para cerrar, los invito a que usen esta matriz para realizar refinamiento de historias de usuario con sus equipos, asegúrense que existe certidumbre en la tecnologia y acuerdo en los requerimientos, de esta forma fluirán mejor sus sesiones de planning y no se enfrascarán en discusiones innecesarias.

Saludos ágiles,

Jorge Abad

Referencias

1. Entendiendo la complejidad: La matriz de Stacey - https://academy.jeronimopalacios.com/courses/145560/lectures/5315213
2. https://www.researchgate.net/figure/Stacey-Matrix-Stacey-1996-adapted-to-software-development_fig3_336899045
3. Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario

La Agilidad en la era de la Transformación Digital

Estamos en tiempos altamente cambiantes y turbulentos: el COVID, el cambio climático, la guerra que se cierne sobre Ucrania amenazando la estabilidad y el orden mundial, más los avances de la inteligencia artificial, metaverso, las criptomonedas, la robótica, la carrera privada por conquistar el sistema solar, entre muchas cosas más, desafían nuestra imaginación, nuestra forma de vivir y de reaccionar a un mundo que reta a todos aquellos que fuimos formados en el siglo pasado, y a quienes tenemos la fortuna de formar a los nacidos en este siglo, pues estamos batallando hombro a hombro con formas de pensar disruptivas y a la vez retadoras. 

Hay que reconocerlo, estamos frente a frente contra mentes como las de Elon Musk, Jeff Bezos, Satya Nadella y Mark Zuckerberg (por solo mencionar a unos cuantos), pues al “aplanar” la Internet al mundo, las ideas y negocios de todos compiten entre sí, grandes y pequeños acceden a la misma visibilidad, velocidad, tecnología y preponderancia, pudiendo en cualquier momento tomar una porción de mercado inimaginada, donde el usuario es el rey.

Pero, quisiera antes de avanzar, tomar una afirmación respecto a la agilidad de mi gran amigo @LuchoSalazar:

"Agilidad es solo una"(1)

Y sí, después de ir a muchas fuentes y revisar mucha bibliografía, que pondré al final de este artículo (2), me atrevería a definirla como:

Agilidad (para el contexto empresarial, de los negocios y de desarrollo de software): Es la habilidad de responder —e incluso liderar— el cambio, generando valor de un equipo de trabajo, un área funcional, una empresa, un gremio o un grupo humano.(3)

Y es allí en donde está el desafío al cual nos estamos enfrentando, el mundo de hoy demanda que seamos capaces de girar las velas de nuestra organización y nuestra vida casi de forma inmediata, y lo cierto, es que muy pocos son capaces de hacerlo.

"Bienaventurados los flexibles porque no se romperán cuando los doblen" Michael McGriff

Somos burocráticos, amantes del control y del poder, de imponer nuestro punto de vista, de querer predecir y exigir los resultados, enfocados en exprimir a nuestros colaboradores y proveedores, en últimas, un liderazgo del siglo pasado, un liderazgo añejo que es inútil en este mundo que cambia a ritmo vertiginoso, a la velocidad de la Transformación Digital. 

Esta era requiere de un nuevo liderazgo, un liderazgo ágil que empodere a los equipos, que no tema innovar, que no tema delegar, que acepte que no tiene la razón, que comprometa y direccione; sin este liderazgo cualquier reacción al cambio será tardía y el impacto en nuestros clientes será cada vez más desfavorable.

Quisiera cerrar este artículo con esta afirmación; 

"En el largo plazo, de poco sirve hacer proyectos que involucren tecnologías digitales como: RPA, robótica, customer centricity, machine learning, realidad aumentada, big data, metaverso, blockchain, etc., sino cambiamos nuestra forma de pensar y liderar e incluimos la agilidad dentro de las capacidades core de la organización, pues estaríamos resolviendo nuestros problemas presentes, pero estaríamos desamparando los problemas del futuro"

Saludos ágiles

Jorge abad

Referencias:

1. Lo que no les enseñan a los CEO sobre agilidad
2. Links para profundizar sobre varias definiciones de Agilidad, Business Agility, Enterprise Agility:
• Agile en la Agile Alliance: "Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment." https://www.agilealliance.org/agile101/
• Business Agility en la Agile Alliance:
•  "Business agility is the ability of an organization to sense changes internally or externally and respond accordingly in order to deliver value to its customers" https://www.agilealliance.org/agile101/agile-glossary/
• Business Agility - https://www.agilealliance.org/glossary/business-agility 
• Business Agility por el Business Agility Institute: "Business Agility is a set of organizational capabilities, behaviors, and ways of working that affords your business the freedom, flexibility, and resilience to achieve its purpose. No matter what the future brings." https://businessagility.institute/
• La primera vez que se escribió de Business Agility: 
• Paradigm Shift International - http://parshift.com/library.htm
• Response Ability: The Language, Structure, and Culture of the Agile Enterprise https://www.amazon.com/Response-Ability-Language-Structure-Enterprise/dp/0471350184/
3. Elaboración propia.

Retorno a la inocencia. Una invitación a compartir conocimiento

Hace poco hablaba con un gran amigo y agile coach, Carlos Palacio, sobre la necesidad de ser inocentes e ingenuos a la hora de escribir, y observábamos lo importante de liberarse de la carga de satisfacer a todos cuando estamos compartiendo conocimiento.

Y en esa conversación recordé que una de mis motivaciones para tener este blog era así, sencilla e ingenua: "ayudar a otras personas con lo que yo he experimentado y devolver un poco de lo que he recibido al leer a otros".

Reconozco que he crecido como bloguero y referente por este acto, por estas ganas de retribuir lo que he ganado al leer (escuchar y ver) a otros en el mundo de la agilidad y los negocios y llevarlo a mi empirismo; y hoy quiero escribirte a ti, que de vez en cuando me lees o que por suerte te topaste con esto y tienes ganas de compartir conocimientos y experiencias, pero sientes miedo a ser criticado o cuestionado, pues bien, deseo animarte y decirte que estoy seguro de que has vivido cosas que a otros le van a servir, que tu punto de vista les enriquecerá, les hará crecer, y les darás ideas para muchas circunstancias, no importa que alguien más lo haya hecho antes, tu mirada es única, valiosa e irrepetible..

Todos ganamos con el conocimiento de todos, nos apoyamos y generamos una gran red que nos impulsa a llegar más lejos. Yo, estaré ansioso de leerte y agradecerte por también ayudarme en mi camino. Como lo escribió Newton:

"Si he visto más lejos ha sido porque he subido a hombros de gigantes" Atribuida a Newton (1)(2)

Saludos ágiles

Jorge Abad

Notas y Comentarios

1. https://es.wikipedia.org/wiki/Pararse_sobre_hombros_de_gigantes
2. Dos recomendaciones: usa referencias cuando emplees cosas de otros y revisa la ortografía, ambas prácticas darán profesionalismo y estructura a lo que compartes.

Respuestas Ágiles: vengo fallando los últimos 4 sprints ¿Qué hago?

Caricatura: Deuda Técnica - Ya todo tiene sentido

 

Nota Preocupante:

Existen muchos Equipos Ágiles, Scrum Masters, Product Owners, Áreas de Sistemas, CIOs y Organizaciones que no gestionan la deuda técnica.

De Colección: De la Idea hasta las Historias de Usuario del Sprint Backlog - Un Ejemplo Completo

Hola a todos

Les comparto un ejemplo que desarrollé desde la Idea hasta el Sprint backlog de los primeros tres sprints. Los artefactos elaborados son;

• Elevator Pitch (Visión)
• Product Vision Board
• Ideación de posibles funcionalidades
• Asignación del valor usando la serie de Fibonacci modificada. 
• Asignación del esfuerzo usando la serie de Fibonacci modificada
• Uso del Modelo Kano de priorización para identificación de funcionalidades clave
• Elaboración del User Story Map
• Visión End-2-End
• Cálculo de la relacion Valor / Duración de cada funcionalidad
• Priorización de funcionalidades usando MoSCoW
• Identificacion del Producto Minimo Viable (MVP)
• Plan de Releases
• Roadmap del producto
• Explicacion del cálculo del tiempo y costo
• Product Backlog vertical, donde cada realese esta priorizado por la relación Valor/Duración
• División de historias de usuario de las primeras tres funcionalidades o épicas
• Identificación de los primeros tres sprints donde la velocidad promedio del equipo es aproximadamente 20 puntos de historia por sprint.

La imagen la pueden descargar en alta resolución de:

• formato png - clic aquí 
• formato pdf - clic aquí

Actualización 2022-11-10


Enlace a Mural - Clic aquí -