Here we introduce the Agile Delivery Model that we use to drive delivery across our business. Like most models, it is not perfect, but we believe it is useful. It illustrates the focus areas that a team may have over time—often simultaneously—and provides context for the plays and practices described in the rest of this playbook.
Our intentions are to show that delivery is the the majority of our work and that successful delivery is built on a foundation of alignment and preparation.
To truly put this model into action, refer to the plays and practices
We’ll describe these focus areas in broad strokes. To truly put this model into action, refer to the details captured in the plays and practices.
We must have a clear understanding of who we are and what we’re trying to build.
With this focus, we cultivate relationships with our stakeholders and users. Together, we build a shared understanding of the project vision, goals, values, and expectations. We often employ chartering sessions to build product roadmaps and user personas, and capture strategic themes.
We also create our team working agreements—how we will work together. These identify how we’ll communicate, resolve conflict, and have fun, among other things, and we’ll establish technical expectations, such as coding standards and our definitions of done.
This is a dominant focus area during a project’s first several days (but no more! We want to align quickly, and get to delivering as quickly as possible). While our teams begin with this focus, we realize that this is not only important during project startup. Teams may need to re-align throughout the life of a project when significant change occurs.
Once we are clear on who we are and what we’re here to do, the team needs to come together to get a look ahead, and prepare enough to get started.
With this focus, we build, estimate, and groom our Product Backlog. We put some thought into architecture. We sketch out a few sprints’ worth of work—three months or so. Here, we’re trying to understand the things we will do soon. We accept that we are fuzzy on things we’ll be doing a few months from now, and that time spent planning these things now is possibly waste. Because software development is primarily highly-creative knowledge work, we have to do it to understand it. We continually discover. It is difficult to pull together a 12-month master schedule – if we did, it would probably be wrong in a matter of days. We embrace this truth instead of fighting it.
In addition to doing just-enough planning, we generally invest some time in our infrastructure and tooling. We want to make sure we can get from a commit to a build quickly. Let’s smooth our deployment process so it’s not a pain when time is tight.
This is where the rubber meets the road, so to speak.
With this focus, we transform the needs of their users into valuable, tested, potentially shippable software. Generally, we follow small Plan-Do-Check-Act cycles. In the Delivery section of this playbook, we expand on several popular agile delivery frameworks, and when we use them.
When we are delivering, we build; we test; we keep designing; we keep talking to users. We inspect and adapt. We do this as much as we need to, until we are done. Any team members that are not actively delivering something for the current sprint are helping the team get ready for the next sprint.