Predictability in an Agile World

As agile methodologies have grown and evolved, one common challenge encountered is how to give the proper visibility and establish a degree of confidence regarding predictability.  There are many schools of thought tailored to different agile methods, but one observation I have made is most organizations adopt a flavor or mashup of a methodology.  A popular term many have used is “Scrumbanfall.”

This blog is not to debate the merit of pure methodologies nor discuss if mashups should or should not be leveraged, but rather to discuss a common problem observed outside engineering:

“How do other departments and functional groups increase their confidence in the predictability around when an agile project will be released?”

More specifically – a common “brand” I have observed from groups external to engineering is that it appears agile is a hall pass to predictability.  Fair or unfair this brand exists and needs to be owned and addressed.

Now there is basic blocking and tackling, which for an instance let’s assume is being addressed/worked on, such as getting units of work into small enough items that you are not trying to “back-of-the-napkin” estimate huge items without knowing what they are.  If you do not address this, then there is no magic bullet approach that will help you address this brand.

Assuming that you have a handle on the above, then how can you improve your predictability?

Strongly believing in self-organizing teams whereby the work streams and plans come from the project teams – a framework that has been working is the notion of Commit and Stretch.

Having more than a dozen development teams each with a variant flavor of Scrumban(fall) (which is tailored to the individual team and nature of the work) has required us to speak a common language around commitments.   It should be noted we essentially have release streams going out weekly.

The way we have been approaching this has been with the following guidelines:

1. Looking at a window of delivery (a month to 5 weeks) – teams look at the body of work they are undertaking
2. Not for every task/card, but for items that make sense from a communication perspective (i.e., to our Go To Market team, other dev teams), teams flag or highlight them as those that will be classified as Commit or Stretch
3. Of the body of work over the next 4-5 weeks, if teams are breaking things down as described enough – they are asked to Commit to about 75% of the work they look to address and the remaining 25% is identified as Stretch
4. Expectations from the teams are:
   1. First and foremost – always do right by our customers – don’t solve for % of delivery
   2. Given the above – teams should drive to 80%+ hit rate on their commits, and deliver stretch items ~25%
   3. Items that “pop up” within the work period, but are required, are called “in flight” and the expectation is, of course, if they are needed they will impact % complete

We have seen this help with transparency and confidence in our predictability.  Where we have come in with a lower % on commits is when:

• Work items are unknown/too big – teams commit to an item before knowing all it entails
• Assumptions are based on resources that are not made available
• Cross-team dependencies (i.e., a commit on one team is dependent on another team’s item, which is a stretch)

These are items that would impact regardless of the approach.

So … How are we doing?

Looking at our recent track record, adopting a commit/stretch framework, and empowering the teams to declare its commitment cadence has had a positive impact on our predictability.  Looking forward regarding how we plan to continue to improve our focus:

• If you have an item you want to commit to that has outbound dependencies, ensure the dependent teams are also committing to that item.  If not, you should declare this as a stretch.
• Teams that act as platform providers or centers of excellent should establish what amount of cycles they dedicate to ad hoc requests.  This then becomes a planned activity versus always showing up as an in-flight item.
• Smaller smaller smaller – Teams are continuing to focus on how to deliver value in smaller increments.
• Estimates – We are focusing on minimizing variance in estimates of items.  Planning up front should be commensurate with the task at hand.

In summary, there is always more work to be done than can be done – that won’t change.  However, empowering the teams to self identify what really needs to be done (commit) and what they’d like to get done (stretch), and giving the flexibility (not all commits need to be done) has been a valuable tool in helping our teams figure out when to dig in even more to get an item complete versus deferring it to be addressed another day.

Have a comment? We’d love to hear it!