These are the three things I encourage people to look at when they aren’t getting what they need out of their software development process. Because I had started with these so many times, I sometimes imagine everyone knows all about them; but each time I start helping a software team turn things around I find that these techniques have yet to be applied.
Make Work Visible
Making work visible means putting all the work in one place, ideally somewhere it cannot be ignored. Walls are a great location for work. An important and often neglected part of this is uncovering all of the stuff people don’t classify as work. All of the ad-hoc requests and regular tasks, whether they arrive in person, via email, or via any other means; it all needs to be there. Until you can see the problem, you can’t fix the problem.
Once you can see the full extent of the work, you can apply one of the most cost-effective and brilliant tricks of software development: you can choose not to do it. Once you have sliced your way to a valuable set of work, you can continue onto the second way to improve your software development process.
Limit Work in Process
When there is a lot to be done, it can be tempting to start a lot at the same time. This makes everything take much longer. It’s mathmatical fact. It’s empirical. It has been put to bed. The more you start, the longer you have to wait for everything you have started. The solution to this problem is simple. Start less. When you start less, you finish more.
This sometimes requires quite a bit of reinforcement. I regularly express my preference for something to be deployed, rather than for new work to be started. You can make this preference explicit by limiting how much work can be in any particular state. To make this work, you may also need to limit how big any piece of work is. By putting limits on your work in process, you unblock the flow of value.
Many teams also find that once you reduce work in process, you discover lots of other ways to improve your software development process.b
Deliver Early and Often
Once you can see all of the work and you have limited how much can be active at once, you may find this next part emerges naturally. In case it doesn’t, you need to ensure that you deliver early and often. Small regular releases lower the risk of bad releases. Not only will a small release statistically reduce the chance of a bug, doing releases regularly means you’ll do a better job of deployments.
I have encouraged teams to deliver more often. I have encouraged them to do it on days they previously never released on (whether for practical or superstitious reasons). Basically, I encourage the thought pattern of “this could go live at any time”. You can’t squeeze quality in during the preparation for a deployment; it has to be there all the time.
Saving up lots of features to release in one go doesn’t make sense when you think of things in terms of the whole organisation. If you have a bug that causes one-hundred customers a day to phone customer services for support, why would you hold onto it for a week in order to deploy at the same time as other work? That’s up to five-hundred failure demand phone calls, plus countless hours of wasteful internal dialog talking about a problem that has already been solved (just not made available). Now imagine that one of the other features in that release has an issue… you’re now rolling back and re-introducing the bug because of some unrelated issue you have introduced.
Whenever I introduce these three concepts, it makes people happier. The developers are happier because the work becomes manageable, the stakeholders are happy because they get regular releases of valuable software, the customer services team are happy because they aren’t taking those phone calls, and the customer is happy because their software works.
Make the work visible. Limit work in process. Delivery early and often.