I liked Emmanuel Gaillot‘s Borrowing the First 5 minutes a lot. You can almost see the Diagrams of Effects in the words, so I decided to draw some (systems thinking step 1: tell story). I’ve made a bunch of them, hoping that it makes the thought process easily traceable.
The first two diagrams are on the problem
The more pressure you’re under to deliver, the less you care about the quality of the software you’re releasing. Unfortunately, the less the quality is, the more rework you’ll have to do. And of course, more rework means more schedule slippage, ergo more pressure to deliver the next bit.
Lower quality means more rework, more rework means more slippage, more slippage leads to more pressure, which in turn leads to lower quality – a vicious circle.
and the first analysis:
Here’s the catch: changing your work process means that first, you’ll have to slow down.
Improving your process will (hopefully) in time lead to higher quality (the || indicate a delay). In the short run, process improvement is likely to cost time and cause noteable slippage.
The first two were easy to draw, as the cycles and arrows are literally in the text. Emmanuel offers five solutions, drawing diagrams for them required more interpretation. And that is what I like about DOE’s: they require another mode of thinking, and open different perspectives on the problem or proposed solution.
So in the third step, two interventions are added. As Emmanuel says,accepting pressure is a choice and there is always something you can do to improve.
So two ‘interventions’ are added to the diagram. The intervention from Slippage to Pressure means that you can choose to accept the slippage as a fact of life. Calmness will save you! Maintaining a clear head will increase your chances of actually delivering. The other intervention, between improved process and slippage, indicates there might be a way to improve the process without causing noticeably more slippage. If you can not find such a way, take no small slips .
After the third DOE, I notice I forgot something. The assumption is that ‘ordinary’ rework will increase quality. I’ve been in places where rework caused quality to remain insufficient for release. Rework without sufficient safeguards will introduce new defects, so instead of improving quality by removing defects, the number of defects increased…
I’ve used the techniques Emmanuel mentions in recommendation #2 – Don’t try to deny all the pressure at once – before (usually up-front with moderate pressure, though). Writing a test for a defect and doing (if even a little) pair-work would be the kind of safeguards that ensure your rework is a quality improvement.
If we take the steps from #2 as our improved process, and draw Pair Rework, new Tests per Defect and Hasty Rework as variables, we get a choice of which activities to perform when Quality is insufficient.
Hasty Rework is likely to decrease quality (haste makes waste), a new Test per Defect will focus the repair work, and prevent the defect from re-appearing in the future. Assuming these tests are programmed (not done by hand), collected in a test-suite, and re-run regularly.
Pair rework ensures knowledge about the defect and its’ repair is spread, and that errors made in repairing are caught before the fix is released.
Looking at diagram 3, we may notice these suggestions all work on the defects directly. How can we come up with suggestions like these, and new ideas to improve the process? Ask ‘why’ five times about every matter. Which gives me energy to write about, at another time. The DOE helps to see at which level you are working, and gives inspiration for other levels.
In proposal #3, Emmanuel recomends to watch for improvement and in #4 to reinvest . I’ve combined them in a new DOE – managing the process improvement process is at another level of abstraction than what we had before. Since the timings are measureable, they are drawn as ellipses rather than clouds – clouds are for observables:
The Process Improvement Effectiveness depends in part on the time you spent on it; if you spend no time on PI then the process is unlikely to improve, but after some point, more time spent will not increase the effectiveness. Effective PI will reduce the mean time to solve a defect (I refuse to use the word bug, as that suggests the defect magically came
into life in the code…) .
Emmanuel suggests in #, that once you’ve had some success, you might call for some guidance.
Getting an Expert in will increase the effectiveness of your process improvement. It also might save you time spent on PI per defect, as the expert can quickly guide you to what to do and what not. Guidance will improve the quality of your work, save time on improvement, and (not drawn) if you get a hands-on kind of person in, he or she may directly contribute to repairing defects as well – and often with more awareness of possible root causes as well .
Proposition #5 is about spiraling up – what to do when you’ve gained so much time through process improvement that
your managers will start noticing that it takes you significantly less time to do stuff
At first management may not notice the change in Mean time to solve defect, then when they notice, they’ll celebrate, hopefully after making sure you are not reducing time by cutting corners…
Then it is time to negotiate . Together with your management you can choose to divide the gained time between increasing throughput (solve more defects per week) and training (drawn here as a higher investment in Expert Guidance).
Do not increase throughput implicitly – you’ll lose the time you’ve gained, and you lose an opportunity to share your gains with other teams around you.
The diagrams have worked for me, it helped me better understand what Emmanuel was exactly writing about and spin off some more ideas, some of which ended up in this post, others as fieldstones.
I hope they have worked for you, and I’m looking for feedback (systems thinking steps 10 and 11: get feedback from presenting to a group, and adjust the diagrams).
. Small transformations make it easy to check if what we want to happen actually happens, and how far of we are. If you’re reading this blog there is a fair chance you are familiar with growing software in small steps – I apply the same principles when working on myself or helping others to improve their (development) performance.
I say my camera, because Marc Evers and Rob Westgeest also shot a bunch (of pictures) with it. A semi-random sample of the above:
