I planned to write individual posts about new and upcoming workshops, but the rate at which we get invited and accepted to conferences this fall outstrips my ability to post new entries 
I have to post now, before the conferences themselves are over… I hope you’ll join us for at least one of these. We’ll be doing some hard-core programming workshops as well as more enterprise and facilitation oriented sessions this fall.
Tag Archive for 'test-driven-development'
We are partnering with local companies to provide our training curriculum in other countries. We started the Mastering Unit Testing course after we found many teams have started writing unit tests, but very few have experienced the benefits of hard-core test-driven development.
“You have some experience writing unit tests, but wonder how you could get more out of unit testing. Register for the Mastering Unit Testing training to experience how test driven development can make development faster and more enjoyable. You’ll learn how working test-first lets you create better designed code, and understand why unit testing techniques that are ‘simple’ in theory can be difficult to practice. Past participants have experienced less defects in production code, as well as higher velocity, which leads to happier clients and more fun in your job!”
See the Mastering Unit Testing page on the iLean site for registration and details. The first course is scheduled for September 24 and 25. After that we’ve also got our Mastering legacy code, November 16 and 17, also in Antwerp.
photo found through Photo Suggest
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).
Recent Comments