Al observar los comportamientos de los equipos por los que he pasado, he visto numerosos estándares que les impedían evolucionar y convertirse en equipos más productivos.
Muchos de ellos utilizaban Scrum y por eso he elegido las principales trampas en las que caían, y a continuación las comparto contigo para que no caigas también.
Si estás comenzando ahora, te sugiero que antes leas este artículo: ¿Qué es Scrum?
¿Cómo debes leer este texto?
(!) Recuerda que todo lo que está aquí son trampas, es decir, evita hacer cada elemento que te comparto, salvo en los que agregué #consejo más adelante. (¡!)
Planning de Scrum
El objetivo aquí es alinear a todos con el problema comercial que se resolverá y qué métricas tenemos el potencial de mejorar. Detallar qué se hará y cómo se hará.
¿Quieres ayuda para ir más allá y crear un Roadmap para tu planning? Lee este artículo sobre cómo crear un roadmap.
Llegar hasta aquí sin un objetivo de sprint claro
#consejo Hay tres formas comunes de definir el objetivo del sprint:
1 – El PO llega con una idea objetiva, el equipo colabora y creamos juntos un objetivo de sprint (esto sucede cuando el equipo tiene una visión de negocio);
2 – El PO llega con un objetivo de sprint y el equipo sólo acata;
3 – El equipo extrae la lista de elementos del backlog y luego elige el objetivo, el famoso “tiro al blanco”.
Tener como objetivo de sprint una lista de tareas
#consejo El Objetivo debe basarse en entregar valor al cliente. Si tu equipo hace X, ¿cuál es el resultado para el cliente? Este debería ser el objetivo.
Tener más que 1 objetivo
#consejo Si tienes más de uno, al menos tendrás una prioridad.
Que el objetivo sea entregar historias y no valor al cliente
Ej.: “Poner fin a la historia xyz que le da autonomía al cliente” en lugar de simplemente “darle al cliente más autonomía en el momento de la compra”.
Puntuar bugs
#consejo Por lo general, bugs son una deuda técnica y deben resolverse independientemente de la puntuación. Además, hay un cambio natural de comportamiento en el equipo de renunciar a la calidad para poder arreglarla más tarde, en la onda de “después lo puntuamos y lo llevamos a sprint”. Para cuando el equipo esté haciendo el sprint de corrección de bug.
Ejemplo:
1 – El equipo puntúa el elemento con 13 puntos;
2 – Un día antes del final del sprint, el equipo decide entregar ese elemento con “2 bugs conocidos”;
3 – En el siguiente sprint, el equipo puntúa los bugs con 5 y 3 puntos.
Consecuencias:
- a) El elemento realmente “ha costado” 20 puntos;
- b) Como todo está “bien” y el equipo “está cumpliendo”, el equipo no se da cuenta de que ha estimado mal y no lo mejora;
- c) El equipo se acostumbra a entregar con errores y a puntuar los errores más tarde, sin entregar valor al cliente;
- d) En última instancia, los bugs terminan siendo despriorizados, ya que son un elemento de backlog como cualquier otro, y no una deuda técnica;
- e) Eventualmente el equipo termina encontrándose en una situación desagradable: “sprints de bugs”, “muy mala aplicación de mantenimiento”, etc.
Asegurarse de que el equipo resuelva los bugs independientemente de la puntuación hace que el equipo se sienta “penalizado” por haber dejado pasar un bug.
Esto refuerza el comportamiento positivo, que es tener una tolerancia muy baja a bugs y asumir efectivamente la responsabilidad de la calidad – refuerza el uso de DoD aquí.
El equipo sólo descubre el backlog en la planning
#consejo El backlog de PO debe estar disponible para el acceso del equipo en cualquier momento. Esto permite que el equipo vea lo que viene a continuación y ayuda en lo que sea necesario.
Daily
El objetivo aquí es coordinar los esfuerzos para lograr el objetivo del sprint.
Hazte las 3 preguntas (¿Qué hice ayer? ¿Qué voy a hacer hoy? ¿Algo me detiene?)
#consejo <opiniónpolémica> Esto conduce a un status report de forma natural. Si quiero saber qué hice ayer, debería mirar el board. Si quiero saber qué están haciendo los demás, debería mirar el board. Si hay algo que me detiene, debería haberlo dicho en ese momento, ¡por el amor de Dios! (“Es que mi board no está actualizado” -> Este es OTRO problema.)</opiniónpolémica>
La pizarra sólo se actualiza una vez al día
¡¿El único momento del día en que se actualiza tu pizarra es a diario?! Esto significa que en todos los demás momentos de trabajo del día tu equipo estará sujeto a la descoordinación, retrabajo y falta de visibilidad.
#consejo ¡Actualiza tu pizarra lo más cerca posible del tiempo real!
No empieces con el objetivo del sprint
#consejo Todos los días recuerda el objetivo del sprint y pregunta si alguien necesita ayuda para lograrlo.
Sugiero comenzar a diario con el Confidence Chart y crear acciones para el día que hagan que tu equipo tenga más confianza para alcanzar la meta del sprint.
El PO dice lo que debe hacer el equipo
Esto interfiere en la autoorganización del equipo.
#consejo Recuerda que el equipo de desarrollo es autoorganizado.
(Texto sugerido: Recuerda el rol del PO.)
El SM dice lo que el equipo debe hacer
Esto interfiere en la autoorganización del equipo.
(Sugerencia de texto: recuerda el rol del SM.)
La rutina hecha para el PO
Se convierte en un status report y refuerza la jerarquía (que no debería existir entre el PO y el equipo).
La rutina hecha para el SM
Se convierte en un status report y refuerza la jerarquía (que no debería existir entre SM y el equipo).
Review
Aquí el objetivo es recoger feedback sobre la evolución del producto o servicio y saber si vamos por el camino correcto.
Ningún cliente final (persona que utilizará el producto/servicio) en la review
#consejo Me gusta mucho usar la comparación con el código en producción. Nuestro objetivo es tener el código en producción, no en homologación, no en el entorno de desarrollo, no en la máquina local.
El mismo razonamiento funciona para la review y la recepción de feedbacks. Primero del cliente final (producción), no de los stakeholders y la gerencia (homologación), no de los otros equipos (desarrollo), no del PO (máquina local).
¡¡¡Disclaimer alert!!! Review para el PO es el peor de los escenarios #nolorecomiendo, por la misma razón de que sólo tiene un código en su máquina. Si el PO espera la review para averiguar qué está pasando, no está haciendo el trabajo correctamente.
El PO no anota feedbacks
#consejo PO, recuerda: este es el propósito de esta ceremonia.
El PO no trae el objetivo y la estrategia del sprint
No dejar que el equipo de desarrollo te muestre lo que ha construido
#consejo El equipo necesita mostrar lo que ha hecho, aumenta el compromiso y el deseo de pertenecer.
Retrospectiva
El objetivo aquí es ver dónde podemos mejorar como equipo en general.
No hacer retrospectivas “porque no tenemos tiempo”
Hacer una retrospectiva después de la planificación
Parece obvio, ¿verdad? Pero me he encontrado con muchos equipos que hacen la retrospectiva después de la Planificación.
#consejo Aplicar ya en la planificación las mejoras del último sprint, y esto sólo pasa si haces la retrospectiva antes.
No tener planes de acción / Tener demasiados planes de acción
Por favor, céntrate en algunos, los que más duelen.
#consejo Si estos planes de acción son elementos que haces una vez y listo, fenomenal, ¿vale? Sin embargo, si son elementos que necesitas repetir para siempre, considera colocarlos en el acuerdo de equipo. Por favor, ¡ten un acuerdo de equipo!
Repetir siempre la misma retrospectiva
No tener un objetivo claro con la retrospectiva
El #consejo a mis queridos SM es que necesitáis construir o ejecutar una retrospectiva enfocada en el problema del equipo que queréis resolver. El “cómo” queda a cargo del equipo.
La retrospectiva es la planificación del SM. En la planificación, el PO presenta el problema del producto/servicio que el equipo va a resolver, el equipo propone cómo lo hará.
En la retrospectiva, el SM trae el problema que quiere resolver desde el equipo en forma de dinámica (no necesitas hacer explícito el problema, deja que tu dinámica hable por ti) y el equipo trae el cómo.
No actualizar la Definición de Preparado (DoR)
#consejo Utiliza la pregunta: “¿Qué debería estar claro de antemano, que no está y nos hubiera permitido entregar?”. Una respuesta puede ser, por ejemplo: “Ah, si hubiéramos sabido a qué tablas acceder antes, no habríamos perdido tanto tiempo en esto y habríamos podido entregar”. Fenomenal, un nuevo elemento en DoR -> Tablas a las que accederemos explícitamente.
Refinamiento
El objetivo es plantear problemas, necesidades, oportunidades y métricas, así como preparar los elementos para el equipo.
<opiniónpolémica> Esto ya debería ser un evento oficial. </opiniónpolémica>
Negocio
No tener clientes y stakeholders
No tener claro el problema que vamos a resolver
El PO está solo en el refinamiento de negocio
#consejo Sí, alguien del equipo de desarrollo debería estar aquí para comprender el negocio.
Refinar ampliamente hasta los últimos micro detalles
No tener una métrica de negocio vinculada al elemento de backlog
#consejo En general, el refinamiento de negocio permite que el PO y el equipo comprendan mejor la demanda antes de crearla. Además de alinear las expectativas de los clientes, stakeholders y el equipo de desarrollo.
Técnico
No observar el DoR
No tener planes de acción sobre las dependencias que surgirán
Hacerlo con la persona de siempre
Queremos que todos los miembros del equipo se involucren con las dependencias técnicas y cómo resolverlas. La idea es evitar el aumento de dependencia del conocimiento técnico de 1 o 2 miembros del equipo.
#consejo El refinamiento técnico permite al equipo mitigar los riesgos y dependencias antes del sprint. Dejarlo para el momento de la planificación será demasiado tarde, el equipo no tendrá tiempo suficiente para resolver los impedimentos. Tener un buen DoR y observarlo con refinamiento técnico ayuda a que el trabajo sea más fluido durante el sprint.
DoD
Aquí el objetivo es garantizar la calidad.
Lista demasiado superficial
#consejo Intentad hacerlo lo más explícito posible. Por ejemplo: En lugar de “Seguridad de la información OK”, intenta “Lista de los 10 principales OWASP cubiertos”.
No tener en cuenta el escenario del equipo
Ser top-down
Entiendo que en muchos escenarios la organización necesita reglas y compliances, y está bien que se transmitan a los equipos a través de DoD, pero no pueden ser los únicas.
#consejo El equipo debe colocar los elementos que en su opinión tienen sentido para garantizar la calidad en su contexto.
Ignorar el DoD al mover al estatus Done
No actualizar
DoR
El objetivo aquí es mitigar los riesgos de sprint.
Lista demasiado superficial
#consejo Tienes que ser específico, evita cosas como: “¿Todo el equipo lo ha entendido?”. ¿Lo habéis comprendido de verdad? ¿Estáis seguros? De lo contrario, surgirán varias preguntas en medio del sprint. Exprésate, por ejemplo, de la siguiente manera: “Campos que se utilizarán, mapearán”, “Se necesita crear API, sí o no” y varias otras cosas específicas de día a día.
No usarla en el refinamiento técnico
No actualizar el DoR en la retrospectiva cuando sea necesario
Ser demasiado radical con los elementos de la lista
#consejo Recuerda que los elementos de esta lista son trade-offs explícitos sobre el riesgo. Si el elemento al que estáis renunciando puede generar un riesgo bajo para el sprint, quizás esté bien no seguirlo.
¿Ha faltado algo importante?
Comenta a continuación e intercambiemos ideas.
