Software product development is a seemingly simple process with loads of inherent complexity.
It’s a process you can probably describe in 3 or 4 steps: identify a problem, build some software to address the problem, give it to the people who have the problem.
But you people aren’t satisfied with a simple process, are you? You have to go and complicate it with all sorts of real world problems. Things get clunky, slow down, frustration builds, and you find yourself nowhere near that magical flow state where things just happen smoothly.
One of the most successful practices we can learn from is the world of lean, as originally developed by Toyota.
(By the way, I’m not talking about Lean startup & Eric Ries, which is awesome, and well worth borrowing from too).
The aim of lean manufacturing was to eliminate waste — that is the non-value adding components in a process.
In the manufacturing of physical goods, the forms of waste are defects, overproduction, waiting, inventory, transportation, motion and non-utilised talent.
Software product development has many similarities to those processes, and some smart people have already translated these forms of waste into equivalents for knowledge based work.
And here they are:
1. Partially Done Work
2. Excess Work
6. Context Switching
8. Under-utilised Skills
Simply identify and eliminate these forms of waste from your process and… step 3, profit!
So, seriously, where do you start? Lean says identify value and map your value stream. Then you start measuring.
The question I asked the team that was still forming is, can you start with a subjective approach to identifying waste?
Well, yes, as long as you acknowledge the inherent weaknesses of such an approach, that is, it’s likely to be wrong. But my experience is that it is directionally right, i.e. people involved in the process can likely point you in the right direction.
I recently ran a retrospective with a team where we took a subjective approach to identifying waste in their process.
This is how it went.
We started off by discussing the different forms of waste, and what they meant in the team’s context.
Everyone then reflected on the experience of working with the current process, and made some observations about waste in the process. Specifically they were asked to consider each type of waste, and how much of each type of waste existed in the current process, with notes.
Here are the questions:
- Partially done work – Is work going from beginning to end in a single rapid flow? For example; are you building up large amounts of untested or undeployed work? Do you have long-lived feature branches?
- Excess work – Do our customers or users actually need what we’re analysing and building?
- Rediscovery – Do you spend a lot of time rediscovering what you (or someone else on your team) already knew at some point?
- Handoffs – Are we truly collaborating, or handing off bits of work to each other, losing tacit knowledge in the process?
- Delays – Does work typically spend lots of time stalled awaiting things like environments, someone to be available, or decisions to be made?
- Context Switching – Do you spend your day switching between projects and subjects? Are you able to focus enough to get into a “flow state”?
- Defects – Do we have a low defect rate? How late in the development process do we find defects? Could this feedback loop be shorter?
- Under-utilised Skills – Are we under-utilising the skills and knowledge or the team?
This produced some really interesting results. Some types of waste were painfully obvious to everyone. In other cases, individual perspectives on waste were vastly different. This is probably not surprising given the subjective nature of the exercise.
It also led to some fantastic conversations – simply by exposing different perspectives and giving people the space to discuss why they thought something was wasteful led to a number of actions that the team were immediately able to take into their process.
Here’s how it ended up looking in Miro:
The next step for this team, which is an ongoing process, is further instrumenting the process to generate data on waste, so that the team has a way of identifying waste, and take immediate action if waste starts occurring.