Otra estrategia para escalar Scrum: Disciplined Agile Delivery (DAD)

La semana pasada vimos una recopilación de las estrategias más conocidas a la hora de escalar Scrum en empresas grandes. Y este tema es uno de los que se tratan en el programa de formación online en agilidad de 233 Grados de TI.
Y Disciplined Agile Delivery (DAD) era una de las estrategias que faltaba por explicar más a fondo.

¿Qué es Disciplined Agile Delivery (DAD)?

DAD fue creada por Scott Ambler durante sus años en el departamento de metodologías de IBM.
Es un framework “híbrido”: se basa en los principios ágiles, y combina prácticas extraídas de Scrum, XP, Kanban, Lean y sobre todo conceptos de DevOps (Vayamos al grano, ¿qué es eso de DevOps? ) y entrega y despliegue continuo (¿qué es eso de integración, entrega y despliegue continuos?)
El objetivo de DAD es ayudar a las empresas a implantar los valores y principios ágiles no solo en desarrollo software, sino desde la definición de requisitos, pasando por el desarrollo, hasta el despliegue del software y contacto con el cliente.
Para hacer esto, DAD parte de la premisa de que no todas las empresas son iguales y no todas las prácticas van a ser igual de útiles en todas las empresas. Por eso DAD se basa en establecer una serie de metas que hay que cumplir, pero no te dice cómo debes cumplirlas, sino que te da varias estrategias para cumplir dichas metas y consejos para que decidas qué estrategia funcionará mejor en tu empresa.
Por ello DAD no es prescriptivo. Por ejemplo, mientras que Scrum te indica que la única estrategia para gestionar los requisitos es el Product Backlog, DAD te propone varias estrategias. Mientras que otros métodos ágiles promueven un solo tipo de ciclo de vida del software (iterativo e incremental por ejemplo), en DAD puedes elegir tomar uno de entre varios ciclos de vida (de momento existe un ciclo basado en Scrum, uno Lean, un ciclo de vida con entrega continua y uno que lo llaman exploratorio).
Como último ejemplo, en desarrollo para DAD es necesario mejorar la calidad del código (meta). Como consejos para conseguirlo te proponen refactorizar código, refactorizar la base de datos, establecer estándares de codificación comunes, aceptar ciertos tipos de deuda técnica, etc.
Además, a diferencia de SAFe o LeSS, que sí se declaran como frameworks para escalar Scrum, el concepto de DAD como tal no solo implica Scrum, ni solo sirve para escalarlo en grandes empresas. De hecho, la tendencia es que empresas pequeñas y medianas también tomen consejos de DAD.

Ciclos de vida y DAD: “Ciclos de entrega ágiles”

Este tema de los ciclos de vida es algo que me ha llamado mucho la atención de DAD. Disciplined Agile Delivery dice que debes establecer un ciclo de vida de principio a fin, desde la concepción de la idea y requisitos, hasta la salida del software al cliente, con tres etapas diferenciadas:

– Comienzo (inception): Fase muy cortita de preparación, antes de comenzar a desarrollar. Aquí entrarían temas de definición de requisitos, planificar releases, etc. En Scrum, a esta fase se le suele llamar Sprint 0.
DAD está orientado a las personas, cosa que se muestra por ejemplo en que en esta fase están incluidos temas como construir un equipo multifuncional y autoorganizado, darle la formación que necesite, etc.
– Construcción (construction): Fase de desarrollo en sí. Al terminar tendremos listo una solución software que puede pasar al cliente. Aquí si decidimos utilizar Scrum, tendremos iteraciones o sprints; si usamos un enfoque lean, un flujo continuo de trabajo, etc.
– Transición (transition): Despliegue de la solución a producción, formación de los stakeholders, demos, etc.
Ojo, no te confundas. DAD es ágil, no es cascada. Además de tener estas fases, los ciclos propuestos por DAD suelen ser iterativos, incrementales o ambos. De una manera u otra, se acaban entregando periódicamente pequeñas soluciones al cliente.
Imagínate que decides que a tu empresa le viene bien seguir solamente Scrum. DAD te propone que además de tener tus sprint, hagas una fase de planificación previa (que también cuente en las estimaciones, en la planificación de la release) y que tengas en cuenta después el tiempo y recursos necesarios para realizar el paso a producción.
Si quieres saber más sobre los ciclos de vida que propone DAD, te aconsejo que le eches un vistazo a esta página.

Escalando la agilidad con DAD.

En cuanto a escalar la agilidad con DAD en una gran empresa, cabe destacar que este framework promueve los principios de DevOps, y entre ellos, que haya visibilidad en toda la organización, conciencia de equipo y ayuda común a distintos niveles: a nivel de equipo, departamento, organización, etc.
Por otra parte, en DAD, existen distintos factores que influirán a la hora de elegir cómo escalar la agilidad en una empresa: el tamaño del equipo, si los equipos son distribuidos o no, el grado de criticidad del software, la complejidad técnica, etc.
Factores con los que estoy de acuerdo, y una propuesta muy innovadora de DAD, al contrario que por ejemplo SAFe.

En función de estos factores DAD, te da consejos. Por ejemplo, diferentes formas para organizar equipos pequeños (con distintos roles), equipos grandes, etc.

Para saber más…

Tanto si quieres escalar la agilidad como si no, la verdad es que DAD es un buen sitio de donde tomar ideas. Para mí el libro que lo resume (Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise) y la web www.disciplinedagiledelivery.com son una fuente de recursos muy interesantes.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
• Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
• Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024