Systems thinking about software development
Marc Evers pointed me to a PDF book published by Chris Corrigan – The TAO of open space. I’ve never seen a book quite like it – it’s got chapters of the Tao Te ching on the same page as how that chapter translates to Open Space.
The chapters are brief, and seem to provide interesting quotes (from chapter 14):
Harrison Owen once called Open Space “vapourware.” There are a million people who want to describe it, but no one is ever satisfied with the explanation.
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).
The open space conference on continuous integration and testing in London was a lot of fun. Lots of energy from the participants and a good variety of session topics. I’ve put my citcon photos up. Some samples:
opening session
Jeffrey and Paul explain the open space conference format
Steve Freeman proposes a session, someone else takes a card to write a proposal on
animated discussion
using the beamer to show the notes that have been taken so far (instead of presenting slides 
)
closing session
I’m having an open space themed week:
A manager says:I spend a lot of my time dealing with and talking to managers about agility and how the principles of XP are relevant to the non programmers in the organisation. It may seem obvious to us but sometimes it needs to be spelled out. There is a sort of fear of loss of control from most of the management people I talk to. I have to assure them that control is an illusion at the best of times and that trust is a better, more productive way. One of the things I like about the open open session is that it grasps that fear and says “ok lets see what happens if you do relinquish control – will people mutiny and waste time or will they rally and try to address the issues.”. We can use these sessions to show that people will naturally allow the real priorities to surface and in a more direct way than they might otherwise be able to on a rigid agenda.
. The website isn’t up yet apparently, hope it will be soon.
Willem van den Ende
Profile
Recent Comments