Buscar en Gazafatonario IT

sábado, julio 30, 2016

Un vistazo a la guía de Scrum

¿Hace cuánto leíste por última vez la guía de Scrum? Es bien sabido que a medida que tu experiencia y conocimientos crecen, tu forma de ver (leer) algo cambia respecto a la vez anterior. Quizás aprendas algo más, quizás seas capaz de visualizar o entender algo que antes no habías percibido o entendido.

Aprovechando la revisión de la que fue objeto la guía por parte de sus autores y de que había que traducir esa actualización, realicé una revisión exhaustiva tanto de la versión en inglés como de la versión en español en la que tuve la oportunidad de trabajar por primera vez en 2013. (Para conocer los cambios introducidos a la guía, ve a: http://www.gazafatonarioit.com/2016/07/revision-la-guia-de-scrum.html)

Con tres años más de experiencia y conocimiento en Scrum y temas relacionados, me tomé la libertad de actualizar la Gramática y redacción del documento y también algunos asuntos de fondo que me hacían ruido desde hacía mucho tiempo respecto a la versión original de la guía en inglés.

Con todo esto, aproveché también para “repasar” lo que dice la guía, para mirarla más a fondo y decidí traer aquí una lista, arbitraria por demás, pero de todo mi gusto, de algunos puntos que quiero resaltar. Son los siguientes:
“Scrum no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas”.
Es impresionante la cantidad de personas, equipos y organizaciones que solo “aprenden” o quieren aprender Scrum, como si con eso fuera suficiente para hacer todo el trabajado que se les viene por delante. La lista de proceso, técnicas, marcos de trabajo y prácticas que podemos y deberíamos usar con Scrum es extensísima, no voy a elaborarla aquí, pero lo que sí es cierto, lamentándolo mucho por quienes no lo han visto, es que Scrum solo no es suficiente.
“Scrum muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas de desarrollo de modo que podamos mejorar”.
Scrum se basa en la teoría empírica  de control de procesos. Esto quiere decir básicamente que aprendemos de la experiencia. Scrum nos permite visualizar la eficacia las prácticas que usamos las personas, los equipos y las organizaciones y nos permite inspeccionarlas continuamente y adaptarlas y adaptarnos de acuerdo con los distintos escenarios circundantes.
“El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto”.
Todavía me encuentro con muchos equipos y organizaciones que no terminan de integrar al negocio, vía el Dueño de Producto, en sus equipos. Y muchos menos son los Dueños de Producto que realmente actúan como tal. El muy comentado pero pocas veces entendido “backlog” de producto sigue siendo gestionado por el equipo y muchas veces solo por el Scrum Master o por alguien más que no es ninguno de los roles propuestos en la guía.
“El Scrum Master es el responsable de asegurar que Scrum se entienda y se adopte. 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”.
Usar Scrum no nos hace ágiles, eso lo tenemos claro muchos. Pero muchos no tienen claro que si vamos a usar Scrum como marco de trabajo ágil, debemos ajustarnos a las reglas enumeradas en la guía. Estas reglas condensan la experiencia de muchos años de trabajo, sobre todo en proyectos de software, de los autores y de muchos otros en la industria. Conjuguemos esta observación con la del primer punto más arriba.
“La Planificación de Sprint tiene un máximo de duración de ocho horas para un Sprint de un mes. Para Sprints más cortos el evento es usualmente más corto”.
En las versiones anteriores es español aquí decía que el tiempo de las reuniones era proporcional a estas ocho horas para sprints más cortos. En ninguna parte de la guía original en inglés dice así, de tal forma que la actualicé en este sentido.
“Al finalizar la Planificación del Sprint, el Equipo de Desarrollo debería ser capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado”.
¿Cuántos de los equipos en los que has trabajado, en los que eres Scrum Master, miembro del Equipo o Dueño de Producto, hacen esto? De hecho, muchos quieren terminar lo más rápido posible la planificación para ponerse a trabajar pero nadie es capaz de explicar cómo van a trabajar para lograr la meta trazada del Sprint.
“El objetivo del Sprint puede representar otro nexo de unión que haga que el Equipo de Desarrollo trabaje en conjunto y no en iniciativas separadas”.
Es más, muchas veces los equipos no establecen un objetivo más allá de aquel que indica el número de historias de usuario a construir en el sprint. La meta del Sprint debería ser algo más de Valor para el Dueño de Producto y, por ende, para el negocio. Dejaré este asunto de la meta del sprint para otro artículo pero además de pensar en las características o funcionalidades a implementar siempre es bueno pensar en las razones para llevar a cabo la iteración. Bien sabemos que metas efectivas nos sirven para probar o demostrar que nuestras ideas funcionan, para fomentar el trabajo en equipo, para reducir o eliminar un riesgo específico o para proporcionar mayor valor entregado al negocio.
 “El Equipo de Desarrollo o los miembros del equipo a menudo se vuelven a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar, o replanificar el resto del trabajo del Sprint”.
La expresión clave aquí es “a menudo”. Hacer otras cosas después de la reunión diaria puede hacernos perder foco y, por consiguiente, productividad y puede alejarnos de la consecución del objetivo del sprint. Por ejemplo, en la reunión diaria no hablamos de las soluciones a los impedimentos, entonces es buena idea tener reuniones específicas sobre estos asuntos justo después de aquella.
“El Scrum Master se asegura de que se cumpla la regla de que solo los miembros del Equipo de Desarrollo participan en el Scrum Diario”.
Sigo viendo mucho de comando y control en la reunión diaria. ¡El seguimiento diario, dicen algunos! Esta es una reunión de coordinación, de planificación, es precisamente “una reunión clave de inspección y adaptación”. Cualquier otra cosa que se requiera hacer con el equipo, debe ser en otra reunión especial, no en esta.
“Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto y en cualquier cambio a la Lista de Producto durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor”.
La Revisión de Sprint no es solo para hacer la demostración del incremento de producto terminado. Y puesto que a esta reunión asisten o pueden asistir interesados clave en el producto, es una oportunidad única para discutir lo que viene a continuación en el proyecto.
“Una Lista de Producto nunca está completa. Mientras el producto exista, su Lista de Producto también existe”.
“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”. ¿Hace falta decir algo más?
“Los elementos de la Lista de Producto tienen como atributos la descripción, el orden, la estimación y el valor”.
El valor para el negocio. Noten además que hablamos de “los elementos de la lista”, no son solo historias de usuario, como muchos erróneamente creen y manifiestan.
“Scrum no reconoce subequipos en los equipos de desarrollo, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas o análisis de negocio; no hay excepciones a esta regla”.
No existe tal cosa como “ellos y nosotros”, somos un único equipo indivisible, somos una unidad morfológica (orgánica) y funcional y actuamos como tal. Valoramos las habilidades y fortalezas de cada uno de los miembros de esta unidad, pero hacia el mundo exterior somos El Equipo.


Y bueno, como dice mi amigo y colega Jorge Abad, hasta aquí estas reflexiones, viscerales por demás, sobre la guía de Scrum. Los invito a que la descarguen y vuelvan a leerla y a que nos cuenten en el foro cuáles son sus puntos favoritos de la guía, con cuál no están de acuerdo, cuál cambiarían, etcétera.

También pueden descargar la guía de:

Guía de Scrum en español

miércoles, julio 13, 2016

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:

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

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

miércoles, julio 06, 2016

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.