Raising the Waters PDF Print E-mail
Written by Ed Willis   
Tuesday, 02 August 2011 18:41

Defects or features?Imagine a product team of seven people. They work together to develop new releases of their product while simultaneously supporting the released versions in the field. Year after year, they get solidly positive feedback on the quick turn-around they provide on customer-reported issues. Historically the team released new product versions about once a year but in the months following their adoption of Scrum they improved their productivity while increasing the pace of their releases to around one per quarter. A significant problem the team has encountered along the way is meeting Sprint commitments in an environment where the amount of support work needed for customers is tricky for them to forecast. Sound familiar? There’s got to be a very large number of us in this position or something close to it. This post is about how this common situation can be hard to manage in Scrum because of the difficulty accounting for support demand in Sprint planning and how an unusual application of the analogy of the lake and the rocks analogy from Lean can help.

The team chose a one week Sprint duration because they wanted to use the retrospective cycle to put their learnings into practice quickly. Again a fairly common approach. Over the course of the first four months of their Scrum adoption, though, they found that support requests caused no end of trouble with their Sprint commitments. Some weeks no requests come in and the team does everything it committed to and ends up coming back to the table for more work. Other weeks, though, support requests spike and the team is unable to deliver against its commitments. Their problem is depicted in the graphic below showing completed story points delivered for each weekly Sprint of the four months – the picture seems to tell the story of a team that can’t plan its way out of a paper bag.Story points per week

I’ve seen this situation played out any number of times – really all that’s required is a product development team that’s also responsible for supporting released product and has a desire to support their customers as capably as possible. I had a small internal tools team, for example, that was in precisely this position. They released new versions of their products every Sprint but also had to deal with high priority issues from their users as they arose. I saw this also in a services group that provided demand-driven coaching at the same time as they did other work more amenable to planning. I suspect many of us can recall similar situations.

In lean thinking, the analogy of the lake and rocks is used to help guide teams towards exposing impediments and ultimately increasing the pace at which they deliver value to their customers. Here’s how Craig Larman and Bas Vodde describe it in their wonderful book “Scaling Lean and Agile Development”:

“The depth of the water may represent the inventory level, batch size, iteration length, or cycle time. When the water is high (large batch or inventory size, or iteration length), many rocks are hidden. These rocks represent weaknesses. For example, consider an eighteen-month sequential release cycle with a massive batch transfer; inefficient testing, integration, and poor collaboration are all hidden below the surface of such a long cycle and such a large batch. But if we work with that group and ask, ‘Please deliver a small set of features that is potentially shippable in two weeks, every two weeks,’ then suddenly all the ineffective practices become painfully obvious. “
The lake and  the rocks

In our example, the team lowered the water level with their one week Sprints and exposed the problem that they have trouble doing both feature work and support at the same time. This is a weakness given their current planning model because it impedes their ability to deliver their planned work on time, but note that, from a customer’s point of view, the situation is still pretty rosiy – the customer is getting both timely defect fixes and new features with regularity (much more so than the team was able to previously before adopting Scrum). They want to improve but their options would appear to be limited. There is no one else to do the support work – so this small team must do it somehow. They are reluctant to go to their customers with a message anything like “we will handle your support requests as soon as our current Sprint ends” as they are justifiably proud of the reputation they’ve developed as a team that’s very responsive to customer needs. One possibility – doing pure lean software development and treating both features and defects as work to be done within a lean software development process – seems interesting but they would like to continue their Scrum adoption because of the other benefits they’ve realized. In the end, they consult their release burndown and notice that, while the delivery of story points per Sprint is very erratic week to week, if they take the same data and aggregate it into four week intervals, it’s clear that team delivery is much more regular month to month. This makes sense, because while the arrival rate of individual new support requests may be hard to predict with great precision, the arrival rate of the next N such requests will be more regular.

Story points per monthRealizing this, the team decides to increase the length of their Sprints to four weeks and finds that they are much more able to deliver against their commitments while simultaneously handling support requests from the field. The longer Sprints give them enough breathing room to deal with short-term bursts in support work while leaving enough time to successfully deliver their Sprint commitments.

From a lean perspective, though, they raised the water level to “hide” the problem of supporting released product impeding their ability to deliver new features to their customers.

Were they in any sense wrong to do so?

Consider it again from the perspective of the customer. The team’s Scrum adoption has resulted in increased delivery of product both in terms of releases per year and in terms of features per unit time – all while not giving away any of the team’s ability to address high priority issues as they arise. From a project stakeholder’s perspective, the adjustment of the Sprint length has resulted in an increased predictability in team delivery.

Raising the waters seems to have been a good choice for them given where they found themselves.

In general, I’d agree that lowering the waters is a reasonable goal for any product development team – reducing cycle time has powerful benefits including increased agility, more effective product development process, and increased pace of learning but I wouldn’t hesitate to suggest raising the waters if, as was the case in this example, a team found their current development process unreliable given the current cycle time. In particular, for a team that has to absorb a significant amount of difficult-to-forecast, demand-driven work, raising the waters by increasing cycle time may be a way to help the team deliver their commitments reliably because doing so aggregates this less plannable work in larger batches which are less likely to see wild swings in total amount.

What do you think?

I’d like to thank Selaine Henriksen for her help in developing this post.


Last Updated on Wednesday, 04 April 2012 15:29