DoD (Definition of Done), una responsabilidad que no es solo del equipo de Desarrollo

Hace unos días estuve con mi familia observando la carrera de la Formula E (toda una experiencia recomendada, por cierto) y, en el lugar en el que estábamos, nos encontramos con un amigo desarrollador que trabaja en una importante organización del sector bancario en este hermoso país en el que me encuentro actualmente. Después de varias conversaciones sobre la carrera automovilística que estábamos presenciando, se me dio por preguntarle como iban las cosas en su lugar de trabajo y si se había repetido una situación como la que vivieron en dicha organización meses atrás, y de la que habíamos conversado en otro espacio.

Para ponerte un poco en contexto mi querido amigo lector, en aquella ocasión, nuestra conversación fue por un problema que se había presentado luego de un paso a producción que realizo el equipo en el que mi amigo se encontraba (ya fue reasignando a otro equipo). En ese entonces (según me comentó), no solo el equipo en el que él estaba, sino toda la organización, estaba en pánico. Dado que tres días antes, el equipo implementó una nueva funcionalidad en la aplicación de dicha organización, la cual apuntaba a fortalecer un servicio critico que presta la organización. Los primeros días (según el análisis de seguimiento sobre la funcionalidad) mostraban que al parecer la nueva funcionalidad fue bien recibida. Incluso mejor de lo esperado (según me comentaba).

Sin embargo, al tercer día surgió la noticia de que la aplicación tenía una violación de seguridad, la cual fue detectada en la nueva funcionalidad implementada. Datos personales e información de los producto de los clientes estaban expuestos a cualquier persona. Sin duda una mala noticia para el producto, pero también malo para la organización (si se hacía pública), la cual podía recibir una fuerte multa por este tipo de violaciones de datos y sin mencionar, el daño a la reputación que sufriría la organización.

Según me comentaba mi amigo, al detectar esto (como es normal) se realizó una reunión de crisis, con el equipo completo, junto con el Director de Tecnología, el Product Manager, un representante de seguridad y otras personas (me indicó que nunca había visto), presenciaron dicha reunión, en la cual el Director de Tecnología preguntó:

«¿Cómo puede ser que no hayamos previsto esta violación de datos?»

Un compañero de mi amigo, integrante del equipo de Desarrollo dijo: «No sabíamos que debíamos tener esto en cuenta».

Sorprendido, el Director de Tecnología respondió: “Somos una institución financiera. Tener presente este tipo de cosas, debe estar en nuestro ADN”

Entonces el Scrum Master manifestó: Tenemos un definición of Done (DoD) que indica que “Un producto solo debe ser liberado cuando se cumple el DoD” y somos muy estrictos en esto. Sin embargo, sobre lo que esta presentando el problema, no tenemos nada en él.

A lo que una persona del área de seguridad dijo: «¿Cómo es posible que esto (lo que se debió controlar), no esté en Definition of Done (DoD)? Estas reglas de protección de datos son vitales «.

En ese momento de la conversación con mi amigo, le manifesté la siguiente pregunta: ¿Quién o quienes definieron el contenido del Definition of Done?, a lo que me indico que el equipo de desarrollo y el PO. Acto seguido le indique que quizás el problema, tenga que ver con el hecho de que el Definition of Done (DoD), es creado solo por el equipo de Desarrollo incluso con la ayuda del PO. Lo cual en su momento no me entendió, pero luego de manifestarle mis argumentos al respecto (los cuales te expongo mi querido amigo lector en este post), llegamos a un buen acuerdo.

Este mi querido amigo lector, no es el único caso que conozco. Ya que, en los últimos años, he podido conocer casos similares, en donde por una incorrecta definición del Definition of Done, organizaciones completas han tenido problemas similares. Por lo cual, te planteo entonces mi punto de vista.

El Definición of Done (DoD), NO es una responsabilidad única del equipo de desarrollo y del PO. De hecho, si revisamos por ejemplo la guía de Scrum, vemos que hay un fragmento vital, que a menudo es pasado por alto por coaches, scrum master y hasta desarrolladores, el cual dice:

“Si la definición de “Terminado/hecho” (DoD) para un incremento es parte de las convenciones, estándares o guías de la organización, al menos todos los Equipos Scrum deben seguirla. Si “Terminado/hecho” (DoD) para un incremento no es una convención de la organización, el Equipo de Desarrollo del Equipo Scrum debe definir una definición de “Terminado/hecho” apropiada para el producto.”

Los equipos de desarrollo pueden ampliar la definición de «Terminado/hecho» (DoD), agregando elementos adicionales en la parte superior de la convención. Pero comienza con la convención de organización, según lo indica la guía:

«El Equipo Scrum planifica formas de aumentar la calidad del producto mejorando los procesos de trabajo o adaptando la definición de «Terminado/hecho» (DoD), si corresponde y no está en conflicto con los estándares del producto u organización».

Es decir, mi querido amigo lector, que el Definition of Done, debe ser algo organizacional en el que participen los diferentes actores que hacen parte (ya sea de forma directa o indirecta) de los proyectos que lleva la organización, para así tener una visión mas global.

Algo que veo muy a menudo, es que los equipos de desarrollo crean su propio Definition of Done (DoD) y lo ajustan incluso a sus propios intereses o a su silo. Es decir, algunos ni siquiera consideran en el Definition of Done a los QA y peor aún, rara vez hay una alineación entre los diferentes equipos que puede llegar a tener un proyecto más grande, un Art (Agile release Train – Concepto de SAFe, una tribu, o un Squad. Algo que sin duda puede llegar a ser considerado un anti-patrón.

Es importante que la organización avance, ayudando a los equipos con un Definition of Done sólido y global. Este DoD puede incluir todo tipo de reglas y regulaciones de la organización, como los problemas de cumplimiento mencionados en la historia de lo que le paso a mi amigo.

Estoy seguro de que alguien podría decir, “Pero en agile buscamos formar equipos autoorganizados». Lo cual es verdad. Sin embargo, hay una limitación a lo que un equipo puede decidir hacer. No pueden ignorar las convenciones, reglas o restricciones organizacionales o incluso de negocio. Y estas deben incorporarse en el Definition of Done de los equipos. Por lo tanto, un equipo de desarrollo no puede dejar de lado estas cosas solo por el hecho de considerarse «autoorganizado».

Por lo tanto, mi querido amigo lector, mi invitación es que, como organización, se definan Definition of Done adecuados, globales y que sirvan de base para que los equipos de desarrollo los complementen según su contexto. Dado que, un Definition of Done (DoD) incompleto o una desalineación en los DoD de los Equipos Scrum, puede resultar en grandes problemas para la organización y/o sus clientes. Ahora bien, incluso en el día a día, es importante que todos comprendan lo mismo, cuando un incremento de producto está «Listo/terminado/hecho». Esta transparencia es vital para un entorno Complejo.

Gracias por tu tiempo.

Pd:Te invito a dar un vistazo a mi libro recomendado del mes (Clic Aquí)

Saludos,

Referencias:

  • Scrum Guide 2019

También te puede interesar Leer



SUSCRÍBETE A MI BLOG

Y cada vez que realice una nueva publicación, recíbela al instante.


    
Suscríbete al Blog
Y entérate cada vez que realice una nueva publicación.
Suscribirse
Te puedes dar de baja cuando lo desees!
close-link
A %d blogueros les gusta esto: