domingo, 25 de agosto de 2019

¿Es la Agilidad solo una moda?

Transformación digital - cortesía de Pixabay
Sin duda hay empresas, y probablemente grandes compañías, para las que la Agilidad es un "moda" a seguir, sellos de certificaciones de calidad y procesos a obtener para poder licitar, o simplemente para practicar el "agilipostureo" y estar "in". En otros casos hay compañías que siguen la "moda" para cumplir con los objetivos estratégicos de transformación ágil, con la idea de que los métodos ágiles aportarán soluciones mágicas a corto plazo que aumenten la productividad de los equipos y bajen los costes... creyendo que eso fuera posible sin cambiar estructura ni cultura.

La Agilidad busca entregar un buen producto además del producto correcto, por tanto invertir el presupuesto que tenga la compañía de la mejor forma posible... eso suena muy bien y de hecho para muchas compañías construir el producto correcto es un necesidad de supervivencia aunque no sean conscientes todavía. El producto correcto no implica alta productividad, sino en acertar en el producto y que este sea de alta calidad; en otras palabras ser productivos en términos de entrega de valor a nuestros clientes. Y eso sumado a sacar el máximo de las personas que hacen el trabajo, personas motivadas que para hacer cosas serias y grandes disfrutan haciéndolo.

Una realidad palpable que está ocurriendo en todas las áreas es la transformación digital, el uso de robots combinados con el uso de la internet de las cosas y el aprendizaje automático está cambiando quién hace el trabajo y está cambiando fuertemente el panorama del empleo.

Empleos como cajeros, brokers de seguros, agentes inmobiliarios, analistas de riesgos, asesores de inversiones, periodistas gráficos, reporteros, taxistas, conductores, traductores, personal de limpieza, grabadores de datos, contables, secretarios, trabajadores de fábricas y cadenas de montaje, trabajadores de servicio al cliente y muchos más van a ser reemplazados por la automatización.

Por otro lado los empleos que requieran creatividad, inteligencia social y un alto nivel de complejidad o destreza crecerán, como lo son los científicos de datos (big data), los especialistas en inteligencia artificial y aprendizaje de máquinas, los desarrolladores de software y aplicaciones, los analistas, expertos en robótica, en drones y en ciberseguridad, los profesionales de ventas y marketing y otros más.

Personas sobre procesos - cortesía de Pixabay
Por lo tanto los empleos del futuro son aquellos que den respuesta a un mundo donde lo constante es y será el cambio, un mundo donde la incertidumbre es consustancial y la capacidad de adaptarse rápidamente a los cambios que surjan es esencial. Los empleos del futuro son aquellos donde las personas tengan que pensar activamente, innovar y tomar decisiones de forma descentralizada.

Si lo miramos desde la perspectiva del marco de Cynefin vemos que los empleos a desaparecer son los de los dominios simple y complicado, y los empleos emergentes son aquellos de los dominios complejo y caótico.

La Agilidad da solución al dominio complejo, por ejemplo donde con Scrum podemos encontrar prácticas emergentes a problemas adaptativos complejos a través de sus ciclos de inspección y adaptación.

Los trabajos donde no haya que pensar y solo seguir un conjunto de reglas, o se pueda crear un algoritmo que los ejecute, están siendo automatizados y por tanto desaparecerán como empleos. Las compañías automatizables tendrán escasos empleados, la compañías no automatizables, que requieran de adaptación constante y empleados que lidien con el cambio, necesitaran para sobrevivir los valores y principios de la Agilidad. Para estas compañías la Agilidad no será una moda, será un necesidad para poder sobrevivir.

domingo, 18 de agosto de 2019

¿Un par de chistes relacionados con la Agilidad?

Thanks to Oliver from Geek & Poke
Hay algunos chistes que tienen que ver con la Agilidad, o sus disfunciones, y que me han hecho mucha gracia y que he decidido compartir en este post.

1. DoAD. La imagen la izquierda, una disfunción clásica: DoAD o definición de casi hecho, que a veces también se presenta como DoD seguido de DoDD; cuando finalmente está "done done".

