martes, 14 de noviembre de 2017

¿En Scrum utilizamos colchones en las estimaciones?

Durante unos cuantos años fui jefe de proyecto tradicional, y como tal utilicé los colchones para acercar las estimaciones de los desarrolladores a lo que yo creía como factible, a lo que me decía mi experiencia, o al menos de eso estaba convencido.

Los colchones resultaron en una trampa: yo le pedía una estimación a un desarrollador y él me decía 4 horas por ejemplo, mi experiencia me decía que por lo menos iban a ser 6, y como no podía llevar dos contabilidades de las estimaciones registraba 6 horas en el gestor de tareas y planificaba 6 horas en mi hermoso y perfecto gantt. Cuando le llegaba la tarea al desarrollador este veía 6 horas, y convencido de que eran 4, dedicaba las primeras 2 horas a cerrar otras tareas, contestar emails, etc. Finalmente se ponía con la tarea justo cuando le quedaban las 4 horas, lo que había estimado, pero como algo de razón llevaba yo acababa necesitando 5 horas... Los colchones son algo engañoso, ya que, aunque introduciendo el colchón daría tiempo de sobras para realizar la tarea, nunca resultaba así, siempre falta alguna hora. Y así esas pequeñas desviaciones se acumulan y escalan con implicaciones mayores por la complejidad y las interdependencias propias de un gantt...

Slack time o aire provee de margen de capacidad para hacer posible la cadencia
Y después conocí Scrum y me di cuenta que por mis venas corría Agilidad. En Scrum tenemos el concepto de "slack time", holgura o aire, que permite que haya ritmo. Scrum, Kanban, Agilildad y Lean buscan imprimir flujo de forma sostenible a la construcción de cosas. El flujo viene a ser el ritmo con el que progresan las tareas o el trabajo. El flujo recorre la cadena de valor y puede estar afectado por impedimentos como los cuellos de botella, las restricciones y las políticas empresariales.

La cadencia, que viene a ser marcar un ritmo de tiempo fijo a nuestras tareas, hace que acometamos estas de principio a fin maximizando el ratio de entrega y calidad, como lo hacemos con los sprints de Scrum. La cadencia nos permite poner flujo a tareas que tengan alta variabilidad, como lo son las tareas en el desarrollo TI. Para hacer posible la cadencia necesitamos pequeñas holguras o aire con cada golpe de ritmo, entre cada sprint, no podemos concebir un solo de batería sin silencios.

Para crear un sistema que funcione es necesario que los tres elementos, flujo, cadencia y aire trabajen de forma conjunta. La respuesta al post es que necesitamos aire, no colchones, entre sprint y sprint, un concepto algo distinto. El aire es algo transparente que forma parte del método, el colchón es algo con tendencia a que lo ocultemos, ya que pondría a la luz nuestra ignorancia sobre el flujo real de nuestro plan.

Si no tuviéramos aire nos costaría cada vez mas cumplir con nuestras tareas y el sistema entraría en estrés. He observado una y otra vez como compañías que intentan llenar al 100% los sprints con tareas, se sumergen en un estrés que escala y que por ende hace que los proyectos fracasen:
  • Se produce una carencia en la absorción de variabilidad, lo que impacta fuertemente la predecibilidad
  • No hay innovación, los equipos se encuentran en constante situación de urgencia
  • La deuda técnica crece de forma incontrolada
  • Los miembros de los equipos se queman
  • No hay tiempo para planificar, revisar ni mejorar de forma conjunta
En un marco de Scrum escalado sería imposible trabajar sin espacios de aire, en un marco escaldo hemos de garantizar la entrega a final de sprint, ya que si falla un equipo pueden fallar todos aquellos que trabajen en el mismo producto, y eso es un riesgo demasiado grande correrlo.

Hemos visto la importancia de inyectar aire, pero si ese aire no fuera necesario para absorber cambios y accidentes, ¿qué hacer en ese tiempo?
El aire permite que haya cadencia, mejora continua,
grandes ideas y serendipia - Cortesía de Pixabay
Uno de los pilares de Scrum es la mejora continua, y para que se produzca esta es necesario espacios de tiempo que nos permitan reflexionar y hacer aquellas cosas que nunca hacemos porque parecen poco importantes, pero resulta que mejoran sensiblemente nuestra forma de trabajar: siempre suele haber actualizaciones pendientes, herramientas que probar, mejoras que queremos hacer pero no encontramos el tiempo, ideas y experimentos que queremos realizar, artículos que leer...

Hay más beneficios que de otra manera no se darían: team-building realizando una actividad de la que disfrutamos y que compartimos con nuestros compañeros, propicia la confianza dado que los temas ocultos pueden emerger, espacio para que ocurra la serendipia, esas ideas y descubrimiento inesperados y geniales que ocurren cuando se está buscando otra cosa... ese aire o slack time tiene muchos beneficios, nos da la posibilidad de hacer cosas creativas y grandes.

Mis agradecimientos a José, os animo a leer su post "Reservas de contingencia y reservas de gestión", refuerza y enriquece este post desde la gestión de proyectos en cascada, en la que el concepto paralelo de reservas se trata desde hace tiempo :-)

sábado, 11 de noviembre de 2017

¿Quienes forman los squads?

Roles en el squad y en la tribu, basado en una
imagen de Henrik Kniberg & Anders Ivarsson
Fue una cuestión que surgió en una de las sesiones para Scrum Masters de la tribu. ¿Los Propietarios del Producto (PO) son squad?, ¿y los Business Owners (BO)?

El modelo de Spotify es una experiencia compartida de tal como les funcionó en los inicios, y tal como vienen explicadas las tribus es bastante claro al respecto de los Propietarios del Producto, no son squad. Posteriormente otras compañías, como ING por ejemplo, han adoptado el modelo y lo han adaptado a sus singularidades, para ING los Propietarios del Producto si son squad. Nosotros hemos hecho lo mismo, hemos partido del modelo de Spotify y lo hemos adaptado, y es por ello que surge la duda, ya que nuestros squads deben de ser la mejor solución para nosotros.

Resaltar que con este post pretendo dar una solución, la que hemos adoptado nosotros.

Squad

Recordemos que un squad es un equipo de desarrollo, y un equipo de desarrollo en Scrum es un equipo multifuncional de especialistas que trabajan juntos cada día. La clave está en "que trabajan juntos cada día", un squad lo forman aquellas personas que hacen el trabajo que aporta valor de negocio de forma cotidiana días tras día. Como squad son un grupo autónomo y autoorganizado, y con las habilidades, herramientas y poder de decisión necesarios para construir de forma independiente.

Principalmente son los desarrolladores y constructores, y entre ellos está el Chapter Lead, un miembro más del squad que está involucrado en el diseño y la construcción de lo que se está desarrollando en el squad. Este tiene además un rol como experto y responsable del chapter para su disciplina específica. Es un líder al servicio que se centra en entrenar y ayudar a los miembros del chapter a crecer en su función.

A veces utilizamos distintas denominaciones para lo mismo y para evitar confusiones hemos convenido que cuando nos referimos al "equipo" a secas nos referimos al squad.

Equipo Agile

El equipo Agile es un equipo más amplio y lo forman aquellos que están focalizados en los sprints, son aquellas personas que tienen la capacidad y la autoridad para definir, construir y probar los incrementos de valor de la solución. Tanto Propietario del Producto (PO) como Scrum Master (SM) son miembros del equipo Agile, el Propietario del Producto lidera la dirección a través de los "qués" hay que construir, y el Scrum Master facilita el camino del squad hacia sus objetivos de entrega y ayuda a construir un equipo de desarrollo autoorganizado de alto rendimiento.

Resaltar que aunque ambos roles formen parte del equipo Agile, pueden estar relacionados con más de un squad: un Scrum Master dedicado al 100% puede participar en 2 a 3 squads, y un Propietario del Producto dedicado al 100% en 1 a 2 squads.

Tribu

Una tribu es un grupo de squads que se han formado alrededor de un objetivo de producto o negocio determinado y son responsables de los resultados de un segmento comercial o área funcional. Dado que dan solución a flujos de valor de principio a fin, las tribus deben de estar dotadas de todos aquellos roles que representen las diferentes áreas que cruzan su flujo de valor.

En la tribu está el Tribe Lead (TL), el líder al servicio que con ayuda del coach ágil (AC) acompaña a la tribu a través de las etapas de la adopción de Agilidad a nivel de escala, para actuar después como lider de la coalición POCLAC y conducir a la tribu a lo largo de la estrategia y la mejora continua.

