Sí, usted está listo para implementar un proyecto ágil

En caso de duda, pregunte a un experto.

Además de conocer, entender y adoptar los valores y principios del manifiesto por el desarrollo ágil de software, piense que no se trata de un solo proyecto, se trata de toda una transformación organizacional que implica cultura, filosofía, enfoques, técnicas, métodos y, lo más importante, personas.

La evolución hacia ágil es importante, igual que establecer cuáles serán los factores clave de éxito y, entre aquella y estos, la selección de equipos y proyectos pilotos se convierte en algo vital en todo esfuerzo de mejoramiento ágil.

Sobre la evolución a ágil

Si viene de una metodología en cascada, de un enfoque tradicional de comando y control tipo PMI, de un modelo de calidad riguroso tipo CMMI, o de una combinación de todos, entonces esto le interesa:

1. Debe definir un proceso de mejoramiento continuo que lo lleve del enfoque actual a una estrategia ágil. No intente hacerlo tipo “Big Bang”, es decir, de la noche a la mañana. Seguramente durante mucho tiempo tendrá que convivir con los dos universos de proyectos.
2. La implementación del proceso ágil empieza con la interiorización de los valores y principios ágiles (El Manifiesto Ágil) y es única y adaptada a todas las especificaciones que se ajusten a las metas organizacionales.
3. Debe ser una transformación progresiva a través del enfoque ágil, el cual integra paso a paso las prácticas ágiles requeridas. Por ejemplo, empiece con Scrum y algunas prácticas adicionales (Kanban, Story Mapping, Impact Mapping, Planning Poker, User Stories) y luego siga con algunas de estas: TDD, BDD, Pair Programming, Refactoring, entre otras.
4. Si tiene que tomar elementos del proceso actual, use prácticas de Lean para hacerlos más livianos y eliminar lo que podría constituirse en desperdicio.
5. Implemente los conceptos de Valor, Software de Valor para el negocio, Definición de Terminado, Definición de Listo y Criterios de Aceptación. Haga que todas las personas en la organización los adopten y los conviertan en tema cotidiano de conversación.
6. Despójese y remueva de la organización los vicios y las comodidades actuales. Si quiere nuevos y mejores resultados, cuéntele a todos, debe empezar a hacer las cosas de una manera diferente.
7. Tenga el coraje para decir que implementar Ágil no es fácil. Hacer software es una tarea compleja y, aunque las prácticas ágiles son livianas y fáciles de entender, son extremadamente difíciles de llegar a dominar… ¡o algo así reza en la guía de Scrum!

Sobre los factores clave de éxito

1. Los miembros del equipo deberían estar dedicados 100%y trabajar fuera de su rol funcional actual.
2. La administración debe estar dispuesta a seguir adelante con el enfoque, sin importar los errores que se cometan.
3. El Dueño de Producto es parte del equipo.
4. Un Scrum Master debe estar presente y ser capaz de trabajar con el nuevo proceso.
5. Defina una estrategia de trabajo con todas personas y recursos de apoyo.
6. No sea impaciente, el éxito quizás no se logra en el primer intento.
7. Empiece con unas pocas métricas para medir la realidad de los proyectos y de la organización, no a las personas.

Sobre los proyectos piloto

Uno o más proyectos pilotos son importantes. Algunas de las características que debe tener un piloto son las siguientes:

Duración: ni muy corta ni muy larga. De 3 a 9 meses, con una media de 6 meses es un buen tiempo para un proyecto piloto. Recordemos que aunque los resultados parciales de los Sprints nos van a permitir afinar el proceso y las técnicas, también necesitamos el resultado final de cada proyecto piloto para tomar decisiones importantes y mirar aspectos a reforzar. Más de 9 meses es mucho tiempo para ello. Importante aquí es explicar bien a la organización que los métodos ágiles no solo son para proyectos pequeños como estos pilotos, sino para cualquier tipo de proyecto.

Complejidad: ni muy fáciles ni muy complejos. Deben ser mediamente importantes pero definitivamente no críticos para la organización. Hay que recordar que estamos en un proceso de aprendizaje y que podemos cometer errores. Si estos errores son en proyectos críticos, podemos echar al canasto de la basura todo el esfuerzo de implementación ágil debido a la mala imagen ante la organización, al retiro de nuestros patrocinadores, etc. La organización puede ver esto como que Ágil no funciona. Importante es que el proyecto, aunque no corporativo, tenga visibilidad organizacional, que sea conocido por la alta gerencia.

