 |
Disciplined Agile Delivery
(DAD):
A Practitioner’s Guide to Agile
Software Delivery in the Enterprise
by Scott W. Ambler and Mark Lines, IBM
Press
|
 |
| |
|
|
Myself and Mark Lines of
UPMentors are currently writing a book about Disciplined Agile Delivery
(DAD) and we'd like your feedback.
Introduction to Disciplined Agile Delivery (DAD)
This book describes the Disciplined Agile Delivery (DAD) process framework in
detail, working through a case study to show how it can be applied in practice.
The DAD process framework has several important characteristics:
- People first. DAD team members should be self-disciplined and DAD
teams should be self organizing and self aware. The DAD process framework
provides guidance which DAD teams leverage to improve their effectiveness,
but it does not prescribe mandatory procedures. In DAD we foster the
strategy of cross-functional teams made up of cross-functional people (generalizing
specialists). There should be no hierarchy within the team, and team
members are encouraged to be cross-functional in their skill set and indeed
perform work related to disciplines other than their original specialty.
- Learning oriented. In the years since the Agile Manifesto,
we’ve discovered that the most effective organizations are the ones that
promote a learning environment for their staff. There are three key aspects
which a learning environment must address. The first is domain learning –
how are you exploring and identifying what your stakeholders need, and
perhaps more importantly how are you helping them to do so? The second is
learning to improve your process at the individual, team, and enterprise
levels. The third is technical learning, which focuses on understanding how
to effectively work with the tools and technologies being used to craft the
solution for your stakeholders.
- Agile. The DAD process framework adheres to and enhances the
values and principles of the Agile Manifesto. Teams following either
iterative or agile processes have been shown to produce higher quality,
provide greater return on investment (ROI), provide greater stakeholder
satisfaction, and deliver quicker as compared to either a
traditional/waterfall approach or an ad-hoc (no defined process) approach.
- Hybrid. 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. These sources include Scrum, Extreme Programming (XP), Agile
Modeling (AM), Unified Process (UP), Kanban, and several others.
- IT solution focused. The DAD approach will advance your focus
from producing software to providing solutions --which is where real
business value lies for your stakeholders. A fundamental observation is that
as IT professionals we do far more than just develop software. Yes, software
is clearly important, but in addressing the needs of our stakeholders we
will often provide new or upgraded hardware, change the business/operational
processes that stakeholders follow, and even help change the organizational
structure in which our stakeholders work.
- Full delivery lifecycle. DAD addresses the
project lifecycle from the point of initiating the project through
construction to the point of releasing the solution into production. We
explicitly observe that each iteration is NOT the same. Projects do evolve
and the work emphasis changes as we move through the lifecycle. To make this
clear, we carve the project into phases with light-weight milestones to
ensure that we are focused on the right things at the right time, such as
initial visioning, architectural modeling, risk management, and deployment
planning. This differs from mainstream agile methods, which typically focus
on the construction aspects of the lifecycle; details about how to perform
initiation and release activities, or even how they fit into the overall
lifecycle, are typically vague and left up to you.
- Goals driven. One of the challenges in
describing a process framework is that you need to provide sufficient
guidance to help people understand it, but if you provide too much guidance
you become overly prescriptive. As we’ve helped various organizations
improve their software processes over the years, we’ve come to believe that
the various process proponents are coming from one extreme or the other.
Either there are very detailed processes descriptions -- the IBM Rational
Unified Process (RUP) is one such example -- or there are very light-weight
process descriptions, Scrum being a perfect example. The challenge with RUP
is that many teams didn’t have the skill to tailor it down appropriately,
often resulting extra work being performed. On the other hand many Scrum
teams had the opposite problem with not knowing how to tailor it up
appropriately, resulting in significant effort spent reinventing or
relearning techniques to address the myriad issues that Scrum doesn’t cover.
Either way, a lot of waste could have been avoided if only there was an
option between these two extremes.
- Risk and value driven. The DAD process framework adopts what is
called a risk/value lifecycle; effectively, this is a light-weight version
of the strategy promoted by the Unified Process (UP). DAD teams strive to
address common project risks, such as coming to stakeholder consensus around
the vision and proving the architecture, early in the lifecycle. DAD also
includes explicit checks for continued project viability, whether sufficient
functionality has been produced, and whether the solution is production
ready. It is also value-driven, a strategy which reduces delivery risk, in
that DAD teams produce potentially consumable solutions on a regular basis.
- Enterprise aware. With the exception of start-up companies,
agile delivery teams don’t work in a vacuum. There are often existing
systems currently in production, and minimally your solution shouldn’t
impact them although your solution should leverage existing functionality
and data available in production. There are often other teams working in
parallel to your team, and you may wish to take advantage of a portion of
what they’re doing and vice versa. There may be a common vision which your
organization is working towards, a vision which your team should contribute
to. There will be a governance strategy in place, although it may not be
obvious to you, which hopefully enhances what your team is doing.
Enterprise awareness is an important aspect of self discipline because as a
professional you should strive to do what’s right for your organization and
not just what’s interesting for you.
The book is organized in following manner:
Part 1: Introduction to Disciplined Agile Delivery (DAD)
-
Chapter 1: Disciplined Agile Delivery in a Nutshell
-
Chapter 2: Introduction to Agile and Lean
-
Chapter 3: Foundations of Disciplined Agile Delivery
Part 2: People First
-
Chapter 4: Roles, Rights, and Responsibilities
-
Chapter 5: Forming Disciplined Agile Teams
Part 3: Initiating a Disciplined Agile Delivery project
-
Chapter 6: The Inception Phase
-
Chapter 7: Identify a Project Vision
-
Chapter 8: Identify the Scope
-
Chapter 9: Identify a Technical Strategy
-
Chapter 10: Initial Release Planning
-
Chapter 11: Forming the Work Environment
-
Chapter 12: Case Study: Inception Phase
Part 4: Building a Consumable Solution Incrementally
-
Chapter 13: The Construction Phase
-
Chapter 14: Initiating a Construction Iteration
-
Chapter 15: A Typical Day of Construction
-
Chapter 16: Concluding a Construction Iteration
-
Chapter 17: Case Study: Construction Phase
Part 5: Releasing the Solution
Part 6: Disciplined Agile Delivery in the Enterprise
-
Chapter 20: Governing Disciplined Agile Teams
-
Chapter 21: Scaling Disciplined Agile Delivery
-
Chapter 22: Adoption and Tailoring
-
Chapter 23: Overcoming Organizational Impediments
Part 7: Conclusion
Chapters 1 through 3 are currently available
here on Safari. We'll be posting chapters a few at a time, removing
access to earlier chapters as we go. Implication of that is that you'll
want to visit the site every month or so.
There are several ways to provide feedback:
- Please join the discussion on
Safari.
- Email either
myself or Mark (mark at upmentors dot com).
- For IBMers, we have an internal discussion forum on Lotus Connections
called Disciplined Agile Delivery book reviewers. Please email me
internally and I'll point you in the right direction. This group has
access to chapters earlier than what appears on Safari to get a first round
of feedback before going public.
We're firm believers in sharing the credit wherever we can. So, if you do
provide feedback that we act on we'll include you in the list of
acknowledgements in the preface.
