¿Qué técnica utilizar para estimar epics y temas?

Existen varias técnicas de estimación relativa, la más extendida es el planning poker basado en la serie de Fibonacci. Otra técnica común está basada en tallas de camisa: XS, S, M, L y XL. Está técnica tiene la ventaja de ser puramente relativa, no es posible traducir sus valores a tiempo, a jornadas u horas. Tiene dos desventajas frente a la serie de Fibonacci, sus valores no son aditivos, sería complicado medir la velocidad de un sprint en base a tallas de camisa, y la relación entre sus valores seguramente no significa lo mismo para los distintos miembros de un equipo.

Baraja para la estimación por tallas de camisa - cortesía de BEEVA

¡Nosotros utilizamos ambas técnicas! Dentro del ámbito de las historias de usuario utilizamos la serie de Fibonacci y para los epics grandes y los temas, las tallas de camisa. Nos hemos planteado utilizar la serie Cohn, derivada de la serie de Fibonacci, que sustituye el 21 por 20 e incluye el 40 y el 100, para historias, epics y temas, pero esos últimos dos valores, aunque muy grandes, dan idea de cierta precisión inexistente. Realmente los elementos más grandes de la pila de producto son muy vagos para estimar y el utilizar las tallas de camisa nos da algo como una intuición más que una estimación, con un gran grado de incertidumbre amplio acorde a epics y temas.

Así tenemos una pila de producto con elementos estimados con dos técnicas, pero coherente con Agilidad. Los elementos de la parte cercana de la pila están detallados, incluida la estimación, y los elementos más lejanos poco granulados, con una estimación más vaga y amplia. En la reunión de refinamiento, cuando epics se dividen en historias de usuario, es cuando reestimanos con la técnica correspondiente.

El Propietario del Producto se basa en el resultado de ambas técnica para priorizar la pila de producto, tiene valores más detallados de lo que tiene frente a sí y necesita estar más perfilado, y tiene valores con detalle suficiente para elementos los lejanos y poco prioritarios.

¿La respuesta al cambio por encima del seguimiento de un plan?

Del meetup de Madriagil
Agile Manifesto: Back to Basics

Scrum es un marco de desarrollo que se creó para dar respuesta a entornos inestables con un alto grado de variación, entornos que tienen como factor inherente el cambio y la evolución rápida y continua. Este cuarto valor del Manifiesto Ágil muestra que resulta mucho más valiosa la capacidad de respuesta al cambio que la de seguimiento y aseguramiento de planes preestablecidos. Los principales valores de la gestión ágil son la inspección y la adaptación, diferentes a los de la gestión de proyectos predicitiva donde tienen importancia la planificación y el control para evitar desviaciones sobre el plan.

De ahí nace uno de los mitos más extendidos sobre Scrum, hay la creencia de que en Agilidad no se planifica... nada más lejos de la realidad, ¡en Agilidad se planifica a cinco niveles!

El malentendido viene del hecho de que la Agilidad no le da importancia a los planes, pero sí, y mucha, a la al acto de planificar y la replanificación continua. Con cada cambio, con cada desgranado y detallado de las historias de usuario, con cada medición de la velocidad de los equipos, Scrum prescribe replanificar. El modo en que Scrum absorbe la variación y por tanto responde al cambio, hasta deberíamos decir "abraza al cambio", es aceptar el cambio y replanificar en cada nivel el siguiente paso correspondiente. A nivel de reunión diaria se microreplanifica día a día, a nivel de planificación de sprint se planifica el próximo sprint, a nivel de release se replanifica la próxima release, a nivel de hoja de ruta se ajusta sus etapas y finalmente a nivel de visión puede ser que se ajuste esta, aunque este caso es muy poco frecuente y solo ocurre con cambios sustanciales.

Alinearse con este valor requiere una mente abierta para recibir el cambio cultural que implica. Los planes, como herramienta establecida, hacen sentirnos seguros, pero ponen el foco fuera de la realidad. Cuando hemos logrado pintar nuestro plan en forma de un un gantt gigantesco, hay equipos que lo imprimen y decoran una pared con él y los irradia continuamente, luego creemos que cuando no se cumple el plan, el problema tiene que estar en la realidad.

En nuestra vida personal absorbemos fácilmente las cosas que se cruzan en nuestro camino, nos adaptamos y seguimos. Por ejemplo si viajamos de Madrid a Zaragoza y hemos planificado un viaje de 3 horas, si resulta que hay una tormenta a medio camino, bajamos de 100 km/h a 60 km/h y aceptamos sin más que el viaje serán 4 horas. Ese comportamiento natural no lo aplicamos igual en nuestra vida profesional, miramos el plan y nos aferramos a él intentando que se cumpla a toda costa. Por tanto el problema a resolver para adoptar la respuesta al cambio cuando aún no somos ágiles, está en nosotros, en superar nuestros miedos, inseguridades y incertidumbres.

¿La colaboración con el cliente por encima de la negociación contractual?

Del meetup de Madriagil
Agile Manifesto: Back to Basics

Este tercer valor del Manifiesto Ágil es tan evidente como algunas veces lejano a la realidad en ciertos proyectos de TI.

Un contrato es una formalidad que establece líneas divisorias entre responsabilidades y fija los referentes para cuando las cosas van mal, y como tal no aporta valor alguno al producto. En un proyecto con metodología predictiva, con una sola entrega a final del proyecto y en el que el cliente no ha participado durante el mismo, la negociación contractual suele ser inevitable. Ocurre hacia el final de proyecto, cuando la fecha de entrega aprieta, los equipos del proveedor hacen jornadas maratonianas a base de "tracción sangre" para llegar a mínimos, con el único objetivo de cumplir con el contrato. Cuando lo esperado no concuerda con lo construido, cuando ya es tarde para tomar medidas para reconducir el proyecto, es entonces cuando cliente y proveedor entran en negociación contractual.

En un proyecto ágil el cliente es un miembro más del equipo, está comprometido y se integra y colabora con el proyecto. Hoy en día la informática es algo necesario para toda compañía, está presente en las estrategias empresariales, por tanto lo que realmente necesitan las compañías son partners, no sólo proveedores, partners que construyan, liderados por el cliente, las herramientas que harán funcionar su core-business.

Por la naturaleza de entrega frecuente hay una constante sensación de avance por parte del cliente y del partner, y, especialmente de conducción del rumbo por parte del cliente. La transparencia, la entrega frecuente, sprints que dan los resultados esperados, generan confianza entre ambos, confianza que refuerza aún más la colaboración. Un proyecto ágil pone sobre la mesa los problemas y trae los riesgos al principio de proyecto, por tanto en un momento que permite tomar medidas de reconducción en una fase temprana y dentro de un marco de colaboración. La negociación contractual queda reducida a casos extremos y puntuales.

Para terminar, mencionar que los modelos de contrato de proyecto cerrado no encajan con la agilidad, es objetivo de un contrato ágil es establecer las bases para la colaboración.

¿El software que funciona por encima de la documentación exhaustiva?

Del meetup de Madriagil
Agile Manifesto: Back to Basics

Uno de los mitos sobre Scrum es "no hace falta documentar...". Los documentos son importantes ya que permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero ¿son más importantes que los productos que funcionan? y, ¿aportan valor al producto? o ¿quizá solo aporte la documentación justa y al 100% necesaria?

Tal como dice el segundo valor del Manifiesto Ágil, los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con prototipos, o el feedback estimulante y enriquecedor sobre partes elaboradas del producto que genera ideas imposibles de concebir en un primer momento.

Desde la perspectiva ágil los documentos deben ser cortos y centrarse en lo esencial, y deben de constituir la documentación necesaria que debe de ser mantenible, compartida y generada por todos mediante un flujo solapado con las demás fases de inicio a final del proyecto. Por tanto esta se escribe a lo largo de todo el proyecto, es viva y sólo recoge aquello que es de utilidad para alguien.

No olvidemos que la documentación (diseño, especificación técnica de un sistema) no es más que un resultado intermedio, y por tanto, siempre que sea posible, debe preferirse y reducir al mínimo indispensable el uso de documentación, ya que genera trabajo que no aporta un valor directo al producto y al cliente.

