Buscar en Gazafatonario IT

jueves, junio 27, 2013

Vademescrum, Sección I: El Scrum Master 1

El Vademescrum
No se trata de un lapsus calami ni de ninguna charada. Simplemente usé un procedimiento morfológico para crear una nueva palabra cuyo significado se hará evidente en breve. Usando el formato de la Academia de la Lengua, podemos decir que Vademescrum proviene de Vademécum (obra de referencia que contiene las nociones más importantes de una materia, ya sea ciencia o arte) y de Scrum (marco de trabajo liviano y adaptativo para desarrollo iterativo e incremental de software). El Vademescrum es, por lo tanto, una especie de marco referencial de Scrum y de sus componentes.
Vademescrum, Sección I: El Scrum Master 1
Entrando en materia, el Scrum Master es quien inspira los valores y las prácticas de Scrum en todo el equipo Scrum y, junto con otros Scrum Masters, en la organización. Es quien debe llevar al equipo a jugar Scrum Extremo y que lo haga a su máxima capacidad. El SM es como el médico que prescribe una receta o régimen a su paciente (el equipo Scrum) y se asegura de su cumplimiento y, aunque el SM no tiene autoridad sobre el equipo, sí tiene autoridad sobre el proceso Scrum que se sigue, por ejemplo, puede tomar la decisión de cambiar la duración de los sprints.
El SM también busca en las entrañas del proyecto y del equipo para encontrar los motivos por los que algo salió mal, por ejemplo, si no se entregó software potencialmente distribuible, probado y funcionando, al final de un sprint, o si el equipo no logró la velocidad esperada, o simplemente el por qué no se alcanzó la definición de Hecho (Done), o que los miembros del equipo no estén “anclados” en roles específicos. El Scrum Master también sirve como un escudo insalvable del equipo de interferencias externas, por ejemplo, cuando un interesado quiere modificar el alcance o la duración de un sprint, o ambos.

La guía de Scrum dice además que:
“El Scrum Master es el responsable de asegurar que Scrum es entendido y llevado a cabo. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum. El Scrum Master es un líder servil, al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones, para maximizar el valor creado por el Equipo Scrum.”
Ahora bien, cuando un Scrum Master se une a un equipo, debe recordar que está allí para servir a:
  1. El Dueño de Producto
  2. El Equipo de Desarrollo
  3. La Organización

Para ello el SM debe tener en cuenta no solo el nivel de madurez en Scrum del equipo y de la organización, sino la capacidad de los miembros del equipo para obrar bajo el manto del espíritu Scrum. Esto quiere decir que el SM debe interactuar con cada persona en el equipo tanto como sea posible y promover la interacción entre ellos ya que, como recordarán, “valoramos individuos e interacciones sobre procesos y herramientas”.
En principio, no es buena idea que el SM haga cambios profundos en la Forma de Trabajo del equipo porque esto podría disminuir considerablemente su velocidad; en cambio, el SM debe considerar acompañar y guiar al equipo hacia el éxito constante. También debe lograr que haya confianza entre todos los miembros del equipo y que ellos tengan confianza en su SM, tal y como un paciente confía en su médico de cabecera.
Otras indicaciones que debe tener en cuenta el Scrum Master son:
  • Soportar activamente el proceso de adopción, adaptación y mejoramiento de prácticas ágiles en la organización.
  • Entender lo bueno y las mejoras que el equipo está buscando.
  • Tratar de establecer una comunicación abierta con el Dueño del Producto.
  • Interactuar con otros SM e identificar los desafíos que enfrentan.
  • Constantemente inspeccionar, ser transparente y adaptar, es decir, promover los pilares de Scrum.
  • Entrenar al equipo, entrenarlo y luego entrenarlo más. Cuando esté cansado de entrenar al equipo, entrenarlo en algo más. Ser el mentor que todos esperan que sea.
  • Promover la comunicación abierta.
  • Resaltar cuando el equipo alcance hitos de adaptación y mejoramiento.
  • Preguntarle al Dueño del Producto por 2 o 3 cosas que él/ella piense que no están bien, dañadas o que no están funcionando o simplemente con las que no está feliz.
  • Hacer lo anterior, pero con el Equipo de Desarrollo.
  • Mostrar a todos como planea corregir estos aspectos con la mayor brevedad.
  • Entender la cultura y el contexto del equipo.
  • Identificar oportunidades de mejora y facilitar y fomentar el mejoramiento.
  • Promover la retrospectiva al final del Sprint e, incluso, durante el Sprint.
  • Finalmente, pero no menos importante, hacer que el equipo tenga acceso rápido a una buena máquina de bebidas de café, esto también resuelve muchos asuntos.

