Process Improvement on “borrowed time”

<meta name="GENERATOR" content=" 2.0 (Linux)" /><meta name="AUTHOR" content="willem ende" /><meta name="CREATED" content="20061019;9374500" /><meta name="CHANGED" content="16010101;0" /><br /> <style type="text/css"> <!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } --> </style> <p class="western" style="margin-bottom: 0in">I liked <a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-article','']);">Emmanuel Gaillot</a>‘s <a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-article','']);">Borrowing the First 5 minutes</a> a lot. You can almost see the <a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-article','']);">Diagrams of Effects</a> in the words, so I decided to draw some (<a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-article','']);">systems thinking step</a> 1: tell story). I’ve made a bunch of them, hoping that it makes the thought process easily traceable.</p> <p class="western" style="margin-bottom: 0in">The first two diagrams are on the problem</p> <p class="western" style="margin-bottom: 0in"> <p class="western" style="margin-bottom: 0in"><img alt="" src="" /></p> <blockquote> <p class="western" style="margin-bottom: 0in">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.</p> </blockquote> <p>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.</p> <p class="western" style="margin-bottom: 0in">and the first analysis:</p> <p><img alt="The image “” cannot be displayed" src="" /></p> <blockquote><p>Here’s the catch: changing your work process means that first, you’ll have to slow down.</p></blockquote> <p>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.</p> <p>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.</p> <p class="western" style="margin-bottom: 0in"> <p class="western" style="margin-bottom: 0in">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.</p> <p class="western" style="margin-bottom: 0in"><img alt="The image “” cannot be displayed, because it contains errors." src="" /></p> <p>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, <a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-article','']);">take no small slips</a> .</p> <p>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…</p> <p class="western" style="margin-bottom: 0in"> <p class="western" style="margin-bottom: 0in">I’ve used the techniques Emmanuel mentions in recommendation #2 – <em>Don’t try to deny all the pressure at once</em> – 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.</p> <p class="western" style="margin-bottom: 0in"><img width="477" style="cursor: -moz-zoom-in" alt="" src="" /></p> <p class="western" style="margin-bottom: 0in"> <p class="western" style="margin-bottom: 0in">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.</p> <p class="western" style="margin-bottom: 0in">Hasty Rework is likely to decrease quality (<a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-article','']);">haste makes waste</a>), 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.</p> <p class="western" style="margin-bottom: 0in">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.</p> <p class="western" style="margin-bottom: 0in">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? <a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-article','']);">Ask ‘why’ five times about every matter</a>. 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.</p> <p class="western" style="margin-bottom: 0in">In proposal #3, Emmanuel recomends to <em>watch for improvement</em> and in #4 to <em>reinvest</em> . 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:</p> <p class="western" style="margin-bottom: 0in"><img alt="" src="" /></p> <p class="western" style="margin-bottom: 0in"> <p class="western" style="margin-bottom: 0in">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<br /> into life in the code…) .</p> <p class="western" style="margin-bottom: 0in">Emmanuel suggests in #, that once you’ve had some success, you might call for some guidance.</p> <p class="western" style="margin-bottom: 0in"><img width="493" style="cursor: -moz-zoom-in" alt="" src="" /></p> <p>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 .</p> <p>Proposition #5 is about <em>spiraling up</em> – what to do when you’ve gained so much time through process improvement that</p> <blockquote><p>your managers will start noticing that it takes you significantly less time to do stuff</p></blockquote> <p><img width="493" alt="" style="cursor: -moz-zoom-in" src="" />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…</p> <p>Then it is time to <em>negotiate . </em>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).<br /> 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.</p> <p class="western" style="margin-bottom: 0in"> <p>The diagrams have worked for me, it helped me better understand what <a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-article','']);">Emmanuel</a> was exactly writing about and spin off some more ideas, some of which ended up in this post, others as <a href="" >fieldstones</a>.</p> <p>I hope they have worked for you, and I’m looking for feedback (<a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-article','']);">systems thinking steps 10 and 11</a>: get feedback from presenting to a group, and adjust the diagrams).</p> <p class="postmetadata alt"> <small> This entry was posted on Thursday, October 19th, 2006 at 9:43 am and is filed under <a href="" title="View all posts in people & systems" rel="category tag">people & systems</a>. You can follow any responses to this entry through the <a href=''>RSS 2.0</a> feed. Both comments and pings are currently closed. </small> </p> </div> </div> <!-- You can start editing here. --> <h3 id="comments">3 Responses to “Process Improvement on “borrowed time””</h3> <ol class="commentlist"> <li class="alt" id="comment-1188"> <cite>anil</cite> Says: <br /> <small class="commentmetadata"><a href="#comment-1188" title="">November 13th, 2006 at 2:08 pm</a> </small> <p>Did u use any specific tool to do capture these diagrams. I am looking at any free tools that allow us to capture these diagrams as easily as they flow through our mind.</p> </li> <li class="" id="comment-1267"> <cite><a href="" rel='external nofollow' class='url'>Willem van den Ende</a></cite> Says: <br /> <small class="commentmetadata"><a href="#comment-1267" title="">November 13th, 2006 at 9:42 pm</a> </small> <p>Hi Anil,</p> <p>I used a tool called <a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-comment','']);">dia</a> to make these. Ubuntu and other linux distributions have packages for this. Drawing is fairly easy. To export the diagrams to the website I created a ruby script using various tools to make the exported pictures look nice.</p> <p>Drawings don’t always appear in my mind… The way it often works for me, is that the diagram grows as I am drawing it (whether on paper or using a drawing tool), even though the basics are already in my minds’ eye.</p> </li> <li class="alt" id="comment-9778"> <cite><a href="" onclick="javascript:_gaq.push(['_trackEvent','outbound-commentauthor','']);" rel='external nofollow' class='url'>systems thinking for borrowed time « silk and spinach</a></cite> Says: <br /> <small class="commentmetadata"><a href="#comment-9778" title="">May 12th, 2007 at 1:09 pm</a> </small> <p>[...] way to effect guerilla process improvement. Willem van den Ende has followed up on this by creating diagrams of effects to model the original article. Recommended [...]</p> </li> </ol> </div> <div id="sidebar"> <ul> <li> <form method="get" id="searchform" action=""> <div><input type="text" value="" name="s" id="s" /> <input type="submit" id="searchsubmit" value="Search" /> </div> </form> </li> <!-- Author information is disabled per default. Uncomment and fill in your details if you want to use it. <li><h2>Author</h2> <p>A little something about you, the author. Nothing lengthy, just an overview.</p> </li> --> <li class="pagenav"><h2>Pages</h2><ul><li class="page_item page-item-2"><a href="">About Willem</a></li> <li class="page_item page-item-367"><a href="">Archives</a> <ul class='children'> <li class="page_item page-item-851"><a href="">We are uncovering better ways of moving post-its</a></li> </ul> </li> <li class="page_item page-item-705"><a href="">Contact</a></li> </ul></li> <li><h2>Archives</h2> <ul> <li><a href='' title='August 2013'>August 2013</a></li> <li><a href='' title='June 2013'>June 2013</a></li> <li><a href='' title='May 2013'>May 2013</a></li> <li><a href='' title='January 2013'>January 2013</a></li> <li><a href='' title='December 2012'>December 2012</a></li> <li><a href='' title='October 2012'>October 2012</a></li> <li><a href='' title='May 2012'>May 2012</a></li> <li><a href='' title='February 2012'>February 2012</a></li> <li><a href='' title='January 2012'>January 2012</a></li> <li><a href='' title='December 2011'>December 2011</a></li> <li><a href='' title='November 2011'>November 2011</a></li> <li><a href='' title='September 2011'>September 2011</a></li> <li><a href='' title='June 2011'>June 2011</a></li> <li><a href='' title='February 2011'>February 2011</a></li> <li><a href='' title='January 2011'>January 2011</a></li> <li><a href='' title='December 2010'>December 2010</a></li> <li><a href='' title='October 2010'>October 2010</a></li> <li><a href='' title='May 2010'>May 2010</a></li> <li><a href='' title='April 2010'>April 2010</a></li> <li><a href='' title='October 2009'>October 2009</a></li> <li><a href='' title='September 2009'>September 2009</a></li> <li><a href='' title='August 2009'>August 2009</a></li> <li><a href='' title='July 2009'>July 2009</a></li> <li><a href='' title='June 2009'>June 2009</a></li> <li><a href='' title='May 2009'>May 2009</a></li> <li><a href='' title='April 2009'>April 2009</a></li> <li><a href='' title='March 2009'>March 2009</a></li> <li><a href='' title='February 2009'>February 2009</a></li> <li><a href='' title='January 2009'>January 2009</a></li> <li><a href='' title='December 2008'>December 2008</a></li> <li><a href='' title='October 2008'>October 2008</a></li> <li><a href='' title='September 2008'>September 2008</a></li> <li><a href='' title='August 2008'>August 2008</a></li> <li><a href='' title='July 2008'>July 2008</a></li> <li><a href='' title='June 2008'>June 2008</a></li> <li><a href='' title='May 2008'>May 2008</a></li> <li><a href='' title='April 2008'>April 2008</a></li> <li><a href='' title='March 2008'>March 2008</a></li> <li><a href='' title='February 2008'>February 2008</a></li> <li><a href='' title='January 2008'>January 2008</a></li> <li><a href='' title='December 2007'>December 2007</a></li> <li><a href='' title='November 2007'>November 2007</a></li> <li><a href='' title='October 2007'>October 2007</a></li> <li><a href='' title='September 2007'>September 2007</a></li> <li><a href='' title='August 2007'>August 2007</a></li> <li><a href='' title='June 2007'>June 2007</a></li> <li><a href='' title='May 2007'>May 2007</a></li> <li><a href='' title='February 2007'>February 2007</a></li> <li><a href='' title='January 2007'>January 2007</a></li> <li><a href='' title='November 2006'>November 2006</a></li> <li><a href='' title='October 2006'>October 2006</a></li> <li><a href='' title='September 2006'>September 2006</a></li> <li><a href='' title='August 2006'>August 2006</a></li> <li><a href='' title='July 2006'>July 2006</a></li> <li><a href='' title='June 2006'>June 2006</a></li> <li><a href='' title='May 2006'>May 2006</a></li> <li><a href='' title='April 2006'>April 2006</a></li> <li><a href='' title='March 2006'>March 2006</a></li> <li><a href='' title='February 2006'>February 2006</a></li> <li><a href='' title='January 2006'>January 2006</a></li> <li><a href='' title='December 2005'>December 2005</a></li> <li><a href='' title='November 2005'>November 2005</a></li> <li><a href='' title='October 2005'>October 2005</a></li> <li><a href='' title='September 2005'>September 2005</a></li> <li><a href='' title='August 2005'>August 2005</a></li> <li><a href='' title='June 2005'>June 2005</a></li> <li><a href='' title='May 2005'>May 2005</a></li> <li><a href='' title='April 2005'>April 2005</a></li> <li><a href='' title='March 2005'>March 2005</a></li> <li><a href='' title='February 2005'>February 2005</a></li> <li><a href='' title='January 2005'>January 2005</a></li> <li><a href='' title='August 2004'>August 2004</a></li> <li><a href='' title='July 2004'>July 2004</a></li> <li><a href='' title='June 2004'>June 2004</a></li> <li><a href='' title='May 2004'>May 2004</a></li> <li><a href='' title='February 2004'>February 2004</a></li> <li><a href='' title='December 2003'>December 2003</a></li> <li><a href='' title='November 2003'>November 2003</a></li> </ul> </li> <li class="categories"><h2>Categories</h2><ul> <li class="cat-item cat-item-3"><a href="" title="View all posts filed under bookmarks">bookmarks</a> (5) </li> <li class="cat-item cat-item-4"><a href="" title="View all posts filed under people & systems">people & systems</a> (255) </li> <li class="cat-item cat-item-94"><a href="" title="View all posts filed under programming">programming</a> (9) </li> <li class="cat-item cat-item-8"><a href="" title="View all posts filed under public courses">public courses</a> (5) </li> <li class="cat-item cat-item-7"><a href="" title="View all posts filed under testing">testing</a> (2) </li> <li class="cat-item cat-item-1"><a href="" title="View all posts filed under unfiled">unfiled</a> (4) </li> <li class="cat-item cat-item-5"><a href="" title="View all posts filed under wrestling with programs">wrestling with programs</a> (6) </li> </ul></li> </ul> </div> <hr /> <div id="footer"> <p> <a rel="license" href=""> <img alt="Creative Commons License" style="border-width:0" src="" /> </a> <br />All works on this site are licensed under a <a rel="license" href="">Creative Commons Attribution 3.0 Netherlands License</a>.<br/> me.andering – Willem van den Ende is written, photographed and drawn by <a href="">Willem van den Ende</a> and people who are kind enough to donate comments :)<br/> me.andering is powered by <a href="">WordPress</a> <a href="">Entries (RSS)</a> and <a href="">Comments (RSS)</a> and proudly hosted by <a href="">Wyrd Web</a>. <!-- 15 queries. 0.043 seconds. --> </p> </div> </div> <!-- Gorgeous design by Michael Heilemann - --> </body> </html>