A Hybrid Process Framework

DAD is the formulation of many strategies and practices from both mainstream agile methods as well as other sources. The DAD process framework extends the Scrum construction lifecycle to address the full delivery lifecycle while adopting strategies from several agile and lean methods. Many of the practices suggested by DAD are the ones commonly discussed in the agile community—such as continuous integration (CI), daily coordination meetings, and refactoring—and some are the “advanced” practices commonly applied but for some reason not commonly discussed. These advanced practices include initial requirements envisioning, initial architecture envisioning, and end-of-lifecycle testing to name a few.

The DAD process framework is a hybrid, meaning that it adopts and tailors strategies from a variety of sources. A common pattern that we’ve seen time and again within organizations is that they adopt the Scrum process framework and then do significant work to tailor ideas from other sources to flesh it out. This sounds like a great strategy. However, given that we repeatedly see new organizations tailoring Scrum in the same sort of way, why not start with a robust process framework that provides this common tailoring in the first place? The DAD process framework adopts strategies from the following methods:

• Scrum. Scrum provides an agile project management framework for complex projects. DAD adopts and tailors many ideas from Scrum, such as working from a stack of work items in priority order, having a product owner responsible for representing stakeholders, and producing a potentially consumable solution every iteration.

• Extreme Programming (XP). XP is an important source of development practices for DAD, including but not limited to continuous integration (CI), refactoring, test-driven development (TDD), collective ownership, and many more.

• Agile Modeling (AM). As the name implies, AM is the source for DAD’s modeling and documentation practices. This includes requirements envisioning, architecture envisioning, iteration modeling, continuous documentation, and just-in-time (JIT) model storming.

• Unified Process (UP). DAD adopts many of its governance strategies from agile instantiations of the UP, including OpenUP and Agile Unified Process (AUP). In particular these strategies include having lightweight milestones and explicit phases. We also draw from the Unified Process focus on the importance of proving that the architecture works in the early iterations and reducing much of the business risk early in the lifecycle.

• Agile Data (AD). As the name implies AD is a source of agile database practices, such as database refactoring, database testing, and agile data modeling. It is also an important source of agile enterprise strategies, such as how agile teams can work effectively with enterprise architects and enterprise data administrators.

• Kanban. DAD adopts two critical concepts—limiting work in progress and visualizing work—from Kanban, which is a lean framework. These concepts are in addition to the seven principles of lean software development, as discussed in Chapter 2.

The concept of DAD being a hybrid of several existing agile methodologies is covered in greater detail in Chapter 3, “Foundations of Disciplined Agile Delivery.”

Our Apologies Throughout this book we’ll be applying agile swear words such as phase, serial, and yes, even the “G word”—governance. Many mainstream agilists don’t like these words and have gone to great lengths to find euphemisms for them. For example, in Scrum they talk about how a project begins with Sprint 0 (DAD’s Inception phase), then the construction sprints follow, and finally you do one or more hardening/release sprints (DAD’s Transition phase). Even though these sprint categories follow one another this clearly isn’t serial, and the Scrum project team clearly isn’t proceeding in phases. Or so goes the rhetoric. Sigh. We prefer plain, explicit language.