Contraindicaciones
Esta es la primera entrega de este Vademescrum, volveré con más. Mientras tanto es importante tener claro que un SM hace mucho más de lo que enumeré aquí. Una persona debe preguntarse, ¿cómo me llegó la idea de convertirme en Scrum Master? Y también, ¿dónde consigo la experiencia necesaria y suficiente para hacerlo bien? ¿Dónde y cómo puedo aprender más? Asimismo debe cuestionarse quién le enseña.
Es un hecho, en estos días parece que Scrum Masters con toda esa experiencia son concebidos en cursos de 2 días y un examen de selección múltiple. Al final, caen en el olvido sin que nadie en el equipo se haga cargo. Es toda una experiencia misteriosa que se puede dominar sin antes pasar por las etapas clásicas de aprendiz –> practicante –> practicante -> experto –> entrenador -> mentor y sin que se extienda el manto ágil de Scrum sobre el equipo y la organización.

Lecturas Adicionales

Scrum Fundamental lo encuentran en este mismo Gazafatonario, en:

La lista de verificación de Scrum la encuentran en:

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

Scrum Orgánico para Iniciantes

martes, junio 11, 2013

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

La mitología es un conjunto de mitos relativamente cohesionados: relatos que forman parte de una determinada cultura. Los mitos son relatos basados en la tradición y en la leyenda, creados para explicar el universo, el origen del mundo, los fenómenos naturales y cualquier cosa para la que no haya una explicación simple [1]. En el bestiario mitológico de la humanidad encontramos seres fantásticos que nos hacen soñar o morir de miedo: el Dragón, el Fénix, el Grifo, el Kraken, el Cancerbero, la Hidra, el Minotauro, la Escila, el Pegaso y la Sirena, para citar algunos de los más arraigados en nuestros temores y pesadillas.

Se trata de esa necesidad inherente al ser humano de aferrarse a lo desconocido y a lo sobrehumano para entender mejor la realidad que lo rodea, o simplemente para escaparse de esta. En el caso de los métodos de software, por ejemplo, estas aprehensiones tienen su origen en la falta de conocimiento teórico-práctico sobre algo específico, en el miedo o rechazo al cambio o en la fobia a equivocarse de quienes practicamos el desarrollo de software. Lo que haré a continuación es mencionar brevemente algunos de estos arquetipos quiméricos que pululan en el universo de los métodos ágiles en general y de Scrum en particular.

Ágil no necesita documentación

¡Esta es la madre de todas las entelequias! Su origen está en ese valor expuesto en el Manifiesto Ágil que reza: “valoramos software funcionando sobre documentación extensiva” [2]. En ninguna parte del manifiesto dice que no se hace documentación, esta debe elaborarse justo cuando se necesita y solamente la suficiente y necesaria y en los formatos más adecuados, que llegue al público interesado, que entregue valor a la organización. Y siendo consecuentes con el primer valor del manifiesto, esta documentación no se requiere producir con herramientas sofisticadas.

Ágil significa “no hay un plan”

De hecho, ágil no soporta el desarrollo sin planeación. Los métodos ágiles usan planeación y estimación continua para maximizar el ROI. En realidad, ágil es sobre manejo de alcance. La planeación continua permite redireccionar el compás del proyecto de acuerdo con el entorno cambiante del mismo; también, asegura un foco consistente en las prioridades del negocio teniendo en cuenta las restricciones impuestas al proyecto. Además, la planeación constante posibilita tomar mejores decisiones y comunicarlas más efectivamente. Plan sí hay, solo que es dinámico y flexible.

Podemos rastrear el origen de este mito a otro  valor del Manifiesto Ágil que invoca: “valorar la respuesta ante el cambio sobre seguir un plan” [2]. Otra vez, se trata de un malentendido nocivo para la industria del software. Este artículo es un intento más por remediar esa situación.

Ágil es la solución tipo “bala de plata” a todos los problemas de la ingeniería de software (Existe una solución tipo bala de plata)

De todos los monstruos que llenan las pesadillas de nuestro folclor, ninguno más terrorífico que los llamados licántropos. Para ellos buscamos balas de plata que mágicamente los hacen desaparecer para siempre.

La industria del software tiene muchos problemas, aquellos que precisamente se quisieron arbitrar con el manifiesto ágil. Sin embargo, ningún método actual, por sí solo o combinado, es capaz de enfrentar la enorme cantidad de variables que se mezclan en el ambiente de los proyectos de software, dada la magnitud y complejidad de la mayoría de estos. Los métodos ágiles no son la excepción. Si bien su modelo iterativo y adaptativo de gestión posibilita en gran medida la resolución de muchos impedimentos, siempre habrá que poner de manifiesto nuestro sentido común para afrontar escenarios hostiles.