Tamaño: un solo equipo de desarrollo, como dice la guía de Scrum, de entre 3 y 9 personas. 5 o 6 personas es un tamaño adecuado. Adicionemos el Dueño de Producto y el Scrum Master y estamos listos. Por supuesto, esto debemos conjugarlo con la complejidad y duración del proyecto. El equipo debe estar físicamente en una sola ubicación. Un coach de más experiencia puede apoyar ciertas tareas y ser un soporte para el Scrum Master.

Personas: Los miembros del equipo deben:

• Tener empatía y ser abiertas
• Tener coraje para aceptar y conducir el cambio
• Tener auto-disciplina que se traduzca en disciplina de equipo
• Confiar en ellas mismas y en el resto del grupo

Como siempre, debe ser un equipo multi-funcional empoderado, con los recursos y autoridad necesaria para alcanzar las metas del negocio. Aspectos como la visión de las personas, colaboración, responsabilidad y productividad se conjugarán bien en un proyecto piloto y mantendrán elevada la energía del grupo.

Muy importante es conseguir Orientación vía entrenamiento o acompañamiento para los Scrum Master y adicionar a esto dedicación, para lograr que el proyecto funcione sin importar lo que pase. No se comprometa más allá de lo posible, explique a la organización que al principio el equipo ágil recién formado perderá el balón varias veces, pero se embarcará en una estrategia de mejoramiento continuo.

Cuando el equipo alcanza un buen paso/velocidad, invite a los ejecutivos a las ceremonias, especialmente a la Revisión. Observe Transparencia todo el tiempo, teniendo todos los artefactos (tablero Scrum, burndown chart, burndown de entrega, lista de impedimentos, Meta del Sprint, Definición de Terminado, etc.) a la vista de todos en el área de trabajo del equipo Scrum. Programe la agenda para que los interesados “vayan a ver” la actividad y guíelos a través del proceso, los artefactos y las actividades del Sprint. Haga que se “involucren” y busque su retroalimentación.

Otros aspectos a tener en cuenta

Más allá de todo lo anterior, considere lo siguiente:

• Asegúrese de que los líderes hayan entendido y recibido bien los valores y principios del manifiesto ágil. Sí, ya sé que lo dije antes, lo repito dada la relevancia y lo que significa para una iniciativa de mejoramiento ágil que se conozca el Manifiesto.
• Para un mejoramiento más rápido, considere involucrar un buen coach.
• Enfóquese primero en la calidad.
• Limite la cantidad de trabajo-en-proceso.
• Mantenga la inspección y adaptación. Los procesos ágiles como Scrum se basan en el empirismo, donde se aprende por observación. La inspección y adaptación son los medios mediante los cuales podemos mantener el proceso de mejoramiento encausado y los proyectos piloto en el camino correcto.
• Conozca cómo medir el avance (Tarea, Historia, Sprint, Release). En cualquier caso recuerde: el software funcionando es la medida principal de progreso.
• Asegúrese de que el Dueño de Producto esté empoderado para tomar decisiones por el equipo.
• Madure el enfoque de manejo de código fuente y de las pruebas.
• Estudie o trate de reconocer cuando está convirtiendo los sprints en “cascadas disfrazadas”. Este es uno de los errores más frecuentes cuando la transición se hace desde los métodos clásicos de ejecución de proyectos.
• Mantenga comunicación constante con los equipos piloto y con la organización y conserve su compromiso con la transparencia.
• Finalmente, la organización necesita comprar el proceso. No tener retroalimentación del negocio (o del Cliente) es una falla. Asegúrese de tener los interesados y Dueños de Producto correctos que puedan gestionar el backlog de producto y compartir su visión.

¿Quiere saber más?

Puede visitar estos enlaces:

El Manifiesto por el desarrollo ágil de software:

http://www.agilemanifesto.org/iso/es/

Scrum Orgánico para Iniciantes

http://www.gazafatonarioit.com/2013/05/scrum-organico-para-iniciantes.html

Lista de Chequeo Scrum

http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html

Scrum – Lo Fundamental

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html

Vademescrum, Sección I: El Scrum Master 1

http://www.gazafatonarioit.com/2013/06/vademescrum-seccion-i-el-scrum-master-1.html

Nueva Versión de la Guía Oficial de Scrum

http://www.gazafatonarioit.com/2013/08/nueva-version-de-la-guia-oficial-de.html

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

http://www.gazafatonarioit.com/2013/06/mitos-monstruos-leyendas-urbanas-y.html

Planificación del Sprint: el primer paso para producir el máximo efecto

http://www.gazafatonarioit.com/2013/09/planificacion-del-sprint-el-primer-paso.html

Gerentes de Proyectos de software, ¿una especie en vías de extinción?

http://www.gazafatonarioit.com/2013/09/gerentes-de-proyectos-de-software-una.html

De Jedi Master a Scrum Master

"Irás al sistema Dagobah. Allí aprenderás de Yoda, el Maestro Jedi que me enseñó."

Obi-Wan Kenobi a Luke Skywalker [Star Wars Episode V: The Empire Strikes Back]

Jedi Master era el rango más alto que un Jedi podía obtener. Era un requisito para poder formar parte del Alto Consejo Jedi, que era el principal medio de comunicación entre los Jedi y el gobierno de la Antigua República. Este era un título reservado para individuos que habían demostrado devoción y habilidad excepcional en la Fuerza. El rango generalmente estaba reservado para Caballeros que habían tenido éxito en convertir a varios padawan en Caballeros. Cuando un Caballero sentía que su padawan estaba listo(a), el Consejo normalmente elevaba el rango del padawan a Caballero y el Caballero a Maestro(a) bajo la condición de que el pupilo pasara una serie de pruebas. Este título también podía ser otorgado a un Caballero por acciones extraordinarias, pero este era un caso muy escaso. [1]

El Scrum Master y la Comunicación

Pero ¿qué tiene que hacer un Jedi Master en este lado de la galaxia para convertirse, para ser un buen Scrum Master? De entre las muchas respuestas que surgen, estas llaman mi atención: obtención de información, lograr que las personas se comuniquen y descubrir y discutir (algunas veces resolver) impedimentos. Como siempre, no está de más el excelso conocimiento que debe tener de Scrum como tal, para que pueda velar porque se cumplan sus reglas como lo dice la Guía. Pero es el asunto de la comunicación el que me va a ocupar a continuación.

Ser un facilitador de la comunicación es uno de los talantes cardinales que distinguen a un excelente Scrum Master. Como conductor de la información es donde un Scrum Master agrega el mayor valor al equipo y a la organización. De hecho, el rol sería menos crítico si el equipo y los interesados fueran capaces de comunicarse mejor entre ellos, pero esto generalmente no ocurre. Es bien sabido la comunicación es un problema inherente al ser humano y que está más arraigado entre quienes trasegamos diariamente por los vericuetos de la Ingeniería de Software. Un estudio de la Universidad de Case Western Reserve en Estados Unidos concluyó que “cuando el cerebro humano se aboca por completo a una tarea que requiere sus habilidades analíticas, sus habilidades sociales simplemente se van de vacaciones.” [2]

Cuando el Scrum Master está lejos se presentan vacíos en la comunicación entre los miembros del equipo y entre estos y el resto de la organización. Una de las situaciones más comunes se presenta cuando en una reunión diaria un miembro del equipo de desarrollo justifica su falta de productividad o de trabajo argumentando que otra persona del equipo o el Dueño de Producto no le ha entregado cierta información que requiere. Es en esos momentos en los que se evidencia la falta de un Scrum Master que ayude a salvar esos hoyos negros comunicativos y le explique al desarrollador que esa otra persona no muerde, que bien puede reunirse con él (ella) en vez de estar esperando la respuesta a un correo electrónico, que siempre recuerde el valor del manifiesto ágil: “Personas e interacciones sobre procesos y herramientas”.

El Scrum Master, el Equipo y la Organización

Adicionalmente, un Scrum Master debe entender la cultura de la organización para generar buenos momentos de implementación del proceso y para que la nueva cultura ágil sea consistente con la visión actual de la organización. El Scrum Master debe además guiar y apoyar a cada individuo en el uso de Scrum y de las prácticas ágiles relacionadas.

Este es un rol que evoluciona junto con sus responsabilidades y que evoluciona en círculos, ya que siempre habrá un equipo nuevo, un miembro nuevo, un proyecto nuevo; de tal suerte que la paciencia es una virtud que todo Scrum Master debería tener. También la flexibilidad, para ser capaz de colaborar con diferentes personalidades y para enfrentar los diversos obstáculos que encontrará en el camino, desde la persona ultra-radical a la que nada le sirve, pasando por el individuo pasivo hasta el proactivo que quiere hacer de todo.

