Disciplined Agile Delivery
I spent some time in the past month working with a group of people in an IT department helping them with tools and process around Agile development. I’ve done this any of a number of times but what was unique about this team is that they recognized early in the process (before I was even on the scene) that they wanted an Agile process framework that was not just designed for the software construction phase of a project. They wanted something that helped them with the entire delivery process for a given project (be it software, hardware or something else). This was a very interesting to me as I have often given thought to how Agile could be applied to the broader project delivery cycle rather than just to the construction phase. What they were adopting was a new Agile framework called Disciplined Agile Delivery (DAD). I think it has a lot to offer.
Your average Agile project
If you think about it, the process for the average Agile project using a common framework (E.G. Scrum) will almost invariably have some number of modifications tacked on to it to support the things that the basic process isn’t very good at. How often have you heard people say “We use a modified Agile/Scrum process” or “We always start with Sprint 0 in order to gather some early project requirements” or “We always run some sprints at the end just around testing and deployment”. All of these statements are indicators that the chosen process framework (in this case Scrum) is being augmented to take additional things into account. Scrum, for instance, expects some sort of tangible deliverable at the end of every sprint, things like Sprint 0 don’t really fit the framework as well as one would like. Wouldn’t it be better if the framework itself were structured to support full end-to-end delivery of the project?
Disciplined Agile Delivery is just that, its an Agile process framework that pulls from a variety of other Agile frameworks in order to create a framework that is designed around full end-to-end delivery of a project. Furthermore, DAD is designed not just for traditional software delivery but also for more generalized IT projects. DAD explicitly acknowledges that there will be 3 phases of any project: inception, construction and delivery. It expects, for instance, that the inception phase will have requirements gathering, architectural modeling, proof of concept creation, etc. This makes a tremendous amount of sense to me when compared to other frameworks which typically still end up doing these sorts of things but don’t really acknowledge that they are doing so.
DAD is also designed to be a flexible framework that allows each implementation to vary according to the needs of the project or team. Need 3 weeks for the inception phase and only a week for delivery on this project? Sure, that’s fine. Only need 5 hours for the inception phase of this other project? That’s fine too. It’s a framework, not a set of rules. It also derives from a wide variety of other Agile frameworks so that it can be made to fit the needs of most organizations. Just to name a few Agile methodologies it draws from: Scrum, eXtreme, Agile Modeling and Kanban are all in there.
What about tools?
Since DAD draws from so many other popular methodologies, the same tools that are popular for Agile projects today can be used for DAD projects. The construction phase of a DAD project, for instance, looks very much like a Scrum process so your favorite Scrum tool should work just great. Collaborative tools built around shared knowledge and collaborative decision making work very well for the conception phase. The team I was working with this month adopted the Atlassian suite for nearly all aspects of the process and it was working very well for them. I can already see some ways things could be improved but the basis toolset fit quite nicely. The Atlassian tools are also built more on a framework than as vertical/unchangeable tools so I the toolset itself can grow and mature as the team itself matures around DAD.
OK, where do I learn more?
If this sounds interesting to you. If you, like me, have always wondered why Agile has never quite fit the full end-to-end needs of IT projects then I’d encourage you to go to the Disciplined Agile Delivery site and read more. I’ve done that as well as worked my way through this book, not because I had to, more because DAD seems to solve a problem I’ve wrestled with for years. Its interesting stuff and it feels to me like a real step forward in the evolution of Agile as it spreads beyind the boundaries of smaller scale software projects.