Es decir, además de recurrir a balas de plata, estacas de madera, ajos o apelaciones a la mediación divina (léase procesos y herramientas, documentación detallada, contratos y acuerdos de servicio, planes, etc.), necesitamos encontrar mecanismos que nos permitan interactuar mejor entre nosotros, construir productos de software por incrementos, colaborar íntimamente con los usuarios y reaccionar hábilmente ante los cambios que se presentan todo el tiempo durante un proyecto. Esto es lo que dice realmente el manifiesto ágil.

Ágil no necesita diseño previo

Este quizás es un derivado del primer mito. En la realidad, la pieza funcional de software que se entrega en cada iteración requiere de diseño, el suficiente y necesario para construir un producto con calidad. Se trata de un diseño funcional, tan robusto pero tan flexible como se requiera para que todos los cortes del software se puedan integrar en uno solo. Si pensamos en “diseñar a medida que avanzamos”, seguramente fallaremos en el intento y nuestro producto nunca verá la luz del día. El ciclo convencional del software no desaparece porque lo hagamos ágil: análisis, diseño, implementación, pruebas y despliegue. ¡Algunas cosas no cambian!

Ágil siempre usa “Historias de Usuario"
Esta leyenda también desciende de la primera. Es que la “no documentación” es el más arraigado de todos los mitos alrededor de los métodos ágiles. Tanto las organizaciones como los individuos necesitamos de conocimiento explícito, o sea, de aquel que tenemos y del que somos plenamente conscientes cuando lo ejecutamos, que está estructurado y muchas veces esquematizado para facilitar su difusión. Esas son las claves: estructurado y esquematizado, es decir, documentado. Otra cosa es el formato que usamos para documentar, quizás ese es el que debe cambiar, pero ese es un problema diferente.

Y en cuanto a las historias de usuario, rutinarias en los métodos ágiles, hay que decir que ágil no siempre las usa. Hay que usarlas sí, y solo sí, son apropiadas. Existen otros instrumentos, unos más efectivos que otros, como los prototipos, los tableros de historias, los simuladores. ¿Alguien ha intentado “porciones de caso de uso”? Estas últimas son tan livianas como las historias de usuario y tienen el poder de los casos de uso. Y otro error muy común es creer que las historias de usuario siempre son elaboradas por el Dueño de Producto.

Scrum siempre Funciona

Ya tenemos claro que ágil no es una bala de plata y Scrum es ágil, conclusión…

Primero debemos saber cuándo implementar Scrum en la organización. Y luego debemos saber cuándo usar Scrum en un proyecto. ¿Está preparado nuestro cliente/usuario? ¿Habrá un dueño de producto? Más importante aún, ¿está dispuesto nuestro equipo para entregar software probado y funcionando que sea potencialmente distribuible cada periodo corto de tiempo – 2 semanas –? ¿Están claros los valores y principios del manifiesto ágil? Este artículo es un síntoma de que no lo están. ¿El equipo es autogestionado y experto? ¿Nuestro usuario está dispuesto a involucrarse al 100%?

Entre otras, estas son algunas de las cuestiones que debemos responder y establecer antes de intentar Scrum en nuestros proyectos. Se requiere de cierta capacidad y de cierta madurez para enfrentar el reto.

Scrum Master igual a Gerente de Proyecto

Scrum Master es un rol de gestión, sí, pero no es un gerente como lo conocemos en los proyectos tradicionales, mucho menos un gerente tipo PMI o algo parecido. “El Scrum Master es un líder servil, al servicio del Equipo Scrum.” [3] Un SM es un facilitador, es alguien que se sitúa en algún lugar entre el equipo de desarrollo y el cliente. También puede verse como un “guardián de Scrum”, un custodio, alguien que vigila que el proceso se esté llevando a cabo como lo indica la guía de Scrum.

El SM puede venir de una PMO, es cierto, pero también puede llegar desde el equipo de Analistas o de cualquier otro miembro de la organización que tenga las habilidades y la empatía requerida. El SM tampoco es un desarrollador líder o arquitecto, también hay que decirlo.

Podemos hacer Scrum sin un Dueño de Producto o con muchos dueños de producto

Cuando no tenemos un dueño de producto que está fuera del equipo o, mejor, fuera de la jerarquía del equipo, perdemos algo precioso e inherente a ágil: la noción del cliente. Perdemos a la persona que nos puede ayudar a entender lo que realmente quiere el cliente. “El dueño de producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo.” [4] El dueño de producto es quien establece los criterios reales de aceptación del producto, esto no lo puede hacer otro rol en el equipo o en la organización. Es un hecho, sin este personaje, el equipo no sabrá que hacer.