Hay que comprender que si queremos ser ágiles y poner nuestro foco en generar valor este solo está presente en una funcionalidad si esta está acabada al 100%, sino simplemente no está, una funcionalidad acabada al 99% tiene valor = 0. Una de las lecciones más difíciles para algunas compañías es aprender a permitir que sus equipos encuentren el ritmo en el que sprint a sprint entreguen funcionalidades acabadas al 100%.

2. Ante un vaso medio lleno algunos lo verían medio lleno y otros medio vacío, pero, ¿qué diría un Scrum Master? ... pues preguntaría ¿porqué el vaso es tan grande?

Este chiste me encanta ya que pone foco en las dos características clave de un Scrum Master: las personas y el proceso. Desde la perspectiva de las personas con un vaso más pequeño todo el mundo lo vería lleno, lo que se puede traducir en un aumento de motivación, y desde la perspectiva del proceso un vaso demasiado grande es puro desperdicio o muda.

3. ¡Jajaja, tu lado del barco tiene un agujero!

Muchas veces confundimos un equipo con un grupo de trabajo, un equipo integrado tiene un objetivo común por el que todos van a "muerte". Este chiste ilustra la disfunción clásica de supuestos equipos en los que podemos escuchar frases como "esta no es mi tarea" o "a mi no me pagan para hacer esto"...

4. El problema de los post-its es que se caen a los seis meses.

Este chiste ilustra disfunciones como el agilipostureo y la ignorancia, utilizar post-its por razones que nada tienen que ver con la Agilidad. Si un equipo trabaja con Scrum y hace sprints de digamos dos semanas, sus post-its tienen una vida de dos semanas, no se van a caer. En ambientes escalados la vida de un post-it seria cómo máximo de 3 meses. Si los post-its se caen a los seis meses es que no hay cadencia, seguramente se trate de un waterfalling encubierto.

5. Un desarrollador aprende a disparar y no hay manera de que acierte en la diana, y dice: "desde mi punto la bala ha salido, si no ha llegado debe de ser problema de la diana".

Este chiste es tan sutil como real, ¿cuántas veces los desarrolladores desconocen de qué forma parte el código que escriben? ¿y lo que escriben otros con los que están directamente relacionados? A veces su visibilidad es solo sobre sus tareas particulares, quizá hasta QA, donde puede que desconozcan las pruebas que se aplicaran a su código... por no hablar de los despliegues de su código que hacen terceros de forma independiente. Es como intentar acertar en una diana que no ves y todo tu foco está en la tarea, en disparar la bala.

También es un chiste disfuncional de DevOps, con DevOps un desarrollador tiene visibilidad y responsabilidad hasta el mismo despliegue en producción, es el responsable directo de la calidad de lo que se despliega, y eso fomenta y crea compromiso.

6. Historias de usuario. Es un chiste tan simple como delicioso :-)
Del post "Historias de usuario, ¿por qué?" de enciendelaluz :-D
Si alguien supiera un chiste relacionado con la Agilidad le invito a añadirlo en los comentarios, mis agradecimientos de antemano.

miércoles, 7 de agosto de 2019

¿Cuál podría ser una agenda de una PI Planning?

La PI Planning, usualmente en un entorno trimestral, sirve para la sincronización y alineamiento entre equipos, con negocio y con sistemas/arquitectura. Es una reunión abierta donde todos los interesados (negocio, sistemas, ...) y miembros del tren (ART) comparten información y se coordinan con la idea de reformular la visión, planificar el siguiente trimestre y obtener feedback sobre cómo están funcionado las cosas.

Una agenda resumen de lo que ha sido exitoso en mi experiencia sería algo así:
Agenda de una PI Planning con los puntos a tratar y quienes intervienen en cada paso - gracias Ángel por la foto
Día 1

7:30 - 8:00 Café y desayuno
Un café con desayuno tiene dos bondades, primero atrae, en nuestra cultura española es signo de relevancia, y segundo despierta nuestras mentes y nos predispone a ser más abiertos de mente. 