Un ejercicio interesante para detectar qué documentación de nuestra empresa aporta valor es preguntar al equipo completo (desde negocio al equipo técnico, analistas, usuarios...) quién escribe algún documento, para luego preguntar por quienes son los lectores de cada uno de esos documentos. Si descubrimos documentos de "solo escritura" habremos dado con posible desperdicio y deberemos de preguntarnos si no es preferible invertir el tiempo en el producto que estamos construyendo en vez de escribirlos.

Como anécdota contar que un colaborador mío incluyó la receta de la tortilla de patatas en la documentación de usuario para averiguar si alguien se daría cuenta. 2 años después un becario al que le dieron a leer un montón de documentos en su primer día, descubrió la receta durante la primera semana, jajaja.

Otro punto crítico se produce cuando la empresa y los equipos se comunican a través de documentos, cuando además de perder la riqueza que da la interacción con el producto, los documentos se convierten en barreras entre personas y departamentos. Un documento escrito es un dibujo incompleto de las ideas de quién lo escribe, y cuando lo lee un lector, este crea otra abstracción que está a dos pasos de distancia de lo que se escribió originalmente. No es sorprendente que de esta manera se generen malentendidos, haya peloteos que van y vienen (muy comunes en la comunicación por email) y se acaben empleando los documentos de forma defensiva.

Mi agradecimientos a Fernando por la receta de tortilla de patatas :-P

¿A los individuos y su interacción por encima de los procesos y las herramientas?

Hay un par de afirmaciones que expuestas en clase todo el mundo está de acuerdo:

"El 90% de los proyectos fallan por la falta de comunicación"

"El 90% de los proyectos que tienen éxito lo tienen por las personas que intervienen"

Del meetup de Madriagil
Agile Manifesto: Back to Basics

Este es el primer valor del Manifiesto Ágil. La industria del software es una industria de talento extremo que se basa en trabajadores de conocimiento, en personas que con sus diferencias hacen equipos ganadores, innovadores y creativos, que con su conocimiento tácito hacen posible lo que ningún proceso o herramienta puede hacer. Si, los procesos y herramientas son importantes, pero lo único que de verdad lo hace posible son las personas y las interacciones entre ellas.

Los procesos, como el marco de Scrum, deben ser una ayuda y un soporte para guiar el trabajo, un elemento alineante, y deben adaptarse a la organización, a los equipos y a las personas, y no al revés. Por ello Agilidad habla de prácticas en lugar de procesos, de procedimientos de ayuda a las personas, que son quienes aportan con su conocimiento tácito, el “saber hacer”, clave para lograr el resultado, marcando así muy claramente los límites del trabajo de persona/práctica.

Pensar que los procesos son más importantes que las personas y que se puede conseguir resultados extraordinarios con personas mediocres, hace que las personas con talento queden desmotivadas o abandonen la empresa. Incluso en los años 90, con la teoría de producción basada en procesos y la reingeniería de procesos en auge, estas deben gran parte de su valor al conocimiento y al talento de las personas que las realizaban.

¿Cómo preparar la reunión de revisión de sprint?

Preparando la sala para la revisión de sprint

He vivido unas cuantas reuniones de revisión de sprint y algunas han ido mal por diversas razones. A veces el problema fue ajeno al equipo y les creó una profunda frustración e impotencia, hasta he visto lágrimas. Durante todo el sprint, el software en construcción ha funcionado perfectamente y, el día de la revisión todo falló. Un análisis posterior reveló que alguien instaló una librería equivocada en el servidor de integración, justo antes de la reunión... Por tanto una pequeña revisión y preparación anterior maximizan las garantías de éxito de la reunión.

La preparación de la reunión no debe de consumir más de 30 minutos a 1 hora de un miembro del equipo:

