Buscar en Gazafatonario IT

martes, marzo 04, 2014

Algunas Notas Sobre Gestión del Producto en Scrum

"Si puedes soñarlo, puedes hacerlo". Walt Disney.
Image courtesy of Stuart Miles / FreeDigitalPhotos.net
Image courtesy of Stuart Miles / FreeDigitalPhotos.net
Quienes venimos de enfoques tradicionales de desarrollo de software caracterizados por proponer y hasta exigir una diversidad de artefactos, encontramos la Lista de Producto (Product Backlog) de Scrum como algo tan hermosamente simple que raya en lo poético. Quizás a esa simplicidad se deba su inmensa popularidad entre los practicantes ágiles.
La Lista de Producto es un inventario priorizado del trabajo pendiente necesario para traer el producto a la vida. El Dueño de Producto es el responsable de la Lista de Producto y de su contenido. Nadie tiene una visión del producto que va más allá del producto en sí, como el Dueño de Producto.

Sus elementos pueden incluir:
  • Una exploración de las necesidades del usuario
  • Opciones técnicas variadas
  • Una descripción tanto de requisitos funcionales como no funcionales
  • El trabajo necesario para lanzar el producto

También puede contener otros elementos como:
  • Configuración del entorno
  • Defectos del producto. 

La Lista de Producto reemplaza los artefactos tradicionales de requisitos, tales como las especificaciones de requisitos del software. Mientras que el Dueño de Producto se compromete a manejar la Lista de Producto, el Scrum Master, el equipo y los interesados contribuyen a esta tarea. Juntos, descubren la funcionalidad del producto. Además, la Lista de Producto es también una herramienta para proporcionar transparencia durante el proyecto.
Sobre la Priorización
La priorización de la Lista puede hacerse de muchas formas, pero es algo que siempre se hace con el Dueño de Producto a bordo, liderando la priorización. Por ejemplo, es posible crear temas que contienen una lista de historias. Cada uno de estos temas tiene un “costo de retardo” asociado. Esto permite conocer el impacto de no implementar un tema si antes implementamos otro.
En este apartado debemos tener en cuenta que si se nos dificulta la priorización de la Lista de Elementos del Producto, puede estar sucediendo que:
  1. Los elementos, por ejemplo las historias de usuario, son muy grandes para priorizar
  2. No hay ningún valor de negocio asociado al Elemento de la Lista de Producto.
En el primer caso podemos dividir las historias en historias más pequeñas y relacionadas. En el segundo caso, podemos desechar estas historias “sin valor” y encontrar otras que sí reflejen valor del negocio o Retorno de la Inversión. Recuerda, si el Dueño de Producto no es capaz de escribir estas historias, el Scrum Master está a su servicio para ayudarle. No pretendas en el primer intento que un usuario tenga las habilidades y experiencia necesarias para escribir historias de usuario que cumplan con los atributos INVEST. Además, por lo general, no es posible cambiar de Dueño de Producto, es alguien sin quien el proyecto no puede vivir.

Sobre los defectos del producto
Si te estás preguntando como encargarte de esas anomalías que surgen o pueden surgir luego de la salida a producción del software y no sabes si decidirte por usar historias y priorizarlas en la Lista de Producto junto con las nuevas características, y si no estás buscando dogmas, puedes simplemente pensar en trabajar con el Dueño de Producto para clasificar y priorizar esos defectos en producción, luego los puedes tratar como historias de usuario a incluirlos en una entrega específica.
Al igual que en enfoques clásicos de mantenimiento de productos, si el defecto causa un alto impacto en los usuarios, este debe escalarse y resolverse como un ajuste en producción sin pasar por la cadencia normal de Scrum. Lo que sí puedes hacer es manejar la reparación del software usando un proceso Kanban, el cual permite un enfoque más liviano de gestión. Eso sí, no olvides que un error en producción representa valor negativo para el negocio así que dedica un esfuerzo mayor a evitarlos o a reducirlos al mínimo más que a corregirlos.
Cuando hagas esto piensa que:
  • Si una parte del producto tiene desperfectos, todavía no está Terminada.
  • Cualquier trabajo que necesite hacerse, necesita priorizarse.
  • Cualquier actividad que realice el equipo, toma tiempo.
  • El tiempo consumido en una cosa, no puede consumirse en otras cosas.