Los Business Owners (BO) forman parte de la tribu, son partes interesadas involucradas en forma de equipo de negocio que tienen y son responsables del negocio principal; son usuarios principales seleccionados, el cliente... saben del mercado y están en la tribu para colaborar asesorando, aconsejado, sugiriendo y dando feedback para garantizar que los incrementos tengan valor de negocio.

Finalmente la tribu opera bajo una cultura DevOPS, dónde las áreas de arquitectura, sistemas, ingeniería y otros servicios tienen personas dedicadas en la tribu a modo de línea directa con estas áreas externas.

Las buenas soluciones tienden a converger y en nuestro caso el modelo de roles de la tribu es muy similar al ART (Agile Release Train) de SAFe:
Essential SAFe con los roles a nivel de equipo y ART - cortesía de Scaled Agile
  • El squad corresponde al Dev Team
  • El Propietario del Producto (PO) al Product Owner
  • El Scrum Master (SM) está presente tal como es en ambos modelos
  • El Tribe Lean (TL) similar a un Release Train Engineer (RTE) más liderazgo en Product Mgmt
  • El coach ágil (AC) a la parte del Release Train Engineer (RTE) que lidera a los Scrum Masters
  • El Business Owner (BO) con el mismo rol más el cliente
  • Operaciones (OPS) a System Arch/Eng
Dedico este post a mis compañeros Nayua, Esther, Fran y Patxi. Con el mismo espero haber sentado las bases de lo que es un squad y lo que no :-)

lunes, 6 de noviembre de 2017

¿Existe algún tablero Kanban para el Propietario del Producto?

El ciclo de vida de los épics y las historias de usuario empieza con la visión del producto y la materialización de la misma a través de la pila de producto, y acaba con el despliegue en producción de las funcionalidades en forma de software.

El uso de un tablero Kanban para el Propietario del Producto o el equipo de Product Management, proporciona el contexto y la visibilidad necesaria para trabajar en un producto específico:
  • Hace visible el producto a través de sus funcionalidades, permitiendo alinear la pila, nuevas historias emergentes y lo que se va construyendo con la estrategia del producto.
  • Aporta estructura al análisis, al valor y a la toma de decisiones.
  • Provee de una herramienta transparente y cuantitativa para la toma de decisiones basada en economía.
  • Mantiene el enfoque en los objetivos a largo plazo del producto.
  • Ayuda a prevenir expectativas no realistas.
  • Es el referente para la colaboración entre Propietarios del Producto, Business Owners e interesados del producto/proyecto.
  • Provee de límites WIP para ajustar la inyección de historias de usuario a la capacidad del sistema (equipos/sprints)
Un ejemplo de un tablero Kanban para el Propietario del Producto lo proporciona Scrum Manager en su curso troncal:
Descripción del tablero propuesto por Scrum Manager:
  • El Propietario del Producto mantiene en un área todas las historias de la pila de producto que tiene previstas con mayor o menor grado de certidumbre para los próximos 6 meses.
  • En otro área están las historias que ya ha decidido que van a ser las próximas en programar, tienen el grado de concreción necesario y han sido explicadas y estimadas con el equipo.
  • El equipo emplea TDD para el diseño y programación de las diferentes historias. Por eso en un área del tablero coloca aquellas para las que se están escribiendo y programando las pruebas.
  • Hay otra área en curso para colocar las historias para las que ya se ha escrito la prueba y están siendo programadas.
  • Una vez terminadas se colocan en otra zona hasta que el cliente las da por validadas.
  • Finalmente pasan al área para integrar donde quedan hasta que se integran en la siguiente release.
  • En terminado están aquellas que ya se han desplegado en la release correspondiente.
Otro ejemplo de tablero Kanban en el marco de escalado SAFe para Product Management, el equipo de Propietarios del Producto:
Program and Solution Kanban - Scaled Agile Framework
Descripción del tablero propuesto por SAFe:
  • Funnel o embudo: una bandeja de entrada donde todas las grandes ideas son bienvenidas.
  • Analyzing o análisis: se describe la hipótesis de beneficios y los criterios de aceptación, se calcula el WSJF (sistema de priorización basado en el coste de la demora y el esfuerzo) y se limita por WIP.
  • Backlog o pila de programa: representa la pila de producto a inyectar en las pilas de los equipos, son funcionalidades aprobadas por Product Management que siguen en continua priorización.
  • Implementing o implementando: son las funcionalidades que están en construcción en forma de historias de usuario en las pilas de sprint de los diversos equipos.
  • Validating on staging o validación en la staging: contiene las funcionalidades construidas, integradas y desplegadas en un entorno de staging.
  • Deploying to production o despliegue en producción: funcionalidades desplegadas en producción, algunas veces deshabilitadas esperando el momento de su lanzamiento.
  • Releasing o lanzamiento: las funcionalidades liberadas a los usuarios/clientes y en estado de evaluación de la hipótesis de beneficios esperados.
  • Done o hecho.
Los tableros para los Propietarios del Producto pueden ser singulares y específicos según la compañía. Un tablero cuya definición facilité resultó en los estados "Open" para funcionalidades en consideración, "Ready" para historias de usuario que cumplen con la definición de listo (DoR), "In progress" para aquello que están construyendo los equipos, "Blocked" para historias bloqueadas por algún impedimento, "Testing" para lo que esté probándose, "Delivered" para las historias entregadas e "In use" para las historias en uso por parte de usuarios y negocio.

Como coach ágil es un logro ver como los Propietarios del Producto tienen su propio radiador de información, ver como les proporciona visibilidad y claridad, y como es un referente para su colaboración. También les ha aportado la métrica del promedio del tiempo de entrega, métrica que les permite proyectar a futuro y realizar hojas de ruta con releases impregnadas de factibilidad.

miércoles, 1 de noviembre de 2017

¿Cómo guiar y mantener a una tribu en un entorno correcto, motivante y productivo?

Tribe Lead, un líder al servicio de la tribu
Henrik Kniberg & Anders Ivarsson
Cuando trabajamos con Scrum de forma escalada a nivel de equipo de equipos, se hace imprescindible un rol cuyo foco sea el equipo de equipos como un solo ente, de forma holística. El foco en los detalles está en aquellos que tratan directamente con los equipos de desarrollo, los Propietarios del Producto y los Scrum Masters entre otros.

Para cubrir este rol el modelo Spotify introduce al Tribe Lead, un líder al servicio que primero acompaña a la tribu a través de las etapas de la adopción de Agilidad a nivel de escala, y luego la conduce a lo largo de la estrategia y la mejora continuaEstablece la estrategia en base a la visión y los objetivos a largo plazo de la compañía, y se centra en sincronizar la cultura con la estrategia para involucrar a la tribu en los valores ágiles, causas nobles, resultados (outcomes) y adopción de nuevos hábitos y así alinear los comportamientos con la Agilidad.

Desarrolla a los que le rodean fomentando equipos multifuncionales autoorganizados, tanto tecnológicos como de negocio y de líderes de equipo. Para ello trabaja muy estrechamente con los Propietarios del Producto, Chapter Leads y coaches ágiles en los POCLAC's, con los que forma el equipo de liderazgo de la tribu.

Este equipo (TL, CL, PO AC) es el punto de contacto con gerencia, proporciona información sobre los squads de la tribu y obtiene directrices estratégicas de estos.

Entre sus funciones están:
    Cartel cultura/estrategia para la tribu - gracias Miguel Ángel Ocaña
  • Ser responsable de proporcionar el entorno adecuado a todos los squads
  • Hacer crecer a los squads hacía equipos de alto rendimiento
  • Liderar la cultura Agile en la tribu
  • Establecer prioridades estratégicas
  • Alinear a todos los componentes de la tribu con la estrategia
  • Garantizar que el conocimiento y las ideas sean compartidas entre todos los squads
  • Desarrollar Chapter Leads fuertes y empoderados
  • Crear una coalición de líderes de equipo y tribu fuerte (POCLAC)
  • Asignar presupuestos disponibles
  • Coordinar la comunicación con otras tribus
  • Gestionar y escalar impedimentos sistémicos que afecten a la tribu
  • Ayudar a administrar el riesgo
  • Impulsar la mejora continua
