2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns – Half-Day Sessions
2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- April 11, 2018
- Rants
WIP stands for work-in-progress. It’s a fundamental concept in queuing theory, which has become a central part of Lean Software Development.
Some of us like to work on several projects at once. It feels like we’re getting a lot of things done sometimes but often that’s not really the case. Work-in-progress means that we have several things we have to attend to and so we round-robin our time and attention to address these multiple things.
The problem with having multiple pieces of work in progress is that there is a ramp-up time to get re-familiar with the task after we’ve abandoned it to work on a different task. How much time do we lose re-familiarizing ourselves with tasks? The answer varies but it could be as significant as half of all our time is spent getting back up to speed on projects that we dropped.
Of course, we can’t make perfect progress on every task all the time and when we’re blocked and waiting for something that we depend on, such as an external library or an answer to a question, we don’t just want to do nothing. Having other tasks that we can work on at these times is a good use of our effort.
Limiting work-in-progress is so critical that Lean defines waste in software as any work started but not yet finished. Based on this definition the Waterfall approach of building to a release is enormously wasteful.
Writing software is not like assembly line work. You can’t just pick up where you left off. There is an enormous amount of details that we have to keep track of when we build software, so getting back up to speed on a project can take a lot of time and effort.
Sometimes managers ask developers to work on several tasks at once. Perhaps they have critical knowledge of a certain technology or are the most senior person on the team. But I often find that as we start slicing these people’s time up they get less efficient. After all, we are only human.
In situations like these, I like to take out what I call my WIP whip. No, it’s not a physical whip but rather a mental one. It’s about imposing WIP limits so that no more than one, two or three tasks can be juggled by any one person at a time. I know managers who assign their top developers to up to eight projects within a single iteration and then they wonder why these developers aren’t getting all of their work done. Task switching is expensive.
For this very same reason, we say that you shouldn’t change directions on a team in the middle of an iteration because it pretty much invalidates everything that was done in that iteration. Instead, wait a week or two until the iteration is finished and then introduce new work. Even if what’s currently being worked on may not be used it’s still advisable to wait until the iteration ends before changing tasks because it’s very frustrating to be told that a task being worked on is no longer valuable.
I find that the very best teams limit their work-in-progress and that’s one of the main ways that they get more efficiency in what they do.
Previous Post: « The Power of Continuous Integration
Next Post: What’s Agile Software Development? »