Introducing work-in-progress limits
In January this year, we (the NET-A-PORTER GROUP Product Management team) introduced work-in-progress limits to our software development process. For example, we have at most five items “in development” (including in code review) and four “in test”. An item in this case is a user story, bug fix or investigation task.
We added the work-in-progress limits as part of a Kanban-inspired move away from a fixed-iteration process to a continuous flow of work.
Work-in-progress limits were initially a bit controversial. Sometimes, we (the developers) said, “I’m not allowed to do any work”. In fact, there are several useful things that developers can do rather than start a new development task. Work-in-progress limits are one way to focus our attention on these other useful activities.
Benefits of work-in-progress limits
Fewer items in progress means that each gets more attention from the developer, tester or analyst working on it. This means we’re more likely to get the fine details right first time, reducing the number of times we have to revisit our work late in the process or after release.
Reduced waiting times
Because we look at ways to move the work already in progress forward before starting new work, items spend less time waiting for the next stage of the progress. For example, there’s not usually a queue of work that’s completed development but is waiting for testing. The result of this is to cut the cycle time (the time taken from starting to completing a piece of work). The aim is to cut the cycle time by cutting waiting – but not by cutting corners.
Reduced integration work
As a direct result of having fewer pieces of work in progress simultaneously, we have less integration work to do because it’s less likely that different team members will be changing the same code.
We have also reduced the amount of integration work indirectly by reducing the cycle time for development. Other teams can sometimes change the same code as we are changing and shorter the time from creating a new feature branch to completing the work, the less work we’ll have to do to integrating with changes introduced by other teams.
What developers can do when the development limit is reached
Imagine you’re a developer. You’ve just completed a piece of development work and moved it into the list of work for testing. When you look for a new story to work on, someone else has got there before you and we have reached the development work-in-progress limit. What can you do?
Help with support, release and integration
In the past, we’ve been so focused on our targets for completing stories by the end of an iteration that queries about operation, release testing and integration with other teams’ changes have seemed like an annoying distraction. We should deal with production problems as a high priority if our aim is to release useful business value – what’s the point in producing lots of new work if we don’t make sure it actually works in production?
- Investigate live issues.
- Investigate issues raised by release testing.
- Help other teams integrate our changes.
- Help to facilitate user acceptance testing for code that has passed testing within the team.
- Do some final checks and merge code that has passed testing to the upstream branch, ensuring that it builds and passes the automated test suite afterwards.
Help stories pass testing
Stories that we are testing within our team will need to be moved on before we can start new development. So we should make that a priority. This doesn’t necessarily mean developers doing testing.
- Fix bugs raised during testing
- Clarify requirements and technical constraints to help with test plan analysis
- Maintain the test environment
- Test another developer’s story (with the testers’ permission)
Help prepare stories in development for a smooth journey to “done”
Think about the story that you just finished development on. Are you sure it’s ready for testing? Is there anything else you can do to smooth its journey to completion?
- A bit more sanity checking.
- Improve coverage of the test suite.
- Add more documentation.
- Think about how we release, deploy and monitor this piece of development.
Can you help with any of the stories that are now in development?
- Review some code.
- Help another developer understanding the system or fix a tricky problem.
- Do some pair programming.
Identify and prepare future stories
- Log some technical debt or a bug for the team to solve in the future.
- Review some stories in analysis to help them pass smoothly through the development process.
Administration and clean-up
Maybe now is the perfect time to book a holiday, sign a form, file away some old notes, close old review requests and work tickets. It all makes it easier to focus on the work in progress when we’re busy.
Apply common sense – rules are made to be broken
If we’re at our limit for development and an urgent issue in production needs our attention, we will look at that and worry about the work-in-progress limits later.
We might also take a consensus view that it makes sense to break the limits in a non-emergency situation. With the work-in-progress limits in place, we’ll at least think about whether there’s anything else useful to do first.
We’ve already changed our work-in-progress limits several times as part of the process of finding the right level. We expect to change them again as we continuously improve and evolve our team.
Work-in-progress limits are a useful guide and reminder that there’s more to software development that just churning out code as quickly as possible. They can help us focus on rapidly delivering high-quality features.
When we reach the work-in-progress limit, it’s a great opportunity to help with another part of the process, improve the process itself or prepare future work for development.