La próxima semana Scrum Inc. emite su Webinar mensual sobre algunos de los escollos más costosos en los que se meten los equipos al implantar Scrum. Al preparar las diapositivas para la presentación, el Jefe de Scrum Inc., Alex Brown, hizo que parte del personal analizara los problemas más frecuentes utilizando la lente del proceso A3. Fue un gran ejercicio y un recordatorio de lo útil que puede ser el análisis de las causas profundas cuando se intenta superar un impedimento obstinado.
Para quienes no estén familiarizados con el proceso A3, Se trata de una herramienta para identificar las causas profundas de problemas complejos y llegar a un consenso sobre cómo solucionarlos. Toyota fue pionera en este proceso para documentar los problemas de su proceso de producción. Cualquiera en Toyota puede iniciar el proceso y lo hacen para casi todos los problemas que encuentran. Para plasmar su análisis, utilizan la hoja de papel más grande que cabe en una fotocopiadora, el A3 o Tabloide (dos hojas de 8,5x11 una al lado de la otra).
Arriba se muestra un ejemplo de un A3 que realizamos para un OpenView Venture Partners empresa. El proceso se basa en Planificar, Hacer Comprobar, Actuar o el ciclo PDCA. En el lado derecho desglosamos el problema y empezamos a planificar. Las partes interesadas se reunieron para esbozar el contexto, las condiciones actuales y las previstas, e hicieron un análisis básico de las causas profundas. El análisis de las causas subyacentes parece una asignatura extravagante de la escuela de negocios, pero consiste básicamente en canalizar el niño de cinco años que llevamos dentro.
En el ejemplo anterior, el equipo no podía realizar las pruebas dentro del Sprint y los Sprints fracasaban constantemente. Esto le costaba a la empresa asociada unos 2 millones de euros al año. Hicimos que las partes interesadas preguntaran por qué pensaban que los Sprints estaban fallando. Nos daban una respuesta y les volvíamos a preguntar: ¿Por qué? Esto continuó hasta que las partes interesadas llegaron a unas cuantas capas de profundidad, momento en el que todo el mundo pensó que había descubierto la causa raíz. Los ingenieros no trabajaban bien juntos y todos pensaban que era obvio que si el Scrum Master hiciera su trabajo, los ingenieros formarían un equipo que funcionaría.
Una causa raíz es como una pequeña hipótesis científica y hay que probarla. Por eso es importante tener varias posibilidades. En el formulario A3, utilice el lado derecho para esbozar cómo puede probarse cada causa raíz. Empiece por la causa más probable. Esboza lo que haría falta para alcanzar las condiciones objetivo que el equipo acordó anteriormente. Es una buena idea disponer de algunos parámetros sólidos para las condiciones objetivo, de modo que el grupo tenga una forma objetiva de saber si la mejora del proceso ha funcionado. (La velocidad siempre es un buen parámetro). Aplique el cambio propuesto y compruebe si tiene el resultado deseado. A menudo algo cambiará, pero será inesperado. El cambio puede ayudar a aclarar el problema. O puede que lo resuelva. Si no lo hace, siga bajando en la lista de causas raíz. A menudo, los equipos piensan que han resuelto el problema, pero luego alguna otra fuerza provocará el mismo problema y las partes interesadas tendrán que reunirse de nuevo. El A3 es un documento vivo y, a medida que cambia el problema, hay que actualizarlo.
En el ejemplo anterior, todos los implicados pensaban que el Scrum Master no estaba consiguiendo que el equipo trabajara unido, así que la dirección decidió disciplinarle. Sin embargo, unas semanas más tarde, el problema volvió a surgir. Los implicados volvieron al A3 y profundizaron un poco más. Resultó que el Product Owner estaba tan centrado en añadir nuevas funciones que el equipo no tenía tiempo de poner en marcha la integración continua que les permitiría probar su código dentro del Sprint. Dado que el Product Owner era también el CEO de la empresa, el equipo no se sintió capaz de hacer frente a este problema con eficacia.
El uso del A3, sin embargo, hizo que esta causa subyacente fuera transparente para todos, incluidos los inversores que formaban parte del consejo de administración de la empresa. Ellos podría y consiguió que se comprometiera a implantar la integración continua antes de que se permitiera la inclusión de nuevas funciones en el Backlog. Esto resolvió el problema y unos Sprints más tarde, el Equipo aumentó su velocidad en 50% y OpenView se ahorraron a sí mismos y a la empresa 2 millones de euros. Si le interesa profundizar en el proceso A3, puede obtener un desglose completo en http://scrumlab.scruminc.com/index.html.
El 26 de junioth El seminario web abordará una serie de impedimentos que los equipos encuentran con frecuencia. Cada uno de ellos se presentará utilizando un formato similar al A3. Sin embargo, el secreto para eliminar los impedimentos persistentes es utilizar las técnicas incorporadas en el proceso A3. Su Equipo verá una mejora significativa en la Velocidad si, como los trabajadores de Toyota, lo utilizan para casi todos los problemas.
-- Joel Riddle
Spanish 
English 
French