This comes from cobbling together the best parts of all my experiences being a participant in, and consulting or coaching, program deliveries. By “program”, assume that there was more than one team involved requiring coordination and collaboration across boundaries AND there are multiple related “projects” occurring in parallel.
I’ll group my thoughts across 5 stages:
- Starting the program;
- Planning integrated releases / launches;
- Regular tracking / reviews;
- Launching;
- Transition
The biggest problem when starting programs is false agreement
There was an image that Luke Barrett created that we used a lot at ThoughtWorks to explain the problem of false agreement. Jeff Patton has a version of it here:
I also like the way the Toyota/Lean community describes this:
The general idea is that people avoid conflicts early which just leads to greater problems later rather than embrace conflict early to have smoother progress later. This is essentially the Early Pain principle that competent Agile practitioners follow.
The essence of the solution for false agreement is Starting Together. I’ve done this in two main ways:
- Inception
- Pilot teams
Agile Inception / “Quickstart”
The basic idea of an Agile Inception is to use a series of workshops to rapidly come to a shared understanding of the goals, target high-level architecture, and ways of working such that we can immediately transition to delivery once Inception is done. Google Design Sprints are similar but target a different context and seem to have a narrower scope.
Jonathan Rasmussen has a simple version of an Inception Deck here (and in his Agile Samurai book) which is pretty close to an older version that Rob Gibson originally created at ThoughtWorks Australia. Later on, we shifted to using a set of Inception Method Cards (inspired by IDEO’s Method Cards) to select and dynamically shuffle-in activities as relevant.
The rule of thumb at ThoughtWorks used to be 1 week per 3 months of delivery but that was coming in cold with limited to no context AND we needed to be more wary of overcommitting with contractual agreements. I’d expect the timing can be shorter with ongoing context and more trusting relationships. Use your judgment.
Pilot team / “Think It Squad”
A pilot team approach can either be an alternative to, or a follow-up to, an Inception. Spotify called these “Think It Squads”.
Membership of the pilot team should be representatives from all the key teams/areas needed to deliver the program. The goal is the same as the Inception. Reach shared agreement and/or flesh out shared agreement on goals, architecture, key interfaces, ways of working, and structure. The difference is that we’ll do this by building things together rather than doing workshop activities.
Pilot teams typically split up after reaching shared agreement (aka Conquer and Divide) but they can sometimes convert into a longer-running team.
Release / launch planning
There are a few key problems to consider when planning releases/launches:
- how to deal with fixed dates (regulation, specific calendar events (i.e., Christmas, end-of-year, some external event, etc.));
- how to deal with multiple stakeholders with competing needs;
- how to deal with dependencies to enable parallel development;
- how to identify and agree on the incremental integrated releases
Right-to-left Planning
This is only applicable when there is a fixed time constraint (which you generally want to avoid, but it does happen).
Basically, start from the target date and work your way backward. As the critical path(s) become apparent, make sure to protect them with backup options. Given people typically go left-to-right when mapping out schedules, working backwards is called “right-to-left”.
See also the Last Planner System from the Lean Construction Institute.
Buy a Feature / Fixed allocation
This is only applicable when you have multiple stakeholders with competing needs AND the overhead of resolving conflicts on-demand during delivery will be too high.
Buy a Feature comes from Luke Hohmann’s Innovation Games. Different features / stories are given “prices” and stakeholders are able to “buy” what they want using a limited amount of “money” that reflects the available capacity. I liked using a variant of this using poker chips.
Buy a Feature is essentially a version of fixed allocation. Each stakeholder group is given a portion of the available capacity and they work out themselves what they want to use it for. This isn’t theoretically optimal but practically tends to dramatically reduce the amount of time spent arguing over priorities.
Contract Tests
We’ve identified interfaces to allow parallel development. How can we trust that the interface contract will hold? Contract tests are more trustworthy than an ambiguous verbal promise. It also becomes clear what kind of changes need to be communicated (breaks contract tests) versus what doesn’t (doesn’t break contract tests).
Back-and-forth dialogue / “Catchball”
Especially if there is no Inception, and sometimes even if there is, it’s necessary to negotiate commitments to dependencies. Some of this can be addressed with Contract Tests (expected behaviour) but some cannot (delivery timing).
The worst way I’ve found to do this is to just assume people agreed to your dependencies. The best way I’ve found to do this is back-and-forth dialogue (aka “catchball”).
Use maps
One of the reasons why I dislike pretty much every program/project management tool is that they make it difficult to create an overall visual representation of the entire program. An overall map helps when determining incremental, integrated releases and also doubles as a way to track progress.
The maps I’ve found most useful are User Story Maps, wireframes organised in terms of user journeys, Parking Lot Charts from Feature Driven Development), architecture diagrams. What works best really depends on the specific context.
Tracking / regular review
At a minimum, some kind of regular delivery sync should happen. How often depends on how long you’re comfortable potentially going off track. Also, a less frequent, steering committee sync.
Daily check-ins can be useful. These can be asynchronous. They should not be loyalty tests.
Optimally, you’re doing regular end-to-end integration checkpoints. Don’t trust status reports, trust integrated system tests.
I’ve never seen fancy tracking tools matter. Simpler, visual tracking tools are generally more effective.
At a minimum, maintain a decision log. This should include product, architecture, and process decisions. Better yet, use decision records.
Launch
Every time I’ve seen production release coupled to marketing launch, there were a lot of unnecessary coordination problems created. Decouple production releases from marketing launches.
Finishing together is really about closing the loop, both in terms of assessing whether or not desired outcomes were achieved and also in terms of celebrating the people who participated in enabling the launch to happen.
Transition
If ownership of product capabilities and/or systems will shift after launch, embed representatives from the owner teams during the delivery to smooth the transition. Waiting until launch to start handover activities is almost always too late.