8:00 - 9:00 Contexto de negocio
¿Cuantas veces hemos oído a los miembros de los equipos interesarse por los valores y la dirección de la empresa? No sobre informes de éxitos y ventas en el último año, sino sobre el propósito de la empresa y sobre su futuro. Es la ocasión ideal para que el CEO o un directivo dé una primera introducción poniendo contexto de negocio al trimestre junto al mensaje "¡esto va en serio y tenéis todo nuestro apoyo!".

9:00 - 10:00 Visión del producto y top features
¿Cuántas veces hemos visto como los desarrolladores de software codifican software en base a tareas aisladas y no entienden de lo que forma parte su trabajo? Los jefes de proyecto se quejan de trabajo duplicado y de decisiones desafortunadas que éstos toman. Esta es la ocasión ideal para hacer que todos se sientan parte de algo más grande, el producto o proyecto. Product Management expone la visión con los grandes rasgos del producto a construir y los principales objetivos de negocio a dar solución en el trimestre. Los miembros de los equipos así comprenden de qué forman parte y tomaran mejores decisiones en la construcción del software.

10:00 - 11:00 Visión de arquitectura y UX
Si queremos dar verdadera guía arquitectónica, de UX y sobre el contexto tecnológico, es responsabilidad de arquitectura, UX, sistemas y líderes técnicos comunicar, y con comunicar quiero resaltar que se trata de hacer entender y dar las herramientas necesarias para que los equipos de desarrollo se alineen y construyan eficientemente.

11:00 - 11:30 Descanso con icebreaker y café
Los icebreakers tienen la bondad de energizar a los asistentes, de darles ocasión de divertirse y conectar con los demás y sentirse más despiertos. Estos junto a un momento de distensión con un buen café prepara a los equipos para su primera sesión de trabajo.

11:30 - 12:00 Contexto del evento
El RTE, el coach ágil, expone el objetivo principal de la PI Planning, presenta la agenda y explica el funcionamiento de la misma.

12:00 - 15:00 Primera sesión equipos (breakout)
En la fase preparatoria se han distribuido tableros y post-its en áreas de trabajo independientes para cada equipo. En este paso los equipos dividen features en historias de usuario e historias técnicas (enablers) y las planifican a modo de borrador en los sprints del trimestre. También identifican sus objetivos para el trimestre, y toman nota de dependencias y riesgos que detecten.

Las dependencias que hayan emergido las resuelven con los otros equipos, si estos están e la sala, para luego ajustar las historias de usuario en los sprints en consecuencia. Principalmente son las dependencias resueltas las que  determinan el orden de ejecución de las historias, estas se recogen en program board junto a las features.

15:00 - 16:00 Comida
La comida es la ocasión ideal para que la gente hablé de niños, fútbol y toda clase de temas terrenales y que se forjen relaciones y confianza. La comida es especialmente útil en caso de equipos deslocalizados, una ocasión para crear conexiones entre las personas de diferentes localizaciones y para potenciar su colaboración.

16:00 - 17:00 Revisión de los borradores de la planificación
De vuelta a la PI Planning los equipos presentan sus planes individuales a todo el tren, uno por uno exponen sus objetivos, capacidad, riesgos detectados y dependencias resueltas. No se muestran historias de usuario, lo importante es exponer qué objetivos de negocio se resuelven con estas.

17:00 - 18:00 Revisión de managers
Business Owners, Product Managment, RTE, arquitectos y otros líderes y directivos han recibido un plan impregnado de realidad que probablemente no cuadre al 100% con sus deseos expresados mediante las features... es un momento de aprendizaje sobre lo que es factible y decidir que hacer para el segundo día de la PI Planning.

Día 2

7:30 - 8:00 Café y desayuno
Ocasión ideal para que los asistentes reconecten de nuevo y esté preparados para afrontar el día con energía y proactividad.

8:00 - 9:00 Ajustes para los planes
En base a lo que los managers hayan aprendido sobre la factibilidad éstos devuelven a los equipos ajustes como cambios en la visión, variación en las prioridades de negocio y movimientos de personas y de recursos. 

9:00 - 11:00 Segunda sesión equipos (breakout)
Segunda sesión de trabajo en la que los equipos hacen ajustes en sus planes, Business Owners les habrán marcado valor de negocio a sus objetivos para que les sirva de guía, siguen resolviendo dependencias y detectando riesgos.

11:00 - 11:30 Descanso con icebreaker y café
Momento necesario para descansar y reponer energías.

11:30 - 12:30 Revisión de los planes finales
Después de una segunda revisión probablemente los planes individuales de los equipos se hayan acercado lo suficiente al deseo expresado por las top featuresBusiness Owners aceptan los planes y dan su visto bueno, si no fuera el caso habría que retrabajar.

12:30 - 13:30 Gestión de riesgos
Antes de llegar a la fase final se tratan los riesgos detectados por los equipos que afecten al tren: cada uno de ellos se clasifica según una matriz ROAM (Resuelto, Asignado gestor - Owned, Aceptado y Mitigado).

13:30 - 14:00 Voto de confianza
Con una técnica muy simple, levantando en el mismo instante una mano con 1 a 5 dedos extendidos (desde 1 que significa sin confianza en el plan a 5 que significa un plan perfecto), todo el mundo da feedback de su nivel de confianza en el plan obtenido. Todos han participado durante dos día en el evento, todos deberían de estar convencidos de que plan funcionará, y si hubiera alguien que no confiara deberemos aclarar sus preocupaciones antes de empezar el PI.

Si el voto de confianza indica un buen plan
Se han podido aclarar y resolver las preocupaciones de quienes hayan levantado 1 y 2, si es que los ha habido.

14:00 - 15:00 Retrospectiva sobre todo el evento
Con espíritu de mejora continua la PI Planning termina con una retrospectiva ligera. En tres tableros con tres temas, lo que ha ido bien, lo que no y lo mejorable, se recogen ideas que finalmente cada asistente puede votar, usualmente con 3 palitos o estrellitas a repartir libremente. La idea es recoger feedback que RTE con Scrum Masters trataran durante el PI para la siguiente PI Planning.

15:00 - 17:00 Comida con cervezas para team-building
Una buena sesión de PI Planning se merece un buen manjar y que el CEO o directivo invite a cervezas ;-)

Si el voto de confianza indica que hay que retrabajar el plan
Las preocupaciones han levantado temas de mayor calibre que hay que despejar antes de seguir, una posible agenda podría ser la siguiente:
Quiero aprovechar el post para agradecer al grupo de RTEs lo
mucho que he aprendido de ellos :-) Thanks! Alexey, Yann,
Guy-Alexandre, Denis, Matt, Alex, Lionel, Sébastien y Benoît

14:00 - 15:00 Retrabajo
15:00 - 16:00 Comida
16:00 - hh:00 Retrabajo
hh:00 - hh:30 Voto de confianza
hh:30 - Retrospectiva sobre el evento

Pudiera ocurrir que aún con retrabajo un nuevo voto de confianza indicara que el plan no fuera factible. En ese caso hay que parar, escalar, averiguar causas raíz, resolver y planificar una PI Planning posterior. Para que un PI tenga éxito y se produzca la mejora continua no podemos empezar en ningún caso en falso, estamos hablando que 100 personas pueden fallar y eso no debemos de permitirlo.

miércoles, 31 de julio de 2019

¿Qué hacer con los especialistas en una transformación ágil?

El especialista hace crecer a los demás
Cortesía de Pixabay
La Agilidad literalmente no tiene tiempo para héroes ni para divas. Por un lado los héroes y las divas no suelen ser colaborativas, y por otro, todo el concepto de construcción iterativa a través de ciclos cortos de feedback y aprendizaje continuo no son compatibles con las nociones de heroísmo, héroes y divas no admiten el fracaso. Como equipo ágil, y como empresa ágil, debemos de esperar que muchas de las ideas fallarán y que incluso las historias de usuario no siempre acaben siendo buenas soluciones a la primera.

