Ken Schwaber y Jeff Sutherland definieron un artefacto muy importante en el Scrum: la definition of "Done" (DoD), en español la definición de "Hecho". El objetivo de la DoD es describir de forma muy clara para el equipo Scrum cuáles son las condiciones necesarias para que un elemento del backlog (normalmente escrito en formato de historia de usuario) se considere hecho.
Cuando el elemento está hecho, en principio, no hay más tareas que hacer. En empresas que utilizan buenas prácticas de DevOps como la entrega continua, la única actividad por hacer debería de ser que el Product Owner (PO) presione un botón y mande todo el incremento de producto a los clientes.
Nosotros versus ellos
Desgraciadamente, a lo largo de los años, creamos especialistas y ponemos a esos especialistas en distintas unidades dentro de la organización. Como consecuencia, tenemos silos difíciles de deshacer: Desarrollo, Pruebas, Banco de Datos, Producción, Middlewares, Arquitectura etc.
Jerarquía organizativa reforzando los silos de especialistas.
El resultado común en diferentes empresas son discursos como «está hecho, solo falta que lo pruebe el equipo de pruebas»; «está hecho, solo falta que los de bus de datos permitan la llamada»; «está hecho, solo falta que los del banco de datos apliquen un script». Mi favorito: «está hecho, solo falta integrarlo».
Integración Tardía
Un equipo ágil es multidisciplinario. Esto significa que deben componerlo personas que tengan todas las habilidades y autorizaciones necesarias para que una necesidad de negocio se transforme en producto y la entregue en mano al usuario.
¡Compruebe las próximas formaciones de la Knowledge21!
¿Cuál es el problema del «solo falta...»?
Vamos a decir que el Equipo Azul, muy implicado, trabajó con ahínco durante la Sprint y consiguieron «entregar» cinco elementos que probará el Equipo de Calidad. Por algún motivo, imaginamos que los de Calidad cogerán nuestro encargo, lo pondrán en su backlog, que está vacío, y en algunas horas recibiremos el resultado de las pruebas.
Situación Imaginaria
Situación genial, pero falsa. Normalmente, cuando se da este paso del bastón de entrega, encontramos otros equipos atascados con tareas por hacer. Además de eso, tenemos un problema de priorización. Lo que es muy importante para el Equipo Azul, puede ser la cosa menos prioritaria para el Equipo de Calidad, que está recibiendo «entregas» de otros equipos distintos.
Situación real
Sepa que este problema se repite para cada equipo que utiliza para completar la frase «está hecho, solo falta...». El atraso inducido por las dependencias es exponencial.
Sprint de Pruebas
No, no, no y no. No existe Sprint de Pruebas separada del desarrollo. La Sprint debe englobar todas las tareas necesarias para que su producto esté hecho para facilitárselo al cliente. Separar la Sprint en partes creará reflujo de trabajo, falta de visibilidad, poca previsibilidad de la entrega y además reforzará la idea de subequipos dentro del equipo (nosotros versos ellos interno). Pregúntese: ¿por qué estamos haciendo Sprints separadas? Llega a la causa raíz del problema y resuélvela.
Reflujo en el trabajo, causando problemas.
¿Y cómo salgo yo de este embrollo?
Visibiliza y no escondas los problemas
En el caso de que tu entrega de valor al cliente dependa de personas externas al equipo, no escondas esa dependencia. Visibiliza este aspecto y da transparencia al proceso. Diseña todas las transiciones necesarias en la cadena de valor de tu producto. Barrer el problema para debajo de la alfombra traerá efectos terribles a largo plazo.
Transparencia en la Tabla de Tareas. Las dependencias externas se visualizan y se marcan en rojo.
Me gusta utilizar la siguiente analogía. Imagina que te has roto el brazo. La solución para ese problema es trabajosa. Buscar un médico, hacer una radiografía, inmovilizar el brazo durante semanas, incluso operar. Estás tremendamente ocupado y no tienes tiempo para esto, así que decides tomar solo un medicamento para el dolor. Con el tiempo el dolor aumenta y tú estás ya tomando morfina, pero te niegas todavía a ver la situación real del problema y sigue tomando acciones puntuales y temporales. Cuando todo se vuelva insoportable podrá ser demasiado tarde.
Definition of Transition (DoT)
Al poner un cuadro en la pared, define cuáles son las condiciones necesarias para que un elemento del backlog avance en las etapas del proceso. Para cada columna de su cuadro, puedes hacer una pequeña definición de transición. Utilizando como ejemplo la imagen anterior, podríamos tener las siguientes DoT:
• Desarrollo.
- El código-fuente del programa está versionado
- Las pruebas automatizadas garantizan la cobertura necesaria
- El código fue revisado por otro
- El producto está aprobado en el 100% de las pruebas automatizadas
• Equipo de Calidad
- Aprobado por el e Equipo de Calidad
- No hemos encontrado ningún bug impeditivo, crítico o relevante
• Equipo de Seguridad
- Aprobado en las pruebas de vulnerabilidad
- No hemos encontrado ningún bug impeditivo, crítico o relevante
- Logs de auditoría añadidos
• …
Fíjese en que la suma de sus DoT ayudó a componer su DoD.
Métricas para tomar como base en los debates
Jamás entres en una reunión con el discurso: «yo creo que...». Esto solo te va a desgastar políticamente sin necesidad. Utiliza métricas como Customer Lead Time, System Lead Time, Waiting Time, Cost of Delay para cimentar este tipo de debate.
Mejora continua
En reuniones como las ceremonias de Retrospectiva, saca los retos que hacen que los equipos sean incapaces de hacer la entrega de punta a punta. En algunos casos, puede ser necesario que tengas que subir los niveles de la jerarquía organizativa para resolver el problema. Haz esto siempre basándote en números y demostrando las consecuencias de los retos propuestos.
Equipos multidisciplinarios
¿Por qué no tenemos todas las competencias necesarias para hacer una entrega de punta a punta? Las respuestas a dicha pregunta deben ayudar a crear estrategias concretas que transforme los equipos en equipos multidisciplinarios.
Algunas otras preguntas que pueden ayudar al equipo a diseñar las acciones: ¿cuáles son las competencias que no tenemos y que necesitamos? ¿Tenemos personas interesadas en desarrollar esas competencias? ¿Qué silos deben romperse para tener un equipo al 100%? ¿Cuál es la competencia que no tenemos y que más impacta en nuestra entrega? Y así un día tras otro.
Autorización
«Modificar una tabla en el banco de datos. Bien. Para eso necesitas: rellenar el formulario A-35. B-57 y D-3, tener la firma de tres administradores de Nivel 1, abrir una solicitud de cambio, certificar una firma en la notaría, dar siete vueltas a la Plaza de la Catedral andando para atrás, tener la bendición del Papa...»
En muchas empresas lo que retrasa la entrega no es la falta de competencias en el equipo, sino la falta de autorización para hacer el trabajo necesario. Las respuestas que deben guiar las estrategias concretas deben venir de preguntas como: ¿por qué no tenemos autorización para hacer tal cosa (sé específico)? ¿Qué traumas tuvieron lugar en el pasado y llevaron a esa falta de autorización?
Trabajo por parejas
«¡Ah! Pero no todo el mundo sabe hacer el trabajo que hace el Equipo de Pruebas / Seguridad / etc.».
Trabaja en parejas para que el conocimiento sobre prácticas, tecnologías y el contenido se difunda entre los miembros del equipo o sea traído al equipo. El trabajo por parejas es una forma excelente para la constante transformación del conocimiento del equipo y una práctica para estimular la colaboración.
Práctica de DevOps
Muchas empresas aún poseen unidades enteras para ejecutar procesos manuales y burocráticos que, si no son automatizables al 100%, pueden ver su burocracia reducida significativamente por automatización. Busque la forma de utilizar prácticas como pruebas automatizadas, integración continua, entrega continua, versionamiento, TI escalable etc.
Definición Real de Hecho
No estoy creando un artefacto nuevo. Solo proponiendo que la Definición de Hecho del equipo debería incluir todo el trabajo necesario para que la única cosa que quede entre la entrega del equipo de desarrollo y la entrega del producto a manos del cliente sea una decisión de negocio y nada más.
Si su producto debe ser aprobado por el dueño de la empresa antes de ponerlo a disposición del cliente, entonces esa aprobación debe incluirse en la Definición de Hecho. Si se exige un manual del usuario, entonces la escritura y puesta a disposición del manual deben estar en la Definición de Hecho. Si la entrega debe aprobarse en pruebas de seguridad, entonces el Aprobado en las pruebas de seguridad debe componer su Definición de Hecho.
Haga que la Definición de Hecho de su equipo cumpla su propósito y describa exactamente las condiciones necesarias para que el cliente reciba el producto que necesita.