• Repasar que todas las historias de la pila de sprint estén cumplan con los criterios de aceptación y hecho. Si hubiera alguna que no se podrá entregar hay que preparar una explicación clara, corta y concisa, que aconsejo se exponga al principio de la reunión, ya que así colocamos las expectativas de todos en la realidad en el primer momento.
• Preparar un pequeño guión con los pasos de la demo.
• Preparar una pequeña batería de pruebas básica para la demo.
• Preparar y comprobar que todo funciona en el ordenador en el que se va a efectuar la demo, quizá desplazar un ordenador del equipo de desarrollo a la sala de la reunión.
• Preparar la sala y que todo lo necesario (suficientes sillas, pantalla o proyector visible desde toda la sala, scrumboard, rotafolios, rotuladores, post-its...) esté disponible.
• Efectuar una prueba de humo de las funcionalidades que se van a mostrar.
• Si es posible avisar a sistemas para que durante la reunión no se despliegue nada en el entorno de la demo.

Una vez todo preparado os sentiréis más seguros y eso se irradia y todos lo sentirán. Quién haya preparado la reunión será quién exponga como ha ido el sprint (qué fue bien, qué problemas hubo y como se resolvieron) y mostrará el incremento de software. Es importante dirigirse a los interesados de negocio como audiencia principal, dar la bienvenida a todo feedback de estos y estar abierto a cualquier duda o pregunta.

¡Os deseo mucho éxito!

¿Cómo priorizar una pila de producto de la forma más completa posible?

Una herramienta que puede ayudar al Propietario del Producto a priorizar la pila de producto de forma adecuada es el cálculo del ROI (Return of Investment) o retorno de la inversión:

• Valor de negocio: el valor relativo del elemento para negocio o el cliente.
• Tamaño: estimación en puntos de historia del esfuerzo necesario teniendo en cuenta complejidad y tamaño.

El ROI aplicado de forma descendente resulta en una excelente guía para priorizar la pila, cuanto más alto el retorno de inversión tanto más alta es la prioridad del elemento.

Recientemente asistí a un curso de SAFe® con Dean Leffingwell en el que recomendó la técnica de priorización lean de Don Reinersten WSJF (Weighted Shortest Job First). Esta técnica esta basada en la economía de flujo de desarrollo de productos que calcula dividiendo el coste de demora por la duración.

Lo interesante del coste de demora es que incluso las historias técnicas, que intrínsecamente no tienen valor de negocio, lo tienen. El coste de demora representa el valor que no obtenemos por no construir determinada historia, y en caso de una historia técnica se puede no obtener el valor de negocio de las historias de usuario que consumen esta última.

Dado que la duración es imposible de estimar el coste de demora utiliza el tamaño del elemento como sustituto. Al coste de demora se considera que contribuyen los siguientes tres elementos:

• Valor de negocio
• Criticidad en el tiempo: Esta medida se ocupa de la "necesidad" de la entrega del elemento en una escala de tiempo, viene asociado con la caída de valor con el tiempo. A más "necesidad" de entrega más alto será el valor.
• Reducción del riesgo y valor de oportunidad: Esta medida da un valor relativo a la eliminación de uno o varios riesgos o, un valor por el potencial de nuevas oportunidades de negocio que puede aportar el elemento.

La técnica de priorización WSJF consiste en aplicar los siguientes pasos a la pila de producto:

Ejemplo de una pila de producto priorizada por WSJF

• La técnica estima las funcionalidades / historias de usuario / epics entre si de forma relativa
• La escala de unidades es la serie de Fibonacci: 1, 2, 3, 5, 8, 13, 21
• Se rellena la lista columna por columna
• Se pone un 1 en el elemento con el valor más pequeño, tiene que haber un 1 en cada columna
• Se rellena el resto de elementos de la columna con estimación relativa respecto a la del 1
• Hecha la última columna se calcula el WSJF y se ordena de mayor a menor
• El elemento con mayor prioridad es el de WSFJ más alto

Ejercicio sobre una diapositiva del curso de Leading SAFe :-)

¿Kanban se puede utilizar con Scrum?

Scrum y Kanban son marcos de desarrollo ágiles que adoptan una estrategia de desarrollo incremental, basados en equipos autoorganizados y el solapamiento de las fases del desarrollo. La diferencia entre ambos marcos es que Scrum construye con incremento iterativo a través de sus sprints y reuniones periódicas, y Kanban con incremento continuo a través de la gestión del flujo de trabajo en base a un sistema de arrastre con restricciones al trabajo en curso (WIP).