Un buen Scrum Master es el pegamento del proyecto así como su capa protectora externa. En el interior, el Scrum Master sirve como apoyo y ayuda para que todo, y todos, esté(n) en continuo movimiento. En el exterior, debe ser capaz de maniobrar cualquier posible interferencia que pueda poner en problemas al equipo. Su táctica debe ser averiguar qué hacer en el momento adecuado, alineando Scrum con el sentido común, que algunas veces no es tan común.

Ahora bien, no hay un modelo de Scrum Master universal, un comodín, ya que cada proyecto y cada equipo es una galaxia dentro del universo de la Ingeniería de Software, y cada uno de aquellos se despliega en un contexto diferente en cada organización. Aun durante el mismo proyecto, en distintas etapas, es muy probable que el Scrum Master requiera mostrar habilidades específicas.

¿Quieres ser Scrum Master con habilidades extraordinarias?

Nigel Steane, en su blog Agile Experience, menciona estos 10 atributos que todo buen Scrum Master debe tener [3], muy a la usanza de los Jedi Master:

10. Ilumina el camino hacia un futuro más brillante para tu equipo - remover impedimentos

9. Haz el viaje con tu equipo y comparte el camino - promover el Burndown diario

8. Reconoce que eres un líder al servicio de los demás - facilitar el manejo del backlog de producto

7. Se consciente del (software) legado que estás creando - implementar prácticas ágiles de ingeniería

6. Involucra al equipo en la mejora continua - facilitar Retrospectivas del Sprint, actúa sobre los hallazgos

5. Asegúrate que el equipo tenga la siguiente Historia cuando la requiera, y que no sea seleccionada al azar – promueve y desarrolla un equipo multifuncional

4. Sigue el marco de trabajo de Scrum - Asegúrate de contar con los roles correctos para garantizar el éxito

3. Fomenta la comunicación - asegúrate de que la reunión diaria se lleve a cabo

2. Conviértete en un embajador Ágil - transmite los beneficios de Scrum

1. Da ejemplo y predica con el ejemplo - asume la responsabilidad de la adopción y la práctica de Scrum

Yo quiero agregar que no es necesario obtener una certificación como Scrum Master [4], al menos no mientras adquirimos experiencia. Volviendo a la historia de los Jedi Master, Anakin Skywalker, quien sobrepasaba a varios Maestros Jedi en poder puro, nunca logró el rango de Master,  aun cuando Palpatine lo designó como miembro del Consejo Jedi antes de seducirlo hacia el lado oscuro de la Fuerza. Se cree que esto se debió a su orgullo, a su escasa experiencia y que emocionalmente era muy inmaduro. [1] ¿Algún parecido con la realidad?

Finalmente

En cualquier caso, el Scrum Master debe ser alguien con quien todos en el equipo y en la organización sientan que pueden comunicarse. Alguien que tenga la confianza del equipo y la habilidad de motivar a todos.

¡Que la fuerza los acompañe!

Referencias

[1] http://es.starwars.wikia.com/wiki/Maestro_Jedi

[2] Estudio explica por qué ingenieros, programadores y científicos son antisociales

http://www.biobiochile.cl/2012/10/31/estudio-explica-por-que-ingenieros-programadores-y-cientificos-son-antisociales.shtml

[3] http://nsteane.wordpress.com/about/

[4] ¿Por qué fallan las implementaciones Scrum?

http://www.gazafatonarioit.com/2013/10/por-que-fallan-las-implementaciones-de.html

¿Por qué fallan las implementaciones de Scrum?

Respuesta: porque desconocemos los valores y principios del Manifiesto Ágil punto

El Manifiesto por el Desarrollo Ágil de Software

La razón que expuse es apenas una de las muchas por las cuales podemos fracasar al intentar Scrum. Para hacerle frente, entonces es necesario conocer de qué se trata exactamente el Manifiesto Ágil. Este lo encontramos en http://www.agilemanifesto.org/iso/es/. Sin embargo, lo copiaremos aquí para explicar mejor el asunto que nos ocupa:

Estamos descubriendo formas mejores de desarrollar

software tanto por nuestra propia experiencia como

ayudando a terceros. A través de este trabajo hemos

aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,

