Las 3 principales quejas que escucho de mis alumnos y que he visto en equipos a los que he apoyado:
Dependencias
Presión de las partes interesadas para que asuman el trabajo independientemente de su capacidad
Requisitos poco claros
¿Le suenan familiares? Vamos a centrarnos en las Dependencias.
Para los equipos Scrum, las dependencias son un vestigio de la gestión tradicional de proyectos, donde el trabajo fluye a través de equipos de especialistas que realizan un trabajo específico: Analizar, Diseñar, Construir, Probar, Desplegar. El proyecto avanza lentamente de una fase a la siguiente. Para "utilizar eficientemente los recursos", hacemos que esos miembros del equipo trabajen en varios proyectos para asegurarnos de que no están inactivos. Desde un punto de vista contable, maximiza el ROI del personal, haciendo rotar a los expertos como engranajes de una máquina para que el tiempo ocioso desaparezca de las hojas de cálculo. Sin embargo, el enfoque se convierte en mantenerse ocupado en lugar de producir trabajo del que podamos obtener retroalimentación o entregar valor.
Los equipos Scrum siguen abordando este mismo trabajo, pero el gran cambio es que vamos a hacerlo todo en un solo Sprint. Nos centramos en convertir una idea, o hipótesis de valor, en realidad actualizando nuestro producto. Mis alumnos responden: "Ummmm... vale... eso suena interesante, pero ¿cómo?".
Lo primero que tenemos que hacer es enfrentarnos a la realidad. No vas a poder cambiar la forma de trabajar de toda tu organización basándote sólo en una idea; necesitas pruebas. Un patrón interesante que he visto es que los equipos quieren estudios de casos de empresas similares que lo han hecho con éxito. Esto a menudo acaba creando más oportunidades para las excusas ("no tenemos su financiación", "no tenemos su pila tecnológica", etc.) en lugar de potenciar el movimiento hacia adelante.
Mi recomendación es centrar los esfuerzos en crear un experimento. Consigue la aprobación para reunir a todas las personas adecuadas en un único Sprint, sin otras distracciones, y comprueba lo que pueden hacer cuando se les permite trabajar juntos. El objetivo es convertir al menos una idea en un trabajo realizado que pueda utilizarse para obtener comentarios y, tal vez, incluso ofrecer un mayor valor a su cliente.
Esta es la primera ficha de dominó que cae para crear un cambio mayor. Demostrar que un equipo que trabaja en equipo, sin dependencias externas ni distracciones, puede convertir una idea en una actualización real del producto que invite a las partes interesadas a dar su opinión o, mejor aún, que proporcione al equipo la validación de los clientes. Entonces la pregunta pasa a ser: "¿Somos buenos para hacer otro Sprint como este?". Si las partes interesadas han visto un cambio deseable, puede crear un hambre de más. Este puede ser el pivote que convierte a los escépticos en defensores, porque han visto que funciona para ellos en su propio contexto.
Si estás listo para probar esto en tu próximo Sprint pero necesitas ayuda para conseguir esa aceptación inicial, o apoyo para conseguir que tu equipo se centre en la colaboración, ponte en contacto con nosotros en Improving. Tenemos experiencia ayudando a equipos a realizar su primer gran Sprint. Charlemos y hagamos que caiga tu primera ficha de dominó.