Kanban y Scrum, incremento continuo e iterativo, cortesía de Scrum Manager

Una gran diferencia es que Kanban se puede implementar en una compañía o departamento de forma evolutiva y Scrum siempre se implementa de forma disruptiva, todo el marco se aplica de un día para otro, por tanto puede parecer de entrada que Scrum y Kanban no se pueden utilizar a la vez.

Tablero Kanban o scrumboard de equipo Scrum

Lo que hace que un equipo construya de forma incremental e iterativa es el marco de Scrum, se planifica el sprint al principio y se revisa al final el incremento obtenido. Durante el sprint el equipo utiliza un scrumboard o tablero Kanban para hacer visible su trabajo, ver el avance de su trabajo e irradiar información. Dentro del sprint la construcción es con flujo continuo de tareas, no se espera a final del sprint para poner las tareas en "hecho", flujo que se ve puede  ver representado en forma de curva descendente en el gráfico burndown. Podríamos concluir que Kanban no utiliza sprints pero se puede utilizar dentro de un sprint. Hasta se podría poner límites WIP en el scrumboard, propios de Kanban, pero no se suele hacer ya que el propio timebox de 2 a 4 semanas del sprint resulta en un límite WIP que se establece con el contenido de la pila de sprint.

¿Cómo conocer el grado de madurez en Scrum de un equipo nuevo?

Recientemente tuve la necesidad de evaluar el grado de madurez de un equipo nuevo que se iba a incorporar para trabajar en Scrum. Me imaginé que preguntar directamente no serviría de mucho, reconocerán que no están certificados pero dirán que tienen experiencia en Scrum. Tenía claro que lo que tenía que observar es la confianza entre los miembros del equipo, ver cómo interactúan entre ellos y la seguridad con que se muestran como equipo, y para eso la mejor forma sería hacerlos colaborar en alguna dinámica frente a un tablero.

Así que idee una variante del tablero de acuerdos de trabajo y maté dos pájaros de un tiro. En este tipo de acuerdo se les pide a los participantes que escriban lo que no les gustaría que pasase, y para este tablero que idee debían de escribir lo que no les gustaría que pasase durante el proyecto relacionado con el Scrum Master (SM), el Propietario del Producto (PO) y el equipo (TEAM). Dado que lo que escribirían iría directamente relacionado con los roles de Scrum, obtendría de paso la madurez del equipo.

Resultado de un equipo que ha trabajado bajo scrumbut, no han vivido
problemas con el Scrum Master pero si con el Propietario del Producto

Fue una buena experiencia, me encontré con un equipo muy bien integrado y conocedor de los procesos de Scrum. Como podemos ver en la imagen superior hay un claro desequilibro, en la parte de Scrum Master prácticamente no hay post-its, mientras que en la del Propietario del Producto y la del equipo hay muchos, incluida la zona de separación, que en este caso representa la intersección de ambos.

Me llamó la atención que una de sus mayores preocupaciones fuera la interferencia en los sprints, la adición o modificación desde fuera del equipo de la pila de sprint. Con esto supe que el equipo sabe de Scrum, y también cual es su realidad. Me extrañó que la columna del Scrum Master no tuviera apenas post-its, pero todo encajó cuando conocí más a fondo la metodología de la consultora del equipo, habían incorporado los procesos de Scrum en su metodología tradicional. Básicamente no hay post-its en la columna del Scrum Master porque no hay gestión de personas, por tanto me encontré ante una situación de claro scrumbut. Fuere como fuere es un buen punto de partida, es un equipo integrado y conocedor de los procesos de Scrum, el hacerlos evolucionar ya solo depende de este Scrum Master.  :-)

¿El framework SAFe® es a una compañía ágil como Scrum a un equipo ágil?

Big picture con la versión 3.0 del framework
cortesía de ScaledAgileFramework.com

Había oído, y hasta hace poco tenía la creencia, de que SAFe® (Scaled Agile Framework®) es un framework que está concebido para absorber la jerarquía de una gran compañía y así poder vender un producto dirigido a hacer negocio con las grandes compañías. Por otro lado había oído de la rigidez del modelo, que ciertamente se basaba en principios ágiles, pero que en conjunto no era un modelo muy ágil.

