SCRUM CARD GAME – Un juego para experimentar Scrum

SCRUM CARD GAME es un juego simple que permite a los jugadores experimentar el trabajo en sprints de Scrum discutir muchas cuestiones y temas que suceden en la vida real mientras trabajan en un equipo Scrum. La discusión sobre la mesa  de juego será muy cercana a la experiencia real del trabajo en un equipo Scrum. Este juego usualmente se juega durante un entrenamiento o taller. Los participantes ya deben conocer y entender el marco de trabajo Scrum o pueden aprenderlo mientras participan del juego. También puede servir como método para hacer que un equipo experimentado reflexione sobre sus rituales y reglas establecidas de Scrum.

El eje del juego es que cada equipo (de 4 a 6 personas) es un centro de desarrollo competitivo contratado para llevar una nueva aplicación al mercado. El equipo más productivo gana.

Los materiales para el juego incluyen:

• Un juego de cartas de Historias, Eventos, Problemas y Soluciones. Estas son las cartas de Oportunidad. Estas se encuentran en el manual oficial del juego del que comento más abajo.
• Dos dados de seis lados (para cada equipo)
• Rotafolio
• Marcadores

Podrán imaginar ustedes que los sucesos del juego ocurren durante los sprints, se pueden jugar hasta tres sprints aunque es posible jugar 4 o más. Los sprints son de tres días de duración y durante cada día cada uno de los miembros del equipo trabaja en el sprint. En cada Sprint los equipos realizar Planificación, Revisión y Retrospectiva y durante la ejecución del sprint se experimentan conceptos como impedimentos o bloqueos, definición de Terminado, trabajo, Tablero de tareas, Backlog, entre muchos otros.

Al final del juego es posible hacer un análisis de temas tan importantes para los equipos ágiles como:

• Esfuerzo planeado versus Real
• Variaciones en la velocidad
• Horas Estimadas versus Tamaño (Estimado Original)
• Riesgos mayores que sucedieron (Técnicos, Personas, Eventos No Planeados)
• ¿Cuáles son los tipos de riesgos más difíciles de tomar?
• ¿Podemos proyectar eventos malos?
• Entre otros

El autor del juego es Timofey Yevgrashyn, un agilista de Europa del Este, Gerente Ágil con experiencia en consultoría, coaching y entrenamiento. Timofey  tiene experiencia en el lanzamiento y liderazgo de transformaciones Ágiles/Lean que conducen a alinear las entregas con los objetivos del negocio. Hasta este año (2016) ha ayudado a más de 50 equipos de más de 10 países y ha completado cerca de 3000 horas de entrenamiento Ágil a más de 4000 personas. ¡Eso es estar en el campo de batalla!