Los Atributos DEEP de la Lista de Producto
Dice Mike Cohn que una Lista de Producto efectiva tiene estas cuatro propiedades: detallada apropiadamente, estimada, emergente y priorizada. De allí el acrónimo DEEP.
Detallada Apropiadamente
Los Elementos de la Lista de Producto en la parte superior se describen en mayor detalle que los que están en la parte inferior de la Lista. A medida que bajamos en la lista, los elementos están menos detallados. Esto tiene sentido: son elementos que se convertirán en software apenas varias iteraciones más adelante o quizás nunca, si el usuario nota que no los necesita o si se acaba el presupuesto del proyecto. De hecho, es posible que el Dueño de Producto cambie la prioridad de alguno de estos, en cuyo caso solo debe llenar los vacíos de ese elemento para que quede “preparado” para construirse.
Figura: La priorización de la Lista de Elementos del Producto determina el nivel de detalle
Figura: La priorización de la Lista de Elementos del Producto determina el nivel de detalle
Esta técnica asegura que la Lista de Producto se mantenga concisa y que los elementos a implementarse en el siguiente sprint son trabajables. Una consecuencia de este enfoque es que los requisitos se descubren, se descomponen y se refinan a lo largo de todo el proyecto. Es otra de las razones por las cuales el Dueño de Producto debe trabajar con el Equipo de Desarrollo cotidianamente durante todo el proyecto, o más o menos así reza uno de los Principios Ágiles.
Estimada
La estimación de los Elementos de la Lista de Producto usualmente se expresa en puntos de historia o en “días ideales”. Conocer el tamaño de los elementos ayuda a priorizar y a planificar las entregas a producción. Recordemos que otras estimaciones más detalladas a nivel de tareas se realizan durante la Reunión de Planificación del Sprint; y también, estas tareas y sus estimados se capturan en la Lista de Pendientes del Sprint.
Un día ideal es una abstracción del número de horas diarias en las que normalmente esperas que un miembro del equipo sea productivo, restando tiempo para asistir a reuniones, ir al baño, tomar un café o simplemente hacer una pausa laboral.
Emergente
La Lista de Producto tiene una cualidad orgánica. Evoluciona y su contenido cambia frecuentemente. Nuevos elementos se descubren y adicionan a la Lista basados en retroalimentación del usuario, principalmente. Los elementos existentes se modifican, re-priorizan, refinan o se remueven permanentemente.
Priorizada
Todos los elementos en la Lista de Producto se ordenan según su valor e trascendencia para la Organización. Los elementos más importantes y de más alta prioridad se implementan primero. Estos pueden encontrarse al principio de la lista, como indico en la Figura 1. Luego de que un elemento esté “Terminado”, se elimina de la Lista de Producto.
Finalmente
La Lista de Producto existe por un propósito más grande: construir un producto que impacte a los usuarios, que haga resonancia en ellos/ellas y que cambie en algo sus estilos de vida.
El producto debe construirse de manera orgánica, es decir, tan pronto como sea posible, debemos tener una versión que los usuarios puedan usar, el producto mínimo viable. A partir de este producto parcial, coherente y de valor, se construye el producto completo.
Al construirlo, piensa que estás componiendo una pieza musical grandiosa, la sinfonía definitiva, una que será recordada por siempre. Una obra así despliega patrones, trayectorias e incita a las personas a estar a su alrededor.
¿Quieres saber más?
Te recomiendo ampliamente este artículo de Jeff Sutherland:
Enabling Specifications: The Key to Building Agile Systems
El libro de Roman Pichler, Agile Management with Scrum, Creating Products That Customers Love. Addinson-Wesley, 2010.
Sobre Historias de Usuario, mi serie de artículos:
Historias de Usuario: un nuevo orden en los requisitos del software
Historias de Usuario Altamente Efectivas, Parte 1
Historias de Usuario Altamente Efectivas, 2
Historias de Usuario Altamente Efectivas, 3
Historias de Usuario Altamente Efectivas, 4

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?

lunes, octubre 28, 2013

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]
De Jedi Master a Scrum Master
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