Buscar en Gazafatonario IT

lunes, enero 27, 2014

Compendio Sobre el Scrum Diario

Pregunta: ¿Cómo es posible que un gran proyecto de software se atrase un año entero?
Respuesta: ¡Un día a la vez!
[Frederick P. Brooks, Jr. The Mythical Man-Month. Pp. 153.]
Se ha llamado Reunión Diaria, Scrum Diario, Reunión de Pie, Reunión Diaria de Pie y de algunas otras formas equivalentes, en todos los idiomas. Esta no es solo una reunión de pie. Este ritual, que bien puede implementarse en proyectos de todo tipo, ágiles y no ágiles, tiene una importancia que muchas veces pasa desapercibida para el común de los mortales.

Brooks, en su ya antiquísimo libro The Mythical Man-Month, y del que me he permitido extraer la frase inicial, dice que pequeñas demoras incrementales en distintos frentes del proyecto eventualmente se acumulan para producir un enorme retraso. Se requiere entonces atención permanente para alcanzar metas individuales pequeñas o parciales en todos los niveles del proyecto. [1]

Hace ya 40 años Brooks ponía de manifiesto la necesidad de una sesión como esta. Es una reunión de planificación, no de seguimiento como erróneamente creen algunos. También es una ceremonia de sincronización del equipo, para que sus miembros se enteren de los avances del Sprint de todo el equipo y de las dificultades existentes, cuya exposición se hace para que cada participante se postule en pro de su solución.

Así que si eres un Scrum Master o haces parte de un Equipo Scrum, sigue estos consejos que he tomado de aquí y de allá, incluida mi propia experiencia facilitándolas y ayudando a terceros a facilitarlas.

Algunos Patrones de Comportamiento Durante el Scrum Diario

Sé riguroso con la agenda. No permitas discusiones y mantente firme en las 3 preguntas. De esta forma, terminarás antes de 15 minutos. Como Scrum Master es tu trabajo hacer que esto pase. Si comienza una discusión, detenla y pide a los involucrados que la aplacen hasta después de la reunión, pero asegúrate de que se lleve a cabo. Sin embargo, permite que los miembros del equipo brinden ideas rápidas sobre la solución a problemas comunes.

Las decisiones importantes del proyecto no se deberían tomar durante la Reunión Diaria. Esta es una reunión de estatus, un punto de comunicación, no es para resolver problemas. Esta es una característica importante de la Reunión de Pie.

Si promueves discusiones detalladas, a medida que la reunión avanza y llega el turno de los últimos participantes, quizás el tiempo se habrá acabado y algunos asistentes quedarán sin sincronizar con el resto del grupo, así que no permitas los conflictos o diálogos extensos para buscar soluciones o discutir procedimientos; en cambio, fomenta una o más reuniones en grupos pequeños con las personas necesarias para tomar decisiones específicas. De esta forma, los demás podrán regresar a sus tareas regulares del sprint.

La facilitación de un Scrum Master experimentado es clave hasta que todo el equipo sea un Equipo Scrum maduro y hábil. Asegúrate de que los miembros del equipo asistan a la reunión con una buena idea de lo que harán a continuación, pero también permita una discusión rápida entre los miembros del equipo para tomar decisiones sobre colaborar en una tarea o una serie de tareas.

Proporciona algunos recordatorios estratégicos rápidos que son necesarios como: “estamos cerca del final del sprint, enfoquémonos en asegurar que tengamos un producto potencialmente distribuible que entregar”. Esto es algo que se puede incorporar con el pasar de los sprints, a medida que el equipo se envuelve en la cultura ágil.

Algunas otras ideas:

Usa una especie de testigo, al mejor estilo de las carreras atléticas de relevos, para evitar que los participantes hablen unos sobre otros y asegúrate de que el orden de intervención sea estricto, por ejemplo, en el sentido de las manecillas del reloj.

No realices estas reuniones al final del día, la gente ya está cansada y quiere irse a casa. En ese momento, el interés de las personas ya es otro. Una buena alternativa a hacerla en la mañana, es llevarla a cabo justo después del almuerzo, las personas tienen energía, están felices y vienen de un corto descanso.

Además, como Scrum Master:

Sirve como fuente de inspiración del trabajo en equipo, después de todo, eso eres: un líder al servicio del equipo y de la organización.

Facilita la reunión y haz que se mantenga breve y al punto.

Establece que las tarjetas (o notas adhesivas) de tareas se muevan antes o después de la reunión, pero no durante la misma, llega a un acuerdo de trabajo con el equipo. Haz lo mismo con las horas faltantes del Sprint, con el burn-down chart o cualquier otro mecanismo que estés usando con el equipo para monitorear el avance del proyecto.

Impulsa el que los Cerdos respondan las 3 Preguntas al Equipo Completo, no a ti como Scrum Master o a alguna otra persona en particular.

No permitas que las Gallinas (ninguna Gallina) los interrumpa a menos que sea esencial, en la práctica casi nunca lo es.

Finalmente, observa atentamente y resuelve estos asuntos:

Algunas personas no escuchan cuando otros hablan

Algunas personas dan información vaga o insuficiente, o no dicen nada, lo cual es su prerrogativa. Sin embargo, estos casos deben tratarse con cautela, de manera personalizada.

Algunas personas censuran cuando alguien no tiene un buen avance o comete algún error

Algunas personas postergan discusiones o la comunicación entre ellas durante el día hasta la Reunión Diaria

¿Quieres saber más?

La descripción completa sobre el Scrum Diario la encuentras en “La Guía de Scrum", a cuya última versión en español puedes llegar a través de:


Sobre la reunión diaria, este artículo de Jason Yip es todo un tratado alrededor del tema y expone una serie de patrones que bien podemos implementar: “It's Not Just Standing Up: Patterns for Daily Standup Meetings”:

Sobre Scrum y cultura ágil puedes leer estos artículos en mi Gazafatonario:





Scrum Orgánico para Iniciantes


En particular, sobre el rol y responsabilidades del Scrum Master, facilitador del Scrum Diario:



Referencias

[1] The Mythical Man-Month by Frederick P. Brooks, Jr., Addison Wesley Pub. Co., 1975, 25th Anniversary edition, 2000.

lunes, enero 13, 2014

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:

Scrum Orgánico para Iniciantes

Lista de Chequeo Scrum

Scrum – Lo Fundamental

Vademescrum, Sección I: El Scrum Master 1

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

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

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

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