Recientemente me certifiqué como como SAFe Program Consultant y he adquirido una perspectiva algo distinta. SAFe se basa en principios ágiles, en Lean y en tres niveles de abstracción, cada uno sobre los principios del Manifiesto Ágil, así como cada uno con su pila de producto, niveles a coordinar entre sí para implantarlo en una gran compañía:

• Equipo: pila de producto a nivel de historias de usuario.
• Programa (con su ART, un equipo de equipos de entre 50-120 personas): pila de producto a nivel de funcionalidad.
• Portfolio: pila de producto a nivel de epics provenientes de una lista de temas estratégicos.

Mirando el modelo en el big picture podemos ver que el compromiso de Scrum en no variar la pila de sprint, se traduce en el modelo SAFe en el compromiso de no variar la suma de pilas de sprint de un incremento de programa (PI). Eso implica cierta rigidez, pero tiene todo el sentido, cuando hablamos de una gran compañía todo es a lo grande, el producto de software que pueda necesitar, como puede ser un software de gestión crediticia para una banco, es un software muy extenso. Por tanto el modelo es algo menos ágil en ciclos tan cortos como un sprint, ya que lo ha de ser cada 4 o 5 sprints, en equilibrio con el tamaño del producto. Resaltar que el tamaño del PI lo definimos nosotros y por tanto podemos ser más ágiles si en vez de PIs trimestrales hacemos PIs más cortos.

La idea de un framework para absorber la jerarquía de directivos y mandos intermedios no es correcta. Es cierto que SAFe implica una jerarquía, pero de roles, cada uno con sus responsabilidades independientes, con líderes participativos y al servicio orientados a personas que se dedican a mejorar el sistema, organizar, hacer de apoyo y desarrollar a sus equipos, fomentando la creatividad y la colaboración. Lo que vemos en el big picture son roles, ni títulos ni cargos.

A nivel de programa encontramos roles ágiles como:

• System Team
• Product Manager
• System Architect
• Release Train Engineer (RTE)
• UX and Shared Resources
• Release Management Team

Y por supuesto es posible que mandos anteriores, las personas, puedan hacerse cargo de estos roles del framework, pero para ello han de pasar por un cambio cultural hacía la Agilidad, basado en el Manifiesto Ágil; algunos tendrán la actitud apropiada, otros no y si no la adquieren no tendrán cabida en el nuevo modelo.

SAFe funciona porque toma un enfoque holístico y crea partnership entre la dirección y los equipos. Los equipos no están controlados por la dirección, y esta no tiene la única función de eliminación de los impedimentos, sino el foco en el verdadero pensamiento sistémico y desarrollo de las personas de la compañía.

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

¿Cómo crecer e incorporar nuevos equipos en compañías maduras en Scrum?

Hace unos días participé en un curso de SAFe® (Scaled Agile Framework), y mientras tomábamos el café estuvimos hablando sobre cómo incorporar nuevos miembros y equipos a una compañía ágil. La idea es crear huecos en los equipos existentes sacando un miembro de cada uno de ellos para formar con estos un equipo nuevo, para después incorporar en esos huecos nuevos miembros. De esta manera el impacto de estos nuevos miembros se mitiga y el aprendizaje y adaptación a la compañía se maximiza. El nuevo miembro se encuentra directamente situado en un equipo con amplia base de conocimiento y que conoce perfectamente el marco con el que trabaja la compañía, por tanto su curva de aprendizaje está maximizada. Una vez rodados se puede volver a componer los equipos originales, quedando el equipo nuevo perfectamente adaptado e integrado en la compañía.

Sala con varios equipos trabajando en un mismo producto
a modo de Agile Release Train

En nuestro entorno TI en España, dónde impera la subcontratación de equipos y proyectos a consultoras, este sistema permite absorber y formar rápidamente a los equipos nuevos, a la vez que filtra a "miembros de equipo" que no tienen cabida en Scrum. Me refiero a jefes de proyecto y gerentes desconocedores de Scrum y que en ocasiones se pueden ver sentados junto a "sus" equipos, y que bajo la perspectiva ágil resultan en verdaderos impedimentos, sobre todo para la autoorganización y autogestión del equipo. El hecho de mezclar personas de diferentes consultoras en un equipo tiene por tanto una parte positiva, eso sí, sólo funciona si la compañía cliente es ágil y lidera el desarrollo de sus productos.

Yo era reacio a la creación de equipos por personas de diferentes consultoras, yo lo había vivido bajo una perspectiva waterfall. Lo que acabó ocurriendo es que se formaron 3 jerarquías con intereses diferentes, lo que resultó en un verdadero caos: jerarquía del cliente hacía los externos que están en sus dependencias, jerarquía de la propia consultora y jerarquía interconsultoras. Siempre ocurre que hay consultoras con más peso o más ambición que intentan destacar y crean muros entre las personas de diferentes consultoras. Bajo la perspectiva de Scrum, la solución de equipos con personas de diferentes consultoras, conocedoras y practicantes de los valores ágiles, es una solución que funciona, y resulta muy compacta a interferencias exteriores. Añadir que no deben de existir diferencias entre personas de diferentes consultoras, ni entre externos e internos, y se debe de velar por la continuidad y motivación de todos ellos.

Mis agradecimientos a Marc Florit por darme esta nueva perspectiva de equipos multiconsultora :-)

¿Cómo gestionar en un marco ágil la mantenibilidad del software cuando hay rotación de miembros en el equipo?

Esta pregunta viene de un alumno que tiene un equipo dedicado al mantenimiento de un producto que se dedica a incidencias y pequeñas mejoras, equipo que tiene rotación y la compañía parte de la idea de que el mantenimiento no debe depender de una persona, debe poder hacerla cualquier persona que se vaya incorporando en el equipo.

La única ley de la naturaleza que aplica a la informática es la entropía, si no se dedican recursos, y no me refiero sólo a personas, específicamente a la mantenibilidad del producto, y este está pensado para operar a largo plazo, lo más probable es que se vuelva caótico. El problema de no tener un equipo propietario a cargo del producto es que la persona nueva no tiene sentimiento de propiedad de un código que no es suyo, y la persona que lo escribió ya no está, y si tuviera que hacer una modificación habrá perdido el sentimiento de propiedad porque ya no es suyo, su código original lo han modificado otros.

Hay que hacer gestión de cambio de personas:

Taller de transmisión de conocimiento facilitado por el coach ágil

• Más que nunca es necesario un Scrum Master o un coach ágil que forme y acompañe a los nuevos miembros en la incorporación al equipo, y al equipo a integrarlos.
• Cuidando del bus factor para mantener la base de conocimiento en todo el equipo. Se pueden realizar talleres de transmisión de conocimiento entre la gente del equipo, programación por parejas, actividades medio lúdicas de team-buidling... con cada persona que rote, con cada salida y cada incorporación, hay que hacer acciones que mantengan la motivación del equipo.

Hay que invertir en todo aquello que facilite la mantenibilidad:

Aplicar técnicas de desarrollo ágil
- cortesía de Raúl Herranz

• Tener una documentación del diseño del producto mínima y suficiente, y sobre todo mantenible. Crear una base de patrones de desarrollo y documentación en el código, desde dentro y para el equipo. Algo que sea fácil de hacer y usar, por ejemplo una wiki. Para ello hay que crear cultura wiki, el equipo ha sentir que la wiki es una herramienta para ellos, y que se sientan proactivos a enriquecerla continuamente.
• Refactorización frecuente, hacer que el equipo en curso revise el código crítico y refactorice si lo cree conveniente. Así se consigue sentimiento de propiedad mientras el equipo sea estable.
• Stop-and-fix, para los workarounds y problemas que surjan parar completamente el desarrollo, para que el equipo resuelva completamente la causa raíz y luego, una vez resuelta, siga desarrollando. Evitar caer en paliativos y en chapuzas, futuros miembros del equipo las desconocerán y el problema se convertirá en una bola de nieve.
• Si se adquiere deuda técnica, gestionarla, apuntar cada deuda en un post-it y dejarlo bien visible en algún área del scrumboard. De tanto en tanto hay que abordar una de estas tareas. 
• Situar un banner bien grande y visible con mensajes como "NO QUEREMOS CODIGO BASURA" y hacer partícipe al equipo en la motivación de mejorar el código cada vez que les parezca que algo no esté suficientemente bien.
• Implantar integración continua y pruebas automatizadas, ir a máximos, a BDD.