Ahora bien, el dueño del producto es uno solo, no un equipo o comité de dueños de productos. El dueño de producto es una sola voz y representa los intereses del cliente, es decir, de todos los interesados en el producto. Más de un dueño de producto puede “adicionar ruido” al proyecto, es decir, sumar variables que pueden llevar el proyecto a la devastación. Finalmente, este mito tiene sus orígenes en que ninguna persona por sí sola tiene el conocimiento completo de lo que quiere la organización, pero ello no es necesario, solo es suficiente con que tenga contacto con las personas apropiadas.

Scrum no funciona con CMMI u otros modelos de procesos y viceversa

He visto anuncios en la Web sobre “la gran pelea” entre Scrum y CMMI, seminarios virtuales, tertulias presenciales, diplomados para expertos, como si se tratara del campeonato de combate definitivo, la última de las grandes contiendas entre dos “gigantes” del deporte. Esta leyenda urbana tiene sus raíces en la creencia de que CMMI es predictivo mientras que Scrum es adaptativo. Pero lo que hay que saber realmente es que CMMI es un modelo de mejoramiento de procesos, nos indica qué buenas prácticas dan ventaja a nuestra organización, en tanto que Scrum aporta precisamente el cómo implementar esas prácticas.

En la realidad es posible integrar estos dos mundos y ponerlos a funcionar en beneficio de nuestros clientes y de nosotros mismos: a la vez que CMMI permite describir todos los procesos de la organización y su interacción, Scrum regula el procedimiento a seguir en el mero proceso de desarrollo. Quizás el detalle más oscuro en este análisis es aquel de las estadísticas inherentes a toda organización de alta madurez, pero la cultura ágil de alguna manera impuesta por Scrum sirve de fundamento sistemático a los requisitos de un proceso de control estadístico impuesto por CMMI. Las cosas así, es totalmente viable convivir con Scrum y CMMI en un mismo plano.

Scrum produce equipos de súper héroes, tipo los Vengadores o la Liga de la Justicia

Necesitamos expertos, es cierto. Pero estos no se hacen solos. Scrum no es una caneca de desechos biológicos o químicos y donde podamos caer y levantarnos con poderes extrasensoriales que permitan leer la mente de los usuarios o con una memoria prodigiosa que nos faculte a escribir solo las líneas de código correctas o realizar diseños perfectos en cuestión de segundos.

Si seguimos Scrum, si asistimos a las ceremonias propuestas por el marco de trabajo, seremos capaces de entender los obstáculos que evitan mejorar nuestro desempeño. Y sin la habilidad o deseo de remover esos impedimentos, apenas si podremos tener mayor visibilidad de los problemas. Y esto simplemente redundará en el aumento de nuestra frustración, lo que a su vez dejará notar nuestro comportamiento negativo y menos productivo. Ya lo he repetido, Scrum no es la solución definitiva, pero ayuda a ser mejores cada vez. La transparencia y la predictibilidad son los beneficios inmediatos.

¡El plan de mejoramiento personal y profesional lo ejecutamos de nuestra cuenta!

Más Mitos y Leyendas

Otros mitos, no menos perjudiciales, son:

  • Estamos haciendo Scrum, así que no necesitamos otras prácticas ágiles como TDD, Refactoring, Pair Programming, etcétera
  • Ágil es menos disciplinado y más fácil
  • Podemos lograr agilidad sin cambio organizacional e individual
  • Ágil es igual a Scrum
  • Con Scrum podemos hacer cambio en cualquier momento
La lista realmente podría ser interminable.

Conclusiones

Scrum es una idea sencillamente empaquetada y de esta manera podemos transferirla rápidamente de una persona a otra y de un equipo a otro. Con todo y ello, es innegable la gran cantidad de concepciones erróneas que tenemos al respecto. Para sacar estos monstruos y mitos de nuestras mentes es necesario tener acompañamiento, no basta con aprender por sí solo, necesitamos entrenamiento de personas que hayan usado exitosamente el método. Las organizaciones, por su parte, deben concebir un buen plan de implantación del método: configurar el proceso, hacer proyectos piloto, medir, analizar los resultados, ajustar, entrenar a los equipos e institucionalizar.

¡Así lo estamos haciendo!

Referencias Web/Bibliográficas

[1] Colaboradores de Wikipedia. Mitología [en línea]. Wikipedia, La enciclopedia libre, 2013 [fecha de consulta: 11 de junio del 2013]. Disponible en http://es.wikipedia.org/w/index.php?title=Mitolog%C3%ADa&oldid=67124850
[2] El Manifiesto Ágil de Software: http://www.agilemanifesto.org/iso/es/
[3] La Guía de Scrum: http://www.scrum.org/Scrum-Guides
[4] La Guía de Scrum: http://www.scrum.org/Scrum-Guides