Mi hija mayor se casó hace poco. Aproximadamente un mes antes de la boda, me di cuenta de que bailaría con ella y luego con mi esposa en la recepción posterior. Pero oh-oh: no he bailado en mucho tiempo. Necesitaba lecciones.
Pero no entré en pánico. ¿Qué tan difícil podría ser? Patrick Swayze seguro que lo hizo parecer fácil. Y no pensé que mi hija o mi esposa esperarían que los sostuviera por encima de la cabeza.
Resultó ser bastante difícil, a pesar de que parecía tan fácil. Mientras luchaba por aprender, me di cuenta de que bailar period muy parecido a Melé: Fácil de entender pero difícil de dominar.
Veamos ocho razones por las que Scrum es difícil, probablemente incluso más difícil que aprender a bailar.
Problema 1: todo cambio es difícil
Si la nueva forma de hacer algo fuera más fácil, probablemente ya lo estarías haciendo de esa manera. Por lo common, hay una razón por la que hemos elegido hacer algo de la manera que lo hemos hecho. Hace unos meses me di cuenta de que siempre bata la comida en el sentido de las agujas del reloj. Solo por diversión comencé a batir en la dirección opuesta. Es dificil.
Cuando un equipo adopta Agile, afecta casi todos los aspectos de cómo los miembros del equipo hacen su trabajo diario. Un cambio generalizado como ese es un desafío. Incluso si los miembros del equipo están motivados para tener éxito en el cambio, habrá momentos en que se preguntarán si vale la pena el esfuerzo.
Es cierto: algo que es easy de entender puede ser difícil de dominar. Para aliviar parte del dolor del aprendizaje, proporcione a las personas un camino claro a seguir y mucha claridad sobre el cómo y el por qué. Mi por qué para refrescarme en el baile fue que no quería avergonzar a mi esposa e hija en la boda; y mi cómo eran las lecciones.
Problema 2: las revisiones de Dash dan miedo al principio
Mostrar tu trabajo a otros y escuchar sus opiniones al respecto puede parecer una amenaza para tu autoestima. ¿Les gustará? ¿Se bloqueará el sistema durante la parte de demostración del revisión de carrera? ¿Hicimos lo suficiente durante el dash? Estas son preguntas intimidantes.
Sin embargo, estas preguntas, y otras parecidas, nos vienen a la cabeza cuando equipos de scrum primero comience a dar demostraciones durante las revisiones de dash.
La buena noticia es que después de un tiempo, las reseñas se vuelven algo pure. A medida que los equipos de desarrollo ven el beneficio de recibir comentarios rápidos, pueden esperar ansiosamente las revisiones en lugar de temerlas.
Problema 3: saber qué hacer con la retroalimentación es difícil
Incluso después de que los miembros del equipo se sientan cómodos mostrando su trabajo cada dos semanas, saber qué hacer con todos esos comentarios puede ser un desafío. Dado que los comentarios llegan rápido y furiosos, los equipos deben decidir qué comentarios incorporar y cuáles ignorar.
También está el momento: con un proceso en cascada, se solicita retroalimentación al last, después de que el equipo siente que el proyecto ha terminado. Cuando la retroalimentación se proporciona de manera más gradual, cada dos semanas, los equipos pueden sentirse abrumados. Sienten que se atrasan cada vez que piden retroalimentación.
Una solución es… priorizar los objetivos de su producto. Esto lo ayudará a filtrar los comentarios cruciales de los detalles que no necesitan tratarse en este momento. Después de todo, no todo puede ser Prioridad A.
Problema 4: toda esta colaboración parece más lenta
Antes de convertirme en programador, trabajé en un cuarto oscuro revelando fotos. Comencé cada día llevando un montón de película sin revelar a mi cuarto oscuro. No abrí la puerta hasta el almuerzo, cuando puse las fotos de la mañana en una papelera. Conseguí el almuerzo, una nueva pila de película, y me encerré en el cuarto oscuro hasta la hora de salir.
Me gustó el aislamiento. Y eso continuó como programador cuando me ponía auriculares, subía la música y codificaba de forma aislada todo el día.
Por lo tanto, puedo relacionarme con aquellos en equipos ágiles que desearían que se les pudiera asignar una gran tarea y luego irse y hacerlo durante un par de semanas (o más) sin necesidad de comunicarse hasta que la tarea esté terminada.
Pero los productos que construimos hoy requieren mucha más colaboración que cuando comencé mi carrera. Y a veces parece que colaborar con los compañeros de equipo nos frena.
La clave es darse cuenta de que todas las conversaciones, correos electrónicos, mensajes y reuniones ayudan a prevenir problemas. Lo que escuche y diga en una reunión a veces no será útil. Pero muy a menudo, en una reunión bien organizada, lo que escuchas resuelve un problema y lo que dices resulta útil para otra persona.
Problema 5: Los puntos de la historia son una nueva forma de estimar
La thought de estimar en puntos de la historia definitivamente puede ser un desafío para muchos miembros del equipo. Casi puedo escucharlos pensar: “¿Tengo una estimación difícil en días y ahora tengo que estimar en una unidad relativa abstracta de la que nunca había oído hablar antes?”
Los puntos de la historia son un desafío definitivo, pero valen la pena el esfuerzo. Como estimaciones relativas abstractas del esfuerzo, los puntos de la historia permiten mejores conversaciones sobre cuánto tiempo llevará el trabajo.
Sin puntos de historia, un programador senior y un programador junior tienen conversaciones que se convierten en: “Ese es el tiempo que te llevará a ti, pero a mí me llevaría el doble”. Y luego los dos eligen una estimación que es horrible para uno de ellos o, quizás peor, dividen la diferencia.
Con los puntos de la historia, los programadores senior y junior pueden considerar agregar una nueva característica y ambos están de acuerdo en que tomará el doble de tiempo que hacer una característica más easy. Luego le dan al artículo más grande una estimación del doble que la del artículo más easy.
Estimar de esta manera relativa permite a los desarrolladores ponerse de acuerdo incluso si nunca podrían ponerse de acuerdo sobre cuántas horas o días tomaría algo. Bonificación: los puntos de la historia disuaden a los gerentes de comparar la velocidad del equipo.
Problema 6: la gente se queja de que hay demasiadas reuniones
Una queja común sobre Scrum es que hay demasiadas reuniones. Es una crítica justa, pero no creo que esté justificada, porque cada uno puede ser bastante eficiente. Consideremos la duración recomendada de las reuniones de un dash de dos semanascomo se resume en la tabla.
| Reunión | Tiempo por dash de dos semanas (horas) | |
|---|---|---|
| Scrum diario | 1.5 | |
| Planificación de Dash | 2 | |
| Revisar | 2 | |
| Retrospectivo | 1 | |
| Refinamiento de la cartera de pedidos | 1.5 | |
| Complete | 8 |
Eso es alrededor de ocho horas. Entonces, ¿son demasiado ocho horas de tiempo de reunión en un dash de dos semanas? Primero, tenga en cuenta que estos números son conservadores. Siete horas puede ser un complete más realista. Ocho horas es mucho tiempo, pero no creo que sea excesivo.
Las reuniones en Scrum son como las líneas en la carretera. Las líneas están ahí para ayudar a los conductores a avanzar de forma rápida y segura. Las reuniones de Scrum deberían sentirse de la misma manera. Mantienen seguros a los miembros del equipo asegurándose de que cada uno sepa lo que está haciendo el otro.
Las reuniones deben ayudar al equipo a moverse mas rapido creando oportunidades para la comunicación. Si las reuniones de su equipo no se sienten como las líneas blancas en la carretera, considere acortar o eliminar una reunión.
Problema 7: No es fácil ser un Scrum Grasp
Tienes razón. Scrum no es fácil. Y no es fácil ser un Maestro Scrum cualquiera. Pero la mayoría de los trabajos no son fáciles cuando eres nuevo en ellos. Quédate con él el tiempo suficiente y se vuelve más fácil.
Y en este punto, hay muchos libros, cursos, foros en línea y más sobre cómo ser un Scrum Grasp. Nunca estás demasiado lejos de los consejos.
Problema 8: ser propietario de un producto es un trabajo difícil
Si pensabas que ser un Scrum Grasp period difícil, intenta ser el dueño del producto. Los propietarios de productos lo obtienen de ambos lados: los equipos piden claridad y más detalles, los clientes y los usuarios piden funciones. Ser propietario de un producto requiere equilibrar estas demandas competitivas de su tiempo.
Scrum es difícil pero vale la pena
Adoptar un enfoque Scrum es difícil. Es possible que haya momentos en los que quieras levantar las manos y volver a lo que estabas haciendo antes.
Por lo common, esos pensamientos son bastante fugaces. Sin embargo, sigue así, estoy seguro de que ya eres mucho mejor en eso que yo en el baile. Y todavía no me he rendido. Me quedaré con eso si quieres.
¿Qué piensas?
¿Qué aspectos de Scrum te han resultado difíciles? ¿Hubo momentos en los que estuviste tentado a abandonarlo? ¿Te quedaste con eso? ¿Valió la pena? Por favor, comparta sus pensamientos en los comentarios a continuación.