valoramos más los de la izquierda.

Estos son los valores. Le siguen una docena de principios que pueden encontrar en la página que mencioné antes. Este texto parece inofensivo pero encierra una enorme carga emocional; sin embargo, lo más importante es que nos enseña justamente cómo debemos enfrentar los proyectos de construcción de software actuales. Y como leerlo es más fácil que entenderlo, en la sección de Referencia enumero algunos de los artículos de mi Gazafatonario IT que intentan explicar de una u otra forma la razón de ser de este manifiesto.

Algunas recomendaciones para tener éxito al implementar Scrum

• No piense en herramientas antes que en el proceso y no piense en el proceso antes que en las personas y sus interacciones. ¿Cómo va a lograr que las persones interactúen entre sí? “La gente tiene que trabajar cara a cara” dice el mismísimo Jeff Sutherland, y para todos Scrum debe ser una forma de hacer, una forma de ser, una forma de vida. Esto es, valorar el valor “Personas e interacciones sobre procesos y herramientas” del Manifiesto Ágil.
• Necesitamos herramientas, sí, pero no permitamos que estas nos dicten el proceso e indiquen el camino a seguir, lo último que queremos son productos de software costosos antes de lograr que Scrum funcione o antes de lograr los primeros resultados exitosos con el método. Además, necesitamos un proceso para gestionar toda una operación, desde la concepción de los productos hasta la puesta en funcionamiento de los mismos a cabal satisfacción de los usuarios/clientes; y el núcleo de ese proceso debe ser precisamente Scrum, tal y como dice la Guía, no es necesario “inventar” nada más.
• Tampoco es necesario eliminar o agregar nada más a Scrum como marco de gestión. Por ejemplo, decir que hacemos Scrum pero no tenemos Dueño de Producto o usar el patrón proxy del Dueño de Producto, es algo común en las implementaciones deslucidas de Scrum. Uno de los principios del Manifiesto Ágil lo dice claramente: “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.” Esto apunta a resolver la mayor causa de fracaso en los proyectos tradicionales: “falta de involucramiento del usuario” [7]. 
• No piense que Scrum le va a solucionar todos sus problemas, incluidos los personales. Scrum no es una bala de plata [4], de hecho, Scrum por sí solo no es suficiente, debe acompañarse de un conjunto de prácticas y otros métodos preferiblemente ágiles. Eso sí, no intente implementarlos todos de una sola vez y mucho menos intente hacerlo solo, hágase acompañar de expertos, de personas que hayan recorrido el camino y que quizás hayan cometido uno o dos errores críticos; con seguridad, serán ellos quienes lo sacarán del aprieto en el que posiblemente se va a encontrar más de una vez.

• No piense en las certificaciones. Si cree que les hacen falta, estas llegarán a su debido tiempo. Cuando tenga la suficiente experiencia y madurez para darse cuenta que no las necesita. Sí, certificarse nos trae beneficios a nosotros como individuos y a las organizaciones para las que trabajamos o representamos. La certificación verifica que nuestro nivel de pericia y conocimiento es consistente con los estándares de la profesión en un área específica, pero, también a veces, las certificaciones atribuyen competencias donde usualmente no las hay, a quienes usualmente no las tienen.
• Uno de los aspectos que hacen “mágico” a Scrum es que podemos implementarlo usando Scrum. La gran ventaja es que no tenemos que definir un proceso porque ya está definido [8]. Podemos tener una Lista de elementos a implementar (el backlog) y los separamos en sprints de 2 semanas para ir implementando gradualmente en unos pocos meses. Esto permitirá que las personas se sientan cómodas y a gusto con el cambio y se logren mejores resultados más rápidamente.

En cada Sprint de implementación de Scrum realice las ceremonias orgánicas de Scrum:

1. Planee cada sprint de la implementación
2. Haga reuniones diarias
3. Al final de cada sprint revise los resultados
4. Antes del siguiente sprint, haga una retrospectiva de lo que fue bien y lo que fue mal durante el sprint actual de implementación 

Se me ocurre que podríamos usar, para empezar, este algoritmo general de la implementación de Scrum:

Figura 1: Algoritmo general de la implementación de Scrum usando Scrum

Esta es una primerísima versión del algoritmo a “mano alzada”, escucho opiniones al respecto.

Otras Recomendaciones a tener en cuenta para asegurar el éxito en una implementación de Scrum

• Todo el equipo debe tener un pensamiento Ágil.
• Debe haber un alto grado de cohesión en el equipo, incluyendo a los usuarios.
• Centrado en el usuario
• Transparente, es decir, todos deben conocer el estado del proyecto en cualquier momento
• Debe predominar la Cultura de la Calidad
• Debe haber retroalimentación continua de todos los participantes
• Manejo de riesgos conjunto
• Se requiere disciplina
• El equipo debe tener un experto en métodos ágiles en general y en Scrum en particular para hacer coaching y acompañamiento continuo.
• Participe o, al menos, manténgase en contacto con otras personas que estén usando Scrum: la Comunidad Ágiles Colombia [9] es un buen ejemplo de ello; la de Ágiles Latinoamérica [10] también.

Finalmente, cuando tenga la suficiente experiencia y cuente con equipos maduros, quizás antes, atrévase a adicionar sus propios valores al Manifiesto Ágil y póngalos en práctica. Ya en la comunidad Ágiles estamos discutiendo algunos de esos nuevos valores y principios:

Experiencia efectiva sobre certificaciones retóricas

Innovación continua sobre mantenimiento de productos

Satisfacción del Cliente sobre margen de utilidad

Felicidad de las personas sobre inapetencia profesional

¿Se animan con otros? Pueden dejarme sus comentarios o ir al foro de la comunidad Ágiles Colombia y participar de la discusión. Lo encuentran en:

https://groups.google.com/forum/#!topic/agiles-colombia/Cd3QJRnHYEo

Referencias

Scrum – Lo Fundamental

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html

Scrum Orgánico para Iniciantes

http://www.gazafatonarioit.com/2013/05/scrum-organico-para-iniciantes.html

Vademescrum, Sección I: El Scrum Master 1

http://www.gazafatonarioit.com/2013/06/vademescrum-seccion-i-el-scrum-master-1.html

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

http://www.gazafatonarioit.com/2013/06/mitos-monstruos-leyendas-urbanas-y.html

Planificación del Sprint: el primer paso para producir el máximo efecto

http://www.gazafatonarioit.com/2013/09/planificacion-del-sprint-el-primer-paso.html

Gerentes de Proyectos de software, ¿una especie en vías de extinción?

http://www.gazafatonarioit.com/2013/09/gerentes-de-proyectos-de-software-una.html

Chaos Report. Standish Group. www.standishgroup.com/‎

La Guía de Scrum. http://www.scrum.org/scrum-guides‎

Ágiles Colombia. http://agilescolombia.org/

Ágiles Latinoamérica. http://www.agiles.org/‎

Planificación del Sprint: el primer paso para producir el máximo efecto

“Es un mal plan aquel que no admite modificación”

Publio Sirio, siglo I a.C.

Presentación

Ya sabemos que “el trabajo a realizar durante el Sprint se planifica en la Reunión de Planificación de Sprint.” [1] Es durante esta reunión a la que asiste el Equipo Scrum en pleno que se responden estas dos cuestiones:

• ¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
• ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento? [2]

Durante la reunión se propone un Objetivo a alcanzar en el sprint que inicia y se discuten los elementos de la Lista de Producto que, una vez terminados, dan como resultado el logro del objetivo propuesto.

Durante la primera parte de la reunión el Dueño de Producto propone los elementos de la Lista de Producto que quiere ver terminados hacia el final del sprint. En la práctica, el Equipo de Desarrollo realiza todas las preguntas necesarias al Dueño de Producto con el fin de clarificar aspectos de los elementos de la Lista de Producto, por ejemplo, de las historias de usuario seleccionadas para el sprint. Esta parte de la reunión es un evento típico de recolección de información, se establecen los criterios de aceptación de las historias de usuario, los pormenores funcionales y no funcionales de las mismas y todo lo que haga falta para que el equipo pase luego a decidir cómo se conseguirá terminar el trabajo del sprint.

En principio, el equipo debe estimar el esfuerzo necesario que le tomará terminar cada historia de usuario según lo establecido en la Definición de Terminado. Para ello, el equipo debe poner de manifiesto su experiencia en el ciclo de vida del desarrollo del software, desde el análisis, pasando por el diseño, la implementación, las pruebas, la documentación, hasta el despliegue del producto funcional. La estimación puede hacerla entonces usando técnicas ágiles como Planning Poker, que permite fijar los puntos de historia de cada una de las historias de usuario y que servirán luego para calcular la Velocidad del equipo y evaluar aspectos de productividad y calidad.

Al final de la reunión el equipo tiene definidos:

• Un Objetivo del Sprint y
• Una Lista de Pendientes del Sprint

Además del número total de puntos de historia que se construirán en el sprint que comienza. El objetivo del sprint es una corta descripción, una o dos frases, de lo que el equipo planea alcanzar durante el Sprint. Por ejemplo, si estamos construyendo un sistema de publicación en línea, este bien puede ser el objetivo de un Sprint:

• Implementar la creación básica de blogs, adición básica y publicación de entadas a los blogs y publicación de comentarios a esas entradas.
• Implementar la gestión básica de usuarios, el ingreso a la aplicación y el recordatorio de contraseñas.

Es una meta que debe estar visible a todos los miembros del equipo y de los demás interesados y cuyo significado debe entenderse a cabalidad. Por ejemplo, “adición básica de entradas a los blogs” quiere decir que se permitirán entradas con texto y una imagen en algún formato conocido; y no quiere decir que se permitirán todos los formatos de imágenes usados hoy, ni que se permitirá inserción de videos o de documentos, tampoco que habrá revisión ortográfica. Es precisamente el contexto lo que debe ser acordado y entendido por todo el Equipo Scrum.

Algunas malas prácticas en la reunión de Planificación y cómo evitarlas

A la reunión de Planificación del Sprint asiste el equipo Scrum en pleno, incluyendo el Scrum Master y el Dueño de Producto, responsable de direccionar el trabajo del Equipo de Desarrollo. Incluso es posible que asistan algunos interesados que apoyen al Dueño de Producto en la clarificación de los elementos de la Pila de Producto. El Equipo debe planear muy bien la reunión, el Scrum Master debe velar porque se haga en el bloque de tiempo establecido por las reglas de Scrum, por ejemplo, 4 horas para un Sprint de 2 semanas. El Dueño de Producto debe estar preparado para responder las cuestiones que surjan de la selección de elementos de la Lista de Producto que serán seleccionados para el sprint.

El Equipo de Desarrollo debe estar completo, ser multifuncional, preparado física y anímicamente para enfrentar un nuevo sprint, los sprints anteriores son cosas del pasado, las acciones de mejoramiento se tomaron y se llevaron a la Lista de Producto para su implementación efectiva, de acuerdo con la prioridad del Dueño de Producto y del Equipo en general. El Equipo está conformado por personas, no por súper héroes que trabajan 16 o más horas al día o con capacidades por encima del promedio (esto último apenas es una ganancia pero no debe tomarse como fundamento para sobrecargar al equipo con tareas que van más allá de su esfuerzo normal).

Aun así debemos tener cuidado: una reunión de planificación mal ejecutada terminará con un mal plan, con elementos de la Lista de Producto pobremente entendidos (por ejemplo, requisitos incompletos o ambiguos), con sobrecarga de trabajo para el equipo, con “sprints individuales”, es decir, iteraciones planeadas para cada miembro del equipo en vez de una sola para todo el equipo; sin la definición de “terminado” o sin el objetivo del sprint claro. Por ello tengamos en cuenta lo siguiente.

Esto es lo que hemos aprendido de las reuniones de planificación del sprint:

No empiece sin el Dueño de Producto. El Dueño del Producto está ausente o remoto. En Ágil/Scrum promulgamos y valoramos más la interacción entre las personas que los procesos y las herramientas. “El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara” [3], dice uno de los principios del Manifiesto Ágil. Así que es primordial que el Dueño de Producto esté disponible y presencial durante toda la reunión.

Además, el Dueño de Producto debe estar cuando se realice la estimación y la planeación de tareas. En ocasiones, el Dueño de Producto ayuda a bajar la tensión y las expectativas que se hace el Equipo cuando de construir un incremento del producto. El Dueño de Producto quizás insista en hacer las cosas de otra manera, sencilla o más liviana, pero de valor para el negocio. O al contrario, el Equipo de Desarrollo o el Scrum Master pueden motivar al Dueño de Producto a disminuir su interés en ciertos aspectos del producto pero a fijarse en otras características de mucho más valor y rendimiento para la organización. Recordemos “la simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.” [4]