Todo esto sin duda tiene costes, pero no hacer nada tiene un coste mucho mayor. He vivido equipos que adquieren deuda técnica y se acaban ahogando en ella simplemente porque el software sobre el que trabajan está lleno de chapuzas y workarounds. En la naturaleza del ser humano está el síndrome de la ventana rota, si entramos en una habitación con una ventana rota no nos importa que se rompan otras cosas. Un vidrio roto transmite una idea de deterioro, desinterés, despreocupación que va destruyendo los códigos de convivencia, tales como la ausencia de ley, de normas, de reglas, dejando la sensación de que todo vale nada. Lo mismo pasa con el software, cuando te encuentras código basura generas código basura...

Quiero dar mi agradecimiento a los asistentes al curso que me dieron permiso para utilizar la foto del taller de transmisión de conocimiento, entre ellos Ovidio, Marcos, Antonio, Daniel y Patricia.

¿Realmente un Scrum Master está comprometido?

¡El Scrum Master es un cerdo!
caricatura cortesía de pixabay

Esta pregunta la realizó un alumno de un curso on-line después de estudiar los roles de Scrum y conocer la parábola del cerdo y la gallina. Decía que no entendía porqué el Scrum Master es un "cerdo" cuando su foco central es Scrum y no el proyecto/producto.

La idea de que el Scrum Master no esté comprometido no es correcta, tiene que estar totalmente comprometido con su objetivo, con su responsabilidad, que es la de acompañar a los equipos y a la compañía en la correcta implementación de Scrum.

El Scrum Master no está comprometido directamente con el producto/proyecto, su objetivo no es directamente el éxito del proyecto, sino en el cómo el equipo de desarrollo está construyendo asegurando que aplica Scrum y es capaz de entregar de forma continua valor al cliente, que tome las decisiones de la forma más ágil posible y estas sean guiadas por valor de negocio, y también que está aplicando sentido común. Usualmente un Scrum Master tiene capacidad para acompañar a 3 equipos, su foco es el equipo y Scrum, no los proyectos que haya detrás. Una persona con foco en un proyecto pierde de vista la perspectiva desde fuera, y justamente esta es la que necesita un Scrum Master.

Resaltar que el Scrum Master no es una figura de metodología que encorseta a los demás, el Scrum Master acompaña al equipo a encontrar sus propias soluciones para la entrega continua de valor, no hay nada más productivo que ajustar los procesos desde dentro, desde el equipo. Es un guía, alguien que les escucha y por el que se sienten acompañados. Los "procesos" y/o "prácticas" las explicita el equipo una vez que las cosas funcionan y hayan llegado a la madurez.

Para ilustrar el nivel de compromiso del Scrum Master podemos imaginarnos en la situación en que un project manager nos da 5 tareas y se nos pega al hombro para preguntarnos una y otra vez como vamos, además de repriorizar las tareas un par de veces, ¿os suena esa situación? Y en esa situación ¿cuántas veces hemos pensado que ojalá nos diese las 5 tareas y nos dejase organizarnos a nuestra manera, no nos molestase y que de esta forma haríamos un buen trabajo en la mitad de tiempo? Llevar a equipos enteros hacía esa autoorganización que expresa nuestro deseo es parte del compromiso del Scrum Master. Acompaña al equipo para que tome y crea en sus propias decisiones, que se sienta libre de incluir las historias que honestamente crea capaz de poder hacer dentro del sprint para que finalmente se sienta comprometido a construir las historias de la pila de sprint. A modo de analogía podríamos decir que es el aceite que hace que el motor ruede.

Para resumir; como parte del equipo ágil o equipo Scrum, la responsabilidad máxima de los tres roles, Scrum Master, Propietario del Producto y equipo de desarrollo es la entrega continua de valor, por tanto los tres roles son roles comprometidos o "cerdos".

Parábola del cerdo (comprometido) y la gallina (involucrada)