Mi equipo es especial. ¿Necesitamos un ScrumMaster a tiempo completo?
No … siempre que el equipo cumpla las tres condiciones que se enumeran a continuación, un ScrumMaster a tiempo completo es probablemente innecesario.
- El equipo está aprendiendo de sus errores y está perfeccionando su rendimiento a medida que avanzan.
- El equipo está aprendiendo y adaptándose a las características organizativas, es decir a los impedimentos, a través del tiempo.
- El equipo está continuamente mejorando y consiguiendo ser considerablemente mejor mes tras mes.
Cuando los equipos se encuentran en este estado, yo diría que han alcanzado un estado de alto rendimiento. Si empezaron en este estado, entonces algo como Scrum no les beneficiaría. Yo sugeriría dejar que ellos hagan lo que quieran, ya que se ve con claridad que esta funcionando. Si no se encuentran en estado de alto rendimiento, Scrum (o cualquier proceso ágil), podría ayudar.
¿Así que cuando necesitamos un ScrumMaster a tiempo completo? Cuando una, o más, de estas condiciones está presente en del equipo.
- El equipo sigue haciendo los mismos errores una y otra vez mientras se estanca la calidad del producto (o se degrada).
- El equipo encuentra constantemente los mismos impedimentos organizacionales y responde con la misma estrategia de afrontamiento con resultados predecibles.
- El equipo no adopta la mentalidad Kaizen y su desempeño como grupo fundadores.
Trabajar en estas cuestiones a nivel individual, de equipo y de organización es un trabajo a tiempo completo para la mayoría de la gente. Como he mencionado antes, el ScrumMaster son ocho roles metidos en uno y se necesita tiempo para dominarlos. El aprendizaje de estas habilidades no es ciertamente otra tarea desagradable para un miembro del equipo con exceso de trabajo (o el director del proyecto ficticio “ágil”). Ni tampoco puede un ScrumMaster trabajar en un lugar diferente al equipo. Abordar las cuestiones mencionadas anteriormente requiere tiempo, concentración y dedicación.
Por último, Geoff Watts dedica un capítulo entero en su libro Scrum Mastery: From Good to Great Servant Leadership, a este tema. En su libro, Geoff avanza a través de tres escenarios comunes, Product Owner-ScrumMaster, Miembro del Equipo-ScrumMaster y un ScrumMaster para varios equipos, habla de los posibles conflictos de intereses, los beneficios (en realidad hay unos pocos) y los riesgos.