No importa lo inteligente que sea cada individuo en un equipo o tribu, desbloqueadas las motivaciones intrínsecas lo que importa es que todos los individuos en un entorno ágil sean apasionados, proactivos, creativos y pensadores activos, ante eso un héroe o diva no tiene ninguna posibilidad.

Como especialistas entendemos a personas que tiene un conocimiento profundo en una disciplina en particular. La cuestión es si los especialistas en una empresa a transformar son divas o si entienden que todo expertise, especialmente en TI, caduca a los pocos años. Vivimos en un mundo en el que los analfabetos son aquellos que no desaprenden y aprenden continuamente. Especialistas que vivan y persistan en su torre de marfil no tienen cabida en una empresa ágil.

Especialista como mentor - Cortesía de Pixabay
Los especialistas en una compañía ágil se convierten en mentores, en líderes técnicos, en Chapter Leads por ejemplo, que desarrollan a los demás en su disciplina de expertise. Lo hacen a través de la asesoría, de la transferencia de conocimientoSe convierten en líderes al servicio que se centran en entrenar y ayudar a los miembros del los equipos a crecer en su función, desarrollando así la competencia de estos.

Para generar equipos ágiles de excelencia o hiperproductivos hemos de pivotar cuidadosamente a los especialistas entre diferentes equipos para así difundir el conocimientoEntrenamiento cruzado, pair programming, establecer comunidades de práctica nos permiten mitigar los cuellos de botella que puedan significar los especialistas y crear habilidades tipo T, tanto en los especialistas como en los miembros de los equipos.

jueves, 25 de julio de 2019

¿El Manifiesto Ágil debería de actualizarse?

Tablero con el borrador del Manifiesto Ágil en 2001
cortesía de los autores firmantes del mismo
El Manifiesto Ágil marcó en 2001 un punto de inflexión en la ingeniería de software poniendo el foco en cosas como el valor, las personas, la comunicación efectiva, los ciclos cortos de entrega, los ciclos cortos de feedback y el aprendizaje.

El mundo ha evolucionado desde entonces, muchas compañías han incorporado la Agilidad y han madurado en un mundo que conocemos como VUCA; un mundo digital con sus transformaciones digitales, un mundo distribuido e hiperconectado, con una alta pervasividad del software, en el que es necesario la innovación a todos los niveles, el microaprendizaje continuo y la entrega continua bajo demanda con dependencias crecientes y diseños emergentes.

La evolución del mundo y las compañías requiere una revisión del Manifiesto Ágil. Por ejemplo en 2001 la capacidad de ordenadores y servidores era limitada y por ello el tercer principio dimensiona los sprints entre 2 semanas y 2 meses, cuando hoy en día con los sistemas actuales, hay compañías que en un solo día son capaces de identificar una nueva funcionalidad, construirla y llevarla a producción y hasta medir el uso que hacen de ella los usuarios finales.

En 2011, Kent Beck propuso que incluso un gran manifiesto debería de evolucionar y propuso Beyond Agile Manifestoel que muestro a continuación y podría ser el siguiente paso:
  • Visión y disciplina de equipo, por encima de individuos y su interacción, (por encima de los procesos y las herramientas)
  • Aprendizaje validado, por encima de software que funciona (por encima de la documentación exhaustiva)
  • Descubrimiento con el cliente, por encima de la colaboración con el cliente (por encima de la negociación contractual)
  • Iniciar el cambio, por encima la respuesta al cambio (por encima del seguimiento de un plan)
Visión y disciplina de equipo: efectivamente hoy en día el foco está en la formación de equipos de excelencia u hiperproductivos, equipos que tratamos como una sola unidad y que con una misión clara y un mínimo de restricciones construyen sistemas de forma autoorganizada.

Aprendizaje validado: hemos aprendido que cualquier requisito, funcionalidad, historia de usuario no deja de ser una hipótesis, pensamos que nos van a dar beneficios, pero no lo sabemos hasta que las validemos. Para ello utilizamos el ciclo Lean UX que se basa en el ciclo de feedback construir-medir-aprender. A través del mismo generamos conocimiento validado sobre un producto, extrayendo conclusiones valiosas de los usuarios que ya usan o vayan a utilizar ese producto.

