modules at the same time, or work on two sets of documentation at the same time. When you work on two tasks at the same time you aren't really multi-tasking, you are context switching. When you reduce the amount of WIP in the system you will reduce "inventory" (think of it as the amount of unsold work that is sitting in the warehouse half-assembled). By reducing inventory you are limiting the number of bottlenecks that can occur, meaning your cycle time (the amount of wall clock time needed to move a piece of work from "started" to "done") should improve.
DevOps improves upon Kanban's notion of WIP by also removing needless work out of the system. In DevOps you should always ask the question, "Is this work really needed?" It might have been needed last week but not this week, so we should eliminate that work. Outcomes are what matters, not the process, controls, or the work you complete. We need to protect the company by not putting meaningless work into the system. To use the manufacturing analogy again, if you have partially completed work as inventory then you'll find your inventory depreciates as it gets older and is no longer desirable by your customers. In this case the money you spent partially assembling that inventory is wasted. This is sometimes considered "just-in-time manufacturing" and the equivalent in our industry is "just-in-time" software engineering.
Here is a classic example of work that was needed but isn't anymore. A new security patch is released for your DBMS version. You add it to the backlog but a few months pass before you have bandwidth to work on regression testing the patch. In the interim a new DBMS version is released that you want to upgrade to and it does not require the patch. If you eliminate the work required to test the patch and simply apply that time to the DBMS version upgrade, then you've eliminated work. It's even worse if you started regression testing the patch but didn't have time to fully complete it. That time would've been wasted.
DevOps is particularly concerned with this because we know we can eliminate a lot of operational work if we spend some time automating upfront by assigning dev resources to work with ops guys. In this case we've eliminated work that isn't needed from the system.
"Stop starting and start finishing"
...is an aphorism that sums up wip limits quite well. Obviously there are times when you may have a lot of WIP due to factors outside of your control. For instance, you begin work on a task and determine that the requirements are not clear enough to continue. You need to get a BA to refine the reqs. In this case hard-core Kanban-ers would say that you cannot begin work on another task because if you do you'll never get a BA to refine the requirements properly. Instead, you should simply wait and force the "steel thread" to the BA resource to get a better requirement. In some cases that may work but the problem is that this doesn't take into consideration that the BA resource may have other, more pressing issues. Basically, your team's emergency may not be another team's emergency. I handle these situations by moving the "card" to the BA resource so it affects that resource's WIP limits and then have my blocked resource work on something else. I don't like to make WIP limit adherence a religious dogma. Rather, it is a guide to get us the best throughput. Something as simple as denoting the steel threads with a special colored card is enough to get management to prioritize better.
Most importantly WIP limits simply ensure that we don't have a bunch of tasks forever sitting at 80% complete. It's very easy for a developer that needs requirement classification to simply sit the task aside and move on to something else. WIP limits ensure there is accountability for task completion. In the real world, in my experience, WIP limits break down when you have "steel threads" from one team to another. This is by far the Number One Reason for WIP in large software engineering organizations. As I said before, just because Team A is blocked by Team B doesn't mean the blocked task is a priority for Team B. In organizations that struggle with steel thread management, such as large monolithic ISVs, WIP limits will probably not work because there are cultural and political reasons why teams don't collaborate. Only when the culture is forced to change will WIP limits work.
The Need for Idle Time
Everyone (or every resource) needs idle time or slack time. It should be built in to the sprint schedule. If no one has slack time then WIP gets stuck in the system in queues. We've introduced unneeded bottlenecks and constraints to the system. Therefore it is best to always allow for slack time in your development processes.
There are other ways we can simultaneously reduce work and increase slack time. Every process has constraints that we can identify and wish to protect. I discussed this in a previous DevOps post. These resources, once identified, can benefit from a "keeper". A keeper is basically a helper that can move tasks around from work center to work center without wasting the constraint's time. We need the constraint to be working on the important work, not on tasks that another resource could handle (checking-in/merging code, filling out paperwork, attending useless meetings). The keeper can be an intern or a junior member of your team.
Minimum Marketable Feature
Limiting WIP is one of the most important tenants of DevOps. By limiting WIP we find that cycle times are reduced and throughput is improved. This means that we can get the software to the customer faster. This generates an invaluable feedback loop. This is why one of the premises of agile is to release early and often. It is also why Lean software development preaches understanding and delivering only the "minimum marketable feature" (MMF). This is also sometimes called the Minimum Viable Product. We only want to do enough to get sufficient feedback and make profits. Anything else is just polishing the apple.
"The Best Way to Get Work Done is to Not Do Work"
I'm certain I didn't invent this saying but I use it daily. If you work in an ISV shop like I do then you are probably innundated every day with sales guys and BAs that want more and better functionality. Many times the requirements are half-baked, at best. Before we start doing work on these items I like to give these tasks some soak time. I find that after some amount of time that there is no real demand for these tasks and they die before anyone has wasted any time on them. Or I find that work that was deemed necessary a month ago is no longer necessary (see my patching example above). In these cases, don't do the work. I know this sounds a little waterfall-ish (we only start work when it is fully documented) but this is why I never adhere to development practices as if they were dogma. Every organization is different and every situation is unique. But if you suffer from half-baked requirements that never get to a customer then consider a more waterfall-ish approach. You are wasting time creating inventory that is never sold and WIP that never gets to done.
How do you move to a DevOps Reference Architecture?
Here are my final thoughts on DevOps. Obviously I think this is a software engineering method that shows some promise and isn't loaded with a bunch of useless platitudes and metrics gathering that offer no hope of getting better software to customers. This is how I've approached selling and implementing a DevOps approach at organizations I've worked with.
Good luck with your journey to DevOps. I hope this blog series helps you in your quest for greater profits and better software.
You have just read "DevOps: WIP and Final Thoughts" on davewentzel.com. If you found this useful please feel free to subscribe to the RSS feed.
Dave Wentzel CONTENT
devops