Timofey se basó en su trabajo pragmático y en sus entrenamientos para diseñar este fabuloso juego, además de otros que pueden encontrar en su blog que escribe desde 2009 en lengua Rusa “The Improved Methods” (http://tim.com.ua). Conocí el juego y lo he jugado con algunos equipos mixtos de personas con mediana, poca o ninguna experiencia en Scrum y los resultados han sido grandiosos. Por eso hablé con Tomofey para que trabajáramos juntos en la versión del juego en español y el resultado ya está aquí.

Mientras él termina de implementar un sitio exclusivo para el juego, pueden encontrar la versión en español su sitio actual:

http://tim.com.ua/scrum-card-game/

En la sección Переводы. No se preocupen, si no saben ruso, se trata de la sección Translations (Traducciones).

O directamente en: https://scrumcardgame.com/shop/scrumcardgame-es/

Descarguen el juego con las tarjetas coloridas imprimibles y no dejen de contarme en el foro, más abajo, sus experiencias con el mismo.

Revisión a la Guía de Scrum

Actualización 2016/07/23. Ya está disponible la versión en español de la guía actualizada de Scrum. La encuentran en la página oficial de la Guía (http://www.scrumguides.org/download.html), en la sección correspondiente a "Spanish (July 2016)" o buscan en la página la secuencia de caracteres "Lucho Salazar".

Recuerden, si tienen alguna observación sobre la traducción, comenten en el foro (más abajo) o escríbanme a lucho.salazar@gmail.com.

¿Qué te parece la inclusión de los valores Scrum a la guía? ¿Por qué crees que Refinamiento sigue sin ser una ceremonia formal en Scrum? Comenta sobre estos y otros aspectos en el foro.

******************************************************************************

Estos son los cambios presentados a la Guía Scrum por Ken Schwaber y Jeff Sutherland este 6 de julio de 2016.

******************************************************************************
Los Valores de Scrum

Cuando el Equipo Scrum incorpora y vivencia los valores de compromiso, coraje, foco, apertura y respeto, los pilares Scrum de transparencia, inspección y adaptación se materializan y fomentan la confianza en todo el mundo. Los miembros del Equipo Scrum aprenden y exploran estos valores a medida que trabajan en los eventos, roles y artefactos de Scrum.

El uso exitoso de Scrum depende de que las personas lleguen a ser más virtuosas en la convivencia con estos cinco valores. Las personas se comprometen de manera individual a alcanzar las metas del Equipo Scrum. Los miembros del Equipo Scrum tienen coraje para hacer bien las cosas y para trabajar en los problemas difíciles. Todos se enfocan en el trabajo del Sprint y en las metas del Equipo Scrum. El Equipo Scrum y sus interesados acuerdan estar abiertos a todo el trabajo y a los desafíos que se les presenten al realizar su trabajo. Los miembros del Equipo Scrum se respetan entre sí para ser personas capaces e independientes.

******************************************************************************

La guía ya está disponible en ingles en http://www.scrumguides.org. Muy pronto estará en español (¡hace varios días envié la actualización!) y en otros idiomas.

¡El tamaño sí importa!

Vamos al grano. Si la mayoría de tus historias de usuario llegan a “Terminado” apenas unas pocas horas antes de la Revisión del Sprint, todavía pueden ser más pequeñas. Tu equipo debería tener historias tan pequeñas que las puedas finalizar durante las primeras horas o días del Sprint, dependiendo de la duración de este. Así te aseguras desde las primeras de cambio que el equipo está siendo productivo, está enfocado y que van a entregar valor al final de la iteración. ¡Después de todo, finalizar una tarea aumenta la moral del equipo!

Aunque el objetivo de un Sprint no debe medirse en número de historias de usuario a terminar (implementar), sino al cumplimiento de un objetivo específico, siempre es mejor “prometer” o planear terminar varias historias pequeñas o muy pequeñas que muy pocas historias medianas o grandes.

Es evidente: si tienes 10 historias en tu lista de pendientes del sprint (alias el backlog del sprint), y no terminas 2, es mucho mejor que si solo tienes 4 y terminas 2. En ambos casos fallaste en el mismo número de historias, pero en el primer escenario tuviste un acierto del 80% mientras que en el segundo apenas llegaste a la mitad de la promesa del sprint. El resultado es menos alentador si las historias terminadas son dos de 3 puntos y dejaste sin terminar o aun a punto de terminar dos historias de 13. Solo cumpliste con 6 de los treinta puntos que prometiste.

Hablando de puntos, una buena medida, algo que me ha funcionado casi siempre, es implementar historias cuyo puntaje no sobrepase entre una décima parte y una sexta parte de la velocidad del equipo. Es decir, si la velocidad del equipo de desarrollo es 30 puntos por Sprint, las historias a implementar no deberían ser más grandes de 3 a 5 puntos. Historias de ½, 1 y 2 puntos siempre son bienvenidas en este escenario.

Ahora bien, el tamaño de las historias es un concepto relativo. Un equipo de 7 o 9 personas no ve igual una historia de usuario en un sprint de 3 o 4 semanas que un equipo de 3 o 5 personas en un sprint de 1 o 2 semanas. Pero algo en lo que todos estamos de acuerdo es que, una vez terminadas, las historias deben proporcionar valor al negocio. Las cosas así, otro indicador de “pequeño” es Pareto.

El objetivo siempre es encontrar ese 20% de la historia (de funcionalidades que se van implementar vía esa historia) que genere o entregue el 80% del valor total de la misma. A partir de allí, la división se hace de manera orgánica, adicionando historias al backlog de producto que complementen la historia de “más valor”.

También ayuda el nivel de entendimiento de toda la historia y qué tan rápido llegamos a entenderla por completo. Un índice de que quizás la historia no es pequeña es que no la hemos terminado de entender, quizás no están claros algunos de los criterios de aceptación o hay nubes en la conversación (la c de conversación de la historia) relacionadas con los requisitos funcionales o no funcionales a implementar.

El Principio de Sweepnoise, de mi amigo Leonardo Agudelo, ilustra muy bien este punto:

Una historia de usuario debe ser tan pequeña que obligue a una conversación cara a cara donde todos entiendan mejor el problema

— Leonardo Agudelo (@sweepnoise) March 10, 2015

Finalmente, no solo la S de INVEST indica que la historia es pequeña (Sucinta). Un indicativo de que quizás no lo es tanto, es que  algunas partes de la misma (o toda la historia) no sean negociables o que no haya consenso en su estimación o que tengamos dudas acerca de si es posible conducirla a través de un proceso que nos asegure la calidad del producto terminado o de que incluso tenga dependencias con otra(s) historia(s).

Comparte conmigo y con los demás lectores del blog lo que piensas sobre este asunto del tamaño, ¿importa? ¿No importa? ¿Qué haces habitualmente para dividir tus historias de usuario? Cuéntanos tus heurísticas.

---------------------------------------------------------------------------------------------------------------

Para saber más sobre historias de usuario, puedes leer mi artículo introductorio:

Historias de Usuario: un nuevo orden en los requisitos del software:
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

Para saber más de los criterios INVEST de las historias de usuario puedes leer mi serie de artículos sobre el asunto.

La serie de artículos "Escribiendo Historias de Usuario Altamente Efectivas":

Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción

http://www.gazafatonarioit.com/2013/07/escribiendo-historias-de-usuario.html

Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario.html

Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_12.html

Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_19.html

Y este otro:

De historias de usuario, culturas y del arte de narrar historias

http://www.gazafatonarioit.com/2015/03/de-historias-de-usuario-culturas-y-del.html

También puedes visitar el blog Lecciones Aprendidas de mi amigo Jorge Abad:

Video de explicación: Cómo se construyen historias de usuario

http://www.lecciones-aprendidas.info/2016/05/video-de-explicacion-como-se-construyen.html

Ejemplo: Una historia de usuario - Listado de Morosos

http://www.lecciones-aprendidas.info/2015/03/una-historia-de-usuario-listado-de.html

Ejemplo de historia de usuario : Ingreso al sistema

http://www.lecciones-aprendidas.info/2015/03/ejemplo-de-historias-de-usuario-ingreso.html

Purga ágil de producto

Nuestro backlog del producto puede no tener una “buena salud”. Es decir, puede contener elementos que lo oscurezcan o que disminuyan su transparencia. Por lo general estos elementos tienden a ir hasta el fondo del backlog y muchas veces no son detectados hasta que es muy tarde en el proyecto, trayendo como consecuencia la extensión innecesaria del esfuerzo de desarrollo y la desmotivación del equipo debido a la gran capacidad energética que sus miembros invierten en estos elementos de poco o ningún valor para el producto y para el negocio.

Una de las técnicas que podemos aplicar al backlog y, por consiguiente, al producto, es esta de la purga del producto. Los detalles de cómo hacerlo lo encuentran en mi artículo en Pulse de LinkedIn:

https://www.linkedin.com/pulse/purga-agil-de-producto-luis-antonio-salazar-caraballo

Los Pilares de Scrum

Los Pilares de Scrum. Clic en la imagen para ampliar.

Sin ninguna duda, para que Scrum sea eficiente y efectivo, cada uno de estos pilares debe estar en pie, deben promoverse desde las personas y los equipos hasta toda la organización y deben apoyarse sin restricciones. Sin uno o más de estos pilares, cualquier implementación de Scrum está condenada a un cataclismo anunciado.

Déjame saber en el foro como te ha ido con la puesta en macha de estos pilares mientras implementas Scrum en tu organización.

Puedes descargar el PDF de la imagen en alta resolución haciendo clic aquí.

O me la solicitas a mi correo: lucho.salazar@gmail.com.

Del triángulo de hierro al triángulo ágil extendido

Las empresas en período de transformación organizacional se enfrentan a la dicotomía de seguir paradas sobre el triángulo de hierro en lo que se refiere a planificación y gestión de proyectos de software o moverse a una zona que en principio se les parece más al Triángulo de las Bermudas que al área de confort por donde han transitado durante las últimas décadas.

De lo más valioso que hemos aprendido en el desarrollo de software es que muchas de las prácticas y técnicas usadas desde aquella histórica reunión del Comité Científico de la OTAN en 1968 en la ciudad de Garmisch, Alemania y que diera inicio a la Ingeniería de Software como profesión, fueron tomadas a manera de préstamo de otras áreas de la ingeniería y de otras ciencias aplicadas.

Algunas de esas prácticas influyeron directamente en la forma de realizar estimaciones y de planificar proyectos de software. Específicamente, hemos aprendido que no podemos estimar ni planificar proyectos de software como lo hacen en proyectos de la industria de la construcción… ¡a no ser que vayamos  a usar piezas de Lego® para construir ciudades!

Afortunadamente ya sabemos con certeza que la ingeniería de software tiene su propia personalidad. Se trata de un sello que la hace única y que hace que sus practicantes se distingan del resto de profesionales de la ingeniería y de otros cuerpos de conocimiento. Por ejemplo, en su libro Agile Project Management, Jim Highsmith[1] sugirió que si aplicamos el enfoque Ágil al Triángulo de hierro encontraríamos los siguientes vértices:

• Valor, para el usuario en términos de un producto que se pueda distribuir y cuyo uso genere beneficios para la organización.
• Calidad, para entregar continuamente valor al usuario en términos de un producto confiable y adaptativo.
• Restricciones, los ya tradicionales alcance, tiempo y costo, en donde, si movemos uno, usualmente el primero, se mueven los otros dos.

Como dice el mismo Highsmith [2], las restricciones siguen siendo parámetros importantes de un proyecto pero no constituyen el objetivo del mismo. En cambio, el Valor y la Calidad establecen la meta del proyecto y las restricciones mencionadas se ajustan a medida que el proyecto incrementa el valor para el usuario. En particular, El tiempo podría seguir siendo una restricción fija pero entonces el alcance debería ajustarse para entregar el valor más alto posible dadas las restricciones impuestas.

Como nos gusta lo visual, esta otra versión del triángulo ágil de Highsmith nos llega más:

Más allá de este enfoque de planificación y de gestión de proyectos (ágiles), quienes ya hemos trasegado algunos años por los vericuetos, subido a los riscos y caminado por los valles complejos del desarrollo ágil de software, sabemos que todo momento es una oportunidad de mejorar: de mejorar como personas y como profesionales, de mejorar los procesos y las técnicas, de mejorar la calidad de los productos y de incrementar el valor que estos entregan a nuestros usuarios. ¡Es la mejora continua!

Ahora bien, la mejora continua junto al valor y a la calidad forma otro vértice del triángulo, el del resultado. A los agilistas no nos interesa simplemente crear un producto, por más disruptivo o benéfico que este sea. Nos interesa pensar en lo que viene, en lo que llevará al cliente al próximo nivel de optimización, satisfacción y felicidad.

Pero lo más importante en todo proyecto, en todo proceso de innovación o mejoramiento, en todo plan que tenga como propósito el diseño y la construcción de productos (de software), son las personas: la comunicación cara a cara entre ellas, la motivación de todos los individuos que intervienen en el proyecto, la atención continua a la excelencia técnica, la autogestión del equipo y la confianza que la organización deposite en ellas se constituyen en las bases del éxito de cualquier iniciativa que requiera generar nuevos productos o servicios.

Las cosas así, podríamos entonces encontrarnos con esta nueva versión del triángulo ágil:

Referencias:

[1] Highsmith es uno de los 17 firmantes del Manifiesto Ágil

[2] Beyond Scope, Schedule, and Cost: Measuring Agile Performance

Scrumpida o el afán poseso de querer ser ágil

Esta es apenas la definición, al mejor estilo de la Academia de la Lengua.

scrumpida

Basado en estampida.

1. f. scrumpido.

2. f. Prisa repentina y frenética de empresas y organizaciones (pánico) para hacer Scrum porque quieren ser ágiles también.

de escrumpida

1. loc. adv. Empezar a usar Scrum repentinamente y con precipitación impetuosa. Agilizar, escalar de escrumpida.

Gazafatonario - Todo  sobre lenguaje, lengua y habla.

Basado en Scrumpede de Gunther Verheyen, inspirado a su vez por © Tomasz Włodarek.

Agilidad: algunas características intrínsecas

Infografía: Agilidad 101. Clic en la imagen para ampliar.

AGILIDAD

La habilidad de las personas, equipos y organizaciones de crear Valor, a la vez que promover y responder al cambio para tener éxito en un entorno incierto.

Algunas características intrínsecas a la Agilidad son:

RETORNO DE LA INVERSIÓN

Ágil proporciona ROI en forma de beneficios cualitativos como el mejoramiento de la moral del equipo y principalmente ROI en la forma de beneficios cuantitativos, expresado en términos económicos, mediante la entrega continua y frecuente de soluciones con Valor.

MARCOS DE TRABAJO

Estamos descubriendo formas mejores de desarrollar software. Los marcos de trabajo ágiles son iterativos e incrementales y de Valor. Scrum y otros métodos y prácticas ágiles se basan en la teoría empírica, es decir, aprendemos de la experiencia. El propósito final de las prácticas ágiles no es tanto el hacer como el encontrar formas mejores del hacer.

TIEMPO

Entregamos productos frecuentemente, incluso todos los días. Las iteraciones son períodos muy cortos de tiempo que finalizan con la entrega de productos que generan Valor del negocio.

DOCUMENTACIÓN

Valoramos más las soluciones en uso que la documentación exhaustiva. La meta de ágil es encontrar el balance adecuado entre la documentación y la comunicación cara a cara. La documentación es una parte importante de todo producto, pero la documentación exhaustiva como tal no asegura el éxito de un proyecto. De hecho, aumenta la probabilidad de fracaso.

INNOVACIÓN

En la forma de mejoramiento continuo.  Las prácticas ágiles nos permiten encontrar formas innovadoras para crear productos y servicios mejores, más baratos, más livianos, más rápidamente y de una forma más conveniente y personalizada para nuestros clientes.

PERSONAS

Valoramos más las personas y la comunicación cara a cara entre las personas. Lo más importante en el ecosistema ágil somos las personas. Los equipos son autoorganizados y nuestra mayor prioridad es satisfacer al cliente.

MEDICIÓN

Las mediciones se hacen mediante observación directa en el lugar de trabajo, el Gemba, y medimos la realidad de la organización y de los proyectos con el ánimo de encontrar continuamente opciones de mejoramiento. Fomentamos la retroalimentación continua en todas las direcciones. 

Nexus, el exoesqueleto de desarrollo a escala con Scrum

Scrum es un marco de trabajo para desarrollar sistemas complejos. Como dice la Guía Oficial, es liviano, fácil de entender, pero quizás, después de un tiempo, con el acompañamiento adecuado, hayas sido capaz de llegar a dominarlo y tú y tu organización se encuentren en el camino de las entregas frecuentes de software con valor, del mejoramiento continuo vía retrospectivas, con equipos autoorganizados, donde las decisiones frecuentes de adaptación se basan en el conocimiento ganado vía la inspección y la experiencia. Después de todo, la autoorganización y el empirismo constituyen la doble hélice del DNA de Scrum.

Pero ¿cómo ha sido tu experiencia al querer dar el siguiente paso: escalar Scrum? Quizás has intentado SAFe, LeSS o el soberbio modelo de Spotify, para mencionar solo algunos de los ejemplares que prometen llevar con éxito la agilidad a toda la organización. ¿Cómo ha sido tu experiencia al intentar que múltiples equipos trabajen en un producto? O Quizás múltiples equipos trabajando en productos individuales o en una suite de productos integrados. ¿Qué tal toda la organización tratando de adoptar Scrum y otras prácticas ágiles? ¿Acaso has intentado una transformación organizacional de 180º hacia Ágil? Una que sea sostenible, es decir, un cambio que sea capaz de conservarse y reproducirse sin necesidad de apoyo o intervención externa.

Nexus™ – Un Exoesqueleto para 3-9 Equipos Scrum.

De eso se trata Nexus, “un marco de trabajo que consiste en roles, eventos, artefactos y técnicas que vinculan y entrelazan el trabajo de aproximadamente tres a nueve equipos de Scrum que trabajan en una sola Lista de Producto para construir un Incremento Integrado que cumpla un objetivo”.

Para entender Nexus, primero debemos entender de qué se trata el desarrollo de software a escala con Scrum: cualquier implementación de Scrum donde múltiples Equipos Scrum construyen un producto o un conjunto de características de un producto en uno o más Sprints o, también, cualquier implementación de Scrum donde múltiples Equipos Scrum construyen múltiples productos relacionados o conjuntos de características de productos en uno o más Sprints.

En el caso de múltiples equipos construyendo un producto, este tiene una Lista de Producto manejada por un Dueño de Producto y los equipos en conjunto crean un Incremento Integrado en cada Sprint por lo menos. Este Incremento se convierte en el foco y objetivo de todos los equipos dejando de lado el énfasis en el incremento individual que produce cada equipo en un Sprint.

Es precisamente la integración del trabajo (o la ausencia de esta), uno de los mayores obstáculos que encuentran las organizaciones al escalar Scrum o al tratar de implementar Scrum a gran escala. Para sobrepasar este impedimento, Nexus aumenta Scrum de manera orgánica, es el siguiente paso natural. Si has entendido y estás practicando Scrum, Nexus te parecerá más que familiar. Este nuevo marco de trabajo adiciona un nuevo rol, el Equipo de Integración Nexus, responsable de asegurar que se produzca el Incremento Integrado, es decir,  el trabajo combinado de un Nexus que adhiere a la definición de “Terminado”.

Además, Nexus adiciona un conjunto de eventos que, en general, extienden los eventos de Scrum o los reemplazan, lo mismo que un artefacto adicional:

Construido sobre los principios, valores y fundamentos de Scrum, el marco de trabajo Nexus:

• Crea rutas de comunicación
• Extiende y profundiza los mecanismos de inspección y adaptación
• Fomenta la transparencia continuada
• Depende de la inteligencia hacia arriba, en este caso, del Equipo de Integración Nexus hacia los equipos individuales que forman el Nexus.

Con mis grandes amigos Leonardo Agudelo y Jorge Abad tuve la oportunidad de traducir al español la Guía de Nexus, la misma que ya está publicada y disponible para descarga inmediata en:

https://www.scrum.org/Resources/The-Nexus-Guide/Downloads

Nota: este artículo se publicó por primera vez en diciembre de 2015 en Pulse de LinkedIn:

https://www.linkedin.com/pulse/nexus-el-exoesqueleto-de-desarrollo-escala-con-scrum-luis-antonio

------------------------------

Actualización 20150406:

Esta noche estuve hablando de Nexus con amigos de la Comunidad Ágiles Colombia en Medellín. Aquí está la presentación:

Nexus: el exoesqueleto para desarrollo a escala con Scrum

------------------------------

Actualización 20151007 (Ágiles 2016):

Hoy estuve hablando de Nexus con amigos de la Comunidad Ágiles Latinoamérica en Quito, durante las Jornadas Ágiles Latinoaméricanas - Ágiles 2016, una experiencia gratificante. 

Aquí está la presentación actualizada: