Las compañías tradicionales que inician su andadura en Agilidad e intentan implantar Scrum suelen tener que pasar por tres puntos críticos y efectuar su aprendizaje particular para tener éxito y acelerar la entrega de valor.
 |
| Los tres puntos críticos susceptibles de aprendizaje |
1. Los equipos son quienes deben de estimar lo que cabe en la pila de sprint
Una de las disfunciones habituales se produce cuando no es el equipo de desarrollo el que estima qué cabe en la pila de sprint; en ocasiones lo hace un "jefe de proyecto" y en otras ocasiones el contenido del sprint es la parte proporcional de un alcance de proyecto cerrado negociado de antemano.
Este último es el caso de empresas que se basan en un modelo de obediencia de sus empleados, un gestor les dice al equipo cuál es la pila de sprint a ejecutar y este simplemente lo hace... o lo intenta. Este modelo no suele funcionar ya que el equipo no siente verdadero compromiso hacia la pila, se esfuerza y hace lo que puede y si no llega siente que no es culpa suya ya que la pila fue una imposición.
En un modelo de compromiso hemos de entender que sólo las personas que van a hacer el trabajo pueden estimarlo. Obtendremos compromiso cuando el equipo decide libremente lo que cabe en la pila de sprint, al final de la planificación de sprint el equipo debe de estar totalmente convencido de que la pila es perfectamente ejecutable a lo largo del sprint. Solo así conseguiremos compromiso y que el equipo ponga el esfuerzo y toda su energía en la construcción del incremento.
Para que los equipos tengan oportunidad de aprender qué cabe en su pila de sprint hemos de darles la oportunidad para encontrar su capacidad, llamada velocidad en Scrum. Eso implica que la compañía les ha de dar permiso a fallar para aprender del fallo, usualmente un equipo novel encuentra su capacidad a partir del tercer sprint.
2. Aprender a terminar el sprint antes de empezar el siguiente
Una de la características del ser humano es que nos es muy fácil abrir y empezar cosas nuevas, pero nos cuesta horrores acabar las cosas. En este punto crítico el equipo, y el entorno que le rodea, ha de aprender uno de los mantras que provienen de Lean Kanban:
Stop starting and start finishing - Termina de empezar y empieza a terminar
Un incremento resultante de un sprint se define como un parte del producto totalmente terminada, con todo lo acordado hecho, y potencialmente liberable a producción. Para que todos entendamos qué significa terminado Scrum introduce el artefacto de la definición de hecho (DoD). Algo no está terminado hasta que todos los puntos de la definición de hecho estén chequeados y el usuario o interesado pueda usarlo o probarlo en un entorno del que sea propietario.
Una de las mayores disfunciones de Scrum ocurre cuando los equipos no son capaces terminar los sprints de manera recurrente. Puede haber diferentes causas detrás de la disfunción, como el punto 1 por ejemplo, cuando el equipo no tiene la oportunidad de aprender cual es su capacidad para la pila de sprint, o cuando el entorno que rodea al equipo no permite que cumplan con la definición de hecho; un ejemplo corriente es un entorno de despliegue para el usuario, test o preproducción por ejemplo, que no es estable e idéntico al de producción.
A nivel de compañía hay que pasar por el aprendizaje de que lo más importante para un Scrum exitoso es que los equipos encuentren su ritmo en el que de forma sostenible sean capaces planificar y entregar cosas totalmente terminadas. Llegado a este punto es donde los equipos aceleran y se pueden alcanzar incrementos de productividad del 400%, como muestran algunos estudios como el Chaos Report de Standish Group y los Annual State of Agile Reports de Versionone.
3. Apoyar a los equipos para acelerar el flujo de entrega de valor
Las retrospectivas son el latido de la mejora continua, en cada una de ellas el equipo identifica su mayor "dolor" y busca mejoras para que no tropiece de nuevo en las mismas piedras en ocasiones futuras.
Las causas raíz de sus problemas pueden tener el origen dentro del equipo, con lo que el mismo equipo encuentra las mejores soluciones al visibilizar y tratar el problema desde dentro. En otras ocasiones las causas raíz son externas y por ellos mismos no pueden mejorar, así que Scrum Master ha de elevar las soluciones a donde corresponda para que se apliquen.
Este es otro punto crítico, ya que las compañías han de poner los medios para que el entorno del equipo dé solución a sus problemas, un aprendizaje a realizar para entender que es necesario poner los medios para que los equipos estén focalizados en un trabajo de valor, y para que el flujo de trabajo del equipo de desarrollo acelere y aumente la productividad del sistema. Cuando no ponemos los medios ocurre que los equipos tropiezan una y otra vez con el mismo problema y sientan frustración, hecho que a su vez afecta negativamente a la construcción de un software que de buenas soluciones a las necesidades de nuestros clientes.
Termino con una frase que me encanta: ¡para que hacer cosas serias es necesario divertirse! Encorsetados, cansados, estresados... difícilmente haremos cosas serias.