El rol de Tribe Lead es similar al rol del RTE (Release Train Engineer) de SAFe, cuya responsabilidad es conducir y tener el foco en los ARTs (Agile Release Trains), que aunque estén formados por equipos autoorganizados y autogestionarios, necesitan este rol que aporta una comprensión sólida de cómo escalar Lean y Agile, y que comprenden las oportunidades y los desafíos únicos asociados con la facilitación y la alineación continua de un gran equipo de equipos.

sábado, 28 de octubre de 2017

¿Cómo mostrar la importancia de la integración continua?

Jugadores ordenando las fichas
Una de las prácticas que son absolutamente necesarias para ir a favor del flujo de entrega de valor en un equipo Scrum es la integración continua, asegurarnos de forma continua o muy frecuente que las partes construidas por los diferentes miembros del equipo, o de varios equipos que trabajan alrededor de un mismo producto, integra y se engarza para funcionar correctamente de forma conjunta.

Martin Fowler describe la integración continua como: "Integración continua es una práctica de desarrollo software donde los miembros del equipo integran su trabajo frecuentemente; normalmente cada miembro integra al menos una vez al día. Cada integración es verificada por un build automatizado (incluyendo test) para detectar los errores de integración tan rápido como sea posible. Muchos equipos encuentran que este enfoque permite reducir los problemas de integración y permite al equipo desarrollar software cohesivo más rápidamente".

Pero, ¿cómo hacer comprender a personas no técnicas, como lo pueden ser Propietarios del Producto, coaches, líderes, directivos, etc. la importancia de esta práctica técnica?

Para ello podemos utilizar un juego de fichas recortables que permite a los asistentes entender la importancia de integración frecuente. La dinámica trata de que los jugadores encuentren dos caminos, el de integración continua y el de no continua, ordenando las siguientes fichas:
Juego de fichas con imágenes a ordenar
Se les dan un par de pistas:
  • La ficha de inicio es común para ambos y es la 04
  • Con integración continua acabamos las casas en verano, y sin, más tarde en invierno
La solución al juego es la siguiente:
Solución al juego
Con puntos de integración, el camino en verde, los constructores construyen por separado las estructuras de las casas (04), luego comparan y se dan cuenta que no tienen la misma altura (07), retrabajan las estructuras (02), vuelven a comprobar y ahora si integran (10), después trabajan en las paredes (11) con un punto de integración para asegurarse de que son iguales (09), finalmente hacen los acabados (01) y cuando integran en verano el resultado es excelente (12).

Sin puntos de integración, el camino rojo, los constructores empiezan por separado por las estructuras (04) y siguen directamente con las paredes y los acabados (08), cuando integran las cosas no cuadran (05) y tienen que hacer muchos ajustes y retrabajo (06) que requieren mucho tiempo, representado por el calendario que corre, finalmente obtienen un buen resultado en invierno (03), mucho más tarde y con más costes de retrabajo que si lo hubieran hecho con puntos de integración.

Descargas / Downloads
Quiero dar mis agradecimientos al autor de las imágenes y del juego, lo utilizo frecuentemente para explicar la integración continua y no soy capaz de encontrarlo en la web.

sábado, 21 de octubre de 2017

¿Cómo trabaja un coach ágil desde la inteligencia emocional, social y de relaciones?

El coach ágil trabaja el sistema completo, las relaciones del
mismo, entre todos los miembros del equipo - cortesía de Pixabay
Una de las habilidades que todos tenemos es saber leer la energía o el campo emocional de un grupo u equipo de personas. Todos la tenemos, algunos más desarrollada que otros, sabemos ver, oler, intuir algo antes de que ocurra. Cuando entramos en una reunión por ejemplo, sabemos en el mismo momento al entrar por la puerta qué ocurre desde el punto de vista emocional del grupo de personas.

Un coach ágil está entrenado para leer el campo emocional, es experto en los valores, principios y prácticas ágiles, y su función es transformar de forma consciente e intencional las relaciones entre las personas del equipo/grupo para alinearlas con Agilidad y así beneficiar el trabajo de estas.

En función del campo emocional puede detectar si el grupo o equipo entiende su situación como un problema. En ese caso el coach ágil empieza normalizando, haciendo ver a todos que la situación en concreto es algo normal, es algo que ocurre cuando trabajamos con otras personas y que puede pasar en cualquier grupo o equipo.

Para iniciar cualquier transformación el coach ágil lo hace revelando el equipo a si mismo, su realidad, quienes son y quienes están, qué tipo de interrelaciones y roles formales e informales existen en el grupo, sobre su salud o toxicidad, qué aspectos mejoran sus resultados como equipo y cuales los empeoran...  A partir de este momento el equipo o grupo es capaz de observar su realidad desde otra perspectiva, distinguir "hechos" de "interpretaciones" y reconocer la relación entre los "estados de ánimo" y "la creación de futuro", aprender a aprender y a desaprender.

Es el momento de establecer el contexto, la primera etapa de la conversación, creando un ambiente idóneo para que fluya la comunicación de manera clara, con empatía, escucha activa y el estar presentes. También es el momento de formartrabajar la mentalidad ágil, recordemos los valores se Scrum (transparencia, franqueza, foco, respeto y coraje), y dos de los cuatro valores del Manifiesto Ágil que hablan de relaciones entre personas:
Es fácil leer el campo emocional de este equipo
El coach ágil  crea un campo emocional consciente que cambia la energía del equipo, así podrán lograr los resultados deseados y descubrir nuevos aprendizajes. Es el momento de difuminarse, de que el coach ágil se aparte y deje que el protagonista de su rumbo y futuro sea quien debe de serlo: el equipo.

ORSC™ en su modelo de coaching de organizaciones y sistemas relacionales introduce el concepto de MetaHabilidades. Para que el coaching funcione mejor es necesario que el espacio y la atmósfera del coaching sean los correctos. Una MetaHabilidad es la actitud y postura con la que opera el coach ágil, como por ejemplo el compromiso, el respeto, la democracia profunda, el corazón, la juguetonería o la colaboración.

lunes, 16 de octubre de 2017

¿Cómo liderar el crecimiento de equipos impulsados por las motivaciones intrínsecas?

Porqué tenemos POCLACs
Aquellos con roles de liderazgo ágil deben de hacer todo lo posible para que los equipos aprendan y crezcan de forma continua, en un ambiente adecuado con el objetivo de hacer equipos más productivos y motivados. En Agilidad el liderazgo se hace en equipo y por aquellos roles que pueden facilitar las motivaciones intrínsecas de los miembros del equipo: propósito, maestría y autonomía.

En los diferentes marcos de Agilidad, desde Scrum a los marcos escalados, nos encontramos con un liderazgo distribuido en una coalición de tres roles:
El modelo Spotify define un evento denominado POCLAC para que estos roles de liderazgo trabajen en cómo ayudar a los equipos a desarrollarse. POCLAC viene de las siglas de la coalición de Propietario del Producto (PO), Chapter Lead (CL) y Agile Coach (AC), y es el evento que da respuesta al post, a cómo liderar el crecimiento de equipos impulsados por las motivaciones intrínsecas.

El evento se materializa en una reunión informal y regular dentro de la cadencia establecida, al menos debe de efectuarse una vez por sprint. Dentro de la misma se discute acerca de cómo está funcionando el equipo y sobre qué podría hacerse para que trabajen mejor. Podemos apoyarnos en diferentes fuentes de información:
El resultado de la reunión se materializa en una serie de acciones a poner en macha para hacer crecer a los equipos; reconocimientos, adquisición de recursos, resolución de impedimentos, eventos de team-building, formaciones, …

No debemos tratar a los miembros de forma individual, sólo sería adecuado discutir una contribución individual si esta estuviera directamente vinculada al rendimiento del equipo. El resultado de tal discusión puede variar desde dar un gran cumplido a alguien que haya influido positivamente en el rendimiento del equipo, o tener una charla con alguien que está teniendo problemas y hacer un plan para ayudar a ese miembro de equipo a crecer.

Una de las disfunciones más comunes de POCLAC es que se covierta en una reunión de discusión sobre la pila de producto o los hitos de la hoja de ruta, por tanto como facilitadores de la reunión hemos de estar alerta y si ocurre refocalizar la reunión en el equipo. También debemos cuidar que cada rol se mantenga dentro de sus responsabilidades y no asistan otros interesados.

Mis agradecimientos a Scrum Manager por difundir este post también en su blog :-)