Descubrimiento con el cliente: cada vez más lo que tiene futuro son los partnerships y alejarnos del concepto de cliente-proveedor. Colaboramos comos dos partners, el de negocio (ex-cliente) y el tecnológico (ex-proveedor), con un objetivo de crecimiento mutuo poniendo el foco en maximizar la competitividad de cliente (negocio).

Iniciar el cambio: hoy en día un buen Propietario de Producto interactúa continuamente con sus interesados y usuarios para entender sus necesidades y problemas, y levantar nuevas necesidades para mantener el producto en constante evolución y a la empresa competitiva en ese mundo VUCA. Probablemente si no hay cambios en un producto es que ha llegado a la obsolescencia.

Suscribo la actualización, creo que para el mundo de hoy es lo que lo haría que sea un gran manifiesto. ¡Gracias Kent!

jueves, 11 de julio de 2019

¿Cómo gestionar a los diferentes tipos de interesados?

Una de las responsabilidades de un Propietario del Producto es la relación con los diferentes interesados del proyecto/producto:
  • identificar a los interesados y su nivel de apoyo
  • comunicarse con ellos para entender sus necesidades
  • balancear las diferentes necesidades de los mismos
  • influenciarlos
Para identificar el nivel de apoyo una herramienta muy útil es el siguiente cuadrante de tipos de interesados que clasifica según potencial de cooperación y amenaza:
Cuadrante de tipos de interesados - Savage et al. 1991
Según el tipo de interesado podemos aplicar las siguientes estrategias:

Interesado Marginal (Bajo potencial de amenaza, bajo potencial de cooperación)

Estrategia: monitorearlos
  • Al reconocer que sus intereses son limitados y específicos limitándonos a monitorearlos se evita el desperdicio de esfuerzos
  • Se debe de intentar aumentar su apoyo o rechazar su oposición en las cuestiones en las que sus decisiones sean importantes para ellos
Interesado No Apoyador (Alto potencial de amenaza, bajo potencial de cooperación)

Estrategias:
  • Defensa: reducir las dependencias con los intereses del interesado en el producto
  • Comprometerse: mantenerlo informado y satisfecho de forma continua
Interesado Apoyador (Bajo potencial de amenaza, alto potencial de cooperación)

Estrategia: envolverlos en decisiones relevantes para fomentar el potencial de cooperación
  • Atención constante informándolos e invitándolos a los diferentes eventos
  • Aumentar su participación en el proceso de toma de decisiones sobre el producto
Interesado Ventajas y Desventajas (Alto potencial de amenaza, alto potencial de cooperación)

Estrategia: involucrarlos
  • Colaborar buscando maximizar su cooperación, haciéndoles partícipes en los eventos volviendo más difíciles las posibles oposiciones

viernes, 5 de julio de 2019

¿Qué es más barato, construir una funcionalidad con Scrum o en un proyecto en cascada?

¿Qué es más barato? ¿Cascada? ¿Agile?
cortesía de PixaBay
Es una pregunta habitual en mis acompañamientos y mis cursos. La cuestión en primer lugar es ¿cómo nos miden? Si nos miden por alcance de proyecto cumplido probablemente la forma más barata de desarrollar producto es hacerlo con un proyecto cerrado en cascada... pero si nos miden por el valor de negocio entregado las cosas pueden ser muy distintas.

Sin duda un project manager o jefe de proyecto busca la forma de ejecutar el proyecto "cerrado" de la forma más óptima posible, lo que no es tan evidente es si el resultado de un proyecto cerrado es un buen incremento de valor sobre el producto, me refiero a si el software construido a lo largo de un proyecto es una buena solución a las necesidades de nuestro cliente. En todo caso un jefe de proyecto al optimizar minimiza los costes.

