THEAGILEDEPENDENCYWALL

AUTHOR: Allan Waddell Allan Waddell is the Chief Executive Officer of Kablamo. He has executed on-time, on-budget enterprise agile programs with as many 15 concurrent project streams, with CxO-level visibility of progress, and within business units of 400+ people.

Introduction In our Agile Series of articles, I’m sharing some of the techniques we use, that drive consistent Agile delivery. These articles are not intended to be exhaustive, rather an introduction to the theories and concepts we apply day to day.

At Kablamo, we often run complex multi-stream agile projects. ‘Multi-stream’ being a series of concurrent and often dependent projects (and work streams), being executed by a group of teams, under a single program.

Over the years, we’ve seen many ways to skin this cat. The most common approach, (particularly by businesses that are new to agile), is the implementation of the “mega wall.”

The “Mega-Wall” This wall is all things to all people, and often requires a “mega-meeting” to host the mega-wall standup.

This wall is easily identified by its elephant-like size - if you need to stand at 10 paces to view it in its entirety, you have a mega-wall. The mega-wall is usually covered in mega-cards, containing enough information worthy of a short novel. With this, comes the mega-time-suck required to update the mega-cards for the mega-wall so the mega-standup (only) takes an hour. (Tongue pressed firmly in cheek)!

Over-engineering the wall can result in involvement from team members who don’t need, or want, to be across every detail all the time (that’s the opposite of ‘agile’). Instead, team members should trust that items on the wall for the right reasons, and that the finer detail is being tracked within the relevant individual work stream. This level of trust between teams is particularly evident in affiliative leadership models (unfortunately, the same inter-team trust doesn’t thrive so well in classic command and control environments).

Less is More - The Dependency Wall In our experience, the old adage still applies - less is more.

Instead of the mega-wall, the key messages we extract into a simpler view, are cross-stream dependencies. If you want to add only one valuable ceremony to your regular Agile practice, we strongly recommend this:

A Dependency Wall (as the name describes), is devised to communicate project dependencies. Specifically, we use it to track the following:

1. What cross-stream dependencies exist? - These are classed as potential risks or blockers.
2. When will the dependencies be complete? - So they don’t block other streams.
3. If a blocker dependency arises, what is the ripple effect across the dependent work and tickets?; and finally,
4. Are our dependencies on track? If not, there’s a clear view via the wall of the impact, and the Iteration Manager (or Scrum Master) can consider mitigation plan.

The dependency wall has these characteristics:

1. Y axis represents work streams;
2. X axis represents sprints;
3. Cards represent when dependencies are due to be complete;
4. Key milestones/release dates are marked up

Fig. Actual Dependency Wall used with client

The Dependency Wall requires a ceremony similar to an individual stream stand-up, typically managed as follows:

1. Facilitated by a Program Manager, Tribe Leader, or Delivery Manager;
2. Attended only by the Iteration Managers (or Scrum Masters) and Product Owners;
3. The facilitator walks the wall, team by team, work stream by work stream;
4. Each Iteration Manager talks only about dependency tickets that have changed in their stream;
5. “Pairs” (ie, the dependent and dependency) are clearly labelled with the simplest (most relevant) unique name, and are normally colour-coded for ease of tracking;
6. The stand-up is only 5 - 15 minutes (even for a very large program of work); and
7. It happens, religiously.

CAVEATS:

• If an Iteration Manager or leader requires more information about a specific stream, they should engage in the separate stream standup directly;
• If a broader, and more senior stakeholder group is interested in a centralised program status update, we host a supplementary Sprint In Progress (SIP) meeting fortnightly, or weekly, depending on sprint length and urgency of deliverables. (We will share the format and requirements of the SIP in a subsequent article).

We always appreciate feedback. Feel free to share your thoughts on use of the agile dependency wall.