Introduction to Disciplined Agile Delivery describes how the team develops the first release of a mission-critical application while working in a legacy enterprise environment. It describes their experiences from beginning-to-end, starting with their initial team initiation efforts through construction and finally to deploying the solution into production. It also describes how the team stays together for future releases, overviewing their process improvement efforts from their Scrum-based beginnings through to a lean continuous delivery approach that fits in with their organization's evolving DevOps strategy.
The DAD framework is a hybrid of existing methods such as Scrum, Kanban, Agile Modeling, SAFe, Extreme Programming, Agile Data, Unified Process and many others. DAD provides the flexibility to use various approaches and plugs the gaps not addressed by mainstream agile methods. In a nutshell, DAD is "pragmatic agile." DAD describes proven strategies to adapt and scale your agile initiatives to suit the unique realities of your enterprise without having to figure it all out by yourself.
At 102 pages, you should find this book to be a quick, informative read.
Table of Contents
Here's an overview of what each chapter covers:
Chapter 1: Introduction. This chapter provides a quick overview of the book and a brief history of Disciplined Agile.
Chapter 2: Reality over Rhetoric. This chapter explores several common myths - that agile teams don't do upfront planning, that DAD is simply "WaterScrumFall" in disguise, that governance is a dirty word, that DAD is complex and disruptive to adopt, and that SAFe is THE solution to scaling agile - and more importantly disproves them.
Chapter 3: Disciplined Agile Delivery in a Nutshell. This chapter provides a brief yet comprehensive overview of the DAD framework. It describes the DAD roles; explores how DAD is a hybrid framework combining great ideas from a variety of agile and lean sources; how DAD supports a full end-to-end delivery lifecycle; how DAD supports several lifecycles (a Scrum-based lifecycle, a lean lifecycle, a lean start-up lifecycle, and a continuous delivery lifecycle) to support the myriad of teams in modern enterprises; how DAD is easily tailorable via its goal-driven approach; how DAD teams are enterprise aware, thus helping them to work more effectively with the rest of your organization; and how DAD provides a solid foundation from which to scale.
Chapter 4: Introduction to the Case Study. The majority of the book works through a case study of a disciplined agile team within a large financial institution that is building a customer facing application. This chapter introduces us to the team, describes the market opportunity that they hope to address, and describes the environment in which they're working.
Chapter 5: Inception. This chapter works through the team's initiation efforts. This includes how they go about initial requirements modeling and planning with their stakeholders in a streamlined manner, initial architecture modeling, setting up their physical work environment, setting up the start of their tooling infrastructure, initial risk identification, and finally securing stakeholder support and funding for the rest of the first release.
Chapter 6: Construction Iteration C1. During the first construction iteration/sprint the team struggles through, and starts to overcome, a few common challenges experienced by teams new to agile. These challenges include taking on too much work that iteration, daily coordination meetings that go too long, how to test early in the lifecycle, how to take a continuous integration (CI) approach to development, and insufficiently detailed requirements.
Chapter 7: Construction Iteration C2. This iteration goes a bit smoother for the team. The team begins to make improvements based on their retrospective from the previous iteration. More importantly they reach their second risk-based milestone, Proven Architecture, by delivering working end-to-end software that implements technically complex functionality. This greatly reduces the risk faced by the team.
Chapter 8: Construction Iteration C3. After two successful iterations where the team delivered a potentially consumable solution to their stakeholders, they get a spike of new requirements in a look-ahead analysis session. To meet their deadline the team works with the stakeholders to identify the functionality they must have this release versus functionality that could potentially slip to a future release. Due to improved testing and fixing, throughout the iteration the team finds they have less hardening work at iteration end.
Chapter 9: Construction Iteration C7. The team starts to put the scaffolding in place to automatically deploy into demo and pre-production testing environments. The team's regression test suite has improved over time as team members pick up testing skills from the tester embedded on the team. The team has been keeping the deliverable documentation up to date via the practice of continuous documentation. The delivery date for the first release is agreed to with stakeholders, based on the team's actual velocity producing the working, consumable solution.
Chapter 10: Construction Iteration C10. The focus of this iteration is on implementing a handful of high priority functionality and on final hardening of the solution. Parallel independent testing in their pre-production testing environment has enabled the team to identify potential issues that had escaped their whole team testing efforts. Part of their hardening efforts is the finalization of training materials for the upcoming training of support/help-desk staff.
Chapter 11: Transition. The two-week transition "phase" focuses on final testing and fixing, training the support/help-desk staff, finishing a few short end-user "how to" videos, and deploying the solution into production.
Chapter 12: Future Releases. This chapter overviews the team's improvement efforts over the next few releases, describing how they evolve from the agile Scrum-based lifecycle to a leaner approach and eventually to continuous delivery.
Chapter 13: Closing Thoughts. This chapter overviews the disciplined agile resources that are available to you.
Appendix: The Disciplined Agile IT Department. This short appendix overviews our ongoing work on the Disciplined Agile framework to address the full scope of an IT department. This includes activities such as People Management, Product Management, Portfolio Management, Program Management, Enterprise Architecture, Disciplined DevOps, Operations, Support, Release Management, Data Management, Continuous Improvement, IT Governance, and Reuse Engineering.
Buy this Book - Amazon Canada
Buy this Book - Amazon U.S.
Buy this Book - Amazon U.K.
© 2015 Scott Ambler + Associates