Desarrollar con Scrum significa descubrir de forma iterativa un solución óptima para las necesidades de nuestro cliente. Descubrir significa que para construir una funcionalidad le hemos de dar varias vueltas antes de acertar, y eso sin duda tiene un sobrecoste respecto a si construyeramos la funcionalidad correcta a la primera. Pero claro, una funcionalidad no deja de ser una hipótesis de solución a un problema, no podemos no descubrir, ya que en tal caso probablemente construyamos algo que no sea una buena solución a la necesidad.

Dando respuesta a la pregunta del post, cascada es más barato por funcionalidad, pero para construir la funcionalidad equivocada y construir funcionalidades que no resuelvan necesidades, y por tanto que probablemente nadie vaya a utilizar. Scrum es una forma más cara de construcción de funcionalidades, pero bajo ese marco construimos las funcionalidades correctas, las que dan solución a las necesidades del usuario.

Visto esto, ¿qué es más barato? Dependerá de los objetivos: si el objetivo es incrementar la competitividad de nuestro cliente sin duda lo es Scrum, si el objetivo es cumplir con alcances iniciales de proyectos cerrados, sin duda lo son los proyectos en cascada.

domingo, 30 de junio de 2019

¿Cuándo se cierran los criterios de aceptación de una historia de usuario?

Recientemente tuve un asistente especial en uno de mis cursos, Ángel, un coach ágil de los que entienden la Agilidad con una profundidad que no todos logramos. Estábamos hablando de criterios de aceptación, que transformados en escenarios de pruebas con ejemplos específicos, permiten al Propietario del Producto confirmar que el equipo ha entendido y recogido correctamente el comportamiento de la historia de usuario.

Las historias de usuario forman parte de la fórmula de captura de funcionalidades definida en 2001 por Ron Jeffries, la de las tres C's (Card - Conversation - Confirmation):
Cuadro con la técnica de las 3 C's
En la última fase de confirmación los criterios de aceptación proporcionan la precisión necesaria para garantizar que la historia se va a implementar correctamente y así se cubren los requisitos funcionales y no funcionales relevantes.

El debate se inició sobre cuándo se considera que estos criterios de aceptación se dan por cerrados. Echando un vistazo a la técnica de las 3 C's parece evidente que deberían de estar cerrados al final de la planificación de sprint. Desafortunadamente eso son resquicios de un pensamiento clásico y predictivo...

Recordemos que al final del la planificación de sprint el equipo de desarrollo se compromete con el objetivo del sprint, no con la pila de sprint y sus historias de usuario. Por tanto los criterios de aceptación se cerrarán a lo largo del sprint, probablemente cuando se haya acabado la historia de usuario.

No olvidemos que con el objetivo del sprint pretendemos dar solución de la mejor forma posible a las necesidades reflejadas en el mismo, y eso puede significar incluir información fresca alineada con el objetivo. Esa información fresca puede cambiar los criterios de aceptación. Si por ejemplo el objetivo del sprint es que nuestro cliente pueda emitir la factura, lo importante será que a final de sprint el cliente pueda facturar de la forma que más competitivo le haga, y quizá eso signifique con menos funcionalidad que la pensada en la planificación e incluyendo funcionalidad no pensada ni planificada entonces.

Mis agradecimientos a Ángel Lozano que arrojó mucha claridad sobre lo que es ser Agile

martes, 18 de junio de 2019

¿De qué elementos hace seguimiento una PMO ágil?

Una APMO se focaliza en los elementos de la
macrogestión, nunca en los de la microgestión
Una PMO clásica mide el seguimiento de un proyecto/producto desde una perspectiva diferente que una PMO ágil o APMO. Tradicionalmente la PMO mide el avance de un proyecto en base al progreso de las diferentes tareas o actividades del proyecto, por tanto se basa en los outputs de la microgestión del proyecto.

El seguimiento de una APMO debe de ser en base a los outcomes, elementos de la macrogestión del proyecto/producto que agregen valor de negocio, lo que significa que solo funcionalidades acabadas, historias de usuario 100% terminadas que cumplan con la definición de hecho (DOD), cuentan para hacer un seguimiento real de progreso tal como marca el séptimo principio del Manifiesto Ágil:

El software que funciona es la principal medida del progreso

Por ejemplo, el haber resuelto un botón representa un avance a nivel de la funcionalidad que lo requiere, pero no significa nada desde el punto de vista de seguimiento del proyecto/producto. Hacer seguimiento de tareas es desde la perspectiva de la Agilidad engañarnos, si la funcionalidad u historia de usuario no está terminada podemos haber hecho mucho trabajo pero no hay nada que entregar al cliente ni nada que resuelva una necesidad o problema de negocio.

Ejemplos de métricas de macrogestión para una APMO son:
  • Productividad: Tiempo de ciclo medio por funcionalidad
  • Time-to-market: Número de releases/entregas por unidad de tiempo
  • Calidad: Número de defectos y volumen de llamadas a soporte
  • Satisfacción del cliente: NPS (Net Promoter Score)
  • Compromiso de los empleados: Encuestas a empleados
Un beneficio que se obtiene al hacer el seguimiento de a través de los elementos de macrogestión es que con ello se focaliza al equipo en un único objetivo común, por tanto fomenta la colaboración y alienta al equipo a ser más ágil para terminar la historia de usuario en curso y entregar valor antes de empezar la siguiente.

Podemos deducir que, a diferencia de una PMO clásica que suele limitarse a tomar métricas de control y de cumplimiento, una APMO apoya a los equipos en su desempeño poniendo solución a sus necesidades y colabora con los Scrum Masters para resolver los bloqueos e impedimentos que puedan surgir a lo largo de la ejecución de los sprints.

miércoles, 12 de junio de 2019

¿Cómo gestiona SAFe las dependencias de los equipos con otros equipos internos y externos?

Siempre que formo a los alumnos sobre la PI Planning y hablamos del Program Board de SAFe® hay cierta curiosidad y desacuerdo. Recordemos el Program Board; es uno de los tableros output de la PI Planning que muestra en qué sprint (iteración) una determinada feature está prevista que esté terminada, así como las dependencias significativas de esa feature, si las hubiera, sea una historia de usuario, una tarea o una actividad:
Program Board con la visión a nivel de tren - imagen del tema PI Planning cortesía de © Scaled Agile, Inc.
El desacuerdo suele producirse porque en las realidades de la mayoría de mis alumnos lo que ponen en el Program Board son todas aquellas historias de usuario que tienen dependencias entre si, la historia dependiente unida a la historia de la que depende. De hecho en algún tren donde he actuado de coach ágil hemos utilizado tableros de estas características, con dependencias entre historias de usuario, útil pero menos potente que un auténtico Program Board.

La disfunción en estos casos resulta en tableros con dependencias entre historias de usuario que acaban siendo muy poblados en post-its y con una intrincada maraña de hilos, útil sin duda pero ilegibles desde el punto de vista holístico del tren (ART). El Program Board, tal como lo describe SAFe, muestra todas las dependencias desde la perspectiva del nivel de tren, las features. Cuando se celebran los Scrum de Scrums y las PO-Sync ante el Program Board lo que interesa es la lectura del progreso del tren versus las features, no versus las historias de usuario que a priori solo son de interés a nivel de equipos.

En la propuesta de SAFe la gestión de dependencias no se limita al Program Board, en los tableros donde se refleja la pila (de producto) del equipo, un tablero output de la PI Planning donde el equipo ha distribuido de froma preliminar las historias en los sprints del PI, se reflejan las dependencias en las propias historias de usuario afectadas. Concretamente si una historia tiene una dependencia, SAFe sugiere poner un post-it rojo que describa la dependencia y cuando la dependencia se ha tratado y resuelto con el equipo correspondiente se le añade una marca de verificación.
Gestión de las dependencias a nivel de equipo
De esta manera tenemos la gestión de dependencias agregada a nivel de tren y la gestión de las mismas en cada uno de los equipos en la parte que le pertoca y con toda la información local que precisan.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.