Cómo fomentar el compromiso en un sprint para un equipo

No es posible obligar a la gente a comprometerse con algo. El compromiso debería ser, por definición, un acto voluntario. Creo que es posible hacer algo y sé que haré todo lo posible para hacerlo, por lo que me comprometo a lograr la meta.

Si piensas en obligar a la gente, ya no es un compromiso, es solo quitarme el mono de encima. ¿Quieres saber que esto estará listo en 2 semanas y no me va a dejar en paz? ESTÁ BIEN. Aquí, dije esto. ¿Feliz ahora? Pero no me digas que es un compromiso real.

Lo que puedes hacer para conseguir lo que quieres es:

• Primero, aprenda por qué evitan cualquier compromiso. Podrían haber sido castigados por no cumplir con sus compromisos en el pasado, por lo que aprendieron a evitarlos. O es posible que simplemente no entiendan por qué es importante para el resto de la organización. O algo mas. A menos que sepa cuál es la causa raíz de esta situación, sería difícil actuar razonablemente.

• En segundo lugar, ayúdeles a comprender por qué usted y otras personas de la organización necesitan este compromiso. Explique cómo afecta la planificación, la toma de decisiones, la asignación de personas y recursos, etc. Trate de ponerlos en su lugar para que vean por qué es tan importante para usted.

• En tercer lugar, aborde cualquier problema que tenga el equipo para comprometerse con cualquier cosa. Si no quieren ser castigados cuando fallan, asegúrales que no lo serán. Explícales que el objetivo es que hagan lo mejor que puedan y que entiendes que todos fallan ocasionalmente. Si hay alguna otra razón, háblala también.

• Cuarto, intenta enseñarles a conseguir sus objetivos paso a paso. Comience con un compromiso pequeño y fácil de lograr para que vean que pueden hacerlo. También establece un buen historial de esta manera. Si sus metas en este momento son demasiado ambiciosas o demasiado desafiantes, busque algo más pequeño/más fácil o redúzcalas. Tal vez no sea un informe completo sobre posibles bases de datos, sino simplemente una comparación de un conjunto de características cruciales, o la realización de un conjunto de pruebas básicas, etc.

• Quinto, comunicarse con frecuencia. Si al final de la semana te enteras de que no se ha hecho nada es problema tuyo y de los demás. Significa que no se comunica con la frecuencia suficiente o que la calidad de la comunicación es baja. ¿Cómo podría pasar algo así por todos los stand-ups?

• Sexto, evitar, por cualquier medio, forzar a las personas. De esta manera no terminarás con un compromiso real en absoluto. La calidad de la información que obtenga del equipo también será deficiente. No podrá planificar nada basándose en "compromisos" en tal situación.

Para empezar, me gustaría señalar que en la Guía Scrum más reciente de Ken Schwaber y Jeff Sutherland, no estamos hablando de compromiso de una manera en la que le pedimos al equipo que entregue una cierta cantidad de características, sino que se comprometa con significados más profundos como la calidad de estas funciones o el trabajo diario con gente de negocios. Es una diferencia sutil, pero significativa. Lectura sugerida: ¿Está muerto el compromiso?

En cuanto a la situación en la que te encuentras, me gustaría preguntarte si tú, como ScrumMaster, ¿has hecho todo lo posible para evitar esta situación? ¿Estabas al tanto de la situación pero esperabas que el equipo encontrara una solución antes de la fecha límite? ¿O ha intentado activamente encontrar a alguien (un DBA, por ejemplo) que pueda intentar responder cualquier pregunta técnica (o el Cliente para cualquier pregunta comercial) que el equipo pueda tener para aclarar cuál es su mejor opción? ¿Hubo alguna razón por la cual su Cliente fue informado bastante tarde sobre los problemas y no antes?

Como ScrumMaster, su trabajo es hacer eso. No solo para estar allí en las reuniones de artefactos de Scrum y eliminar cualquier impedimento solicitado, sino también el que el equipo no puede comunicarle específicamente. Tienes que ser consciente de lo que está pasando y tratar de hacerlo mejor o más simple.

Los equipos fallarán en la entrega de algunas características, eso sucederá en todas las empresas. El mejor enfoque que podemos tener cuando un equipo falla es inspeccionar lo que sucedió y adaptarnos para prevalecer. Y espero que el ScrumMaster de este equipo también intente inspeccionar y adaptarse.

Sé que puedo parecer duro contigo, pero me falta más información sobre la razón por la que el equipo fracasó (y estoy seguro de que el problema no es solo cómo lo manejaste). Leyendo sobre cómo están actuando en su Sprint Planning, me sentiría tentado a decir que no está tratando como un equipo sino como un colectivo de individuos. Es posible que desee intentar tener algunas actividades de formación de equipos con ellos para empezar. Lecturas adicionales sugeridas: Las cinco disfunciones de un equipo y Superación de las cinco disfunciones de un equipo .

Una vez que tengas un equipo, tal vez las cosas sean más fáciles.

Parece que no está recibiendo la retroalimentación que necesita durante sus Scrums diarios. El estado de los entregables críticos siempre debe comunicarse a través de Scrums.

Cuando adoptan Scrum por primera vez, los equipos tienden a comprometerse en exceso y se reducirán a una cantidad de trabajo más realista en cada sprint a medida que aprenden cuál es su verdadera velocidad. El equipo debería tener una mejor idea de cómo y con qué pueden comprometerse con cada retrospectiva de sprint.