¿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.
