Topics

Featured in Development

Understandability is the concept that a system should be presented so that an engineer can easily comprehend it. The more understandable a system is, the easier it will be for engineers to change it in a predictable and safe manner. A system is understandable if it meets the following criteria: complete, concise, clear, and organized.

Featured in Architecture & Design

Sonali Sharma and Shriya Arora describe how Netflix solved a complex join of two high-volume event streams using Flink. They also talk about managing out of order events and processing late arriving data, exploring keyed state for maintaining large state, fault tolerance of a stateful application, strategies for failure recovery, data validation batch vs streaming, and more.

Featured in Culture & Methods

Tim Cochran presents research gathered from ThoughtWorks' varied clients and projects, and shows some of the metrics their teams have identified as guides to creating the platform and the culture for high performing teams.

Scaling Agile with the Disciplined Agile Delivery Framework

The Disciplined Agile Delivery (DAD) framework is a process decision framework with end-to-end strategies for delivering solutions. According to Mark Lines DAD provides a foundation for scaling agile which can be used by small, medium, and large teams.

InfoQ interviewed Mark about the deploying the Disciplined Agile Delivery framework, how it support continuous delivery and DevOps, and how DAD relates to the Scaled Agile Framework (SAFe).

InfoQ: Can you give a brief description of the Disciplined Agile Delivery framework? What are the benefits that it can bring to enterprises?

Mark: Here is a definition of DAD: DAD is a process decision framework that provides a set of coherent, pragmatic, end-to-end strategies for how agile solution delivery works in practice. DAD is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value lifecycle, is goal-driven, is scalable, and is enterprise aware.

Essentially what this means is that DAD provides foundational guidance for extending simplistic methods such as Scrum to address a wide variety of contexts for enterprises and projects of all types and sizes. DAD recognizes that there is no silver bullet and that context really does count. As such you can think of DAD as “pragmatic agile” allowing you to adapt your approach for the context that you find yourself in. It does this by providing lightweight tailoring advice via its goal-driven strategy, more on this in a minute.

DAD is also free and relatively easy to learn and apply. Because teams find themselves in a variety of situations there are various DAD Lifecycles to choose from. This includes the basic agile lifecycle based on Scrum, the advanced lean lifecycle, the continuous delivery lifecycle, or the exploratory “Lean Startup” lifecycle. If you are using Scrum you could even say that you are using DAD, albeit a subset of the DAD agile lifecycle.

InfoQ: One of the key characteristics of the framework that you mentioned is "people first". Can you describe how the framework supports this?

Mark: The phrase “people first” is meant to remind us that without good teams of skilled and motivated individuals no process is going to be effective. As such DAD’s philosophy is consistent with the agile spirit of everyone pitching in to get the job done regardless of each individual’s specialty or formal role. People first principles include concepts such as providing the teams the support they need, allowing them to self-organize, providing the right type of work environment, and allowing them to focus on their commitments to their stakeholders.

To overcome the challenges associated with prescriptive methods such as Scrum, LeSS, and SAFe the DAD framework is goal-driven, providing guidance to help agile teams adopt strategies that enable them to work together effectively. The people-first goals are Form Initial Team, Grow Team Members, Fulfill the Team Mission, and Improve Team Process and Environment. Of course other goals such as Explore Initial Scope, Identify Initial Technical Strategy, Produce a Potentially Consumable Solution, and many more exist to address technical considerations. The goals and recommended strategies are described in detail in our book, as well as on the DAD Blog.

InfoQ: How do enterprises typically deploy this framework to scale agile? Can you give some examples?

Mark: Contrary to common belief DAD is not just about scaling. Indeed it is designed to be adaptable for small, medium, and large teams. We have recently published a lot of guidance on the DAD blog about scaling strategies with DAD. This guidance addresses topics such as how to organize teams at scale, how they need to be supported, how large initiatives affect the ways in which these teams need to work, as well as other scaling topics such as how to be effective with geographically distributed development.

Regarding rolling out DAD in scaling situations, as a process decision framework DAD provides complete flexibility to choose the lifecycles that make sense as well allowing the teams to optimize their process decisions without being prescriptive. Obviously some process decisions, such as integration or communication strategies will need to be consistent across teams.

InfoQ: What if you want to have a software development capability which delivers frequent and fast? Can you elaborate how the Disciplined Agile Delivery framework supports concepts such as continuous delivery and DevOps?

Mark: Continuous Delivery is one of the four DAD lifecycles. While it is fair to say that the most commonly used lifecycle is the basic agile (Scrum-based) lifecycle, where possible we encourage organizations to move towards the continuous delivery approach.

DevOps has been baked into DAD from day one. This guidance includes ideas such as recognizing “stakeholders” as a first-order role that includes production and support, not just customers. DAD describes the need to work with these stakeholders throughout the lifecycle so that there is minimal difficulty transitioning the solution to stakeholders and maintaining it in production. For this reason DAD recognizes that for non-trivial releases a Transition phase can be a useful thing. For teams that use the Continuous Delivery lifecycle the need for a Transition phase disappears in favor of a transition activity which has been fully automated.

InfoQ: How does the Disciplined Agile Delivery framework (DAD) and the Scaled Agile Framework (SAFe) relate to each other?

Mark: This is a very common question. DAD and SAFe are actually different, yet complimentary things. We think of SAFe as a pattern for attacking large-scale agile initiatives. Many of the process decisions are made for you using their pattern which some people might interpret as being prescriptive.

DAD on the other hand provides a number of strategies for scaling. For very large initiatives SAFe might indeed increase your chances of being successful by removing some of the decision making. However our experience indicates that the vast majority of initiatives are not at a scale that warrants the costly structural approach that SAFe recommends.

We are seeing many companies adopting DAD rather than SAFe due to the flexibility that it provides to deal with a vast array of organizational and team contexts.

InfoQ: Has the DAD framework evolved during the years that it has been around? Are there recent developments or upcoming extensions of the framework that you want our readers to be aware of?

Mark: Absolutely. It has matured significantly since the days when it was first introduced at IBM by Scott. IBM is no longer involved in the evolution of DAD as it is now owned by the Disciplined Agile Consortium (DAC). DAC is continually evolving the DAD framework, keeps the corresponding courseware up to date, and manages the disciplined agile certification program.

We are very excited about the new guidance that is being added specifically to address scaling in more detail. Some of the material has already been released and is available on the DAD Blog. I described some of the new material during my keynote in Brussels on January 22nd.