Disciplined Agile Delivery in a Nutshell
- Context Counts-The Agile Scaling Model
- What Is the Disciplined Agile Delivery (DAD) Process Framework?
- People First
- Learning Oriented
- Agile
- A Hybrid Process Framework
- IT Solutions over Software
- Goal-Driven Delivery Lifecycle
- Enterprise Aware
- Risk and Value Driven
- Scalable
- Concluding Thoughts
- Additional Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
- For every complex problem there is a solution that is simple, neat, and wrong.
- —H L Mencken
The agile software development paradigm burst onto the scene in the spring of 2001 with the publication of the Agile Manifesto (www.agilemanifesto.org). The 17 authors of the manifesto captured strategies, in the form of four value statements and twelve supporting principles, which they had seen work in practice. These strategies promote close collaboration between developers and their stakeholders; evolutionary and regular creation of software that adds value to the organization; remaining steadfastly focused on quality; adopting practices that provide high value and avoiding those which provide little value (e.g., work smarter, not harder); and striving to improve your approach to development throughout the lifecycle. For anyone with experience on successful software development teams, these strategies likely sound familiar.
Make no mistake, agile is not a fad. When mainstream agile methods such as Scrum and Extreme Programming (XP) were introduced, the ideas contained in them were not new, nor were they even revolutionary at the time. In fact, many of them have been described in-depth in other methods such as Rapid Application Development (RAD), Evo, and various instantiations of the Unified Process, not to mention classic books such as Frederick Brooks’ The Mythical Man Month. It should not be surprising that working together closely in collocated teams and collaborating in a unified manner toward a goal of producing working software produces results superior to those working in specialized silos concerned with individual rather than team performance. It should also come as no surprise that reducing documentation and administrative bureaucracy saves money and speeds up delivery.
While agile was once considered viable only for small, collocated teams, improvements in product quality, team efficiency, and on-time delivery have motivated larger teams to take a closer look at adopting agile principles in their environments. In fact, IBM has teams of several hundred people, often distributed around the globe, that are working on complex products who are applying agile techniques—and have been doing so successfully for years. A recent study conducted by the Agile Journal determined that 88% of companies, many with more than 10,000 employees, are using or evaluating agile practices on their projects. Agile is becoming the dominant software development paradigm. This trend is also echoed in other industry studies, including one conducted by Dr. Dobb’s Journal (DDJ), which found a 76% adoption rate of agile techniques, and within those organizations doing agile, 44% of the project teams on average are applying agile techniques in some way.
Unfortunately, we need to take adoption rate survey results with a grain of salt: A subsequent Ambysoft survey found that only 53% of people claiming to be on “agile teams” actually were. It is clear that agile methods have been overly hyped by various media over the years, leading to abuse and misuse; in fact, the received message regarding agile appears to have justified using little or no process at all. For too many project teams this resulted in anarchy and chaos, leading to project failures and a backlash from the information technology (IT) and systems engineering communities that prefer more traditional approaches.
Properly executed, agile is not an excuse to be undisciplined. The execution of mainstream agile methods such as XP for example have always demanded a disciplined approach, certainly more than traditional approaches such as waterfall methods. Don’t mistake the high ceremony of many traditional methods to be a sign of discipline, rather it’s a sign of rampant and often out-of-control bureaucracy. However, mainstream agile methods don’t provide enough guidance for typical enterprises. Mature implementations of agile recognize a basic need in enterprises for a level of rigor that core agile methods dismiss as not required such as governance, architectural planning, and modeling. Most mainstream agile methods admit that their strategies require significant additions and adjustments to scale beyond teams of about eight people who are working together in close proximity. Furthermore, most Fortune 1000 enterprises and government agencies have larger solution delivery teams that are often distributed, so the required tailoring efforts can prove both expensive and risky. The time is now for a new generation of agile process framework.
Figure 1.1 shows a mind map of the structure of this chapter. We describe each of the topics in the map in clockwise order, beginning at the top right.
)
Figure 1.1. Outline of this chapter
Context Counts—The Agile Scaling Model
To understand the need for the Disciplined Agile Delivery (DAD) process framework you must start by recognizing the realities of the situation you face. The Agile Scaling Model (ASM) is a contextual framework that defines a roadmap to effectively adopt and tailor agile strategies to meet the unique challenges faced by an agile software development team. The first step to scaling agile strategies is to adopt a disciplined agile delivery lifecycle that scales mainstream agile construction strategies to address the full delivery process from project initiation to deployment into production. The second step is to recognize which scaling factors, if any, are applicable to your project team and then tailor your adopted strategies to address the range of complexities the team faces.
The ASM, depicted in Figure 1.2, defines three process categories:
- Core agile development. Core agile methods—such as Scrum, XP, and Agile Modeling (AM)—focus on construction-oriented activities. They are characterized by value-driven lifecycles where high-quality potentially shippable software is produced on a regular basis by a highly collaborative, self-organizing team. The focus is on small (<15 member) teams that are collocated and are developing straightforward software.
- Agile delivery. These methods—including the DAD process framework (described in this book) and Harmony/ESW—address the full delivery lifecycle from project initiation to production. They add appropriate, lean governance to balance self-organization and add a risk-driven viewpoint to the value-driven approach to increase the chance of project success. They focus on small-to-medium sized (up to 30 people) near-located teams (within driving distance) developing straightforward solutions. Ideally DAD teams are small and collocated.
- Agility@scale. This is disciplined agile development where one or more scaling factors apply. The scaling factors that an agile team may face include team size, geographical distribution, organizational distribution (people working for different groups or companies), regulatory compliance, cultural or organizational complexity, technical complexity, and enterprise disciplines (such as enterprise architecture, strategic reuse, and portfolio management).
)
Figure 1.2. The Agile Scaling Model (ASM)
This book describes the DAD process framework. In most cases we assume that your team is small (<15 people) and is either collocated or near-located (within driving distance). Having said that, we also discuss strategies for scaling agile practices throughout the book. The DAD process framework defines the foundation to scale agile strategies to more complex situations.