By Nick Butler
Tags: Agile , Development
Sometimes less is more. That’s certainly the case with work in progress (WIP). This case study shows how a project team went about reducing WIP to limit risk. It shows how having less work in progress meant more work was completed, and completed to a higher standard.
This is the final post in my guide to Project risk management with Agile. It shows how we can apply in the real world the approaches detailed in my post on limiting work in progress to manage project risk.
We were working on a storehouse of digital assets for a public sector agency. Our client used this collection of images, videos and other resources to communicate and enable the positive change the agency was set up to deliver.
This was the second phase of work on the project. The tool had been live for a year, giving the Product Owner the chance to learn from users. She knew how the tool could be made easier to use, and so more effective.
The Product Owner had an in-depth understanding of the tool and the desired outcomes, based on what she’d learned from actual users. She was also very clear what would deliver these outcomes. In fact, she was an excellent Product Owner in all ways but one: she only had limited time that she could devote to the role. This puts a great deal of pressure on the Product Owner, and on the project as a whole. In our experience, having an “available” Product Owner is crucial for a successful project.
Work was specified in user stories on this project. Because of the Product Owner’s unavailability, the developer was not getting the feedback he needed to complete his stories. He was also not getting stories checked when he put them up for acceptance. As a result, he had to pick up new stories before he completed the earlier ones. Some stories were dependent on others and, when the original story was blocked, this created a cascade of blocked stories. The developer’s work in progress ballooned.
This “thrashing” between stories resulted in regular context switching, with the inefficiencies this produces. Each time the developer picked up a new story he needed time to become familiar with the requirements. Then, when he returned to a story after getting the feedback he needed, he had to re-familiarise himself with his work so far.
The time lost to context switching was making it harder to complete the stories he had committed to within the Sprint. He no longer felt able to devote time to refactoring the code. He was also cutting back on the number of tests he was writing. Both these factors created risks to the quality of his work. As a craftsman committed to creating quality software, he found this very stressful.
In order to have working software to demonstrate at the Review, he merged his unchecked stories on a temporary branch. While this gave him a product that could be reviewed, it also meant that issues were only identified at the Review. Moreover, some of these issues resulted from integrating unchecked work. As a result, the Product Owner had to create new stories to resolve these issues. This delayed completing other stories from the backlog.
So reducing WIP was going to be a key way to limit risk relating to time and quality.
Because the team visualised their work on a Scrum board, the build-up of work in progress was immediately apparent. When every story in a Sprint sits in the In-progress column, you know it’s time to limit WIP!
In this case, we couldn’t just set hard WIP limits because work would have ground to a halt. We needed to address the root cause.
To do this, our Scrum Master sat down with the Product Owner and explained the problem. She immediately understood the impact of her limited availability. While she couldn’t increase her overall availability, we did identify three ways to limit WIP and so reduce the risk that the project would run over time or deliver work that didn’t meet our quality standards.
We did this by:
The Product Owner brought in a number of “assistant Product Owners” to pick up the load when she was not available. Unfortunately, they didn’t have the level of product knowledge needed to progress the stories, so this didn’t have the desired impact.
This was a good example of following the INVEST criteria for Agile user stories. The “I” in INVEST stands for “independent”. We made a special effort to avoid dependent stories, and this certainly stopped the cascade of blocked stories we’d had in the early Sprints.
While the product owner couldn’t be available all the time, she could ensure she made the most the availability she had. She and the developer booked in set days each Sprint during which they would work together to make sure stories were completed. She would dedicate this time to resolving issues and accepting stories.
Having days dedicated to reducing WIP proved effective. While the developer still had switch between stories in the lead-up to these days, knowing that there was a plan in place to get the stories to “Done” removed much of the stress. It also limited context switching for the Product Owner. She was now able to immerse herself completely in the project for extended periods. And working face-to-face meant that she could answer questions and resolve issues in real time.
Get more practical tools for limiting work in progress.
Perhaps not surprisingly, having a clear focus on completing more stories meant that more stories were completed.
In fact, the project completed all the stories in the backlog and finished early. This meant the developer was able to add extra value. He upgraded versions of the software they were using and refactored the code to make sure it was clear, clean, concise and ready for another developer to pick up later.
At the end of the project, the Product Owner took the developer out for lunch. Over their meal, she talked about her plans for phase three. Because of their work reducing WIP to limit risk, they’d managed to get a new, improved version in front of users. The learnings that would guide the next phase were already underway. And the users were already finding it easier to access the digital assets that they needed to drive positive change.
| Guidance | Case studies & resources |
|---|---|
| Introduction to project risk management with Agile | Agile risk management checklist — check and tune your practice |
| Effective prioritisation | |
| Reduce software development risk with Agile prioritisation | Reducing risk with Agile prioritisation: IntuitionHQ case study |
| Increasing transparency | |
| How Agile transparency reduces project risk | Risk transparency: Smells, Meteors & Upgrades Board case study |
| Limiting work in progress | |
| Manage project risk by limiting work in progress | Reducing WIP to limit risk: Blocked stories case study |
| Reducing batch size | |
| How to reduce batch size in Agile software development | Reducing batch size to manage risk: Story splitting case study |