No permita que el Dueño de Producto sea quien decida sobre la cantidad de trabajo que el equipo debe realizar. En otras palabras, que el Dueño de Producto proponga (imponga) la cantidad de elementos de la Lista de Producto a construir durante el sprint, sin tener en cuenta la Velocidad del equipo o el esfuerzo total que el equipo puede acometer durante la iteración. A medida que el Dueño de Producto propone elementos de la lista, el equipo estima su implementación y resta el estimado del tiempo total efectivo del sprint. Recordemos que “los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.” [5]

El Dueño del Producto no está listo para el Sprint. O la Lista de Producto no está lista. Muy bien, estamos todos los que somos para la reunión pero a las primeras de cambio el Dueño de Producto nos empieza a decir que no tiene las respuestas, que desconoce tal o cual característica, que debe consultar dentro de tres o más días con alguien más, incluso externo a la organización, que no está seguro si las cosas son así o de otra forma, en fin, esa serie de respuestas que finalmente nos llenan de requisitos incompletos y, por consiguiente, de supuestos. Nuestro cerebro tiende a llenar los vacíos con conjeturas que le pueden hacer mucho daño al proyecto.

En el caso de las consultas para más tarde o para días posteriores, le debemos aclarar al Dueño de Producto (y por “debemos” quiero decir el Scrum Master), que dado que el sprint tiene una duración muy corta (2 semanas, por ejemplo), no es posible esperar tanto tiempo por sus respuestas y pasamos así al siguiente elemento de la lista. Precisamente, para evitar estas anomalías, recurrimos a prácticas de refinamiento de la Lista de Producto que consisten en que, en medio del sprint actual, nos reunimos con el Dueño de Producto para agregar detalles, lo mismo que priorizar y estimar los elementos de la lista de los próximos dos sprints. Así cuando llegue el momento de la planificación, el Dueño de Producto esté lo suficientemente preparado como para iniciar la nueva iteración sin contratiempos.

Planear un esfuerzo total que sobrepasa los límites del Equipo, por ejemplo, planear tareas del ciclo de vida del software en tiempos de reunión de Revisión o de Retrospectiva. Si el equipo es de 5 personas y estamos haciendo sprints de 2 semanas, debemos restar 15 horas de esfuerzo total por estas 2 reuniones (10 por la reunión de revisión y 5 por la de retrospectiva), además unas 12  horas de esfuerzo por reuniones diarias y 20 horas por la reunión de Planificación del Sprint, esta de la que estamos hablando. Es decir, unas 47 horas menos, con lo que el esfuerzo real sería de 353 horas para ese equipo de 5 personas.

Incluso deberíamos planear jornadas efectivas de menos de 8 horas, por ejemplo 6 o 7, máximo. Con 7 horas, por ejemplo, el esfuerzo total del equipo de 5 personas sería de unas 300 horas. Algo realista y que, a la larga, contribuye a aumentar la productividad, la energía de las personas del equipo, la motivación y, como  consecuencia, mejora la calidad de los productos que construyen. “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.” [6]

Otras cosas que no debemos hacer antes, durante o después de la reunión de Planificación del sprint

• La reunión tarda más de lo debido. El Scrum Master debe estar atento a ello. Puede ser un indicativo de falta de productividad o de que estamos sobre-planificando el sprint.
• Cada miembro del equipo planea su “sprint individual”. O se hace una planeación para alguien en particular, “alguien adicional”.
• No planear de manera colaborativa. Va de la mano con la anterior práctica errónea.
• No planear la reunión con anticipación. Vale para todo el Equipo Scrum. Si hicimos Refinamiento deberíamos tener el suficiente apresto para realizar una reunión dinámica y efectiva.
• No definir un Objetivo del Sprint. ¿Entonces hacia dónde vamos? El Objetivo es la brújula que nos orienta.
• Planear tareas de 8 horas o más para un miembro del equipo. Se deben planear 2, 3 o más tareas cuya suma de esfuerzos individuales sume el tiempo total de esfuerzo diario de cada miembro del equipo.
• Permitir que alguien, por ejemplo el Dueño de Producto o el Scrum Master, incluso alguien externo, asigne las tareas al resto del equipo.
• Ausencia física del Scrum Master en la reunión de planificación. Puede estar virtual pero seguramente el valor de su participación será mucho menor.

Referencias

[1], [2] La Guía de Scrum. http://www.scrumguides.org/download.html

[3], [4], [5], [6]  El Manifiesto Ágil. http://www.agilemanifesto.org/iso/es