Understanding SAFe Work In Progress Limits
What is WIP?
WIP stands for Work In Progress. Limiting your work in progress is a concept of Scaled Agile Framework or SAFe. By limiting your WIP, you force your team to focus on completing existing tasks before starting new tasks or requirements in the project.
Let’s start with an analogy: the “honey-do list”.
Its Friday afternoon, and the weekend starts. Your significant other has several requests for work around the house for the weekend. Some of these are short tasks that must get done by Monday morning, (take garbage to the street), some are very intensive and require dedicated time (mowing the grass), and some may take course over the entire weekend (doing several loads of laundry). We’ve all been there and done it. We only the weekend to do these things and only have 2 days to complete these tasks (a time box).
Thus you get started. One load in the washer, you mow the front grass until lunch. After lunch, you start painting that wall that looked so out of date. You are reminded about a cookout you agreed to go to, and so on, and so on. When Sunday night comes, you look at your to-do list.
- You only mowed the front yard, not the back ( got distracted by painting the wall)
- You’ve washed 2 loads of laundry, but only dried one load.
- The wall was primed, but did not get painted.
- …and 6 other tasks you started, but did not finish
Thus, most of your honey-do list is unfinished, even though you’ve done a bunch of work on every task. Bottom line: you’ve got no customer (spouse) facing value to show for your hard work because its all unfinished.
If we had limited our todo list so that we only had 3, or 4 or 5 tasks in progress at any one time, Sunday evening might have looked like this:
- Yard Mowed (done)
- Laundry (done)
- Wall painted (not started)
- Garbage taken to street (done)
- 3 other items (done)
- 5 other items (not started)
Thus, you could show you delivered on several items during this time box. That is value that can be realized by the customer (your spouse).
How can it help my application development team?
You have several different types of people on your team: database developers, UI developers, Java developers, business analysts, testers, etc. Multi-tasking has proven to be inefficient through numerous studies**. Instead of cramming every requirement into a single release, focus your team so they have a limited number of items to work on. If one member finishes his or her task early, then have them focus on helping a team mate complete their tasks. This means that your team can shift roles a bit: perhaps the tester, who is not very busy at the beginning of the iteration can help the business analyst work on finalizing requirements. In the middle of the project, the business analyst can help the tester rough out test cases. The developers can help both if they are not overloaded. This helps to ensure higher quality software delivery, with more tangible value delivered by a due date.
From the perspective of your customer, if you can release a series of requirements you will have delivered value and met a deadline. They may not notice, or care that lower priority requirements were not delivered. For them, they have something tangible they can work with.
This requires that you are regularly grooming your requirements (your todo list), and prioritizing them accordingly. If this sounds familiar, then it should. This is similar to David Allen’s Getting Things Done methodology, or the Franklin Covey productivity solutions (neither of which have anything to do with software development). Yes, the same concepts, when applied to software development deliver better productivity for your team.
How can I visualize WIP?
The best way to view this is a Kanban chart. You can create this on a team whiteboard in your office with post-it notes. This ‘war room’ type of Kanban chart works fine for teams that are wholly co-located. However, recent studies show that as little as 1/3 of agile development teams are co-located. Thus, if a team member can’t walk into the office to visualize the board, you’ll need some other method to keep them in sync.
Our team works extensively on Team Concert, which has a fantastic Kanban board feature. This supports SAFe 4.0 (and 4.5 with some minor tweaks). In the example below, we have a sprint Kanban that anyone from any region in the organization can see, and interact with. All data is up to date so everyone can see the same version of the truth, not some time-delayed, let-me-poll-the-team-report.
Configuring the limit is easy. On the Kanban board, just edit the view using the drop down next to the “View As Kanban Board”. Then add your WIP limit accordingly. The image below shows it configured just for “In Progress” status items. Team Concert has multiple work item types and can show these all in the same Kanban view. Thus you can visualize different layers of abstraction of the project: Just tasks for the sprint team, just Stories for the scrum master and managers, or just defects for the QA team.
Team Concert is part of an overall Collaborative Lifecycle Management solution.
**References
How (and Why) to Stop Multitasking
