tag:blogger.com,1999:blog-102806682024-03-12T18:10:32.260-05:00Brad Appleton's ACME BlogAgile CM / ALM EnvironmentsBrad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.comBlogger252125tag:blogger.com,1999:blog-10280668.post-54144223115542067482018-03-26T16:15:00.003-05:002019-01-31T10:38:08.666-06:00R.I.P Mike Beedle<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiX2_My2izMjBdVEF0PxojG3ofV_DKZAcl1zYePjUbKLnPXoxrkg4OXwRCuCjzUHUmYmGt8KDIWsIMroWrjDjFs96JICFAUZGz8Kbg_tWskX0G7jJXE0g4eN8KsZfzsjxONFIbC/s1600/Mike-Beedle_In-Memoriam.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="795" data-original-width="1600" height="159" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiX2_My2izMjBdVEF0PxojG3ofV_DKZAcl1zYePjUbKLnPXoxrkg4OXwRCuCjzUHUmYmGt8KDIWsIMroWrjDjFs96JICFAUZGz8Kbg_tWskX0G7jJXE0g4eN8KsZfzsjxONFIbC/s320/Mike-Beedle_In-Memoriam.png" width="320" /></a></div>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Saturday afternoon, I learned from the </span><a href="https://www.facebook.com/groups/EnterpriseScrum/" style="font-family: georgia, "times new roman", serif;" target="_blank">Enterprise Scrum community</a><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"> that Mike Beedle died in Northwestern Memorial hospital, the victim of a fatal stabbing in Chicago:</span><br />
<blockquote class="tr_bq">
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><span style="background-color: transparent; font-size: x-small;"><span style="color: #2c4751; font-family: "barlow" , "helvetica" , "arial" , sans-serif;">"<i>It is with a heavy heart that we bid farewell to Mike Beedle – business agility visionary, </i></span><i><a href="http://agilemanifesto.org/" rel="noopener" style="border: 0px; box-sizing: border-box; color: #19a1d0; font-family: barlow, helvetica, arial, sans-serif; font-stretch: inherit; line-height: inherit; margin: 0px; padding: 0px; vertical-align: baseline;" target="_blank">agile manifesto</a> <span style="color: #2c4751; font-family: "barlow" , "helvetica" , "arial" , sans-serif;">signatory, founder of </span><a href="http://www.enterprisescrum.com/" rel="noopener" style="border: 0px; box-sizing: border-box; color: #19a1d0; font-family: barlow, helvetica, arial, sans-serif; font-stretch: inherit; line-height: inherit; margin: 0px; padding: 0px; vertical-align: baseline;" target="_blank">Enterprise Scrum</a><span style="color: #2c4751; font-family: "barlow" , "helvetica" , "arial" , sans-serif;"> and friend. Several hours ago, the Enterprise Scrum community confirmed that Mike was fatally injured in </span><a href="https://www.nbcchicago.com/news/local/man-stabbed-river-north-chicago-477722403.html" rel="noopener" style="border: 0px; box-sizing: border-box; color: #19a1d0; font-family: barlow, helvetica, arial, sans-serif; font-stretch: inherit; line-height: inherit; margin: 0px; padding: 0px; vertical-align: baseline;" target="_blank">a stabbing in Chicago</a><span style="color: #2c4751; font-family: "barlow" , "helvetica" , "arial" , sans-serif;">. Our thoughts are with his wife, children, family and friends. In this difficult time, the community has come together and created </span><a href="https://www.gofundme.com/mikebeedlesupport" rel="noopener" style="border: 0px; box-sizing: border-box; color: #19a1d0; font-family: barlow, helvetica, arial, sans-serif; font-stretch: inherit; line-height: inherit; margin: 0px; padding: 0px; vertical-align: baseline;" target="_blank">a gofundme project</a></i><span style="color: #2c4751; font-family: "barlow" , "helvetica" , "arial" , sans-serif;"><i> to raise funds for his family.</i>" </span></span><span style="background-color: transparent;"> -</span><span style="background-color: transparent; color: #2c4751; font-family: "barlow" , "helvetica" , "arial" , sans-serif; font-size: x-small;">- </span><a href="https://businessagility.institute/discover/r-i-p-mike-beedle/" style="background-color: transparent; font-family: barlow, helvetica, arial, sans-serif; font-size: small;" target="_blank">R.I.P. Mike Beedle</a><span style="background-color: transparent; color: #2c4751; font-family: "barlow" , "helvetica" , "arial" , sans-serif; font-size: x-small;">, Business Agility Institute. </span></span><span style="font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;">[<i>See news clips from </i></span><span style="font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;"><i><a href="http://abc7chicago.com/river-north-stabbing-victim-idd-as-suburban-ceo/3278239/" target="_blank">ABC7Chicago</a>, <a href="https://www.nbcchicago.com/news/local/mike-beedle-stabbed-chicago-alley-478240333.html" target="_blank">NBC Chicago</a>, <a href="http://www.chicagotribune.com/news/local/breaking/ct-met-mike-beedle-death-20180329-story.html" target="_blank">Chicago Tribune</a></i>]</span></blockquote>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">A few day's later, I still haven't fully processed this. Mike was more than just a colleague, co-<a href="https://www.scrumalliance.org/community/profile/mbeedle" target="_blank">thought-leader</a>, and former co-worker to me, he was an old and dear friend.</span><br />
<br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">I first met Mike in 1995 via OTUG (Object-Technology User's Group) that formed as part of "<a href="https://adtmag.com/articles/2001/07/26/converging-on-ooad-agreement.aspx" target="_blank">Booch & Rumbaugh on Tour</a>" (which eventually resulted in UML). We were both part of the <a href="https://www.ibm.com/developerworks/rational/archives/otug/" target="_blank">OTUG mailing-list</a> (as were many other notables in the O-O community, like [Uncle] Bob Martin) and learned that we literally were working across the street from each other (<a href="https://www.scruminc.com/mike-beedle-on-early-history-of-scrum/" target="_blank">Mike was still working for Mercer at the time</a>). Mike invited me to meet for lunch nearby, to discuss our mutual interests in OOD and Design Patterns, and we quickly became fast friends and colleagues.</span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">From 1995 thru most of 2004, we corresponded and/or spoke almost daily, and had lunch together at least once a month. We bounced ideas off of each other, reviewed each other's works-in-progress (books & papers), and regularly discussed what we were passionate about in the field. We were also highly-active contributors in all the major online forums about Design Patterns (and later, Agile development) but also on the very first ever WikiWeb (<a href="http://c2.com/cgi/wiki?WelcomeVisitors" style="font-family: "Times New Roman";">Ward Cunningham's Wiki Web</a>), where <a href="http://wiki.c2.com/?BradAppleton" target="_blank">Mike started off my first WikiPage</a> for me. </span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">In 1997 (~1 year after Mike left Mercer and started his own consultancy, Framework Technologies), still enthusiastic about patterns, and especially patterns of organization & process design, Mike and I founded <a href="http://wiki.c2.com/?ChicagoPatternsGroup" target="_blank">The Chicago Patterns Group</a> (TCPG), along with Jim Coplien, Bob Martin, Ralph Johnson, Ron Crocker, and Bob Hanmer. We met monthly at the Border's bookstore in Schaumburg (</span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">1540 Golf Road, </span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">across from Woodfield mall). A year or two later, James Grenning joined us (another Agile manifesto co-author). </span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4RjjLeygZho7NtaUik_-tK3qK39cRtnTDSgSvQ-CeTYGyOxhXMLvpS_1T1h2bwcejjHPojgySHy51BdwaH9GN6Xy8AUK49S9PQXCL4PawmsWX72uu9eSN1iUedlDvsHBB-omQ/s1600/Borders-schaumburg.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="525" data-original-width="700" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4RjjLeygZho7NtaUik_-tK3qK39cRtnTDSgSvQ-CeTYGyOxhXMLvpS_1T1h2bwcejjHPojgySHy51BdwaH9GN6Xy8AUK49S9PQXCL4PawmsWX72uu9eSN1iUedlDvsHBB-omQ/s400/Borders-schaumburg.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Border's bookstore in Schaumburg, where TCPG met in 1997-2001</td></tr>
</tbody></table>
<br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Between 1997-2000, aside from co-leading TCPG, Mike had a semi-recurring consulting 'gig' at Motorola in Arlington Heights, where we got to interact even more frequently after I moved there from Motorola's Northbrook campus (in May of '98). We also got to chat more frequently with Ron Crocker then too (my workspace was practically right next to Ron's for much of 2000-2004). I mention this because Ron Crocker created what may have been <a href="http://ciclamino.dibe.unige.it/xp2001/conference/papers/Chapter15-Crocker.pdf" target="_blank">the very first "scaled" Agile method</a> (Grizzly, eXtreme Programming at scale) during that time.</span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Mike & I </span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">traveled together to several of the <a href="http://hillside.net/plop/archive.html" target="_blank">PLoP Conferences</a> (Pattern Languages of Programs), and were program/review members and writer's "shepherds" for several years. We were even roommates </span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">at <a href="https://hillside.net/plop/plop97/" target="_blank">PLoP'97</a>, <a href="https://hillside.net/plop/plop98/" target="_blank">PLoP'98</a> & <a href="https://hillside.net/plop/plop97/" target="_blank">PLoP'99</a>. [In fact, much of the way to PLoP'97 was a horrible rainstorm! I couldn't see more than 20 feet in front of me, and had to follow Mike's tail-lights for several miles until we eventually pulled over to the side of highway and waited for the storm to taper off]</span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">The pictures below are from PLoP'97, where Mike and I were in the "People and Process" workshop group (along with my SCM Patterns + Agile SCM co-author, Steve Berczuk).</span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1aE5k0SAytAYBG5nXHq2J8YR62JMG7gmCJNE_V5IbkRWPJHp1ggeZxErkoAmRlrSUuBJYPHwhlsBPNcRxPsJTNhLVUp7wXeo94PqTgevS51LyKrnMqzBLsumHVPhks0IkjzTB/s1600/PLoP97_People-and-Process-Workshop-Group_Rising1.gif" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="405" data-original-width="556" height="290" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1aE5k0SAytAYBG5nXHq2J8YR62JMG7gmCJNE_V5IbkRWPJHp1ggeZxErkoAmRlrSUuBJYPHwhlsBPNcRxPsJTNhLVUp7wXeo94PqTgevS51LyKrnMqzBLsumHVPhks0IkjzTB/s400/PLoP97_People-and-Process-Workshop-Group_Rising1.gif" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-size: small;">PLoP'97 - People and Process Workshop Group</span></td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">PLoP'98 was where Mike herded together Scrum creators Jeff Sutherland & Ken Schwwaber, along with Martine Devos and Yonat Sharon to create the first written description of Scrum's practices in </span><span style="color: #666666; font-family: "open sans" , "arial" , sans-serif; font-size: 14px;">"<a href="http://jeffsutherland.org/scrum/scrum_plop.pdf" target="_blank">Scrum: A Pattern Language for Hyperproductive Software Development</a>" </span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"> [It's also where Steve B. and I co-authored the first installment of our "Agile SCM" patterns for Branching and Merging, including the variant of <i>Mainline</i> (<i>LAG-Mainline</i>) that is more commonly called <a href="https://trunkbaseddevelopment.com/" target="_blank">Trunk-based Development</a> today]. </span><br />
<br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrMJXXBXTt1XFh7776WJSz7_KutreiVZ4buiPE2bkMs4yuRZhdsKV2D_n005uXdwlP2V_RLsWXKeDwdgeE4w0X_xa5IwvwNKCPj3TgZ740wh3egogdlVw1qwn-ezlVPr7MqAjP/s1600/PLoP97_People-and-Process-Workshop-Group_Rising2.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="405" data-original-width="556" height="291" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrMJXXBXTt1XFh7776WJSz7_KutreiVZ4buiPE2bkMs4yuRZhdsKV2D_n005uXdwlP2V_RLsWXKeDwdgeE4w0X_xa5IwvwNKCPj3TgZ740wh3egogdlVw1qwn-ezlVPr7MqAjP/s400/PLoP97_People-and-Process-Workshop-Group_Rising2.gif" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">PLoP'97 - People and Process Workshop Group, Monticello, IL</td></tr>
</tbody></table>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">On a more personal note, Mike and I carpooled together for PLoP'98: We met for brunch at a nearby Bennigan's, and met each other's spouses (Mike's 1st wife Laura) where Mike announced they were expecting their first child. A few year's later my wife and I were expecting our first, and met up with them for lunch again. We met for lunch at the same place again two years later, with our respective kids, all toddlers and/or infants (I still can't believe we made it thru lunch without either of our kids breaking anything while we were there).</span><br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">In Jan of 2001, Bob Martin was arranging the famous get together at Snowbird Lodge (where the Agile Manifesto was created). I remember Mike telling me about it, and emailing me to tag-along and go with him to the event. I already more than had an inkling of just how momentous the event would be, and really wanted to go (even considered paying my own way when my then employer wouldn't, but knew they would give me grief if my name appeared on the result). </span><br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh6g2-6FgkPIAjUmCDsJzIdVDlYyD9L9vsibtA0XAYCayoZ81frL6JqP-eEWVyb0JTsusi-LVbbDnZ4BVHp5G32p6ikEHy993G4xXt0nWQJW0ScmaxqHbWoSH-6nIDU9teNBttY/s1600/agile-manifesto-background.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="480" data-original-width="640" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh6g2-6FgkPIAjUmCDsJzIdVDlYyD9L9vsibtA0XAYCayoZ81frL6JqP-eEWVyb0JTsusi-LVbbDnZ4BVHp5G32p6ikEHy993G4xXt0nWQJW0ScmaxqHbWoSH-6nIDU9teNBttY/s400/agile-manifesto-background.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Creators/Authors of the Agile Manifesto - Feb 2001, Snowbird Lodge, Utah</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioq9wG3T8cGMKGDrSEVWkoQOKt5hrw47WDoYfVMO-dsX96KHNtjnZSj1wIKkq9puVpbns4IuuScGZ8btiGi5XNnerw0nH6UnSIjBh7h0FyuMz3LY3syOkRomOI-PqcL2QOeX-9/s1600/agile-17-authors.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1069" data-original-width="1418" height="301" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioq9wG3T8cGMKGDrSEVWkoQOKt5hrw47WDoYfVMO-dsX96KHNtjnZSj1wIKkq9puVpbns4IuuScGZ8btiGi5XNnerw0nH6UnSIjBh7h0FyuMz3LY3syOkRomOI-PqcL2QOeX-9/s400/agile-17-authors.png" width="400" /></a></div>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">They decided on the term "Agile" to characterize the set of methods, but it was Mike that first suggested the term for software development during that retreat. I know this because I specifically voiced my support to Mike for the term 'Agile' just *before* he left for SnowBird (in references to conversations we'd had '96-'99 where I</span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"> recall Mike first using the terms "Agile" and "Business Agility" to describe the desired outcomes of applying the kinds of organization & process patterns that he and Cope and others of us were writing about). I specifically asked Mike about it afterward, to confirm.</span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Mike and I first came across the term 'Agile' in a business-context from one of the classic BPR and/or Learning Organization books during the 90s, This bled into much of the "Organizational Change Management" thinking of the time, and the need for organizations and business to be responsive to change. By 2000, the term <i>agile organization</i>, <i>agile business</i>, and <i>business agility</i> were gaining some traction (moreso than Daryl Conner's use of the term "Nimble Organization"), and even in the 6+ months before the manifesto, Mike and I used to comment to each other on the use of those terms in ad campaigns from Sun ("the network *is* the computer") and then MS and others followed suit ("software for the agile business"). That's partly why I remember asking Mike to advocate for the term "Agile" at Snowbird in early Feb of 2001. </span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Anyway, as soon as Mike got back from Snowbird Lodge, we founded the <a href="http://wiki.c2.com/?ChicagoAgileDevelopers" target="_blank">Chicago Agile Developer's meetup-group</a> (ChAD) along with Bob Martin, James Grenning, Martin Fowler, and Lowell Lindstrom. It was so named, in part because of the 2000 U.S. presidential election (the "hanging chads"). ChAD was probably the very first "Agile meetup" in the U.S. (possibly even the world). Our first meeting was April 25, 2001 at Object Mentor in Vernon Hills. (And the first book on Scrum, co-authored by Mike, came out during that time as well). </span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjK6JnXvT7CKcsHYCZUHzNLIj4ti4rdsNKrw33eyLkH9H6m9fmFQjckDHRLi_jwunPx7SrBUW1XFHe69fce5HbypVmTIOjYqBvdGIdfGIZKiBDA0fgqFYi6ehwmdoDH3eh036b/s1600/Scrum-Book.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="250" data-original-width="162" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjK6JnXvT7CKcsHYCZUHzNLIj4ti4rdsNKrw33eyLkH9H6m9fmFQjckDHRLi_jwunPx7SrBUW1XFHe69fce5HbypVmTIOjYqBvdGIdfGIZKiBDA0fgqFYi6ehwmdoDH3eh036b/s320/Scrum-Book.jpg" width="207" /></a></div>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Mike and I planned and arranged ChAD meeting agendas & events (we met monthly, both downtown and in the NW suburbs), right up until our Sep 11 2001 meeting, which was to be in the Sear's Tower. The meeting ended-up being cancelled of course (due to 9/11 happening earlier that day) and the group went on hiatus for ~6months afterward, then revived itself with the help of <a href="https://www.linkedin.com/in/wyatt-sutherland-723863/" target="_blank">Wyatt Sutherland</a>. Mike, Wyatt and I would meetup for lunch every couple months or so to catch-up and plan future events & outings.</span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Mike and I remained big fans/supporters of each others work (but also honest critics). Our respective careers were each going their own direction, and a</span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">fter 2004/2005 we sort of drifted out of touch for awhile, but kept up occasionally (on the various Agile lists/forums, and also on Facebook). </span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Then in late 2016 we reconnected, and within a year Mike was kicking off his latest <a href="https://www.facebook.com/EnterpriseScrum/" target="_blank">Enterprise Scrum</a> ende</span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">avor. Including the facebook group, and <a href="https://medium.com/@mikebeedle" target="_blank">his articles on medium.com</a>. Mike even credited myself and 15+ others with his definition of "Business Agility" for Enterprise Scrum (that's the kind of inclusive and collaborative leader he was). </span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwq-LsPGCjFe7flQNJCMSzmMOzPx8-fWNrN2GgpIExkmcLiHvBzUtVnMNRH-2OPEVDhCnSuaeCFcC0whuasx4gGX5_hBaNn0lyhyPi1iP5ls9ub2URzE17T11sdDm-YwCNwKyH/s1600/Business-Agility-Defn.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1004" data-original-width="1260" height="254" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwq-LsPGCjFe7flQNJCMSzmMOzPx8-fWNrN2GgpIExkmcLiHvBzUtVnMNRH-2OPEVDhCnSuaeCFcC0whuasx4gGX5_hBaNn0lyhyPi1iP5ls9ub2URzE17T11sdDm-YwCNwKyH/s320/Business-Agility-Defn.jpg" width="320" /></a></div>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">He started the <a href="https://www.meetup.com/Enterprise-Scrum-Chicago/" target="_blank">Enterprise Scrum for Business Agility meetup</a> and training sessions in downtown Chicago, and I got to see & speak with him on a regular monthly basis at his downtown meetup. </span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-BSf4CKfOlMrIa8JHeS7R2g4RE8w9BwNUpsiWsIkNpG5sh8rXAuRxG_pKipc8juXJzmwCB8tdi32Ax0WKtRe2JaptfVFaF8J1G2B17qqXar8YYX5c3VfyTDSMxEmBF7M-Ocv1/s1600/MikeB_ES-BAC-2017.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="724" data-original-width="1131" height="255" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-BSf4CKfOlMrIa8JHeS7R2g4RE8w9BwNUpsiWsIkNpG5sh8rXAuRxG_pKipc8juXJzmwCB8tdi32Ax0WKtRe2JaptfVFaF8J1G2B17qqXar8YYX5c3VfyTDSMxEmBF7M-Ocv1/s400/MikeB_ES-BAC-2017.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Enterprise Scrum Business Agility Conference, October 2017, Chicago, IL</td></tr>
</tbody></table>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Most recently, in January of 2018, Mike and I attended <a ajaxify="/groups/member_bio/bio_dialog/?group_id=1774998676085925&member_id=1258867210&ref=floc2-comment" class="profileLink" data-hovercard="/ajax/hovercard/hovercard.php?id=1258867210&extragetparams=%7B%22hc_location%22%3A%22group%22%2C%22directed_target_id%22%3A%221774998676085925%22%7D" dir="ltr" href="https://www.facebook.com/michael.sahota?fref=gc&dti=1774998676085925&hc_location=ufi" rel="dialog" style="color: #365899; text-decoration-line: none;" target="_blank">Michael Sahota</a>'s CAL I training together, where we really had a chance to catch-up and reconnect in depth again (which I was so grateful for at the time, and now even more so).</span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYR1K_UT3YaYvq9ZW9SoKCkeftXkVzk4drltzqclxFI7NYstfAgXQ2hyphenhyphen6ts1ef-gPDw2YLm-n8KuRW1F1odM6izLeT231ZN-JejCGsxmi52I-dF1KtGKO3xVWNKiQkF5a3JJuo/s1600/Mike+Beedle+in+CAL1+Chicago.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1200" data-original-width="1600" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYR1K_UT3YaYvq9ZW9SoKCkeftXkVzk4drltzqclxFI7NYstfAgXQ2hyphenhyphen6ts1ef-gPDw2YLm-n8KuRW1F1odM6izLeT231ZN-JejCGsxmi52I-dF1KtGKO3xVWNKiQkF5a3JJuo/s400/Mike+Beedle+in+CAL1+Chicago.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-size: x-small;">CAL-1 Leadership Training with Michael Sahota - 26 Jan 2018, Chicago, IL </span></td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Not only was Mike impressively smart, but impressively talented t</span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">oo:</span><br />
<ul>
<li><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">He held a Ph.D in high-energy physics, </span></li>
<li><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">He played piano and guitar like a pro (we used to jam together at PLoP)</span></li>
<li><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">was well read in literature, poetry and philosophy (not just patterns).</span></li>
<li><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Also, Mike had one of the first working software packages for HIPPA (using XBreed [Scrum+XP]). </span></li>
</ul>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Mike Beedle was brilliant, visionary, a genuine "renaissance man," and true world-changer with his contributions to Patterns, Scrum, the Agile Manifesto, and was poised to do the same with <a href="http://www.enterprisescrum.com/" target="_blank">Enterprise Scrum</a> for Business Agility. He was as generous as they get when it comes to suppo</span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">rt, openness, thought-leadership and encouragement. </span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNsSgqZHeX-WPkOda-PgilZBqF94XHF91bdEL7wAwYUdAoxOh5k446ihxF8B789F8EGrkAZ8sypXTVUpYBDgHF8zh2whU2Eb6-c6NZmiFS4RSDy6qszko_9d_63veRJu5Djz3-/s1600/Mike-Beedle-BACon-Mar-2018.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="360" data-original-width="574" height="250" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNsSgqZHeX-WPkOda-PgilZBqF94XHF91bdEL7wAwYUdAoxOh5k446ihxF8B789F8EGrkAZ8sypXTVUpYBDgHF8zh2whU2Eb6-c6NZmiFS4RSDy6qszko_9d_63veRJu5Djz3-/s400/Mike-Beedle-BACon-Mar-2018.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-size: small;">Mike Beedle @ Enterprise Scrum, Business Agility NY, March 2018</span></td></tr>
</tbody></table>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Above all else, Mike was PASSIONATE about the things and people he believed in, and determined to change the world and make it (and us) better for it [which is <i>exactly </i>what he did!] I hope we are worthy of carrying-on his work with <a href="http://www.enterprisescrum.com/" target="_blank">Enterprise Scrum</a> to see it thru to fruition. </span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPHpkY9FFHtkqVyHhLQCbhP5G-lsJjD1FHjq9ZjFLjWkybtvrlJMH4Gt554sKo2dvVG8lDeNvIAX7fMk-_N5GkuT0m1Du8Dw2466jLfP-irbr3p9F3udIp8KpepP-_2Ze1WAus/s1600/Enterprise-Scrum_book.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="499" data-original-width="381" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPHpkY9FFHtkqVyHhLQCbhP5G-lsJjD1FHjq9ZjFLjWkybtvrlJMH4Gt554sKo2dvVG8lDeNvIAX7fMk-_N5GkuT0m1Du8Dw2466jLfP-irbr3p9F3udIp8KpepP-_2Ze1WAus/s320/Enterprise-Scrum_book.jpg" width="244" /></a></div>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><b><span style="font-size: large;"><i>Miguel, mi amigo, Vaya con dios! (You have more than earned it!!!)</i></span></b></span><br />
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;">Those who wish to help Mike's family (and six kids) in Mike's absence, please visit </span><span style="color: #1d2129; font-family: "georgia" , "times new roman" , serif;"><a href="https://www.gofundme.com/mikebeedlesupport" target="_blank">gofundme.com/mikebeedlesupport</a> </span>
<div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-32308118362547216292009-08-20T09:23:00.000-05:002009-08-21T20:35:59.019-05:00SOA, Mashups, Mashed Knees and Surgery<span style="font-family: georgia;">Today is my birthday - I had arthroscopic knee surgery last night and am feeling pretty good so far (happy birthday to me). I know I still have a lot of meds/painkillers in my system and that its going to feel more uncomfortable the next few days. I'm still hobbling around on crutches but I'm feeling much more confident that I can attend (and present at) <a href="http://www.agile2009.org/">Agile2009</a>.<br /><br />I received some very good books on Mashups and SOA a few months back and I'm finally getting a chance to look at them in some more detail. They really are quite good! I think Mashups are the "latest frontier" for realizing the promise of SOA, and a natural evolution from Wiki-webs. Here are the books:<br /><br /><ul><li><a style="font-weight: bold;" href="http://www.informit.com/title/0136135161">SOA Design Patterns</a>, by Thomas Erl</li><li><a style="font-weight: bold;" href="http://www.informit.com/title/032157947X">Mashup Patterns: Designs and Examples for the Modern Enterprise</a>, by Michael Ogrinz</li><li><a style="font-weight: bold;" href="http://www.informit.com/title/032159181X">Mashups: Strategies for the Modern Enterprise</a>, by J. Jeffrey Hanson</li></ul>If you follow the links above to the <a href="http://www.informit.com/">InformIT.com</a> homepage for each of the above books, you'll find some good excerpts and related articles that will give a preview of what to expect so you can judge for yourself.</span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-26737223022425459962009-08-13T00:12:00.001-05:002009-08-21T20:21:18.479-05:00BOOK: Running an Agile Project<span style="font-family:georgia;">First, on a personal note, I had the misfortune to tear cartilage in my right knee a couple days ago and will require surgery to repair/remove it. I'm hobbling around on crutches for the time being. I hope I can still attend (and present at) <a href="http://www.agile2009.org/">Agile2009</a>.<br /><br />Anyway, my review of Mike Holcombe's book <a style="font-weight: bold;" href="http://www.amazon.com/Running-Agile-Software-Development-Project/dp/0470136693">Running an Agile Software Development Project</a> appears in this month's <a href="http://www.agilejournal.com/">Agile Journal</a>.<br /><br /><blockquote style="font-family: times new roman; color: rgb(0, 0, 102);"><a target="_blank" href="http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470136693.html">Running an Agile Software Development Project</a> is an interesting book. On the surface it looks like it would be very academic, because the author, <a target="_blank" href="http://www.dcs.shef.ac.uk/%7Ewmlh/">Mike Holcombe</a>, was a University Professor at the time, and running an “agile software development factory” of students (albeit for a real commercial development shop). And yet what is described in the contents is very much the practical, real-world results of running agile projects with those same people for real IT software development work.<br /><br />[...]<br /><br />Overall, I found Running an Agile Software Development Project to be interesting and enjoyable. It still seems just a bit academic for my taste, and probably wouldn’t be the first book I would recommend on the subject unless it was for a classroom audience (in which case this book would be an excellent one to use).<br /></blockquote><br />You can <a href="http://www.agilejournal.com/articles/columns/featured-books-mainmenu-46/2149-featured-book-running-an-agile-software-development-project-by-mike-holcombe">read the full review here</a>!</span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-2460424785344722432009-08-07T00:21:00.006-05:002023-05-24T14:35:25.879-05:00WANTED: Seeking Single Agile Knowledge Development Tool-set<br />
<span><span style="font-family: georgia;">I'll be presenting at Agile2009 in Chicago on the </span><a href="http://agile2009.org/tools" style="font-family: georgia;">Tools for Agility</a><span style="font-family: georgia;"> stage on Tuesday 25 August, 4:45pm-5:30pm.</span><br /><br /><br /><i style="font-family: georgia;">Here is my session description from the Agile2009 conference website </i><span style="font-family: georgia; font-style: italic;">(</span><a href="https://drive.google.com/file/d/0B4cRE_u9k7pXSEV5TjBJZnk1ams/view"><span style="font-family: times; font-size: x-small;"><i>download PDF here</i></span></a><span style="font-family: georgia; font-style: italic;">)</span><br /></span><br />
<h2 class="with-tabs">
<span style="font-family: "georgia";">WANTED: Seeking Single Agile Knowledge Development Tool-set</span></h2>
<span style="font-family: "georgia";"><span style="font-style: italic;"></span></span><br />
<div class="content">
<span style="font-family: "georgia";">Aren’t code, backlog-items, tests, designs & documents all just different forms of system knowledge at different levels of detail? Why can’t the same tools help refactor, browse, search, and provide build/test automation for <em>non-code</em> forms of knowledge <em>without</em> requiring a separate tool/repository for each format? This talk is intended as a challenge to tool vendors/developers to see how this simple treatment of all non-code items as part of a single, unified project knowledge-base can be at once both immensely powerful, and imminently practical, without requiring too much added complexity.</span></div><div class="content"><span style="font-family: georgia;"><br /></span>
<div class="field field-type-text field-field-processmechanics">
<div class="field-label" style="font-weight: bold;">
<span style="font-family: "georgia";">Process/Mechanics</span></div>
<div class="field-items">
<div class="field-item">
<span style="font-family: "georgia";">Approximately ~30 minutes of slides/presentation to “make the case” for why this approach is useful and desirable, followed by discussion of challenges (to and from tool developers/vendors, as well as the rest of the audience) as to its usefulness and benefits, and why their current tools can’t easily do so and why the should or should not be easy to enhancement them to do it.</span><br />
<h2>
<span style="font-family: "georgia";">
Outline</span></h2>
<h3>
<span style="font-family: "georgia";">
Software development as knowledge development</span></h3>
<ul><span style="font-family: "georgia";">
<li>Source-Code as knowledge</li>
<li>Requirements (Stories) and Tests as knowledge</li>
<li>Other usable forms of project knowledge (e.g., build scripts & configuration, build/test result reports version control history/comments, online help & other supporting docs)</li>
</span></ul>
<h3>
<span style="font-family: "georgia";">
How would I do this?</span></h3>
<ul><span style="font-family: "georgia";">
<li>Refactoring Knowledge (thinking about the rest of the “knowledge” the way we think about the code, and its habitability, navigability, and structure/refactoring)</li>
<li>Applying other agile-practices (like TDD, Continuous Integration, etc.) to non-code knowledge development</li>
<li>Wiki-based skins, DSLs, and use-cases/design as domain-driven Wiki-word definitions <ul>
<li>Patterns (giving things names), Retrospectives results and lessons learned</li>
</ul>
</li>
<li>Viewing, searching EVERYTHING (even the code) via wiki?</li>
<li>The “Wu-Wei” of Traceability (Tracing without Tracing)</li>
<li>Versioning and operating on wiki-like entities, just like with code (e.g., making “working copies”, branches and tags)</li>
</span></ul>
<h3>
<span style="font-family: "georgia";">
DISCUSSION & CHALLENGE: Why can’t (or how can) YOUR tools do this!</span></h3>
<span style="font-family: "georgia";">Begin audience discussion/dialogue: Why can’t a tool like Eclipse or a Wiki-based CMS (such as Confluence) be used as a front-end to browsing/refactoring and navigating ALL the knowledge of the system? (not just code, but stories, tests, build/config data, CI reports, backlog, retrospective lessons).</span><br />
<span style="font-family: "georgia";">What makes it easy/hard for these and other tools like any of the following to do this, or to be simple “skins” or plug-ins on top of only a handful of tools instead of a whole kitchen sink full of separate tools and repositories.</span><br />
<ul><span style="font-family: "georgia";">
<li>Eclipse, Confluence, Twiki?</li>
<li>FIT, Fitnesse, Contour</li>
<li>Doxygen / Javadoc</li>
<li>Trac / Agile-Trac?</li>
<li>Jira / Remedy</li>
</span></ul>
<span style="font-family: "georgia";">See also a blog-entry of mine entitled <em><a href="http://bradapp.blogspot.com/2005/09/can-i-have-just-one-repository-please.html" title="blog-entry">Can I have just one repository please?</a></em></span></div>
</div>
</div>
<div class="field field-type-text field-field-learning-outcomes">
<div class="field-label" style="font-weight: bold;"><span style="font-family: "georgia";"><br /></span></div><div class="field-label" style="font-weight: bold;">
<span style="font-family: "georgia";">Learning outcomes</span></div>
<div class="field-items">
<div class="field-item">
<ul><span style="font-family: "georgia";">
<li>Thinking about Agile development as knowledge management & creation</li>
<li>Current barriers to using agile techniques and supporting tools for non-code artifacts </li>
<li>What do refactoring, TDD, continuous integration, etc. mean for <em>non-code</em> artifacts (and why you should care)</li>
<li>Use of wikis for organizing, structuring and refactoring ALL system knowledge</li>
<li>Why manual traceability is unnecessary (and even comes for free) when using such an approach</li>
</span></ul>
</div>
</div>
</div>
<div class="field field-type-userreference field-field-participants">
<div class="field-label">
<span style="font-family: "georgia";"><br /></span></div>
<div class="field-items">
</div>
</div>
<div class="field field-type-nodereference field-field-primary-personas">
<div class="field-label" style="font-weight: bold;">
<span style="font-family: "georgia";">Primary target persona </span></div>
<div class="field-items">
<div class="field-item">
<ul><span style="font-family: "georgia";">
<li>Tomas Tool-smith/Tool-vendor</li>
</span></ul>
</div>
</div>
</div>
<div class="field field-type-nodereference field-field-personas">
<div class="field-label" style="font-weight: bold;">
<span style="font-family: "georgia";">Other target personas</span></div>
<div class="field-items">
<ul><span style="font-family: "georgia";">
<li><a href="http://agile2009.org/node/61/popup" onclick="window.open('/node/61/popup', 'popup', 'width=500, height=400, location=no, menubar=no, toolbar=no'); return false;" target="popup">Billy, Business Analyst </a></li>
<li><a href="http://agile2009.org/node/59/popup" onclick="window.open('/node/59/popup', 'popup', 'width=500, height=400, location=no, menubar=no, toolbar=no'); return false;" target="popup">David, Agile Developer </a></li>
<li><a href="http://agile2009.org/node/71/popup" onclick="window.open('/node/71/popup', 'popup', 'width=500, height=400, location=no, menubar=no, toolbar=no'); return false;" target="popup">Patricia, Project Manager </a></li>
<li><a href="http://agile2009.org/node/64/popup" onclick="window.open('/node/64/popup', 'popup', 'width=500, height=400, location=no, menubar=no, toolbar=no'); return false;" target="popup">Tara, Tester</a></li>
</span></ul>
</div>
</div>
</div>
<span style="font-family: "georgia";">
<br /><span style="font-style: italic;">(</span><a href="https://drive.google.com/file/d/0B4cRE_u9k7pXSEV5TjBJZnk1ams/view" style="font-style: italic;">download PDF here</a><span style="font-style: italic;">)</span></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com2tag:blogger.com,1999:blog-10280668.post-8547886530142047772009-08-01T12:06:00.003-05:002009-08-18T12:56:49.739-05:00Studies on Effectiveness of TDD?<span style="font-family:georgia;">This question came-up in a discussion earlier this week: Do we know of published studies on this subject? A quick Google-search turned up the following for me ...<br /><br /><ul> <li><a href="http://www.idiacomputing.com/">George Dinwiddie</a>'s page on <a href="http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment"><em>Studies of Test-Driven Development</em></a> has links to a dozen or so, with summaries </li><li>A March 2009 InfoQ.com article <a href="http://www.infoq.com/news/2009/03/TDD-Improves-Quality"><em>Empirical Studies Show Test Driven Development Improves Quality</em></a> about a paper published in the Journal of Empirical Software Engineering </li><li>An XP2009 paper on <a href="http://www.xp2009.org/etsm2009/doc/Canfora_Visaggio_2009.pdf"><em>Measuring the impact of testing on code structure in Test Driven Development: metrics and empirical analysis</em></a>. </li><li>A <a href="http://works.bepress.com/djanzen/12/"><em>Survey of Evidence for TDD in Academia</em></a> (2008), published in ACM SIGCSE Bulletin </li><li><a href="http://www.slideshare.net/melnik/empirical-evidence-of-agile-methods-190997"><em>Empirical Evidence of Agile Methods</em></a> (2007) has a nice slide or two devoted to TDD </li><li>A Univ. of Karlsruhe study on <a href="http://wwwipd.ira.uka.de/Tichy/uploads/publikationen/136/MuellerHoefer2007.pdf"><em>The Effect of Experience on the TDD process</em></a> (2007) </li><li>An ITEA 2006 paper on <a href="http://www.agile-itea.org/public/deliverables/ITEA-AGILE-D2.7_v1.0.pdf">TDD Empirical Body of Evidence</a> </li><li>A 2006 Univ. of Kansas Ph.d thesis on <a href="http://portal.acm.org/citation.cfm?id=1195306"><em>An empirical evaluation of the impact of test-driven development on software quality</em></a> </li><li>An ISESE 2006 paper on <a href="http://evidencebasedse.com/?q=node/111">Evaluating Advantages of Test Driven Development: a Controlled Experiment with Professionals</a> </li><li>VTT <a href="http://agile.vtt.fi/docs/publications/2005/2005_business_quality_ifip.pdf"><em>Case Study of TDD in Mobile Software Software Development</em></a> (2005) </li></ul><br />Any others? Any comments on the above?<br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com2tag:blogger.com,1999:blog-10280668.post-40790827000043004142009-07-26T00:55:00.001-05:002009-08-18T12:55:59.133-05:00Resources on Retrospectives<span style="font-family:georgia;">I found a really good resource-list from <a href="http://idiacomputing.com/">George Dinwiddie</a> on <a href="http://idiacomputing.com/moin/IntrospectionAndRetrospectives">Introspection and Retrospectives</a> that includes the following list of resources (mostly patterns & techniques) about conducting retrospectives. It contains many (but not all) of the links below:<br /><br /><ul><li><a href="http://idiacomputing.com/moin/RestrospectiveTechniques">RestrospectiveTechniques</a> compiled by George Dinwiddie</li><li><a href="http://retrospectivewiki.org/index.php?title=Main_Page">Agile Retrospectives Resource Wiki</a></li><li><em>Singing the Songs of Project Experience: Patterns and Retrospectives</em> by Linda Rising and Esther Derby from <a href="http://www.estherderby.com/articles/rising-derby.pdf">Cutter IT Journal</a> (PDF)</li><li><em>Restrospective Agility</em> by Tim Mackinnon in <a href="http://www.ratio.co.uk/ov8pdf.pdf">Objective View</a> (PDF)</li><li><a href="http://www.retrospectives.com/">http://www.retrospectives.com/</a> Norm Kerth's website.</li><li>Esther Derby's <ul><li><a href="http://www.estherderby.com/weblog/archive/2006_03_01_archive.html#114320660266333594">Seven Reasons to Have a Retrospective</a></li><li><a href="http://www.estherderby.com/weblog/archive/2006_02_01_archive.html#114031552004362330">6 Reasons *not* to have a Retrospective</a></li><li><a href="http://www.estherderby.com/weblog/archive/2004_05_01_archive.html#108548723203236478">What a Retrospective Ain't</a></li><li><a href="http://www.estherderby.com/weblog/2007/04/two-more-ways-to-gather-data-in.html">Two more ways to gather data</a></li><li><a href="http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=14358">Five Tips for Retrospective Leaders and Meeting Moderators</a> and <a href="http://www.estherderby.com/weblog/2009/05/tips-for-retrospective-facilitators.html">Tips for Retrospective Facilitators</a></li></ul></li><li>Rachel Davies' <ul><li><a href="http://www.twelve71.org/blogs/rachel/archives/000752.html">Heartbeat Retrospectives</a></li><li><a href="http://www.infoq.com/articles/agile-retrospectives-davies">How To: Live and Learn with Retrospectives</a></li><li><a href="http://www.methodsandtools.com/archive/archive.php?id=63">Refactoring Your Development Process with Retrospectives</a></li><li>Marco Abis' <a href="http://brainscrum.wordpress.com/2006/05/22/retrospectives-in-and-on-action/">Retrospectives IN and ON action</a></li></ul></li><li>Sample chapters 3 & 5 from <a href="http://www.pragprog.com/titles/dlret/agile-retrospectives"><strong>Agile Retrospectives: Making Good Teams Great</strong></a> by Esther Derby and Diana Larsen: <ul><li><a href="http://media.pragprog.com/titles/dlret/Leading.pdf">Chapter 3, Leading Retrospectives</a></li><li><a href="http://media.pragprog.com/titles/dlret/Activities.pdf">Chapter 5, Selected Activities</a></li><li><a href="http://www.infoq.com/resource/articles/Agile-Retrospective-Derby-Larsen/en/resources/dlret-infoq.pdf">Chapter 10, Make it So</a></li><li>a 50min <a href="http://www.youtube.com/watch?v=qqtPZYigfNI">talk/presentation from Esther & Diana on YouTube</a></li></ul></li><li>Ellen Gottesdiener's <a href="http://ebgconsulting.com/Pubs/Articles/TeamRetrospectives-Gottesdiener.pdf">Team Retrospectives — for better iterative assessment</a> looks at the topic from a RUP perspective.</li><li>Bill Wake's <a href="http://xp123.com/xplor/xp0509/index.shtml">Some Patterns for Iteration Retrospectives</a></li><li>James Carr's <a href="http://blog.james-carr.org/2008/09/04/retrospective-patterns/">Retrospective Patterns</a></li><li>Ian Burgess' <a href="http://www.ianburgess.me.uk/software-development/agile-retrospective-lessons-learned">Agile Retrospectives Lessons Learned</a></li><li>Ilja Preuss' <a href="http://radio.javaranch.com/ilja/2009/03/25/1237998972110.html">Retrospective Anti-Patterns</a></li><li>Article: <a href="http://www.agilejournal.com/component/content/article/773-emergent-design-leveraging-agile-retrospectives-to-evolve-your-architecture">Leveraging Agile Retrospectives to Evolve Your Architecture</a></li><li>Simon Baker on <a href="http://www.think-box.co.uk/blog/2007/12/retrospective-using-appreciative.html">Retrospective Using Appreciative Inquiry</a> (see <a href="http://www.ayeconference.com/appreciativeretrospective/">similar article by Diana Larsen</a>)</li><li>Ben Coombs' <a href="http://www.bencoombs.com/bens_blog/2008/08/agile-retrospec.html">A Retrospective based on Agile Values</a></li><li>Mark Levison's <a href="http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html">Agile Games for Making Retrospectives Interesting</a></li><li>Kris Blake's <a href="http://theagileleap.blogspot.com/2009/04/retrospective-agenda-high-performing.html">Retrospective Agenda for High-Performing Teams</a></li><li><a href="http://www.scrumalliance.org/articles/30-seven-ways-to-revitalize-your-sprint-retrospectives" rel="nofollow">Scrum Alliance - Seven Ways to Revitalize Your Sprint Retrospectives</a></li><li>Fabio Periera's <a href="http://fabiopereira.me/blog/2008/11/23/goal-driven-retrospective/">Goal-Driven Retrospective</a></li><li>Mishkin Berteig's <a href="http://www.berteigconsulting.com/archives/AgileWorkCheatSheetRetrospectives.pdf" rel="nofollow">Agile Work: Cheat-Sheet for Retrospectives</a></li><li><a href="http://www.agilejournal.com/component/option,com_magazine/func,show_article/id,51/" rel="nofollow">Agile Journal - Iteration and Release Retrospectives: The Natural Rhythm for Agile Measurement</a></li><li>Retrospectives Content on <a href="http://www.infoq.com/retrospectives">InfoQ.com/retrospectives</a>, including ... <ul><li><a href="http://www.infoq.com/presentations/Heartbeat-Retrospectives-Boris-Gloger" rel="nofollow">InfoQ: Heartbeat Retrospectives to Amplify Team </a></li><li><a href="http://www.infoq.com/news/2008/09/making-retros-stick" rel="nofollow">InfoQ: Making Retrospective Changes Stick</a></li><li><a href="http://www.infoq.com/news/2007/11/retrospective-length" rel="nofollow">InfoQ: How Long Should Retrospectives Last?</a></li><li><a href="http://www.infoq.com/news/2008/04/retro-follow-thru" rel="nofollow">InfoQ: First (Forgotten?) Rule Of The Retrospective: Follow Through</a></li><li><a href="http://www.infoq.com/news/2009/03/Burn-Down-And-Retrospectives" rel="nofollow">InfoQ: Annotated Burn-Down Charts Help During Retrospectives</a></li><li><a href="http://www.infoq.com/news/2007/06/davies-agile-retrospectives" rel="nofollow">InfoQ: Frequent Retrospectives Accelerate Learning and Improvement</a></li></ul></li><li>Jim Shore's <a href="http://jamesshore.com/Agile-Book/retrospectives.html">brief recap</a> and <a href="http://jamesshore.com/downloads/art-of-agile/retrospective-format.pdf">retrospective format</a> from <em>The Art of Agile Development</em> (<a title="ISBN" href="http://www.amazon.com/exec/obidos/ISBN=0596527675/alberg30-20">0596527675</a>)</li></ul><br /><br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-55437113868458902782009-07-17T01:35:00.007-05:002009-09-07T18:57:47.978-05:00Refactoring @ Scale<span style="font-family:georgia;">In my previous post, <a href="http://bradapp.blogspot.com/2009/07/refactoring-for-agility.html">Refactoring for Agility</a>, I posted an outline and some thoughts for Part I of an Overview on Refactoring. Now I'm ready to post on Part II which is about refactoring @ scale. By "at scale" I mean in the larger context of other agile practices, as well as for large projects.<br /><br /><strong>PART II - REFACTORING @ SCALE</strong><br /><br /><strong>1. Scaling-Up</strong><br /><ul><li>To scale refactoring for larger projects, some additional techniques & issues must be added to the mix.</li><li style="font-style: italic; color: rgb(102, 0, 0);">Note that this is “<span style="font-weight: bold;">in addition to</span>” (not “instead of”)</li></ul><ul><table border="1"><tbody><tr><td style="font-weight: bold; text-align: center;"><span style="font-size:130%;">Refactoring In-the-Small</span></td><td style="font-weight: bold; text-align: center;"><span style="font-size:130%;">Refactoring @ Scale</span></td></tr><tr><td style="text-align: center;">Small, Fast & Frequent Refactorings</td><td style="text-align: center;">Larger, Periodic & Planned Restructurings</td></tr><tr><td style="text-align: center;">Emergent Design</td><td style="text-align: center;">Incremental Design & Evolutionary Architecture</td></tr><tr><td style="text-align: center;">Deferred Refactoring</td><td style="text-align: center;">Restructuring & Technical Debt</td></tr><tr><td style="text-align: center;">Code Smells</td><td style="text-align: center;">Architecture Smells</td></tr><tr><td style="text-align: center;">Design Principles & Patterns</td><td style="text-align: center;">Software Modifiability Tactics</td></tr><tr><td style="text-align: center;">Simple/Clean Code</td><td style="text-align: center;">Supple/Domain-Driven Design</td></tr></tbody></table></ul><br /><strong>2. Emergent Design</strong><br /><ul><li>Emergent Design is a fancy name for the resulting design that “emerges” from the synergy of combining Refactoring together with TDD, Continuous Integration and Automated Testing.</li><li><strong><a style="font-style: italic;" href="http://blog.bradapp.net/2009/07/emergent-design-and-evolutionary.html">Emergent Design</a></strong> means that ...<br /></li></ul><strong>3. <a href="http://blog.bradapp.net/2009/06/technical-debt-definition-and-resources.html">Technical Debt</a></strong><a href="http://blog.bradapp.net/2009/06/technical-debt-definition-and-resources.html"> [a.k.a. Design Debt]</a><br /><strong>4. Restructuring Technical Debt</strong><br /><ul><li>If we accrue a non-trivial amount of technical debt, we can’t simply “refactor” it away.</li><li>Paying it off typically requires restructuring efforts (or even reengineering) that must be planned.</li><li>Iteration plans must accommodate specific tasks for these restructuring efforts (or even be dedicated to restructuring).</li><li>Ignoring it, or deferring it for very long is not a viable option!</li></ul><strong>5. Overview of Restructuring</strong><br /><ul><li>Identifies higher-level issues (“architecture smells”) that typically represent violations of known principles of good software architecture & design.</li><li>Periodically applies larger-scale “refactorings” and/or many small refactorings that were previously deferred.</li><li>The goal is to “pay down technical debt” in order to limit the increasing costs of accumulated complexity.</li><li>Typically requires a concerted effort that must be separately planned.</li><li>Uses not only design patterns/principles, but also architectural patterns/principles, as well as software modifiability tactics.</li></ul><strong>6. Refactoring vs. Restructuring</strong><br /><ul><li>See Martin Fowler's description in <a style="font-style: italic;" href="http://www.blogger.com/martinfowler.com/bliki/RefactoringMalapropism.html">Refactoring Malapropism</a><br /></li></ul><strong>7. Restructure Periodically</strong><br /><ul><li>Restructuring is often associated with absent or neglectful refactoring and/or design.</li><li>But … Any large software project spanning multiple teams eventually needs restructuring.<ul><li>Even in the presence expert-level architecture, design & continuous refactoring</li><li>This is just a reality of software evolution/entropy</li></ul></li><li>Therefore … Large software projects should assume that periodic restructuring will be necessary, and should plan accordingly to:<ul><li>Clean-up accumulated code-smells and apply numerous refactorings that were deferred but are now sorely needed, </li><li>Address architecture smells by applying restructurings, patterns and modifiability tactics that have broader impact.</li></ul></li></ul><strong>8. Architecture Smells</strong><br />See Stefan Roock's and Martin Lippert's book <a href="http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470858923.html">Refactoring in Large Software Projects</a> (There was an earlier version of their work entitled <i><a href="http://www.martinlippert.org/publications/review/LargeRefactoringsReviewVersion.pdf">Large Refactorings"</a></i>).<br /><ul><li>Smells in Dependency Graphs</li><li>Smells in Inheritance Hierarchies</li><li>Smells in Packages</li><li>Smells in Subsystems</li><li>Smells in Layers</li></ul><strong>9. Software Modifiability Tactics</strong><br /><ul><li>Localize Changes (increase cohesion)</li><li>Prevent Ripple Effects (reduce coupling)</li><li>Defer Binding-time (defer decision-making)</li></ul><strong>10. When to Consider/Plan Restructuring?</strong><br /><strong>11. Evolutionary Architecture</strong><br /><ul><li>Software Architecture concerns infrastructure elements that must exist before you can begin execution.<ul><li>Architecture is about things that are hard to change later, it is difficult to allow an architecture to emerge.</li><li>For large projects, this includes high-level organization of the system into functionality/elements that will be allocated to separate teams.</li></ul></li><li>Key techniques of <a href="http://blog.bradapp.net/2009/07/emergent-design-and-evolutionary.html">Evolutionary Architecture</a> include:<ul><li>Deferring Irreversible Decisions to the “Last Responsible Moment” (LRM Principle) </li><li>Architectural “Spike”, Architecture Iteration and/or Spike Iteration</li></ul></li></ul><strong>12. Incremental Design</strong><br /><ul><li>Design evolves incrementally, iteration by iteration, based on current business priorities and discovered technical limitations.</li><li>Incremental Design …<ul><li>Does not prohibit thinking about higher-level design.</li><li>Does encourage planning in detail only what will be constructed soon.</li></ul></li><li>Focus is on “Just Enough, Just-In-Time” :<ul><li>Specifying too much detail too soon causes more rework later.</li><li>But doing less now and saving the rest for later should not require significantly more work later than it would today.</li></ul></li><li>We must do <a style="font-style: italic;" href="http://blog.bradapp.net/2009/07/jedi-programming-just-enough-design.html">Just Enough Design Initially</a> to attain the right balance of anticipation and adaptation.</li></ul><strong>13. Just Enough Design Initially (JEDI)</strong><br /><ul><li>Initial design (before coding) is still necessary.<ul><li>This use of “JEDI” was coined by Stephen Palmer as part of Feature-Driven Development (FDD)</li></ul></li><li>Basic rule of thumb to tell when “JEDI” is achieved:<ul><li>At iteration-scope, when, after one pass through the iteration backlog, modeling in small groups does not produce any new classes or associations of real significance.</li><li>At task/TDD scope, when we have defined enough structure & interface(s) to know specifically what code to write/test, precisely where to write it, and exactly how to invoke it.</li></ul></li><li>Techniques of “the JEDI way” include:<ul><li>Collaborative Domain Modeling and Color Modeling [from FDD]</li><li>Supple Design techniques & patterns</li><li>Domain-Driven Design (a.k.a. DDD -- see <a href="http://domaindrivendesign.org/">domaindrivendesign.org</a>)</li><li>Design Blitz & other Agile Modeling techniques (see <a href="http://www.agilemodeling.com/">agilemodeling.com</a>)</li></ul></li></ul><strong>14. Supple Design & DDD</strong><br /><ul><li>Domain-Driven Design (DDD) approaches modeling the core logic of the software by focusing on the domain.<ul><li>The basic idea is the design should directly reflect the core business domain and domain-logic of the problem to solve</li><li>This helps understanding the problem as well as the implementation and increases maintainability of the software.</li></ul></li><li>DDD uses common principles and patterns as "building blocks" to model & create a "supple design”<ul><li>Supple: pliant, malleable, limber, yielding or changing readily. </li><li>The design is firm yet flexible, with structure and intent both clearly conveyed and deeply realized by the code.</li></ul></li><li>Patterns of Supple Design include: Intention-Revealing Interfaces, Ubiquitous Language, Side-Effect-Free Functions, Assertions, Conceptual Contours, Standalone Classes, Closure of Operations, Declarative Style </li></ul><br /><strong>15. Resources:</strong><br /> <br /><b> Resources on Emergent Design and Evolutionary Architecture</b><ul><li>Neal Ford, <b><a href="http://www.ibm.com/developerworks/views/java/libraryview.jsp?search_by=evolutionary+architecture+emergent+design"><i>Evolutionary Architecture and Emergent Design</i></a></b> series of articles on IBM developerWorks: </li><li><b><a href="http://www.informit.com/title/0321509366">Emergent Design</a>: The Evolutionary Nature of Professional Software Development, </b>by Scott L. Bain</li><li><b><a href="http://architectureinanagileorganization.com/"><i>Architecture in an Agile Organization</i></a></b><i> by Chris Sterling</i><i> (online)</i></li></ul><b> Resources on Restructuring</b><ul><li><b><a href="http://www.google.com/url?sa=t&source=web&ct=res&cd=4&url=http%3A%2F%2Fwww.infoq.com%2Finterviews%2Fmichael-stal-on-architecture-refactoring&ei=FZdlSszqAYfENsTIlZUB&usg=AFQjCNGgGxdn_zhxA-a0Gfyrq9JnVa_N9w&sig2=hws48fbHt5iLDvR3KVjlWA">InfoQ: Michael Stal on <i>Architecture Refactoring</i></a></b></li><li><b><a href="http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470858923.html">Refactoring in Large Software Projects: Performing Complex Restructurings Successfully</a></b>, by Martin Lippert, Stephen Roock <i>(also an </i><b><a href="http://www.martinlippert.org/publications/review/LargeRefactoringsReviewVersion.pdf"><i>earlier version online</i></a></b><i>)</i></li><li><b><a href="http://scg.unibe.ch/download/oorp/">Object-oriented Reengineering Patterns</a></b>, by S. Demeyer, S. Ducasse & O. Nierstrasz <i>(freely downloadable online)</i></li></ul><b> Resources on Technical Debt</b><ul><li><b><a href="http://www.danube.com/whitepapers/technical-debt" title="http://www.danube.com/whitepapers/technical-debtTechnical Debt and Design Death"><i>Technical Debt and Design Death</i></a><i>:</i></b><i>How to ensure you can deliver business value in the future as well as in the present; </i>by Kane Mar and Michael James</li><li><b><a href="http://www.ibm.com/developerworks/rational/library/edge/09/jun09/designdebteconomics/index.html" title="http://www.ibm.com/developerworks/rational/library/edge/09/jun09/designdebteconomics/index.html"><i>Design debt economics</i></a>: </b><i>A vocabulary for describing the causes, costs, and cures for software maintainability problems</i><b>;</b>by John Elm, IBM developerWorks, June 2009</li><li><b><a href="http://www.construx.com/Page.aspx?hid=2801">Managing Technical Debt</a></b> and <b><a href="http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx">10X Software Development - Technical Debt</a></b>, by Steve McConnell</li><li><b><a href="http://accu.org/index.php/journals/1301"><i>Managing Technical Debt</i></a></b><i>; by Tom Brazier </i></li><li><b><a href="http://www.think-box.co.uk/blog/2005/11/repaying-technical-debt.html"><i>Repaying Technical Debt</i></a></b><i>; by Simon Baker </i></li><li><b><a href="http://architectureinanagileorganization.com/software-debt/"><i>Software Debt: Depreciation of Value for Software Assets</i></a></b><i> and </i><b><a href="http://architectureinanagileorganization.com/chapter-07-technical-debt/"><i>Technical Debt: Reducing Internal Quality for Short-term Gain</i></a></b><i>, by Chris Sterling</i></li><li><b><a href="http://www.pragprog.com/the-pragmatic-programmer/extracts/software-entropy"><i>Software Entropy: Don’t Tolerate Broken Windows</i></a></b>, and <b><a href="http://media.pragprog.com/articles/sep_02_zerotol.pdf"><i>Zero-Tolerance Construction</i></a></b> by Andy Hunt and Dave Thomas</li></ul><b> Resources on Modifiability Tactics</b><ul><li><a href="http://www.sei.cmu.edu/library/abstracts/reports/07tr002.cfm"><b><i>Modifiability Tactics</i></b></a>, SEI @ CMU Technical Report CMU/SEI-2007-TR-002</li><li><a href="http://www.tar.hu/softarchpract/ch05lev1sec3.html"><b>Modifiability Tactics, Chapter 5 section 3</b></a> of <b>Software Architecture in Practice</b></li><li><b><a href="http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect200708.cfm"><i>Understanding Architectural Patterns in Terms of Tactics and Models</i></a><i></i></b></li><li><a href="http://www.cs.aau.dk/%7Emly/dbsa07/L8_Design_and_Tactics.pdf"><b><i>Design and Tactics</i></b></a>, Lecture notes from an <st1:place st="on"><st1:placename st="on">Aalborg</st1:placename><st1:placetype st="on"> University </st1:placetype></st1:place>course on <b><a href="http://www.cs.aau.dk/%7Emly/dbsa07/">Database and Software Architecture</a></b></li></ul><b> Resources on Supple Design & DDD</b><ul><li><a href="http://en.wikipedia.org/wiki/Domain-driven_design">Wikipedia page on DDD</a></li><li><a href="http://www.infoq.com/articles/ddd-in-practice%20and%20http://www.typo3-media.com/blog/domain-driven-design-introduction.html"><b>DDD Intro Article</b></a><b><a href="http://www.typo3-media.com/blog/domain-driven-design-introduction.html"></a></b></li><li><b><a href="http://www.typo3-media.com/blog/domain-driven-design-introduction.html">DDD – a Brief Introduction</a><br /></b></li><li><b><a href="http://www.cs.colorado.edu/%7Ekena/classes/6448/s05/lectures/lecture30.pdf">DDD: Supple Design Patterns</a><br /></b></li><li><a href="http://domaindrivendesign.org/resources/what_is_ddd"><b>DDD Pattern Summaries</b></a></li><li><b>Free</b> mini-eBook: <a href="http://www.infoq.com/minibooks/domain-driven-design-quickly"><b>Domain-Driven Design Quickly</b></a></li><li><b>Yet another free</b> mini-eBook: <b><a href="http://dddstepbystep.com/">Step-by-Step Guide to DDD</a><br /></b></li><li><b>See also <span style="text-decoration: underline;"></span></b><b><a href="http://domaindrivendesign.org/">domaindrivendesign.org</a></b> and <b><a href="http://www.infoq.com/domain-driven-design">infoq.com/domain-driven-design</a></b></li></ul><br /><br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-51514393277218747342009-07-16T01:32:00.003-05:002009-08-10T10:36:53.206-05:00Refactoring for Agility<span style="font-family:georgia;">Some of you might have guessed from my recent posts on <a style="font-style: italic;" href="http://blog.bradapp.net/2009/07/emergent-design-and-evolutionary.html">Emergent Design</a>, <a style="font-style: italic;" href="http://blog.bradapp.net/2009/06/technical-debt-definition-and-resources.html">Technical Debt</a>, <a style="font-style: italic;" href="http://blog.bradapp.net/2009/07/jedi-programming-just-enough-design.html">JEDI Programming</a>, and <a style="font-style: italic;" href="http://blog.bradapp.net/2009/06/5s-qualities-of-well-designed-well.html">5S Qualities of Well Designed, Well-Factored Code</a>, that I've been looking into trying to teach the fundamentals of refactoring and how it scales to larger projects. I've gathered some references and quotes and some ideas for slides that I wanted to bounce around on my blog.<br /><br />Here is an outline and some thoughts for part I of some slides ...<br /><br /><strong>PART I - REFACTORING FOR AGILITY</strong><br /><br /><strong>1. Overview of Refactoring</strong><br /><ul><li>Identifies design-maintenance issues (“code smells”) that typically represent violations of known principles of good design.</li><li>Incrementally and iteratively applies a set of design improvement techniques (“refactorings”).</li><li>The goal is to minimize complexity & duplication in order to maximize simplicity & ease-of-change.</li><li>Encourages the “right” design details to emerge “just-in-time” with minimal guesswork/rework.</li><li>Scaling-up includes the use of periodic restructuring, initial & incremental design (“just enough”), and evolutionary architecture.</li></ul><br /><strong>2. Refactoring Defined</strong> [cite definition(s)]<br /><br /><strong>3. Refactoring Myths -- Refactoring is NOT …</strong><br /><ul><li>“Rework” – redesigning things that could, and should, have been designed correctly in the first place.</li><li>Design “gold-plating” – work that adds no business value, and merely serves to stroke the egos of perfectionists who are out of touch with business reality.</li><li>Miscellaneous code “tidying” – the kind that is “nice to have,” but should only happen when the team has some slack-time, and is a luxury we can do without, without any serious consequences. </li><li>A license to “hack” – avoiding any and all initial design & analysis and instead jumping straight to coding with no “real” design.</li><li>Reengineering – large-scale restructuring that requires a concerted effort over the course of several weeks/months to re-write or re-architect significant parts of the system.</li></ul><strong>4. Refactoring IS …</strong><br /><ul><li>A systematic approach to source-code “hygiene” that minimizes the chances of introducing bugs</li><li>Improving the design of the code after it has been written</li><li>A behavior-preserving transformation of source-code structure</li><li>The process of simplifying & consolidating a work-product by making several, small, successive revisions focused on: preserving correctness, removing redundancy, revealing thoughts & intentions, and improving clarity & conciseness.</li><li>A disciplined way of making changes while exposing the project to significantly less risk.</li><li>An effective means to address the economic reality of software growth/complexity by reducing & amortizing its cost throughout the daily business of code development & maintenance activities.</li></ul><strong>5. Why Refactor?</strong><br /><strong>6. How to Refactor</strong><br /><strong>7. Rules of Clean Code</strong><br /><strong>8. Rules for Simple Code</strong><br /><strong>9. The Steps of Refactoring</strong><br /><strong>10. Code Smells</strong><br /><strong>11. Categories of Refactorings</strong><br /><ul><li>Small Refactorings</li><li>Larger Refactorings/Restructurings<br /></li><li>Each category contains as many as a dozen or more refactorings, most of which are catalogued at http://refactoring.com/catalog/<br /></li></ul><br /><strong>12. Refactorings</strong> (Some refactorings from real projects)<br /><ul><li>See http://refactoring.com/catalog/ for an up-to-date list (and the “Refactoring to Patterns” catalog too)</li></ul><strong>13. What to do if …?</strong><br /><ul><li>I spot a “smell” that is not already known or catalogued?</li><li>There is no specific known/catalogued “refactoring” for what I think I need?</li></ul><strong>14. When to Refactor?</strong><br /><ul><li>While adding functionality</li><li>While fixing a bug</li><li>While reviewing code</li><li>After coding the same/similar thing for the third time (to “factor out” the duplication)</li><li>A.k.a.: The Rule of Three: 3 strikes and you refactor.</li><li>After the third time you deferred refactoring a change, for any reason [The Rule of Three, again]</li><li>Before the end of the iteration if you haven’t been following The Rule of Three </li></ul><strong>15. Refactor Continually</strong><br /><strong>16. When NOT to Refactor?</strong><br /><ul><li>When the build is broken or tests don’t pass</li><li>When it would compromise meeting an impending deadline or commitment</li><li>When the code in question really just needs to be re-written “from scratch”</li><li>When it would modify code/interfaces that could significantly impact/break other work (e.g.: Published/public interfaces and protocols, Database schemas/tables/operations)</li><li>Sometimes we must defer refactoring for later and/or plan for subsequent restructuring</li></ul><strong>17. Refactoring to Patterns & Principles</strong><br />Software Design Principles and Design Patterns are the underlying foundation for Refactoring:<br /><ul><li>Code smells (a.k.a “code pathologies”): Signal a possible violation of design principles, Suggest which refactoring may be needed</li><li>Refactoring: Correct a design principle violation (at least partially), Converge toward common design patterns </li><li>Design Patterns: Reconcile forces among conflicting design concerns,Restore balance between competing design principles</li><li>Design Principles: Lead us to attain desired design qualities/attributes</li></ul><strong>18. Design Attributes/Code Qualities</strong><br />Qualities of Highly Maintainable Software:<br /><ul><li>Loose Coupling & High Cohesion</li><li>Hierarchy (Structural Decomposition)</li><li>Abstraction, Encapsulation & Modularity</li><li>Sufficiency, Parsimony and Primitiveness</li><li>Readability</li><li>Testability</li><li>Modifiability</li><li>Serviceability</li></ul><strong>19. Design Principles: SOLID, SoC, DRY, Shy</strong><br /><ul><li>The SOLID Principles of Object-Oriented Design (from Uncle Bob)<br /></li><li>The SoC Principle: Separation of Concerns — separate interface from implementation, policy from mechanism, behavior from construction, commands from queries, ...</li><li>The DRY Principle: Don’t Repeat Yourself (Eliminate Duplication), Single Point of Truth</li><li>The “Structure-Shy” Principle: (“Tell, Don’t Ask!”), The Law of Demeter, Principle of Least Assumed Knowledge</li></ul><strong>20. Other Acronyms of Simple/Agile Design</strong><br /><ul><li>OAOO – Say Things Once And Only Once (restatement of the DRY principle)</li><li>DTSTTCPW – Do The Simplest Thing That Could Possibly Work! (restatement of the KISS principle)</li><li>YAGNI – You Aren’t Gonna Need It!</li><li>The LRM Principle: Defer Commitment of Irreversible Decisions to the Last Responsible Moment!</li><li>BDUF – Big Design Up-Front! (vs. JEDI)</li><li>JEDI – Just Enough Design Initially/In-front!</li><li>DDD – Domain-Driven Design</li></ul><strong>21. Design Patterns</strong><br /><strong>22. Summary: Refactoring for Agility</strong><br /><ul><li>Successively applies small behavior-preserving transformations to eliminate code smells</li><li>Based on proven design principles and patterns for achieving maintainability & modifiability</li><li>Good automated testing is a prerequisite</li><li>Refactoring is not rewriting, rework or restructuring</li><li>With refactoring, we continuously invest nominal effort to reduce the risk & cycle-time of changes</li><li>The goal is to minimize complexity & duplication in order to maximize simplicity & ease-of-change.</li><li>Practiced in a highly disciplined manner, it promotes:<ul><li>Sufficient functionality </li><li>Simple & clean code</li><li>Supple design</li><li>Serviceable software</li><li>Sustainable team velocity</li></ul></li></ul><br /><strong>23. Resources:</strong><br />Code Smells:<br /><ul><li><i><a href="http://www.testingeducation.org/pt/Refactoring-smells.pdf">Introduction to Code Smells and Refactoring</a></i> from <a href="http://www.testingeducation.org/">TestingEducation.org</a><br /> </li> <li><i><a href="http://www.cs.siue.edu/wwhite/CS325/CourseNotes/07_Kerievsky0111.ppt">Code Smells and Refactoring to Patterns</a></i>, by <a href="http://www.industriallogic.com/">Josh Kerievsky</a> </li> <li><i><a href="http://wiki.swelab.info/selabwiki/images/4/49/20070523.ppt">Refactoring and Code Smells</a></i> </li> <li><a href="http://c2.com/xp/CodeSmell.html">The original WikiWiki CodeSmells page</a></li> <li><a href="http://martinfowler.com/bliki/CodeSmell.html">Martin Fowler's Code Smells page</a> </li> <li><a href="http://sis36.berkeley.edu/projects/streek/agile/bad-smells-in-code.html">A Catalogue of Bad Smells in Code</a>, by Martin Fowler and Kent Beck </li> <li><a href="http://www.soberit.hut.fi/mmantyla/badcodesmellstaxonomy.htm">A Taxonomy of Bad Code Smells</a> </li> <li><a href="http://www.codinghorror.com/blog/archives/000589.html">CodingHorror.com's list of Code Smells</a> </li> <li><a href="http://www.industriallogic.com/papers/smellstorefactorings.pdf">Smells to Refactorings Quick Reference</a>, by <a href="http://www.industriallogic.com/">Josh Kerievsky</a> </li> <li><a href="http://wiki.java.net/bin/view/People/SmellsToRefactorings">Gene Garcia's mapping of CodeSmells to Refactorings</a> </li> <li><i><a href="http://www.ibm.com/developerworks/library/j-ap07088/">Using Static Analysis Tools to Identify Code Smells</a></i>, IBM developerWorks article by <a href="http://www.testearly.com/">Paul Duvall</a></li></ul>Design Principles:<br /><ul><li>S.O.L.I.D. Principles e-Book (free) <a href="http://www.lostechies.com/content/pablo_ebook.aspx">http://www.lostechies.com/content/pablo_ebook.aspx</a><br /> </li> <li>An O-O Primer, <a href="http://www.rgoarchitects.com/Files/ooprimer.pdf">http://www.rgoarchitects.com/Files/ooprimer.pdf</a><br /> </li> <li>The Principles of Object-Oriented Design: <a href="http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod">http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod</a><br /> </li> <li>Design Principles and Patterns, <a href="http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf">http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf</a> and <a href="http://www.oodesign.com/">http://www.oodesign.com/</a><br /></li> <li>The Art of SoC (Separation of Concerns) <a href="http://www.ctrl-shift-b.com/2008/01/art-of-separation-of-concerns.html">http://www.ctrl-shift-b.com/2008/01/art-of-separation-of-concerns.html</a><br /> </li> <li>Tell, Don’t Ask, <a href="http://www.pragprog.com/articles/tell-dont-ask">http://www.pragprog.com/articles/tell-dont-ask</a><br /> </li> <li>O-O in One Sentence: Keep it Shy, DRY, and Tell the Other Guy! <a href="http://media.pragprog.com/articles/may_04_oo1.pdf">http://media.pragprog.com/articles/may_04_oo1.pdf</a><br /> </li></ul>Design Patterns:<br /> - Online Resources:<br /><ul><li><a href="http://en.wikipedia.org/wiki/Design_pattern">Wikipedia on Design Patterns</a> </li> <li>The Patterns Home page: <a href="http://www.hillside.net/patterns">hillside.net/patterns</a></li> <li><a href="http://www.oodesign.com/">Design Patterns Reference</a> and <a href="http://www.cs.wustl.edu/%7Eschmidt/tutorials-patterns.html">Patterns Tutorials</a></li> <li><a href="http://docs.bradapp.net/patterns-intro.html">Patterns & Software: Essential Concepts & Terminology</a></li></ul> - Books:<br /><ul><li><a href="http://www.informit.com/title/0201633612">Design Patterns</a>, by the “Gang of Four” <i>(the book that started it all)</i></li> <li><a href="http://www.cse.wustl.edu/%7Eschmidt/POSA/">POSA Series of books</a> on Pattern-Oriented Software Architecture</li> <li><a href="http://oreilly.com/catalog/9780596007126/">Head First Design Patterns</a>, from the O’Reilly <a href="http://oreilly.com/store/series/headfirst.html">Head First</a> Series</li> <li><a href="http://www.informit.com/title/0321213351">Refactoring to Patterns</a>; by Joshua Kerievsky</li> <li><a href="http://www.informit.com/title/0135974445">Agile Software Development, Principles, Patterns, and Practices</a> by Robert C. Martin</li> <li><a href="http://www.informit.com/title/0321413091">Implementation Patterns</a>; by Kent Beck </li> <li><a href="http://www.informit.com/title/0321247140">Design Patterns Explained (2ed)</a>; by Alan Shalloway, James Trott</li></ul>Other Agile Design Slogans:<br /><ul><li>XP Simplicity Rules, <a href="http://c2.com/cgi/wiki?XpSimplicityRules">http://c2.com/cgi/wiki?XpSimplicityRules</a><br /></li> <li>Essential XP: Simple Design, <a href="http://www.xprogramming.com/xpmag/expEmergentDesign.htm">http://www.xprogramming.com/xpmag/expEmergentDesign.htm</a><br /></li> <li>DTSTTCPW - <a href="http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork">http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork</a><br /></li> <li>OAOO - <a href="http://c2.com/cgi/wiki?OnceAndOnlyOnce">http://c2.com/cgi/wiki?OnceAndOnlyOnce</a><br /></li> <li>YAGNI - <a href="http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It">http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It</a><br /></li> <li>LRM - <a href="http://stevesmithblog.com/blog/delaying-decisions/">http://stevesmithblog.com/blog/delaying-decisions</a>, <a href="http://vig.pearsoned.co.uk/samplechapter/0321150783.pdf">http://vig.pearsoned.co.uk/samplechapter/0321150783.pdf</a><br /></li> <li>BDUF - <a href="http://en.wikipedia.org/wiki/Big_Design_Up_Front">http://en.wikipedia.org/wiki/Big_Design_Up_Front</a><br /> </li> <li>JEDI - <a href="http://www.featuredrivendevelopment.com/node/507">http://www.featuredrivendevelopment.com/node/507</a><br /> </li> <li>DDD - <a href="http://www.domaindrivendesign.org/">http://www.domaindrivendesign.org/</a><br /></li></ul></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-85982656611426269252009-07-14T01:02:00.001-05:002009-08-10T08:52:51.687-05:00Mercurial, Git and Scala<span style="font-family:georgia;">Three more brand new books I just received that are worth mentioning ...<br /><br /><ul><li><a style="font-weight: bold;" href="http://oreilly.com/catalog/9780596520120/">Version Control with Git</a>: Powerful tools and techniques for collaborative software development, by Jon Loeliger, O'Reilly, 2009</li><br /><li><a style="font-weight: bold;" href="http://oreilly.com/catalog/9780596800673/">Mercurial: The Definitive Guide</a> -- Modern Software for Collaboration, by Bryan O'Sullivan, O'Reilly, 2009 (also see the online version at <a href="http://hgbook.red-bean.com/">hgbook.red-bean.com</a>)</li><br /><li><a style="font-weight: bold;" href="http://pragprog.com/titles/vsscala/programming-scala">Programming Scala</a>: <span style="font-weight: bold;">Tackle Multi-Core Complexity on the Java Virtual Machine</span>,<br />by Venkat Subramaniam, Pragmatic Programmers, 2009</li></ul><br />For those who may not know ...<br /><ul><li><a href="http://mercurial.selenic.com/">Mercurial</a> (like <a href="http://www.git-scm.org/">Git</a>) is an open-source, <a href="http://blog.bradapp.net/2008/02/distributed-version-control-systems.html">distributed version-control system</a>.</li><br /><li>While <a href="http://www.scala-lang.org/">Scala</a> is the "hot" new JVM-based programming language that not only contains the "best of both worlds" from other statically-typed languages (like Java) as well as dynamic languages like <a href="http://groovy.codehaus.org/">Groovy</a>, but also the best of both worlds from object-oriented programming languages (OOPLs) and functional programming languages (like <a href="http://erlang.org/">Erlang</a> and <a href="http://www.haskell.org/">Haskell</a>). Plus it has message-passing and actor-based support for concurrency (like Erlang) while still being strongly typed and having access to all your favorite Java APIs (and anything else that compiles to JVM). Not too mention that Scala has a kick-butt Web development framework called <a href="http://liftweb.net/">Lift</a> that is a next-generation framework to the likes of <a href="http://rubyonrails.org/">Rails</a>/<a href="http://grails.org/">Grails</a> and <a href="http://struts.apache.org/">Apache Struts</a>.</li></ul><br />Scala is my first pick for the programming language that is most excitingly poised for the <a href="http://www.gotw.ca/publications/concurrency-ddj.htm">multi-core programming revolution</a> in the age of multicore processors, cloud-computing, web 2.0 and access to all your favorite Java APIs/apps.<br /><br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-17820881769936580932009-07-11T00:56:00.001-05:002009-08-08T12:54:51.812-05:00BOOK: Landing the Tech Job You Love<span style="font-family:georgia;">I blogged earlier about <a href="http://blog.bradapp.net/2009/06/books-passionate-programmer-and-nomadic.html"><b>The Passionate Programmer</b> and <b>The Nomadic Developer</b></a>.<br /><br />A new book just came out that seems like the perfect complement to these two: <a style="font-weight: bold;" href="http://pragprog.com/titles/algh/land-the-tech-job-you-love">Landing the Tech Job You Love</a> by <a href="http://theworkinggeek.com/">Andy Lester</a> (also from the <a href="http://pragprog.com/">Pragmatic Programmers</a>). I've only just started reading it but so far I like it a LOT! It also received a <a href="http://dobbscodetalk.com/index.php?option=com_myblog&show=Land-the-Tech-Job-You-Love-Book-Review.html&Itemid=29">nice review by Mike Riley in DDJ online</a>.<br /><br />Rather than cite the blurb from the book this time, I rather like the description given in <a href="http://www.pragmaticprogrammer.com/press_releases/land-the-tech-job-you-love">the press release</a>:<br /><blockquote style="font-style: italic; font-family: times new roman; color: rgb(0, 0, 102);"><p>It’s tougher than ever to get that great job. Companies are more demanding and your competition is smart, tech-savvy, and resourceful. You’ve got the right skills for the job—you also need the right skills for job hunting. You need to work deliberately on your new job hunting skills, and this book can help. Old fashioned cookie-cutter job hunting skills aren’t enough: <em>Land the Tech Job You Love</em> gives you the background and the hard-won wisdom to leapfrog those who play by the old rules.</p> <p>Andy tells us, “Life is too short for a job you don’t love. You’re not stuck—other opportunities are available for you, if you know where to look and can work the hiring process to your advantage. This book will help you get that job you love.”</p> <p>In this book, you’ll learn how to find the job you want that fits you and your employer. You’ll uncover the hidden jobs that never make it into the classifieds or Monster. You’ll start making and maintaining the connections that will drive your future career moves.</p> <p>Andy started writing this book years before the recession (a.k.a. “econopocalypse”) hit. He looked at the conventional wisdom and the advice available in generic books on job hunting, and found the conventional wisdom just didn’t work for programmers, system administrators, testers, and other related development positions.</p> <p>He looked at everything from whether you should look for work on online job boards to whether you should lead off your resume with your objectives. Although he has definite answers for these two, he found that the answer to most questions is “it depends.” His book leads you to taking an honest assessment of what you offer and what you want in a job so that you end up in a job that is a good fit for you and your employer.</p> <p>This is an important book for you to read whether you currently have a job or not. The same tactics you take to make yourself more employable will also make it easier to get promoted in your current company.</p></blockquote><br />Also see Andy Lester's presentation on <a style="font-weight: bold;" href="http://assets.en.oreilly.com/1/event/27/Effective%20Job%20Interviewing%20from%20Both%20Sides%20of%20the%20Desk%20Presentation.pdf">Effective Job Interviewing from Both Side of the Desk</a> and his blog @ <a href="http://theworkinggeek.com/">TheWorkingGeek.com</a> for his thoughts on "Job hunting and working life for programmers, sysadmins and all other techies"<br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com1tag:blogger.com,1999:blog-10280668.post-47920004992687115712009-07-08T00:35:00.000-05:002009-07-19T02:44:51.844-05:00BOOK: The Economics of Iterative Software Development<span style="font-family:georgia;">In the July issue of <a href="http://www.agilejournal.com/">the Agile Journal</a> I reviewed Walker Royce, Kurt Bittner and Mike Perrow's book <a style="font-weight: bold;" href="http://www.informit.com/title/0321509358">The Economics of Iterative Software Development: Steering Toward Better Business Results</a>. Here is an excerpt ...<br /><br /><blockquote style="font-family: times new roman; color: rgb(0, 0, 102);"><strong>The Economics of Iterative Software Development: Steering Toward Better Business Results</strong> is an important text for anyone trying to persuade management to "go iterative" as well as to anyone needing to measure & track the kinds of business results that management needs to see for a software development project.<br /><br />I'll be perfectly honest: I was expecting this book to be an extremely dry and boring read, albeit full of lots of useful information densely packed in mathematical models and formulas, perhaps reminiscent of past college days reading a huge tome on socio-political economic theories. It wasn't as bad as I'd feared. Yes - it is a bit dry in places, but those are the exception rather than the rule. And there are lots of "war stories" sprinkled throughout that hold your interest and stop your eyes from glazing over.<br /><br />...<br /><br />All in all, <b>The Economics of Iterative Software Development</b> is a solid-book that is a relatively light/quick read with lots of good, practical advice on how to apply an economic model of thinking and measurement for managing and tracking business-results of an iterative project. If you need help doing that, or with communicating to your management about the need and benefits of an iterative approach, then you need to read this book!</blockquote><br />See <a href="http://www.agilejournal.com/articles/columns/column-articles/1926-featured-book-the-economics-of-iterative-software-development-">the full review</a> for more details.</span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-22698420315471757842009-07-06T01:33:00.005-05:002009-07-19T01:53:44.723-05:00JEDI Programming - Just Enough Design Initially<span style="font-family:georgia;">I left a <a href="http://agileinaflash.blogspot.com/2009/06/what-is-missing.html#comments">comment on the "What is Missing?" entry</a> at the <a href="http://agileinaflash.blogspot.com/">Agile-in-a-Flash blog</a>. The author's asked the questioin "What is missing?" from the stack of Agile flashcards they are developing. I responded ...<br /><br /><br />I think the "JEDI" approach is missing (any by that, I don't mean the mantra of "use the source Luke" ;-)<br /><br />I think there is something missing regarding TDD and Design. <a href="http://agileinaflash.blogspot.com/2009/03/unclebobs-three-rules-of-tdd.html">Uncle Bob's three rules of TDD</a> (and other writings) often mislead people to think that there is ZERO design up-front, as is if NOT doing Big-Design-Up-Front (BDUF) implies that therefore there is zero up-front design (NoDUF).<br /><br />This is false (and Uncle Bob has even vehemently said so in <a style="font-style: italic;" href="http://blog.objectmentor.com/articles/2009/04/25/the-scatology-of-agile-architecture">The Scatology of Agile Architecture</a>) but how does a newcomer reconcile it with the three rules of TDD? I can't write test-code without being able to invoke the thing-under-test. I can't invoke a thing if I haven't attempted to design the interface.<br /><br />If I design an interface (even for a single method/subroutine) I have to have some inkling of which class/package/module it would go in, at least INITIALLY! There is some initial amount of design I do before writing a test that is both necessary and sufficient to define "just enough" of the interface of what I want my test-case to test.<br /><br />So I think that is what is missing, a card called "<strong>JEDI</strong>", for "<strong>Just Enough Design Initially</strong>."<br /><br />To my knowledge, this particular definition of the JEDI acronym in agile development was first used by Stephen Palmer and other FDD luminaries at <a href="http://www.step-10.com/">www.step-10.com</a> and <a href="http://featuredrivendevelopment.com/">featuredrivendevelopment.com</a> (just do a <a href="http://www.google.com/search?hl=en&q=JEDI+AND+%22Just+Enough+Design%22">Google-search on "JEDI" AND "Just Enough Design"</a>).<br /><br />I also think there is a relationship between JEDI and Eric Evan's " <a href="http://www.domaindrivendesign.org/">Domain-Driven Design</a> (DDD), <a href="http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/05/15/domain-driven-design-supple-design-patterns-series.aspx">Supple Design</a> (part of DDD), as well as *some* of the so-called "<a href="http://www.oreillynet.com/pub/a/network/2005/11/15/what-is-prefactoring.html">Pre-factoring</a>". But it can be a risky, slippery-slope, so it would be great to have some guidance to help us know when we've done "Just Enough Design In-front/Initially."<br /><br />I suppose JEDI is a way of straddling the "appropriate range" of risk between anticipation and adaptation. I envision some kind of graph or diagram with axes ...<br /><ul><li>On the left-hand side of overanticipating we have "too much too soon" and big/all up-front design.</li><br /><li>All the way on the right-hand-side we have "too little too late." Here you are faced with legacy-rewrites, system re-engineering, large-scale restructuring, etc.</li></ul>The problem with both extremes is the creation of <a href="http://blog.bradapp.net/2009/06/technical-debt-definition-and-resources.html">technical debt</a>:<br /><ul><li>One Extreme does it by adding complex structures and behaviors too early in the cone-of-uncertainty and causes too much rework to rewrite that which was not yet certain and subject to much variability.</li><br /><li>The other extreme does it by sheer entropy/decay/rot that results from inattention and/or negligence<br /></li></ul>In the middle we have a delicate balance that we need to strike, and which JEDI represents: "Just enough" and "Just-in-Time." The problem is that this is a range, not a single perfect point. What makes the problem harder is that the range is different for different projects, depending on a number of factors (including scale and distribution). There is a certain amount of "pay-up-front" and "pay-later" that need to be balanced with "pay-as-you-go."<br /><br />I imagine this "range" represents how to find the "sweet spot" that demarcates Just Enough Design Initially:<br /><ul><li>In the middle of the scale is pure refactoring. It is strictly emergent, pay as you go just-in-time by focusing ruthlessly on keeping code clean and simple.</li><br /><li>Minor-to-moderate restructurings (too large to be refactorings, too small to be total re-writes) are to the right. Sometimes larger systems and/or systems constructed by multiple-teams can do a great job at refactoring and still not be able to avoid the need for minor-to-moderate restructuring, particular for aspects of the design that cut across teams and architecture and functionality.</li><br /><li>Just to the left of refactoring would be so-called "pre-factoring", where you have enough experience refactoring that you are able to apply basic application of encapsulation, DRY, separation of concerns, etc. without adding premature abstraction of inessential complexity. This is hard to get right, and has risk associated with it. But it does get progressively less with the better judgment that comes experience and practice.</li><br /><li>To the left of pre-factoring would be the subset of DDD known as Supple Design. And the rest of DDD would be to the left of supple-design.<br /></li></ul>Somewhere in this continuum might be "segments" corresponding to specific practices or techniques besides DDD and refactoring, such as <a href="http://www.informit.com/title/0132350882">clean code</a>, simple/incremental design, and evolutionary architecture.<br /><br />The trick of knowing the "just enough" range lies not just in experience and discipline, but also in understanding your context and your "lead-time". Lead-time in particular dictates how soon in advance you need to be able to think and anticipate (and at what level of detail). The shorter the lead/cycle-time, the less you need to anticipate and prognosticate.<br /><br />So I would see JEDI as a card that somehow is able to depict this continuum between anticipation and adaptation and where these various techniques fall on it, and the factors/tradeoffs that help you identify the right "range" for yourself. (And of course there is a close relation to technical debt and the cost-of-change curve :-)<br /><br />Anyone ever seen a diagram that bears any resemblance to what I'm thinking of here?<span style="font-family:georgia;"><br /></span><br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com3tag:blogger.com,1999:blog-10280668.post-49411698588454704752009-07-02T02:02:00.018-05:002013-03-17T12:18:53.932-05:00Emergent Design and Evolutionary Architecture - Resources<span style="font-family: georgia;">As a bit of a follow-up to my earlier posting on <a href="http://blog.bradapp.net/2009/06/technical-debt-definition-and-resources.html">Technical Debt - Definition and Resources</a> I gathered some resources on the subject of Evolutionary Architecture and Emergent Design (which is closely related to refactoring, restructuring and reengineering).</span><br />
<ul>
<li><span style="font-family: georgia;"><a href="http://www.emergentarchitecture.com/pdfs/OZJournal.pdf" style="font-style: italic;">Emergent Processes</a> and <a href="http://www.emergentarchitecture.com/pdfs/YalePerspecta.pdf" style="font-style: italic;">Emergent Models of Architectural Practice</a>, by Tom Wiscombe of <a href="http://www.emergentarchitecture.com/">emergentarchitecture.com</a></span></li>
<li><span style="font-family: georgia;">Neal Ford's series of IBM developerWorks <a href="http://www.ibm.com/developerworks/views/java/libraryview.jsp?search_by=evolutionary+architecture+emergent+design:" style="font-style: italic;">articles on Evolutionary Architecture and Emergent Design</a></span></li>
<li><span style="font-family: georgia;">Chris Sterling's (upcoming) book on <a href="http://architectureinanagileorganization.com/" style="font-weight: bold;">Architecture in an Agile Organization</a></span></li>
<li><span style="font-family: georgia;"><a href="http://www.infoq.com/emergent_architecture">Articles on Emergent Architecture</a>, from InfoQ.com</span></li>
<li><span style="font-family: georgia;"><a href="http://dx.doi.org/10.1109/HICSS.2007.136" style="font-style: italic;">Competing in the Era of Emergent Architecture: The Case of Packaged Software Industry</a>, Proceedings of the 40th Annual Hawaii International Conference on System Sciences (2007)</span></li>
<li><span style="font-family: georgia;">Any of the fine <a href="http://www.theagileengineer.com/public/Presentations/Presentations.html">presentations by Ryan Shriver</a>, over at <a href="http://www.theagileengineer.com/">theagileengineer.com</a></span></li>
<li><span style="font-family: georgia;"><a href="http://scalingsoftwareagility.wordpress.com/category/agile-architecture/">Dean Leffingwell's writings on Agile Architecture</a> and <span style="font-style: italic;">Intentional Architecture</span></span></li>
<li><span style="font-family: georgia;">Jon Kern's <a href="http://javasymposium.techtarget.com/html/images/JKern_Agile_Architecture_001.pdf" style="font-style: italic;">Just Enough Early Architecture to Guide Development</a>, from <a href="http://technicaldebt.wetpaint.com/">TechnicalDebt.WetPaint.com</a></span></li>
<li><span style="font-family: georgia;"><a href="http://mysite.verizon.net/dennis.mancl/oopsla09">OOPSLA '09 workshop on "Architecture in an Agile World"</a></span></li>
<li><span style="font-family: georgia;"><a href="http://csse.usc.edu/csse/event/2009/Arch-Workshop/presentations/Kruchten%20090608%20agile%20architecture%20usc.ppt">Software Architecture and Agile Software Development - An Oxymoron?</a> by Philippe Kruchten </span></li>
<li><span style="font-family: georgia;"><a href="http://www.agilearchitect.org/agile/index.asp">Agile Architect</a> by Philippe Kruchten </span></li>
<li><span style="font-family: georgia;"><a href="http://www.martinfowler.com/articles/designDead.html">Is Design Dead?</a> by Martin Fowler (see the section "Growing an Architecture") </span></li>
<li><span style="font-family: georgia;"><a href="http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book" style="font-weight: bold;">97 Things Every Software Architect Should Know</a> (the book)</span></li>
<li><span style="font-family: georgia;"><a href="http://alistair.cockburn.us/Extending+an+architecture+as+it+earns+business+value">Extending an architecture as it earns business value</a> by Alistair Cockburn </span></li>
<li><span style="font-family: georgia;"><a href="http://www.eoinwoods.info/doc/SA2008-Woods-Agile-Arch.pdf" style="font-style: italic;">Agile Architecture - How much is enough?</a>, by Eoin Woods</span></li>
<li><span style="font-family: georgia;">The <a href="http://www.agilearchitect.org/agile/index.asp">Agile Architect</a> site (including the <a href="http://www.agilearchitect.org/agile/role.htm">role of the agile architect</a>)</span></li>
<li><span style="font-family: georgia;">Articles at <a href="http://blog.softwarearchitecture.com/">blog.softwarearchitecture.com</a></span></li>
<li><span style="font-family: georgia;"><a href="http://www.improvement-services.nl/Agile%20Architecting%20-%20Friends%20or%20Foes.pdf">Agile Architecting</a> by Erik Philippus </span></li>
<li><span style="font-family: georgia;">Eric Evans' work on <a href="http://domaindrivendesign.org/resources/what_is_ddd" style="font-style: italic;">Domain-Driven Design</a>, see in particular the <a href="http://domaindrivendesign.org/sites/default/files/discussion/PatternSummariesUnderCreativeCommons.doc">DDD Pattern Summaries</a> and the <a href="http://www.infoq.com/minibooks/domain-driven-design-quickly">InfoQ eBook Domain Driven Design Quickly</a> (also this <a href="http://dddstepbystep.com/">Step-by-Step Guide to DDD</a>)</span></li>
<li><span style="font-family: georgia;">Scott Ambler's <a href="http://www.agilejournal.com/articles/columns/column-articles/146-scaling-agile-development-via-architecture" style="font-style: italic;">Scaling Agile Development via Architecture</a> from the Agile Journal</span></li>
<li><span style="font-family: georgia;"><a href="http://www.leansoftwarearchitecture.com/" style="font-weight: bold;">Lean Software Architecture</a>, from Jim Coplien and Gertrud Bjornvig</span></li>
<li><span style="font-family: georgia;"><a href="http://techdistrict.kirkk.com/2009/05/06/agile-architecture/" style="font-style: italic;">Agile Architecture</a> and <span style="font-family: georgia;"><a href="http://techdistrict.kirkk.com/2009/06/15/agile-architecture-requires-modularity" style="font-style: italic;">Agile Architecture Requires Modularity</a>, by Kirk Knoernschild</span></span></li>
<li><span style="font-family: georgia;"> <a href="http://www.acube-community.org/wikis/images/7/7c/ProductLineAndAgile.pdf" style="font-style: italic;">Product Line Architectures and Agile Development</a>, M.Ali Babar et.al. </span></li>
<li><span style="font-family: georgia;"> <a href="http://www.acube-community.org/wikis/images/c/c8/AliBabar-GoingAgile.pdf" style="font-style: italic;">Going Agile? Beware of Architecture-Related Changes and Challenges</a>, <span style="font-family: georgia;">M.Ali Babar et.al.</span> </span></li>
<li><span style="font-family: georgia;"><span style="font-style: italic;">The </span><a href="http://epf.eclipse.org/wikis/openup/practice.tech.evolutionary_arch.base/guidances/practices/evolutionary_arch_CF7385B0.html" style="font-style: italic;">Evolutionary Architecture Practice</a> from the <a href="http://epf.eclipse.org/">Eclipse Process Framework </a></span></li>
<li><span style="font-family: georgia;">DevJam's David Hussman on <a href="http://www.intertech.com/resource/usergroup/architecture-agility-color.pdf" style="font-style: italic;">Architecture and Agility</a></span></li>
<li><span style="font-family: georgia;"><a href="http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0809/rW_SW_ArchitectureMeetsAgility.pdf" style="font-style: italic;">Architecture Meets Agility</a>, by Hakan Erdogmus</span></li>
<li><span style="font-family: georgia;"><a href="http://www.isr.umd.edu/%7Eaustin/reports.d/INCOSE2008-Paper378.pdf" style="font-style: italic;">Toward and Evolutionary System of Systems Architecture</a>, by Scott Selberg & Mark Austin, INCOSE 2008</span></li>
<li><span style="font-family: georgia;"><span style="font-family: georgia;"></span><br /></span></li>
<li><span style="font-family: georgia;"><a href="http://greenbay.usc.edu/csci577/spring2006/site/guidelines/LeanMBASE_Guidelines_V1.5.pdf">Guidelines for Lean Model-Based (System) Architecting and Software Engineering</a></span></li>
<li><span style="font-family: georgia;"><a href="http://sse.stevens.edu/fileadmin/cser/2005/presentations/Murray%20Cantor.pdf">Systems Engineering and Architecting Challenges: Application to Agile Development</a>, by Murray Cantor</span></li>
<li><span style="font-family: georgia;">The (freely available online) book <a href="http://scg.unibe.ch/download/oorp/" style="font-weight: bold;">Object-Oriented Reengineering Patterns</a>, by Serge Demeyer, Stéphane Ducasse and Oscar Nierstrasz</span></li>
<li><span style="font-family: georgia;">The <a href="http://homepages.inf.ed.ac.uk/perdita/Reengineering/" style="font-style: italic;">System Reengineering Patterns Project</a>, by Perdita Stevens et.al. from Heriot-Watt University in Edinburgh (also see the <a href="http://www.sei.cmu.edu/reengineering/">SEI page on software reengineering</a>)</span></li>
</ul>
<div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com3tag:blogger.com,1999:blog-10280668.post-44366772873823372222009-06-28T00:52:00.012-05:002009-07-27T17:38:04.196-05:00Embracing Change - quotable quotes on change and uncertainty<span style="font-family:georgia;">Every now and then I come across a good quote about embracing the fact that change and uncertainty are an essential inherent reality of software development. Here are the ones I like so far. Do you have another one you like? If so, leave a comment and share it with me.<br /><span style="font-family:arial;"><ul><table border="1" cellpadding="3" cellspacing="1"><tbody><tr><td><span style="color: rgb(153, 51, 0);">It’s inevitable that requirements will change. Business needs evolve, new users or markets are identified, business rules and government regulations are revised, and operating environments change over time. In addition, the business need becomes clearer as the key stakeholders become better educated about what their true needs are.</span><br /><em style="color: rgb(153, 51, 0); font-weight: bold;">-- Karl Wiegers, <a href="http://www.processimpact.com/more_about_reqs_book/chapter_2.pdf"><i>Cosmic Truths about Software Requirements</i></a></em><br /></td></tr><tr style="color: rgb(0, 0, 102);"><td>The growing unpredictability of the future is one of the most challenging aspects of the new economy:<br /><ul><li>Turbulence—in both business and technology—causes change, which can be viewed either as a threat to be guarded against or as an opportunity to be embraced.</li><li>Rather than resist change, the agile approach strives to accommodate it as easily and efficiently as possible, while maintaining an awareness of its consequences. </li></ul>Facilitating change is more effective than attempting to prevent it.<br /><ul><li>Learn to trust in your ability to respond to unpredictable events; it's more important than trusting in your ability to plan for disaster.</li><li>Agile processes harness change for the customer's competitive advantage.</li></ul><span style="font-weight: bold; font-style: italic;">-- Martin Fowler and James Highsmith, <a href="http://www.ddj.com/showArticle.jhtml?articleID=184414755">On the Agile Manifesto</a></span><br /></td></tr><tr><td><span style="font-family:georgia;"><span style="font-family:arial;"><span style="color: rgb(0, 102, 0);">Orders must change rapidly in response to change in circumstances. If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long.</span><br /><span style="color: rgb(0, 102, 0); font-weight: bold; font-style: italic;">-- Taiichi Ohno, <a href="http://www.amazon.com/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143">Toyota Production System</a></span></span></span><br /></td></tr><tr style="color: rgb(0, 102, 0);"><td><span style="color: rgb(102, 51, 102);">It’s not the strongest who survive, nor the most intelligent, but the ones most adaptable to change.</span><br /><em style="font-weight: bold; color: rgb(102, 51, 102);">-- attributed to Charles Darwin</em><br /></td></tr><tr><td><span style="color: rgb(153, 51, 0);">Doubt is not a pleasant condition, but certainty is absurd. </span><br /><span style="color: rgb(153, 51, 0); font-weight: bold; font-style: italic;">-- Voltaire</span><br /></td></tr><tr><td><span style="color: rgb(0, 0, 102);">It is not necessary to change; survival is not mandatory.</span><br /><span style="color: rgb(0, 0, 102); font-weight: bold; font-style: italic;">-- W. Edwards Deming</span><br /></td></tr><tr><td><span style="color: rgb(0, 102, 0);">When the rate of change outside exceeds the rate of change inside, the end is in sight.</span><br /><span style="color: rgb(0, 102, 0); font-weight: bold; font-style: italic;">-- Jack Welch</span><br /></td></tr><tr style="color: rgb(102, 0, 204);"><td><span style="font-family:georgia;"><span style="font-family:arial;"><span style="color: rgb(102, 0, 204);">The Futility of Fighting Change: Requirements, technologies, teams, priorities, companies, usage, users, everything will change. There are things you cannot know until you know them. Give up. Change is inevitable. Our process must be a process, therefore, of change.</span><br /><em style="font-weight: bold;">-- Scott L. Bain <a href="http://www.informit.com/articles/article.aspx?p=1180983&seqNum=12http://www.cmcrossroads.com/content/view/6752/264/"><i>The Nature of Software Development</i></a>, May 2008</em></span></span></td></tr><tr><td><span style="color: rgb(153, 51, 0);">Uncertainty is inherent and inevitable in software development processes and products.</span><br /><span style="color: rgb(153, 51, 0); font-weight: bold; font-style: italic;">-- H. Ziv and D.J. Richardson, <a href="http://jeffsutherland.com/papers/zivchaos.html">The Uncertainty Principle in Software Engineering</a>, Aug 1996</span><br /></td></tr><tr><td><span style="color: rgb(0, 0, 102);">It will be important to organize future projects with enough agility to be able to adapt to the additional emergence of new sources of unpredictable change.</span><br /><span style="color: rgb(0, 0, 102); font-weight: bold; font-style: italic;">-- Barry Boehm, <a href="http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0308&file=cover.xml&xsl=article.xsl&;jsessionid=JykdXy48m4tvk2thLQP3drL1Gx2PNcTPKMtwY2q0fqRpB">Making a Difference in the Software Industry</a>, March 2008</span><br /></td></tr><tr><td><ul><li>When we program, we transform a poorly understood problem into a precise set of instructions that can be executed by a computer.</li><li>When we think we understand a program?s requirements, we are invariably wrong.</li><li>When we do not completely understand a problem, we must research it until we know that we understand it.</li><li>Only when we truly understand a problem can we develop a superior product to address that problem.</li><li>What the users think they want will change as soon as they see what we develop. </li></ul><b><i>-- Watts Humphrey, <a href="http://www.sei.cmu.edu/news-at-sei/columns/watts_new/2003/1q03/watts-new-1q03.htm">Some Programming Principles--Requirements</a>, January 2003</i></b><br /></td></tr><tr><td><span style="color: rgb(0, 102, 0);">There is a very fancy technical term biologists use to describe completely stable systems. This highly sophisticated technical term is the word “DEAD!” Change is not the enemy – stagnation is!</span><br /><span style="color: rgb(0, 102, 0); font-weight: bold; font-style: italic;">-- from <a href="http://www.cmcrossroads.com/content/view/6752/264/">The Unchangeable Rules of Software Change</a></span><br /></td></tr><tr><td><span style="color: rgb(153, 51, 153);">Requirements changes late in the lifecycle are competitive advantage, IF you can act on them!</span><br /><span style="color: rgb(153, 51, 153); font-weight: bold; font-style: italic;">-- Mary Poppendieck</span><br /></td></tr><tr><td><span style="color: rgb(153, 51, 0);">Becoming agile means accepting uncertainty about the future as a way of dealing with the future. Any project development effort should be a balance between anticipation (planning based on what we know now) and adaptation (responding to what we learn over time).</span><br /><span style="color: rgb(153, 51, 0); font-weight: bold; font-style: italic;">-- James Highsmith, <a href="http://blog.cutter.com/2008/09/16/to-attract-agile-change-embrace-uncertainty/">Embrace Uncertainty</a></span><br /></td></tr><tr><td><span style="color: rgb(0, 0, 102);">Scrum’s Uncertainty Principle is: Customers don’t know what they want until they see it, and they always reserve the right to change their mind.</span><br /><span style="color: rgb(0, 0, 102); font-weight: bold; font-style: italic;">-- Jeff Sutherland, <a href="http://www.controlchaos.com/download/Emergence%20of%20Essential%20Systems.pdf">Emergence of Essential Systems</a></span><br /></td></tr><tr style="color: rgb(0, 102, 0);"><td>Systems requirements cannot ever be stated fully in advance, not even in principle, because the user doesn’t know them in advance--not even in principle.<br /><br />To assert otherwise is to ignore the fact that the development process itself changes the user’s perceptions of what is possible, increases his or her insights into the applications environment, and indeed often changes that environment itself.<br /><br />We suggest an analogy with the Heisenberg Uncertainty Principle: any system development activity inevitably changes the environment out of which the need for the system arose. System development methodology must take into account that the user, and his or her needs and environment, change during the process.<br /><em style="font-weight: bold;">-- Dan McCracken and Michael A. Jackson, ACM SIGSoft, 1982</em><br /></td></tr></tbody></table></ul></span>Is your favorite quote about software change/uncertainty missing from the above? Leave a comment and tell me about it!<br /><br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-12328679119877496812009-06-24T00:47:00.042-05:002010-10-19T11:38:04.568-05:00Technical Debt - Definition and Resources<span style="font-family:georgia;">I ran across a few really good papers on the subject of technical debt that are fairly comprehensive in their treatment of not just what it is, but also how to manage it:<br /><ul><li><a style="font-weight: bold;" href="http://www.danube.com/system/files/CollabNet_WP_Technical_Debt_041910.pdf">Technical Debt and Design Death</a>: <em>How to ensure you can deliver business value in the future as well as in the present</em>; by Kane Mar and Michael James</li><li><a style="font-weight: bold;" href="http://www.construx.com/Page.aspx?hid=2801">Managing Technical Debt - a whitepaper</a>, by Steve McConnell (requires registration, which is free, but also see the blog-entry <a style="font-style: italic;" href="http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx">10X Software Development - Technical Debt</a>)</li><li><a style="font-weight: bold;" href="http://www.ibm.com/developerworks/rational/library/edge/09/jun09/designdebteconomics/index.html">Design debt economics</a>: <em>A vocabulary for describing the causes, costs, and cures for software maintainability problems</em>; by John Elm, IBM developerWorks, June 2009</li><li><a style="font-weight: bold;" href="http://accu.org/index.php/journals/1301">Managing Technical Debt</a>; by Tom Brazier </li><li><a style="font-weight: bold;" href="http://architectureinanagileorganization.com/software-debt/">Software Debt - Depreciation of Value for Software Assets</a> and <a style="font-weight: bold;" href="http://architectureinanagileorganization.com/chapter-07-technical-debt/">Technical Debt - Reducing Internal Quality for Short-term Gain</a>, by Chris Sterling, from his forthcoming book <a href="http://www.informit.com/title/0321700597"><span style="font-weight: bold;">Managing Software Debt</span></a> (also see his <span><a title="blocked::http://video.yahoo.com/watch/4754803/12699073" href="http://video.yahoo.com/watch/4754803/12699073">video presentation</a></span>)</li></ul>For those not already well-versed on the subject, <span style="color: rgb(153, 51, 0);"><strong>Technical Debt</strong> [a.k.a. <em>Design Debt</em>] occurs when our software becomes difficult or risky to change, and takes increasingly more time & effort to evolve. Technical debt represents the cost of the accumulated amount of rework that will be necessary to correct and/or recover from the deviation between:<br /><ul><li>the current design of the system, <em>versus </em>...</li><li>a design that is minimally complex yet sufficiently complete to ensure correctness & consistency for timely delivery.</li></ul>This effort <em>grows more than linearly</em> over time as a system becomes bigger and more complex.</span><br /><br />The economic impact of technical debt is directly related to the cost of complexity and its resulting “friction” against the velocity of the development team (and, subsequently, upon the ease of system evolution).<br /><br />Technical debt can be caused by under-engineering just as much as it can be caused by overengineering (overdesigning). It is a difficult, delicate and dynamic balancing act to achieve the necessary and sufficient amount of design to implement only the essential complexity required by system:<br /><ul><li>Sometimes we knowingly (under great pressure) do something the "quick & dirty" way, with the intent to "do it right" later (but not too late).</li><li>Sometimes we try to do too much to soon, and elaborate or implement details of the requirements when we and our customers/users haven't yet learned enough about the true needs of the system.</li><li>Sometimes we haven't yet learned enough about good design, and unintentionally violate design principles, resulting in undesirable dependencies that make code or other work-products hard to change.<br /></li><li>Sometimes we neglect to properly "tend" to the design and don't give it the necessary amount of ongoing care and feeding needed to keep it "fit" and "supple."<br /></li></ul>But whether it is a deviation between principles and practice (knowingly or unknowingly), guessing incorrectly, anticipating too early, neglect, poor quality, or even just the <a href="http://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution">laws of software evolution</a>, we must make plans and take action to deal with the inevitable entropy of evolution or else we will sink too far into technical debt.<br /><br />That's just my two cents on the subject of course. What do others have to say about it?<br /><br /><a href="http://en.wikipedia.org/wiki/Technical_debt">Wikipedia defines Technical Debt</a> by referring to the words of <a href="http://en.wikipedia.org/wiki/Ward_Cunningham">Ward Cunningham</a>, who first drew the comparison between technical complexity and debt in a <a href="http://c2.com/doc/oopsla92.html">1992 experience report</a>:<br /><blockquote style="font-family: times new roman; color: rgb(0, 0, 102);">"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."</blockquote><br />On the <a href="http://c2.com/cgi/wiki?TechnicalDebt">C2 Wiki, Ward defined Technical Debt</a> as:<br /><blockquote face="times new roman" style="color: rgb(0, 102, 0); font-family: times new roman;">“Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring. Technical Debt doesn't include deferred functionality, except possibly in edge cases where delivered functionality is "good enough" for the customer, but doesn't satisfy some standard (e.g., a UI element that isn't fully compliant with some UI standard).”</blockquote><br /><a href="http://martinfowler.com/bliki/TechnicalDebt.html">Martin Fowler's definition of Technical Debt</a> is also frequently cited:<br /><blockquote style="font-family: times new roman; color: rgb(102, 51, 0);">"Doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future."</blockquote><br />In his <a href="http://www.informit.com/articles/article.aspx?p=360842">introduction to Refactoring to Patterns</a>, Joshua Kerievsky quite simply defines design debt as follows:<br /><blockquote style="font-family: times new roman;">Design debt occurs when you don't consistently do three things.<br /><ol><li>Remove duplication.</li><li>Simplify your code.</li><li>Clarify you code's intent.</li></ol>Few systems remain completely free of design debt. Wired as we are, humans just don't write perfect code the first time around. We naturally accumulate design debt ....<br /><br />Due to ignorance or a commitment to "not fix what ain't broken," many programmers and teams spend little time paying down design debt.... In financial terms, if you don't pay off a debt, you incur late fees. If you don't pay your late fees, you incur higher late fees. The more you don't pay, the worse your fees and payments become. Compound interest kicks in, and as time goes on, getting out of debt becomes an impossible dream. So it is with design debt. </blockquote><br /><a href="http://jamesshore.com/Articles/Business/Software%20Profitability%20Newsletter/Design%20Debt.html">James Shore describes Design Debt</a> in much the same manner:<br /><blockquote style="font-family: times new roman; color: rgb(102, 51, 102);">When the cost of change increases, it's because the design quality is decreasing. Since retiring or rewriting software means writing off a huge investment, you wouldn't expect any team to let design quality deteriorate to that point. Yet it happens all the time. Why?<br /><br />Design debt" explains the problem. When a team is working under pressure, they take shortcuts that compromise design quality. It's like taking out a high-interest loan. The team gets a short-term boost in speed, but from that point forward, changes are more expensive: they're paying interest on the loan. The only way to stop paying interest is to pay back the loan's principle and fix the design shortcuts.</blockquote><br /><a href="http://www.construx.com/Page.aspx?hid=2801">Steve McConnell defines Technical Debt</a> as follows:<br /><blockquote style="font-family: times new roman; color: rgb(0, 0, 102);">“Technical Debt” refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules. Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive. The ability to take on debt safely, track their debt, manage their debt, and pay down their debt varies among different organizations. Explicit decision making before taking on debt and more explicit tracking of debt are advised.</blockquote><br /><a href="http://www.poppendieck.com/">Mary Poppendieck</a> gives a definition of Technical Debt in her upcoming book <a style="font-weight: bold;" href="http://www.poppendieck.com/llsd.htm">Leading Lean Software Development</a>:<br /><blockquote style="font-family: times new roman; color: rgb(0, 102, 0);">“All successful software gets changed. So if we think we’re working on code that will be successful … we need to keep it easy to change. Anything that makes code difficult to change is technical debt. Just like any other debt, the cost of paying off technical debt gets more and more expensive over time. … Technical debt drives the total cost of software ownership relentlessly higher … eventually we will have to pay it off or the system will go bankrupt.”</blockquote><br />Kane Mar, in <a href="http://www.danube.com/whitepapers/technical-debt"><em>Technical Debt and Design Death</em></a>, describes technical debt and later likens it to the effects of entropy:<br /><blockquote style="color: rgb(102, 51, 0); font-family: times new roman;"><em>Technical debt</em> is simply defined as <em>deferred work that is not directly related to new functionality, but necessary for the overall quality of the system</em>. Examples of this include delaying upgrades to necessary tools and frameworks, delaying the refactoring of overly complex system components, and so on. If this technical work is necessary for the health of the system, then what happens when it is ignored for too long? What happens when several layers of cruft accumulate and there are no unit tests to aid refactoring? ...<br /><br />In thermodynamics, “<em>entropy</em>” refers to the randomness of the components of a system. When the term is applied to software it is considered a measure of disorder. Thus entropy in software is the result of changes made to the code base, including bug fixes, updates to existing functionality, and the addition of new functionality. But over a period of time, these small changes can snowball to create a system that is difficult to change, overly connected to external systems, and lacks clear delineation of functionality. </blockquote><br />Chris Sterling, in his <a href="http://architectureinanagileorganization.com/about/">upcoming book on Architecture in an Agile Organization</a>, distinguishes between <a style="font-style: italic;" href="http://architectureinanagileorganization.com/software-debt/">Software Debt</a> and <a style="font-style: italic;" href="http://architectureinanagileorganization.com/chapter-07-technical-debt/">Technical Debt</a>:<br /><blockquote style="color: rgb(51, 51, 51); font-family: times new roman;">Software debt accumulates when focus remains on immediate completion while neglecting changeability of the system. The accumulation of debt does not impact software delivery immediately. At first it creates a sense of increased feature delivery with management, business stakeholders and the team. Business stakeholders respond well to the pace of delivered functionality. What they don’t understand is that this only represents an illusion of earlier returns on their investment.<br />...<br />This allows both the business and software delivery teams to live in the illusion of status quo far longer than they should. At some point previously small forms of decay in the system become large enough to affect our software delivery to the point that working harder and longer doesn’t result in success.<br />...<br />Debt is made glaringly visible when the team works on stabilizing the software functionality late in the release cycle. Integration, testing, and bug fixing is unpredictable and does not get resolved adequately before the release. People involved in the project stay late working to get the release out the door. It is now too late to pay back the debt accrued during the feature development.<br /><br />The following sources constitute what I call <strong>software debt</strong>:<br /><ul><li><strong>Technical Debt</strong>: those activities that a team or team members chooses not to do now and will impede future development if left undone</li><li><strong>Quality Debt</strong>: diminishing ability to verify functional and technical quality of entire system</li><li><strong>Configuration Management Deb</strong>t: integration and release management become more risky, complex, and error-prone</li><li><strong>Design Debt</strong>: cost of adding average sized features is increasing to more than writing from scratch</li><li><strong>Platform Experience Debt</strong>: availability and cost of people to work on system features are becoming limited</li></ul></blockquote><br />Over at the <a href="http://agileinaflash.blogspot.com/">Agile-in-a-Flash blog</a>, Jeff Langr and Tim Ottinger provide a <a href="http://agileinaflash.blogspot.com/2009/02/technical-debt.html">flashcard of tips & truths about technical debt</a>, along with a more detailed discussion about its nature and origins. They distill several nuggets of wisdom like:<br /><ul><li>Incurring technical debt means your velocity slows down and you will deliver less value</li><li>The cost of getting out-of-debt is compounded over time: the longer you wait, the faster it grow! </li><li>If you plan to incur technical debt, the persons responsible must have a workable plan to pay it off!</li><li>“Interest only” payments won’t improve things</li><li>Pay early, pay often, and pay-as-you-go. (The only other options are bankruptcy or death.) </li><li>Remember: Those with the worst debt problems often have the most difficulty imagining a life without borrowing!</li></ul><br />So how might we properly measure/monitor and account for technical debt? Well, some of the above papers I mentioned have some good ideas. Some that address it more explicitly are:<br /><ul><li><span><span> </span></span></li><span><span><li>Israel Gat's <a style="font-style: italic;" href="http://theagileexecutive.com/category/technical-debt/">Agile Executive Articles on Technical Debt</a></li> <li><a style="font-style: italic;" href="http://www.infoq.com/news/2010/03/monetizing-technical-debt">Monetizing Technical Debt</a> (also see other <a href="http://www.google.com/search?q=%22Technical+Debt%22+site%3Awww.infoq.com"><span style="font-style: italic;">InfoQ.com articles on Technical Debt</span></a>)<br /></li> </span></span><li><a style="font-style: italic;" href="http://jamesshore.com/Blog/An-Approximate-Measure-of-Technical-Debt.html">An Approximate Measure of Technical Debt</a> by James Shore</li><li><a style="font-style: italic;" href="http://sonar.codehaus.org/evaluate-your-technical-debt-with-sonar/">Evaluate your technical debt with Sonar</a> (<a href="http://sonar.codehaus.org/">SONAR</a> is a free open-source tool)</li><li>Martin Fowler writes about <a style="font-style: italic;" href="http://martinfowler.com/bliki/EstimatedInterest.html">Estimated Interest</a></li><li>In <a style="font-style: italic;" href="http://www.infoq.com/news/2007/06/Code_Quality_and_Cost_Accounting">Does Cost Accounting Cause Crappy Code?</a> Amr Elssamadisy suggests using throughput accounting (from <a href="http://www.blogger.com/en.wikipedia.org/wiki/Theory_of_Constraints">TOC</a>) instead of cost-accounting for understanding the cost of design debt<br /></li></ul>Here are a number of other very good resources on technical debt culled from blogs, articles, and presentations over the years. Some of them describe it, while others delve into methods for managing it and paying it off:<br /><ul><li><a style="font-weight: bold;" href="http://www.think-box.co.uk/blog/2005/11/repaying-technical-debt.html">Repaying Technical Debt</a>, by Simon Baker </li><li><a style="font-weight: bold;" href="http://www.pragprog.com/the-pragmatic-programmer/extracts/software-entropy">Software Entropy: Don’t Tolerate Broken Windows</a>, and <a style="font-weight: bold;" href="http://media.pragprog.com/articles/sep_02_zerotol.pdf">Zero-Tolerance Construction</a> by Andy Hunt and Dave Thomas</li><li><a style="font-weight: bold;" href="http://mark-dot-net.blogspot.com/2008/10/cost-of-complexity-and-coupling.html">The Cost of Complexity and Coupling</a>, by Mark Heath<br /></li><li><a style="font-weight: bold;" href="http://www.codinghorror.com/blog/archives/001230.html">Coding Horrors: Paying Down your Technical Debt</a>, by Jeff Atwood</li><li><a style="font-weight: bold;" href="http://www.stickyminds.com/s.asp?F=S3629_COL_2">What Testers Can Do about Technical Debt</a> (<a href="http://www.stickyminds.com/s.asp?F=S3629_COL_2">Part1</a> and <a href="http://www.stickyminds.com/s.asp?F=S3643_COL_2">Part 2</a>), by Johanna Rothman (also see Johanna's earlier essay <a style="font-style: italic;" href="http://www.ayeconference.com/climboutoftechnicaldebt/">Climbing Out of Technical Debt</a>)</li><li><a style="font-weight: bold;" href="http://www.crisp.se/henrik.kniberg/presentations/agile2008/Technical-Debt-how-not-to-ignore-it.pdf">Technical Debt - How not to ignore it!</a>, by Henrik Kniberg<br /></li><li><a style="font-weight: bold;" href="http://www.media-landscape.com/yapc/2006-06-26.AndyLester/">Get out of Technical Debt Now!</a>, by Andy Lester</li><li><a style="font-weight: bold;" href="http://patrickwilsonwelsh.com/?p=10">Continous Refactoring and the Cost of Decay</a>, by Patrick W. Welsh<br /></li><li><a style="font-style: italic;" href="http://www.agileadvice.com/archives/2006/12/technical_debt.html">Agile Advice on Technical Debt</a>, by Mishkin Bertieg</li><li><a style="font-style: italic;" href="http://www.infoq.com/news/2008/08/tech-debt-wkshp">A Fresh Look at Technical Debt</a>, an <a href="http://www.infoq.com/agile">InfoQ.com</a> summary of a <a title="Technical Debt Workshop" target="_blank" href="http://www.cs.calvin.edu/activities/technical-debt/">Technical Debt Workshop</a></li><li><a href="http://www.stickyminds.com/s.asp?F=S15549_ART_2"><span style="font-style: italic;">Managing your Analysis debt</span></a>, by Ellen Gottesdiener<br /></li><span><span style="font-family:georgia;"><li><a href="http://www.infoq.com/news/2009/10/dissecting-technical-debt">Dissecting Technical Debt</a>, <span style="font-family:georgia;">an <a href="http://www.infoq.com/agile">InfoQ.com</a> summary from <a href="http://www.infoq.com/agile_techniques">Agile techniques</a> </span> </li></span></span><li><a style="font-style: italic;" href="http://www.brandonsavage.net/paying-down-technical-debt/">Paying Down Technical Debt</a>, by Brandon Savage<br /></li><li><a style="font-style: italic;" href="http://www.codesqueeze.com/refinance-your-technical-debt-just-like-your-mortgage/">Refinance your Technical Debt Just Like Your Mortgage</a><br /></li><li><a style="font-style: italic;" href="http://chrissterling.gettingagile.com/2008/10/20/managing-software-debt-article/">Managing Software Debt</a>, by Chris Sterling (also see <a href="http://video.yahoo.com/watch/4754803/12699073">video presentation</a>)<br /></li><li><a style="font-style: italic;" href="http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/03/fighting-technical-debt-with-the-wall-of-pain.aspx">Fighting technical debt with the Wall of Pain</a>, by Jimmy Boggard </li><li><a style="font-style: italic;" href="http://codebetter.com/blogs/patricksmacchia/archive/2009/03/01/development-psychology-technical-debt-and-the-next-feature-syndrome.aspx">Development Psychology, technical debt and the next feature syndrome</a></li><li><a style="font-style: italic;" href="http://www.techdarkside.com/where-does-technical-debt-come-from">Where does technical debt come from?</a>, by David Christiansen </li><li><a style="font-style: italic;" href="http://www.extremeplanner.com/blog/2005/03/technical-debt-deficit-spending-for.html">Technical Debt - deficit spending for geeks</a>, by Dave Churchville</li><li><a style="font-style: italic;" href="http://iancartwright.com/blog/2009/01/five-kinds-of-technical-debt.html">Five Kinds of Technical Debt</a>, by Ian Cartwright </li><li><a style="font-style: italic;" href="http://blog.technoetic.com/2006/09/19/threshold-of-pain/">Technical Debt: The threshold of acceptable pain</a>, by (Technoetic) Steve Bate </li><li><a style="font-style: italic;" href="http://www.xprogramming.com/blog/tech/technical-debt-2.htm">Technical Debt: Transparency and Customer Communication</a>, by Ron Jeffries</li><li><a href="http://martinfowler.com/bliki/TechnicalDebtQuadrant.html"><span style="font-style: italic;">Technical Debt Quadrants</span></a>, by Martin Fowler (also see <a href="http://martinfowler.com/bliki/DesignStaminaHypothesis.html"><span style="font-style: italic;">Design Stamina Hypothesis</span></a>)</li><li><a style="font-style: italic;" href="http://blog.objectmentor.com/articles/2009/10/15/we-must-ship-now-and-deal-with-consequences">We must ship now and deal with the consequences</a>, by (Uncle) Bob Martin - a response to Martin Fowler's article above<br /></li><li><a href="http://www.informit.com/articles/printerfriendly.aspx?p=1401640"><span style="font-style: italic;">Don't Enron your software project</span></a>, by Aaron Erickson<br /></li><li><strong>Technical Debt:</strong> <a style="font-style: italic;" href="http://blog.abakas.com/2009/04/technical-debt-what-is-it.html">What is it?</a> The <a style="font-style: italic;" href="http://blog.abakas.com/2009/04/technical-debt-warning-signs.html">Warning Signs</a> and <a style="font-style: italic;" href="http://blog.abakas.com/2009/04/technical-debt-paying-it-off.html">Paying it Off</a>, by Catherine Powell<br /></li></ul><br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com3tag:blogger.com,1999:blog-10280668.post-11121426736885874792009-06-21T00:18:00.004-05:002022-04-15T15:18:11.011-05:00Gee Scrum Method Owners!<span style="font-family: "; font-size: 100%;"><i>[NOTE: I originally wrote this before Agile2009 (in Chicago), but forgot to press "publish", so it stayed a 'Draft' until I discovered this and published it much later]</i></span><br />
<span style="font-family: "; font-size: 100%;"><i><br /></i></span>
<span style="font-family: "; font-size: 100%;">Sung to the tune of <i><a href="http://www.westsidestory.com/lyrics_krupke_movie.php">Gee, Officer Krupke!</a></i> from West-Side Story </span><span style="font-family: "; font-size: 11pt;"><span style="font-size: 100%;">-- Music: Leonard Bernstein, Lyrics: Stephen Sondheim </span><i><span style="font-size: 100%;">(see <a href="http://www.youtube.com/watch?v=pq28qCklEHc">video of the movie performance</a>)</span></i></span><div><span style="font-size: 14.6667px;"><i><br /></i></span>
<span style="font-size: 130%;"><span style="font-weight: bold;">Background:</span></span><br />
<span style="font-size: 100%;">For about a year now, I believe there has been a greater than usual amount of Agile-related blogging and mail-list discussion on the subject of the shortcomings of what is currently the most popular agile development method: Scrum. Some of them are legitimately about Scrum, others are really more about the kinds of problems one encounters introducing Agile methods without appropriate emphasis/execution of the technical practices (especially Refactoring and TDD).<br /><br />It seems much of it may have started around the same time that Alan Shalloway (and later others, including Ron Jeffries, below) were banned from the </span><span style="font-family: "; font-size: 100%;"><a href="http://groups.yahoo.com/group/scrumdevelopment/">ScrumDevelopment</a></span><span style="font-size: 100%;"> list for “going meta” and discussing problems with and/or additions to Scrum itself instead of how to apply/use it. Alan subsequently created the</span><span style="font-family: "; font-size: 100%;"><a href="http://tech.groups.yahoo.com/group/leanagile/"> Lean-Agile</a></span><span style="font-size: 100%;"> list for such discussions (and is also working on a </span><span style="font-family: "; font-size: 100%;"><a href="http://www.netobjectives.com/resources/books/lean-agile-software-development">book</a></span><span style="font-size: 100%;">).</span><br />
As of this writing, more recent examples include the following:<br />
<ul>
<li><span style="font-family: "wingdings";"><span style="font: 7pt "Times New Roman";"></span></span><span style="font-size: 85%;">James Shore, <b><i><a href="http://www.infoq.com/news/2008/11/decline-of-agile">The Decline and Fall of Agile</a></i></b></span></li>
<li><span style="font-size: 85%;"><span style="font-family: "wingdings";"><span style="font: 7pt "Times New Roman";"></span></span>Two specific threads on the ExtremeProgramming list: <b><i><a href="http://tech.groups.yahoo.com/group/extremeprogramming/message/147031">What about Scrum + CI + Automated-Tests?</a></i></b> and <b><i><a href="http://tech.groups.yahoo.com/group/extremeprogramming/message/147790">What if Code Smells were counted as …</a></i></b></span> </li>
<li><span style="font-size: 85%;"><span style="font-family: "wingdings";"><span style="font: 7pt "Times New Roman";"></span></span>Robert (”Uncle Bob”) Martin, presentation on <b><i><a href="http://www.infoq.com/presentations/craftmanship-ethics">Craftsmanship and Ethics</a></i></b>, and a follow-up blog-entry on <b><i><a href="http://blog.objectmentor.com/articles/2008/08/14/quintessence-the-fifth-element-for-the-agile-manifesto">Quintessence: The fifth element for the Agile Manifesto</a></i></b></span></li>
<li><span style="font-size: 85%;"><span style="font-family: "wingdings";"><span style="font: 7pt "Times New Roman";"></span></span>The thread from the Lean-Agile list on <i><a href="http://tech.groups.yahoo.com/group/leanagile/message/2617"><b>Controlling</b> <b>Say</b> (was Definition and Scope of Scrum / PO Role)</a></i> </span></li>
<li><span style="font-size: 85%;"><span style="font-family: "wingdings";"><span style="font: 7pt "Times New Roman";"></span></span>Ron Jeffries, <b><i><a href="http://xprogramming.com/blog/2009/01/30/context-my-foot/">Context My Foot!</a></i></b> and <b><i><a href="http://xprogramming.com/blog/2009/02/01/quality-speed-tradeoff-youre-kidding-yourself/">Quality-Speed Tradeoff — You’re kidding yourself</a></i></b></span></li>
<li><span style="font-size: 85%;"><span style="font-family: "wingdings";"><span style="font: 7pt "Times New Roman";"></span></span>Jurgen Appelo, <b><i><a href="http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html">The Decline and Fall of Agilists</a></i></b></span></li>
</ul>
<br />
<span style="font-weight: bold;"><span style="font-size: 130%;">Cast of Characters:</span> </span>You will need individual actors portraying the following roles!<br />
<ul>
<li><span style="font-size: 85%;">Alan Shalloway, <a href="http://www.netobjectives.com/">www.netobjectives.com</a> </span></li>
<li><span style="font-size: 85%;">Ron Jeffries, <a href="http://www.xprogramming.com/">www.XProgramming.com</a> </span></li>
<li><span style="font-size: 85%;">Peter Alfvin, </span></li>
<li><span style="font-size: 85%;">Brad Appleton, <a href="http://blog.bradapp.net/">blog.bradapp.net</a> </span></li>
<li><span style="font-size: 85%;">Uncle Bob (Robert C. Martin), <a href="http://www.objectmentor.com/">www.objectmentor.com</a> </span></li>
</ul>
<span color="rgb(51 , 51 , 255)" style="font-style: italic; font-weight: bold;">NOTE that the people are real, but the dialogue is fictional, even tho it is derived from bits and pieces of actual messages and blog-posts.</span><br />
<br />
<span style="font-size: 130%;"><span style="font-weight: bold;">Lyrics:</span></span><br />
<ul><span style="font-size: 85%;"><span style="font-family: "verdana";"><span style="font-weight: bold;">RON </span>(spoken): </span><span style="font-family: "verdana";">Hey, you! </span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALAN </span>(spoken): </span><span style="font-family: "verdana";">Me, Officer Jeffries? </span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">RON </span>(spoken):</span><br /><span style="font-family: "verdana";">That’s <span style="font-style: italic;">Scrum Master </span>Jeffries to you! Gimme one good reason</span><span style="font-family: "verdana";"> for not draggin’ ya to the scrumdevelopment list</span> <span style="font-family: "verdana";">to answer for blamin all yer troubles on Scrum.</span><span style="font-family: "verdana";"> What’ll you say to Schwaber, ya punk!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALAN </span>(sings):</span><br /><span style="font-family: "verdana";">Dear kindly Scrum-Lord Schwaber, </span><span style="font-family: "verdana";">You gotta understand,</span><br /><span style="font-family: "verdana";">It's just our agile nature </span><span style="font-family: "verdana";">that gets us Scrum-list banned.</span><br /><span style="font-family: "verdana";">Our management is clueless,</span><span style="font-family: "verdana";"> our backlog’s full of junk,</span><br /><span style="font-family: "verdana";">Golly Moses, that’s where Scrum has flunked!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALAN </span>with <span style="font-weight: bold;">BRAD </span>& <span style="font-weight: bold;">PETER</span>:</span><br /><span style="font-family: "verdana";">Gee Scrum-method owners, we're very upset;</span><br /><span style="font-family: "verdana";">Your method doesn’t scale and we’re in technical debt!</span><br /><span style="font-family: "verdana";">We ain't no extremists, </span><span style="font-family: "verdana";">Our motives are clean,</span><br /><span style="font-family: "verdana";">Deep down inside us there is Lean!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALAN</span>: There is Lean!</span><br /><br /><span style="font-family: "verdana"; font-weight: bold;">ALL:</span><br /><span style="font-family: "verdana";">There is Lean, there is Lean, </span><span style="font-family: "verdana";">There is untapped Lean,</span><br /><span style="font-family: "verdana";">Deep inside XP and Scrum there’s Lean.</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">RON </span>(spoken -- imitating Scrum list-owner):</span><br /><span style="font-family: "verdana";">That's an off-topic discussion!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALAN </span>(spoken):</span><br /><span style="font-family: "verdana";">Lemme tell it to the world!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">RON </span>(“Scrum list-owner”):</span><br /><span style="font-family: "verdana";">Just tell it some place else!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALAN </span>(singing, while creating the Lean-Agile list):</span><br /><span style="font-family: "verdana";">Dear Lean-Agile list-readers, </span><span style="font-family: "verdana";">The Scrum-list is too closed.</span><br /><span style="font-family: "verdana";">Despite their Agile leaders, </span><span style="font-family: "verdana";">the truth must be exposed:</span><br /><span style="font-family: "verdana";">They didn't want discussion </span><span style="font-family: "verdana";">of what Scrum oughta add.</span><br /><span style="font-family: "verdana";">Leapin' lizards, that's why I'm so “rad!”</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALAN</span>:</span><br /><span style="font-family: "verdana";">Hey Scrum-method owners, you're really deep-fried!</span><br /><span style="font-family: "verdana";">There’s plenty wrong with Scrum that needs Lean-thinking applied!</span><br /><span style="font-family: "verdana";"><span style="font-weight: bold;"><br />PETER</span>: Those darn product-owners have gotta be curbed!</span><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">RON</span>: They’re pathologic'ly disturbed!</span><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">BRAD</span>: </span><span style="font-family: "verdana";">They’re disturbed?</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALL</span>:</span><br /><span style="font-family: "verdana";">They're disturbed. They're disturbed, </span><span style="font-family: "verdana";">They're the most disturbed,</span><br /><span style="font-family: "verdana";">Like they're pathologic'ly disturbed.</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALAN </span>(spoken, imitating Mary Poppendieck):</span><br /><span style="font-family: "verdana";">Hear ye! Hear ye! </span><span style="font-family: "verdana";">In the opinion of Lean-thinking, </span><span style="font-family: "verdana";">these POs act depraved on account of</span><span style="font-family: "verdana";"> they ain't had a proper “frame.”</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">BRAD </span>(spoken): Hey, they’re depraved on account of their dis-functional context!</span><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">RON </span>(spoken): Lemme to introduce ‘em to my fully functional foot!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">BRAD </span>(singing, to <span style="font-weight: bold;">Ron</span>)</span><br /><span style="font-family: "verdana";">My PO is so dastard, </span><span style="font-family: "verdana";">da coach won’t hear my plea,</span><br /><span style="font-family: "verdana";">da team’s code ain’t refactored, </span><span style="font-family: "verdana";">‘cuz PO won’t agree.</span><br /><span style="font-family: "verdana";">They add it to the backlog </span><span style="font-family: "verdana";">for later to address,</span><br /><span style="font-family: "verdana";">Goodness gracious, dat's why it’s a mess!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">RON</span>:</span><br /><span style="font-family: "verdana";">Please! “Bad product-owners!” that reason’s so lame!</span><br /><span style="font-family: "verdana";">You shouldn’t even ask them, (and you should be ashamed)</span><br /><span style="font-family: "verdana";">It’s really yer context that oughta be changed,</span><br /><span style="font-family: "verdana";">It’s economic’ly deranged!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">BRAD</span>: </span><span style="font-family: "verdana";">We’re deranged?</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALL</span>:</span><br /><span style="font-family: "verdana";">We’re deranged! We’re deranged! </span><span style="font-family: "verdana";">We are so de-ranged,</span><br /><span style="font-family: "verdana";">We're so economic’ly deranged!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">RON </span>(spoken):</span><br /><span style="font-family: "verdana";">In my opinion, Scrum don't need </span><span style="font-family: "verdana";">to have its head roles re-thunk at all.</span> <span style="font-family: "verdana";">Use of RASCI matrices is surely a </span><span style="font-family: "verdana";">management disease!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">BRAD </span>(spoken): Hey, I got a management disease!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALL </span>(spoken sarcastically): So go buy an agile management tool.</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">BRAD </span>(singing to "Agile tool-vendor"):</span><br /><span style="font-family: "verdana";">Dear kindly Scrum-tool master, </span><span style="font-family: "verdana";">they say go use your tools.</span><br /><span style="font-family: "verdana";">They’ll save us from disaster, </span><span style="font-family: "verdana";">‘cuz they’ll enforce da rules. </span><br /><span style="font-family: "verdana";">And for our retrospectives, </span><span style="font-family: "verdana";">they’ll generate nice charts</span><br /><span style="font-family: "verdana";">Glory Osky, that's why our code smarts!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">UNCLE BOB</span> (with <span style="font-weight: bold;">RON</span>):</span><br /><span style="font-family: "verdana";">Yikes! Stupid tool vendors, </span><span style="font-family: "verdana";">you've done it again.</span><br /><span style="font-family: "verdana";">This team don't need a tool, </span><span style="font-family: "verdana";">just index cards and a pen.</span><br /><span style="font-family: "verdana";">It ain't just enough to inspect-and-adapt;</span><br /><span style="font-family: "verdana";"><span style="font-weight: bold;"><br />UNCLE BOB</span>: Value craftsmanship over crap!</span><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">BRAD</span>: Ship 'er crap?</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALL</span>:</span><br /><span style="font-family: "verdana";">Don’t ship crap! Don’t make crap!</span><span style="font-family: "verdana";"> Craftsmanship over crap!</span><br /><span style="font-family: "verdana";">Craft clean code as if you give a crap.</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">UNCLE BOB</span> (spoken):</span><br /><span style="font-family: "verdana";">We hereby declare this project’s code to be crap </span><span style="font-family: "verdana";">on account of its ignerantive and excremental development. </span><span style="font-family: "verdana";">Failure to write clean code is professionally irresponsible!</span> <span style="font-family: "verdana";">TDD and refactoring are not optional!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">RON</span>: The problem is your context!</span><br /><span style="font-family: "verdana"; font-weight: bold;">ALAN: </span><span style="font-family: "verdana";">The answer is go Lean!</span><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">BRAD</span>: The problem is design debt!</span><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">BOB</span>: The answer is code clean!</span><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">PETER</span>: The problem is Scrum's growing!</span><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALAN</span>: The answer is Scrum's grown!</span><br /><br /><span style="font-family: "verdana";"><span style="font-weight: bold;">ALL</span>:</span><br /><span style="font-family: "verdana";">Scrum Lords we got troubles of our own!</span><br /><span style="font-family: "verdana";">To all unclean-coders </span><span style="font-family: "verdana";">We just have to yell,</span><br /><span style="font-family: "verdana";">“Your projects can’t be agile if your code-bases smell!”</span><br /><span style="font-family: "verdana";">Gee, Scrum method-owners,</span> <span style="font-family: "verdana";">What are we to do!</span><br /><span style="font-family: "verdana";">Dear Scrum method-owners,</span> <span style="font-family: "verdana";">SCRUM YOU!!</span></span></ul>
<span style="font-size: 130%;"><span style="font-weight: bold;"><br />Acknowledgements:</span></span><br />
<span style="font-size: 85%;"><br /><span style="font-size: 100%;">I credit Ron Jeffries with my inspiration (obsession?) in crafting the above! Ron quoted a line from the West-Side Story song “Gee Officer Krupke!” in one of his email replies and I couldn’t get the song out of my head all that day and began piecing together the above (which I developed iteratively & incrementally using TDD and refactoring – of course :-).</span></span></div><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-18636549003567447662009-06-20T01:08:00.016-05:002009-07-09T09:26:40.433-05:00Resources on Self-Organizing Teams for Agility<span style="font-family:georgia;">In the past several blog-entries I've been focusing on the agile principle of self-organization, what it means, and what it implies for teams. So far, I've written about <a href="http://blog.bradapp.net/2009/06/agile-self-organization-versus-lean.html"><em>Agile Self-Organization versus Lean Leadership</em></a>, <a href="http://blog.bradapp.net/2009/06/self-organization-and-complexity.html"><em>Self-Organization and Complexity</em></a>, and <em><a href="http://blog.bradapp.net/2009/06/agile-self-organizing-teams.html">Agile Self-Organizing Teams</a>.</em><br /><br />For some online resources (articles and presentations) on self-organization and self-organizing teams, I recommend the following:<br /><ul><li>InfoQ.Com articles: <a href="http://www.infoq.com/news/2009/06/high-performance-teams-teamicide"><em>High-Performance Teams – Avoiding Teamicide</em></a>, <a href="http://www.infoq.com/news/2008/08/coaching_teams"><em>Coaching Self Organizing Teams</em></a>, and <em><a href="http://www.infoq.com/news/2009/07/self-organization-success-factor">Ensuring Success for Self Organizing Teams</a></em></li><li><a href="http://www.mountaingoatsoftware.com/presentation/94-leading-a-selforganizing-team"><strong>Leading a Self-Organizing Team</strong></a>, PDF presentation by Mike Cohn given at the Jan 2009 Dallas Agile Project Leadership Network (APLN)</li><li><a href="http://www.scrumalliance.org/resources/557"><strong>Flock-theory applied</strong></a>, by James Brett -- a look at Flock Theory by D.Rosen for answers to creating highly optimized, self-organised Scrum teams </li><li><strong><a href="http://www.futureworksconsulting.com/resources/TeamAgilityAgileTimesFeb04.pdf">Exploring Self-Organizing Software Development Teams</a></strong>, by Diana Larsen</li><li><a href="http://www.agilealliance.com/system/article/file/784/file.pdf"><strong>Agile Processes and Self-organization</strong></a>, by Ken Schwaber </li><li><a href="http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=4483195&isnumber=4483172"><strong>Understanding Self-organizing Teams in Agile Software Development</strong></a>, from 2008 Australian Software Engineering Conference (ASWEC2008) </li><li><a href="http://www.scrumalliance.org/articles/103-the-managers-role-in-agile"><strong>The Manager's role in Agile</strong></a>, and <a href="http://www.agilejournal.com/content/view/858/195/"><strong>7 Agile Coach Failure Modes</strong></a>, by Lyssa Adkins and Michael Spayd </li><li><a href="http://www.scrumalliance.org/articles/6"><strong>Scum vs Scrum: Emergent behavior in slime molds and software development teams</strong></a>, by Matt Truxaw </li><li><a style="FONT-WEIGHT: bold" href="http://www.targetprocess.com/blog/2008/11/agile-software-development-and-complex.html">Agile Software Development and Complex Adaptive Systems</a>, a 4 part series of articles by Michael Dubakov: <ul><li>part1: <a style="FONT-STYLE: italic" href="http://www.targetprocess.com/blog/2008/11/agile-software-development-and-complex.html">Introduction to Agile Software Development and CAS</a></li><li>part2: <em><a href="http://www.targetprocess.com/blog/2008/11/software-development-is-complex.html">Software Development is a Complex Adaptive System - No Doubt</a></em></li><li>part3: <a style="FONT-STYLE: italic" href="http://www.targetprocess.com/blog/2008/12/edge-of-chaos-and-hyper-productive.html">The Edge of Chaos and Hyper-Productive Software Development Teams</a></li><li>part4: <a style="FONT-STYLE: italic" href="http://www.targetprocess.com/blog/2009/03/simple-rules-complex-systems-and.html">Simple Rules, Complex Systems and Software Development</a><br /></li></ul></li><li><a href="http://www.infoq.com/news/holacracy-agile-enterprise"><strong>Holacracy - The Self-Organizing Enterprise</strong></a></li><li><a href="http://www.lithespeed.com/resources/Agile-Project-Management-Steering-from-the-Edges.pdf"><strong>Steering from the Edges</strong></a>, by Sanjiv Augustine et.al. </li><li><a href="http://jeffsutherland.com/scrum/2009/01/roots-of-scrum-takeuchi-and-nonaka.html"><strong>Roots of Scrum: Takeuchi and Self-Organizing Teams</strong></a>, by Jeff Sutherland </li><li><a style="FONT-WEIGHT: bold" href="http://www.infoq.com/articles/learning_is_the_bottleneck">Learning is the Bottleneck</a>, by Amr Elssamadisy & Deborah Hartmann</li><li><a style="FONT-WEIGHT: bold" href="http://www.infoq.com/news/2007/11/poppendieck-software-leadership">Leadership is not obsolete in Self-Organizing Teams</a>, by Mary Poppendieck</li><li><a href="http://www.infoq.com/selforganizingteam">More InfoQ.com articles on Self-Organizing Teams</a> </li><li><a href="http://www.accelinnova.com/publications.html">Polyanna Pixton's papers/presentations on Agile leadership & collaboration</a></li><li><a style="FONT-STYLE: italic" href="http://www.estherderby.com/weblog/2009/06/when-to-stand-back-when-to-step-in.html">When to stand back, when to step-in (Managing self-organizing teams)</a>, by Esther Derby<br /></li><li><a href="http://softwarecreation.org/2007/what-is-the-best-leader-for-the-software-team"><strong>What is the best leadership style for a software team?</strong></a> by Andriy Solovey (also see <a href="http://softwarecreation.org/2007/evolutionary-software-architecture-or-why-developers-are-not-janitors"><strong>Evolutionary Software Architecture</strong> </a>and <a href="http://softwarecreation.org/2007/self-organization-the-army-vs-jim-highsmith"><strong>Self-Organizing Teams: The Army versus Jim Highsmith</strong></a></li><li><a style="FONT-WEIGHT: bold" href="http://agileconsortium.pbworks.com/Self-Organization-in-Scrum">Self Organization in Scrum</a> and <a style="FONT-WEIGHT: bold" href="http://jeffsutherland.com/scrum/SelfOrganizationShockTherapyBT2Apr2009.pdf">Self-Organization & Shock Therapy</a>, presentations by Jeff Sutherland (also see the corresponding video <a style="FONT-STYLE: italic" href="http://jeffsutherland.com/scrum/2009/04/self-organization-secret-sauce-for.html">Self-Organization - The Secret Sauce for Improving Your Scrum Team</a>)</li><li><a href="http://www2.isye.gatech.edu/~carl/papers/anderson_mcmillan_revised.pdf"><strong>Of ants and men: self-organized teams in human and insect organizations</strong></a> </li><li><a style="FONT-WEIGHT: bold" href="http://pespmc1.vub.ac.be/Papers/IEEE.Self-organization.pdf">The Meaning of Self-Organization in Computing</a> and <a href="http://pespmc1.vub.ac.be/Papers/EOLSS-Self-Organiz.pdf">The Science of Self-Organization and Adaptivity</a>, by Francis Heylighen</li><li>Mishkin Berteig on <a style="FONT-WEIGHT: bold" href="http://www.agileadvice.com/archives/2005/12/agile_work_uses_2.html">Team Self-Organization</a></li><li><a style="FONT-WEIGHT: bold" href="http://www.solutionsiq.com/resources/SIQ-Swarming-Panchal-Agile2008.pdf">Swarming: The Birds, Bees and Agile</a>, by Tom Perry and Dhaval Panchal</li><li><a style="FONT-WEIGHT: bold" href="http://allankelly.blogspot.com/2008/11/limits-of-self-organizing-teams.html">Limits of Self-Organizing Teams</a>, by Alan Kelly<br /></li><li><a href="http://www.systems-thinking.org/bop/bop.htm"><strong>Bureaucracy & Organizational Politics:</strong> <em>Emergent Characteristics of Structure</em></a>, an essay from <a href="http://www.systems-thinking.org/">systems-thinking.org </a></li><li><a href="http://www.noop.nl/2009/05/selforganization-anarchy-part-3.html">Jurgen Appelo on Self-Organizing Teams</a></li><li><a style="FONT-STYLE: italic" href="http://www.systemdynamics.org/conferences/2003/proceed/PAPERS/279.pdf">Systemic Analysis of A Team’s Self- Organizing processes</a>: some insights into the knowledge management</li><li><a style="FONT-STYLE: italic" href="http://www.springerlink.com/content/a1j9j2rh2h9hl8p3/">Be Empowered (That’s an Order !) “Experience the Dynamics and the Paradoxes of Self-Organizing Teams”</a>, by Laurent Bossavit and Emannuel Gaillot<br /></li><li><a style="FONT-WEIGHT: bold" href="http://www.scribd.com/doc/14424701/Conditions-for-SelfOrganizing-in-Human-Systems">Conditions for Self-Organizing in Human Systems</a> by Glenda Holladay Eoyang (Ph.D. Thesis)</li><li>Series of articles on <a href="http://www.groupcoherence.com/">Group Coherence</a> for Agile/Project Teams:</li><ul style="FONT-STYLE: italic"><li><a href="http://www.agilejournal.com/articles/17-articles/893-group-coherence-for-project-teams-a-search-for-hyper-productivity">Group Coherence for Project Teams - A Search for Hyper-Productivity</a></li><li><a href="http://www.agilejournal.com/articles/17-articles/883-group-coherence-for-project-teams-common-purpose">Group Coherence for Project Teams - Common Purpose</a></li><li><a href="http://www.agilejournal.com/articles/17-articles/1222-group-coherence-for-project-teams-collaborative-interaction">Group Coherence for Project Teams - Collaborative Interaction</a></li><li><a href="http://www.agilejournal.com/articles/17-articles/1342-group-coherence-for-project-teams-group-creativity">Group Coherence for Project Teams – Group Creativity</a></li><li><a href="http://www.agilejournal.com/articles/17-articles/1468-group-coherence-practice-in-the-agile-community">Group Coherence Practice in the Agile Community</a></li><li><a href="http://www.agilejournal.com/articles/17-articles/1742-group-coherence-for-project-teams-practice-for-continuous-improvement">Group Coherence for Project Teams - Practice for Continuous Improvement</a></li></ul><li><a style="FONT-WEIGHT: bold" href="http://books.google.com/books?id=FGcPVCca1WsC&pg=PA167&lpg=PA167&dq=%22Self-Organized+Teams%22&source=bl&ots=DV1doiwmFj&sig=nl7B3sUltyE4WgUOoHlmfoKc0NA&hl=en&ei=N_FMSpbgLoHWM_-Z4foD&sa=X&oi=book_result&ct=result&resnum=6">Team Effectiveness in Complex Organizations</a></li><li><a style="FONT-WEIGHT: bold" href="http://www.saferpak.com/teamwork_articles/ensuring_success.pdf">Ensuring Success: A Model for Self-Managed Teams</a>, by Lori Silverman & Annabeth Propst</li><li><a style="FONT-STYLE: italic" href="http://www.margaretwheatley.com/articles/using-emergence.pdf">Using Emergence to Take Social Innovation to Scale</a>, and <a style="FONT-STYLE: italic" href="http://www.margaretwheatley.com/articles/Self-OrganizedNetworks.pdf">Leadership of Self-Organized Networks: Lessons from the War on Terror</a>, by <a href="http://www.margaretwheatley.com/writing.html">Margaret Wheatley</a> et.al.<br /></li><li><a style="FONT-WEIGHT: bold" href="http://books.google.com/books?id=FGcPVCca1WsC&pg=PA167&lpg=PA167&dq=%22Self-Organized+Teams%22&source=bl&ots=DV1doiwmFj&sig=nl7B3sUltyE4WgUOoHlmfoKc0NA&hl=en&ei=N_FMSpbgLoHWM_-Z4foD&sa=X&oi=book_result&ct=result&resnum=6">Complexity, Organizations and Change</a>, by Elizabeth McMillan</li><li><a style="FONT-WEIGHT: bold" href="http://www.plexusinstitute.com/edgeware/archive/think/main_filing12.html">Managing the Unknowable</a>: <em>Strategic Boundaries Between Order and Chaos in Organizations</em></li><li><a href="http://www.alexeikurakin.org/main/soft.html"><em>The Universal principles of Self-organization and the Unity of Nature and Knowledge</em></a>, by Alexei Kurakin</li><li><a style="FONT-STYLE: italic" href="http://www.per.marine.csiro.au/staff/Fabio.Boschetti/papers/Halley_Winkler_Emergence.pdf">Classification of Emergence and its Relation to Self-Organization</a> (also see <a href="http://www.per.marine.csiro.au/staff/Fabio.Boschetti/CSS_emergence.htm">related papers on emergence by Fabio Boschetti</a>)<br /></li><li>Wikipedia entries on <a style="FONT-STYLE: italic" href="http://en.wikipedia.org/wiki/Self-organization">Self-Organization</a> and <a style="FONT-STYLE: italic" href="http://en.wikipedia.org/wiki/Emergence">Emergence</a> (also Wapedia entries on <a style="FONT-STYLE: italic" href="http://wapedia.mobi/en/Self-organization">Self-Organization</a> and <a style="FONT-STYLE: italic" href="http://wapedia.mobi/en/Emergence">Emergence</a>)<br /></li><li><a id="v9b_" title="Self-Organizing Systems FAQ" href="http://www.calresco.org/sos/sosfaq.htm">Self-Organizing Systems FAQ</a> </li><li style="FONT-STYLE: italic"><a href="http://arxiv.org/ftp/nlin/papers/0509/0509049.pdf">10 Questions about Emergence</a></li><li><a style="FONT-STYLE: italic" href="http://www.systemdynamics.org/conferences/2001/papers/Georgantzas_2.pdf">Self-Organization Dynamics</a><br /></li><li><a style="FONT-STYLE: italic" href="http://www.naturalhistorymagazine.com/0603/0603_feature1.html">Patterns in Nature</a></li><li><strong style="FONT-WEIGHT: normal; FONT-STYLE: italic"><a title="Order Out of Chaos" href="http://www.amazon.com/gp/product/0553343637/104-2883280-1296732?tag=softwcreatmys-20">Order Out of Chaos</a></strong>, Ilya Prigogine</li><li><a style="FONT-STYLE: italic" href="http://www.cmqr.rmit.edu.au/publications/lbpositi.pdf">Using Positioning Theory to Make Change Happen</a>, by Lionel Boxer<br /></li></ul><br />I'll be taking a break on this topic (Self-Organization) for awhile, and then returning to it again later to talk about <em>Swarm Behavior, Collective Intelligence, Social Creativity, Group Coherence, Group Decision-Making and Holocracy/Sociocracy</em>.</span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-51256421028706978482009-06-16T00:16:00.011-05:002009-07-06T07:26:49.256-05:00Agile Self-Organizing Teams<span style="font-family:georgia;">The previous blog-entry on self-organization was lots of jargon and technical mumbo jumbo that didn't say too much about what that means for teams of people. So let's shift from talking about self-organizing systems in complexity science to talking about how it applies to self-organizing teams in an agile context.<br /><br />A self-organizing team is a team that is led and organized by it's members, to attain goals and objectives specified by management within the constraints of its environment:<br /><ul><li>Management can shape and "nudge" the team and its members, but management doesn't try to dictate the details of "what" the solution is nor the process of how to create it.</li><li>The team is responsible for not only leading and organizing itself to achieve its goals, but also to monitor and adapt its behavior to correct/improve its own performance.</li><li>This means the team can change how it leads and organizes itself in order to respond to feedback and constraints from its environment, which also implies that ...<br /></li><li>There is no single central "leader" for the team over the lifetime of the team/project - the "leader" is not a static assignment, but rather a dynamic role</li><li>So the person(s) leading any given moment may change, depending on the particular decision, activity, or problem being addressed in any particular context/situation.</li></ul><br />By themselves, self-organizing teams are neither "good" nor "bad." They simply "are." They require a supporting management environment (the "fitness landscape") and organizational culture that establishes, communicates, rewards and reinforces the "right" set of values and principles. Without supportive management and the proper leadership culture, there is a very high likelihood that a self-organizing team may be unable to create good results or effective processes (or both). In fact, it's not uncommon for a newly formed & "empowered" self-organizing team to fall into many of the same dysfunctional patterns of behavior that it was most trying to escape from within the "management" that only recently "empowered" the team.<br /><br />An "agile team" is (supposed to be) a self-organizing team that is guided by the <a href="http://www.agilemanifesto.org/">agile values</a> and <a href="http://www.agilemanifesto.org/principles.html">agile principles</a> (given by the <a href="http://www.agilemanifesto.org/">agile manifesto</a>) and is supported by a trusting and empowering style of management. With management supporting their agile values/principles, Agile teams "self-organize" to collectively decide and do what is needed in order to: make and meet commitments, develop a quality product, respond to feedback, and adapt to changes.<br /><br />So an <i>Agile Self-Organizing Team</i> is:<br /><ul><li><b>Autonomous</b>: There is no single central decision-making authority. Control is distributed collectively to the team.</li><br /><li><b>Adaptive</b>: The team dynamically adjusts as needed across roles, functional specialties, and other boundaries, in order to solve their own problems and improve their own performance.</li><br /><li><b>Accountable</b>: The team collectively shares responsibility for results, and members hold each other accountable for outcomes.</li></ul>Here are some choice quotes regarding self-organizing teams ...<br /><br /><span style="color: rgb(0, 0, 153);font-family:trebuchet ms;" >“The team makes most decisions, while every member could step in and become leader in specific areas and situations. People are highly capable, committed and self-driven.”</span><br />—Andriy Solovey, <a href="http://softwarecreation.org/2007/what-is-the-best-leader-for-the-software-team"><i>What is the best leadership style for the software team?</i></a><br /><br /><span style="color: rgb(102, 51, 51);font-family:trebuchet ms;" >“This causes a shift in the roles of managers from planning, controlling, directing, and managing to new roles like building trust, facilitating and supporting team decisions, expanding team capabilities, anticipating and influencing change.”</span><br />—Diana Larsen, <a style="font-style: italic;" href="http://www.futureworksconsulting.com/resources/TeamAgilityAgileTimesFeb04.pdf">Exploring Self-Organizing Software Development Teams</a><br /><br /><span style="color: rgb(0, 102, 0);font-family:trebuchet ms;" >"Responsibility-Based Planning and Control: Respecting people means that teams are given general plans and reasonable goals and are trusted to self-organize to meet the goals. Respect means that instead of telling people what to do and how to do it, you develop a reflexive organization where people use their heads and figure this out for themselves."</span><br />—Mary Poppendieck, <a style="font-weight: bold;" href="http://www.poppendieck.com/ilsd.htm">Implementing Lean Software Development</a><br /><br />In <a style="font-style: italic;" href="http://www.infoq.com/articles/learning_is_the_bottleneck">Learning is the Bottleneck</a>, Amr Elssamadisy & Deborah Hartmann write:<br /><blockquote style="color: rgb(102, 51, 102); font-family: trebuchet ms;">"Human psychology aspect adds that self-organized teams:<br /><ul><li>are more responsible for end results, self-disciplined and self-driven</li><li>avoid dependency on the formal leader qualities</li><li>motivated, initiative and willing to act</li><li>enjoy work more</li><li>better insured against <a href="http://en.wikipedia.org/wiki/Groupthink">groupthink</a>, <a href="http://en.wikipedia.org/wiki/Conformity">conformity</a> and <a href="http://en.wikipedia.org/wiki/Diffusion_of_responsibility">diffusion of responsibility</a></li><li>not<a href="http://softwarecreation.org/2007/lost-personalities-how-our-company-alters-us/"> shifting judgment and decisions</a> to others, better in finding alternative and balancing options</li><li>every member is in charge, ready to step in as a leader and have incentive to develop leadership skills</li></ul>A self-organized team is possible when people carry shared purpose, principles and values. They support and respect each other. And they want to succeed. The [Agile] team works together to respond to changes that happen together. They collectively do what needs to be done to build the software."</blockquote><br />In his 2001 paper <a style="font-style: italic;" href="http://www.controlchaos.com/download/Self%20Organization.pdf">Agile Processes and Self-Organization</a> Ken Schwaber wrote:<br /><blockquote style="font-family: trebuchet ms; color: rgb(51, 0, 153);">"Agile processes employ self-organizing teams to handle the complexity inherent in systems development projects. A team of individuals is formed. They organize themselves into a team in response to the pressure of a deadline, reminding me of the saying, "Nothing focuses the mind like a noose!" The pressure cooker of the deadline produces cooperation and creativity that otherwise is rare. This may seem inhumane, but compared with non-agile practices for dealing with complexity, self-organization is a breath of fresh air."</blockquote><br />This is what Kevin Kelly wrote about that problem in his book <a href="http://www.amazon.com/gp/product/0201483408"><b>Out of Control</b></a>:<br /><blockquote style="font-family: trebuchet ms; color: rgb(102, 51, 51);">"When everything is connected to everything in a distributed network, everything happens at once. When everything happens at once, wide and fast moving problems simply route around any central authority. Therefore overall governance must arise from the most humble interdependent acts done locally in parallel, and not from a central command."</blockquote><br />Roger Lewin wrote in <a href="http://www.amazon.com/gp/product/0226476553"><b>Complexity: Life at the Edge of Chaos</b></a>:<br /><blockquote style="color: rgb(0, 102, 0); font-family: trebuchet ms;">"Complexity science implies that CEOs and managers must give up control -- or rather, the illusion of control -- when they are trying to lead their organization to some goal. But they do need to create the environment in which creativity can emerge. The message of complexity science is not simply to stand back and wait for the right solutions to emerge. Too little control is just as misguided a business strategy as too much. Some structure is necessary. The degree and nature of control that CEOs establish in their companies strongly influences what emerges, in terms of culture, creativity, and adaptability."</blockquote><br />Mishkin Berteig writes in <a style="font-style: italic;" href="http://www.agileadvice.com/archives/2005/12/agile_work_uses_2.html">Team Self-Organization</a>:<br /><blockquote style="font-family: trebuchet ms; color: rgb(102, 51, 102);">"In agile teams, this concept of self-organization is taken quite far. Team members collaborate to get work done. No one orders a team or an individual to do specific work. The team members volunteer for work that they see needs doing, even if it is not something that is in their area of expertise. An agile team is constantly promoting learning in its people. Agile teams are also cross-functional so that the team can get work done without relying on external services. The team therefore represents a complete work unit capable of taking a function valuable to customers from start to finish, from idea to deployment."</blockquote><br />In <a href="http://www.think-box.co.uk/blog/2006/01/why-agile-principles-are-important.html"><i>Why Agile Principles are Important</i></a>, Simon Baker writes:<br /><blockquote style="font-family: trebuchet ms; color: rgb(51, 0, 153);">An experienced agile software development team is a highly social group that is self-organising around these principles and acts with coordination and collective behaviour. This collective behaviour comprises:<br /><br /><ul><li><i>Collective mind</i> where individual team members develop shared understandings of the team's tasks and of one another, and come to understand how their work contributes to the work of the team thereby facilitating team performance.</li><br /><li><i>Swarm intelligence</i> which gives a team the ability to adapt to changes, and robustness which enables them to still perform and deliver even when one or more members fail.</li></ul></blockquote><br />From <a style="font-style: italic;" href="http://www2.isye.gatech.edu/%7Ecarl/papers/anderson_mcmillan_revised.pdf">Of ants and men: self-organized teams in human and insect organizations</a><br /><blockquote><span style="color: rgb(0, 51, 0);font-family:trebuchet ms;" >To cope with today’s complex, fast-paced, and ever-changing business environment, companies need to shift their overall structure to produce adaptive, highly responsive organizations. The use of teams, particularly self-organized teams with their reactive, emergent properties, may be one way of achieving this goal.</span><br /><br /><span style="color: rgb(0, 51, 0);font-family:trebuchet ms;" >In other words, insect societies often harness the power of self-organization such that with the appropriate set of feedbacks, interindividual interactions, and proximate mechanisms, group-level adaptive behavior simply emerges. No one directs the foragers where to find food, the network of trails and interactions takes care of that; individuals are not allocated to tasks, the reverse is true: the tasks allocate the workers.</span><br /><br /><span style="color: rgb(0, 51, 0);font-family:trebuchet ms;" >McMillan-Parsons (1999) found that the teams fitted Stacey’s (1996) description of self-organizing groups or teams as ones that arise spontaneously around specific issues, communicate and cooperate about these issues, reach a consensus, and make a committed response to these issues. Further, ‘research suggested that self organizing teams have a strong sense of shared purpose, strong personal commitment, display creative and spontaneous behaviors, have high levels of energy and enthusiasm, and that an inherent order emerges from their activities’.</span><br /><br /><span style="color: rgb(0, 51, 0);font-family:trebuchet ms;" >Importantly, in self-organizing teams the members self select and there is no-one checking to see if they have the necessary range of attributes. In her study, McMillan (1999) discovered that members of the self-organizing teams studied learned new skills and developed new attributes to meet the needs of the team.</span><br /><br /><span style="color: rgb(0, 51, 0);font-family:trebuchet ms;" >One characteristic of such organizations is adhocracy. These large, mature yet high-performing companies manage to generate the flexible and adaptive properties of smaller entrepreneurial organizations—in short, to “be big and yet to act small at the same time”. Using teams is one key means of achieving that, for, as Flory (2002, p. 9) remarks, self-managed teams, ‘are fast moving, fast learning groups, flexible, highly autonomous and have a well-developed pro-active attitude and sense of responsibility. These characteristics are the very reason they are brought into life as answers for organizations to respond to a fast moving world.’</span></blockquote><br /><br /><table border="1" cellpadding="1" cellspacing="1"> <tbody><tr> <td style="color: rgb(102, 51, 0);font-family:arial;"> <span style="font-size:130%;"><b>Self-managed Teams </b></span> </td> <td style="color: rgb(0, 102, 0);font-family:arial;"> <span style="font-size:130%;"><b>Self-organized Teams </b></span> </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Part of formal organization structure </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Not part of formal organization structure </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Formal, temporary, or permanent </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Informal and temporary </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Not spontaneously formed </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Formed spontaneously around issue(s) </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Indirectly controlled by senior management </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Boundaries influenced by senior management </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Managers decide ‘who’ and ‘what’ </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Team members decide ‘who’ and ‘what’ </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Replace the hierarchy </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Often in conflict with or constrained by the hierarchy </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Empowered by senior management </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Empowered by the team’s members </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Strongly shared culture </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Cultural differences provoke and constrain </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Some sense of shared purpose </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Strong sense of shared purpose </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Order created via recognized processes </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Inherent order emerges </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Behaviors influenced by procedures and roles </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Spontaneous, creative behaviors </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Strong sense of team commitment </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Strong sense of personal commitment </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Some energy and enthusiasm </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> High levels of energy and enthusiasm </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> Decision making is mainly a planned process </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> Decision making is mainly a spontaneous process </td> </tr> <tr> <td style="font-family: arial; color: rgb(102, 51, 0);"> At least one member’s primary role is organizational </td> <td style="font-family: arial; color: rgb(0, 102, 0);"> All members’ primary role relate to the task </td> </tr> </tbody></table><br /><br />In my next blog-entry I'll give links to several other resources on Self-Organizing Teams.<br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com1tag:blogger.com,1999:blog-10280668.post-75267477767507854352009-06-14T00:17:00.013-05:002009-07-01T01:07:24.118-05:00Self-Organization and Complexity<span style="font-family:georgia;">In my <a href="http://blog.bradapp.net/2009/06/agile-self-organization-versus-lean.html">previous blog-entry</a> I talked a little about how self-organization is a key aspect of <a href="http://blog.bradapp.net/2009/04/what-is-agility-part-2-software-agility.html">software agility</a>. In this blog-entry I'd like to explore in more detail just what "self-organization" really means.<br /><br /><a style="font-weight: bold; font-style: italic;" href="http://en.wikipedia.org/wiki/Self-organization">Self-organization</a> comes from <a href="http://en.wikipedia.org/wiki/Complexity">complexity science</a> and the theory of <a href="http://en.wikipedia.org/wiki/Complex_adaptive_system">complex adaptive systems</a> (CAS). A system is "self-organizing" if, left to its own devices, it tends to become more organized over time. This is in stark contrast to the concept of <a href="http://en.wikipedia.org/wiki/Entropy">entropy</a> from the <a href="http://en.wikipedia.org/wiki/Laws_of_thermodynamics">laws of thermodynamics</a> whereby a closed system tends to move to a state of increasing disorder in the absence of outside influences.<br /><br />In a complex adaptive system where self-organization occurs, we necessarily have an <a href="http://en.wikipedia.org/wiki/Open_system_%28systems_theory%29">open system</a> rather than a closed one. The theory goes that if a <a href="http://en.wikipedia.org/wiki/Complex_systems">complex system</a> possesses the necessary <a href="http://en.wikipedia.org/wiki/Emergence">emergent properties</a> in an appropriate <a href="http://en.wikipedia.org/wiki/Fitness_landscape">fitness landscape</a>, then the system will yield emergent behavior, exhibiting system-wide "patterns", that increases the "order" or organization in the system. Hence the system has become <span style="font-style: italic;">self-organizing</span> as a result of this <span style="font-style: italic;">emergent behavior & structure</span>.<br /><br />Some of the emergent properties of self-organizing systems can include:<br /><ul><li>Autonomy,</li><li>Adaptability,</li><li>Decentralization,</li><li>Dynamic reconfiguration,</li><li>Positive & Negative Feedback</li><li> Cooperation & Information exchange</li></ul>The <a href="http://softwarecreation.org/2007/evolutionary-software-architecture-or-why-developers-are-not-janitors/">theory of complex systems</a> suggests that self-organized systems are:<br /><ul><li>better in selecting optimal state and local decisions</li><li>robust</li><li>effectively adapt to environment and use feedback loops</li><li>often come up with emergent and unexpected solutions</li><li>self-regulated and better cope with perturbations</li></ul>According to <a href="http://www.jimhighsmith.com/">James Highsmith</a>,<br /><blockquote face="trebuchet ms" style="color: rgb(0, 0, 102); font-family: trebuchet ms;">“There's no hierarchy of command and control in a complex adaptive system. There's no planning or managing, but there's a constant re-organizing to find the best fit to the environment. The system is continually self-organizing through the process of emergence and feedback”</blockquote><br />The <a style="font-weight: bold;" href="http://emergent.brynmawr.edu/eprg/">Emergent Phenomena Research Group</a> at Brywn Mawr says:<br /><blockquote style="color: rgb(102, 51, 0); font-family: trebuchet ms;">"In self-organizing systems, global order (i.e., complex aggregate structure/behavior) results (emerges) from the local behaviors of simple agents following simple rules specifying conditions under which those agents act (interact) in such a way that the results of the agents' actions are fed back as input to the operation of the rule system at some future time step. "</blockquote><br />In <a style="font-weight: bold;" href="http://pespmc1.vub.ac.be/Papers/EOLSS-Self-Organiz.pdf">The Science of Self-organization and Adaptivity</a>, Francis Heylighen writes:<br /><blockquote><span style="color: rgb(102, 51, 102);font-family:trebuchet ms;" >Self-organization is basically the spontaneous creation of a globally coherent pattern out of the local interactions between initially independent components. This collective order is organized in function of its own maintenance, and thus tends to resist perturbations. This robustness is achieved by distributed, redundant control so that damage can be restored by the remaining, undamaged sections. ...<br /><br /></span><span style="color: rgb(102, 51, 102);font-family:trebuchet ms;" >Self-organizing systems are characterized by: <span style="font-style: italic;">distributed control</span> (absence of centralized control), <span style="font-style: italic;">continual adaptation</span> to a changing environment, <span style="font-style: italic;">emergent structure</span> from local interaction, <span style="font-style: italic;">robustness/resiliency</span> (able under change and can quickly repair, correct, adapt/adjust), <span style="font-style: italic;">non-linearity</span>, <span style="font-style: italic;">feedback</span> (both positive and negative), <span style="font-style: italic;">self-sufficiency</span> and <span style="font-style: italic;">closure/coherence</span>. ...</span><br /><br /><span style="color: rgb(102, 51, 102);font-family:trebuchet ms;" ><span style="font-style: italic;">Organizational closure</span> turns a collection of interacting elements into an individual, coherent whole. This whole has properties that arise out of its organization, and that cannot be reduced to the properties of its elements. Such properties are called </span><span style="font-style: italic; color: rgb(102, 51, 102);font-family:trebuchet ms;" >emergent</span><span style="color: rgb(102, 51, 102);font-family:trebuchet ms;" >.</span><br /><br /><span style="color: rgb(102, 51, 102);font-family:trebuchet ms;" >Every self-organizing system <span style="font-style: italic;">adapts </span>to its environment; Systems may be called <span style="font-style: italic;">adaptive </span>if they can adjust to such changes while keeping their organization as much as possible intact.</span><br /></blockquote><br />From <a style="font-weight: bold;" href="http://www.targetprocess.com/blog/2008/11/software-development-is-complex.html">Software Development is Complex Adaptive System. No Doubt</a><br /><blockquote style="color: rgb(0, 51, 0);font-family:trebuchet ms;"><span style="font-style: italic;">Emergence </span>is the way complex systems and patterns arise out of a multiplicity of relatively <span style="font-style: italic;">simple interactions</span>. Small actions of agents lead to unexpected <span style="font-style: italic;">emergent </span>system behavior and it is impossible to predict system behavior based on the behavior of an individual agent. Small errors pile up and may cause huge problem.<br /><br />There's no hierarchy of command and control in a complex adaptive system. There's no planning or managing, but there's a constant re-organizing to find the best fit to the environment. The system is continually self-organizing through the process of <span style="font-style: italic;">emergence </span>and <span style="font-style: italic;">feedback</span>.<br /><br />A system in equilibrium does not have the internal dynamics that enables it to respond to the environment and will slowly (or quickly) die. A system in chaos stops functioning as a system. The most productive state to be in is at the edge of chaos where there is maximum variety and creativity, leading to new possibilities. A set of simple rules allows edge of chaos and powers creativity, flexibility and success.</blockquote><br />And last but not least, from <a href="http://www.scribd.com/doc/14424701/Conditions-for-SelfOrganizing-in-Human-Systems">Conditions for Self-Organizing in Human Systems</a> :<br /><blockquote style="color: rgb(0, 0, 102);font-family:trebuchet ms;"><span style="font-style: italic;">Self-organization</span> is the spontaneous generation of order in a complex adaptive system. It is the process by which the internal dynamics of a system generate system-wide patterns. Some of the emergent patterns in a self-organizing system are coherent, and others are not. <span style="font-style: italic;">Coherence </span>is a state of the system in which:<br /><ul><li>Meaning is shared among agents.</li><li>Internal tension is reduced.</li><li>Actions of agents and sub-systems are aligned with system-wide intentionality.</li><li>Patterns are repeated across scales and in different parts of the system.</li><li>A minimum amount of energy of the system is dissipated through internal interactions.</li><li>Parts of the system function in complementary ways.</li></ul>System-wide patterns in which the parts are aligned and mutually reinforcing (coherent) are more stable than other self-organized patterns. Because of the mutually reinforcing dynamics of a coherent pattern, the effort required to change the pattern is greater than the effort to maintain it, so coherent patterns are more stable than incoherent ones. When the system reaches a state of coherence ... tensions within the system are reduced, and the available energy of the system is aligned and focused on system-wide behaviors, rather than diverse and disruptive behavior of individual agents or sub-system clusters. ...<br /><br />In human systems, the process of self-organizing is particularly important. Teams, institutions, and communities include individuals or groups of individuals that function as agents in self-organizing. As the agents interact, patterns of behavior emerge over time.These patterns form and reform spontaneously and continually at multiple levels within the system. Individuals work together to form teams. Ethnic identity groups establish relationships and micro-cultures. Functional departments engage with each other to do the work of the organization. At all of these levels, agents interact naturally to form patterns of system-wide behavior. ...<br /><br />The CDE model is a set of the three conditions for self-organizing of human systems: <span style="font-style: italic;"><span style="font-weight: bold;">C</span>ontainer</span>, <span style="font-style: italic;">significant <span style="font-weight: bold;">D</span>ifference</span>, and <span style="font-style: italic;">transforming <span style="font-weight: bold;">E</span>xchange</span>. The path, rate, and outcomes of self-organizing processes are influenced by these three conditions, which are co-dependent such that the function of each of the conditions depends on the others in nonlinear interactions in the system. A change in any one of the conditions results in a change in the other two over time.</blockquote><br />Also see the following:<br /><ul><li>Wikipedia entries on <a style="font-style: italic;" href="http://en.wikipedia.org/wiki/Self-organization">Self-Organization</a> and <a style="font-style: italic;" href="http://en.wikipedia.org/wiki/Emergence">Emergence</a></li><li><span style="font-family:georgia;"><a href="http://www.calresco.org/sos/sosfaq.htm" id="v9b_" title="Self-Organizing Systems FAQ">Self-Organizing Systems FAQ</a> </span></li><li style="font-style: italic;"><a href="http://arxiv.org/ftp/nlin/papers/0509/0509049.pdf">10 Questions about Emergence</a></li><li><a style="font-style: italic;" href="http://pespmc1.vub.ac.be/Papers/IEEE.Self-organization.pdf">The Meaning of Self-Organization in Computing</a> and <span style="font-style: italic;font-family:georgia;" ><a href="http://pespmc1.vub.ac.be/Papers/EOLSS-Self-Organiz.pdf" id="iq-e" title="The Science of Self-Organization and Adaptivity">The Science of Self-Organization and Adaptivity</a></span>, Francis Heylighen & Carlos Gershenson<br /></li><li><a style="font-style: italic;" href="http://www.systemdynamics.org/conferences/2001/papers/Georgantzas_2.pdf">Self-Organization Dynamics</a><br /></li><li><a style="font-style: italic;" href="http://www.naturalhistorymagazine.com/0603/0603_feature1.html">Patterns in Nature</a></li><li><strong style="font-weight: normal;"><a href="http://www.amazon.com/gp/product/0553343637/104-2883280-1296732?tag=softwcreatmys-20" title="Order Out of Chaos">Order Out of Chaos</a></strong>, Ilya Prigogine</li><li><a style="font-style: italic;" href="http://softwarecreation.org/2007/evolutionary-software-architecture-or-why-developers-are-not-janitors/">Evolutionary Software Architecture, or Why Developers are not Janitors</a>, Andriy Solovey<br /></li></ul>In my <span style="font-weight: bold;">next blog-entry</span> I'll talk specifically <span style="font-weight: bold;">about self-organizing teams</span>. Some specific characteristics and/or results of self-organization that I'll be delving into more deeply in subsequent blog-entries are:<br /><ul><li><span style="font-style: italic; font-weight: bold;">Swarm Behavior</span> (a.k.a. <span style="font-style: italic;">Swarm Intelligence</span>)</li><li><span style="font-style: italic; font-weight: bold;">Collective Intelligence</span> (a.k.a. <span style="font-style: italic;">Collective Mind</span>)</li><li style="font-weight: bold; font-style: italic;">Social Creativity</li><li style="font-weight: bold; font-style: italic;">Group Coherence</li></ul><ul><br /></ul></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com1tag:blogger.com,1999:blog-10280668.post-34499600909545984302009-06-12T00:52:00.005-05:002009-06-30T03:25:37.979-05:00Agile Self-Organization versus Lean Leadership<span style="font-family:georgia;">Getting back to the agility cycle ... recall that I started with <a href="http://blog.bradapp.net/2009/04/agility-cycle-part-1.html">the business agility cycle</a> and used that to derive <a href="http://blog.bradapp.net/2009/04/agility-cycle-part-2.html">the software agility cycle</a>. There isn't a great deal of difference between the first two steps of the business-agility cycle and the software-agility cycle, other than the fact that much of the former takes place at a higher-level of organizational management and strategy.<br /><br />The biggest difference between the two cycles happens after those first two steps. In the business agility cycle we then decide-communicate-act, suggesting that it is the higher-ups who make and communicate the decisions and the lower-end of the organizational food chain (the "worker bees") that execute the organization's strategic solution.<br /><br />If that seems a bit command-and-control, its because it is (a bit). It's also likely necessary in larger organizations where it is virtually impossible to avoid having 2 or more layers of management. There, the "communicate & act" steps are really the process of providing focus, and communicating objectives and constraints to the knowledge workers, and letting them apply principles of collaboration and self-organization to solve the problem (like in the software-agility cycle).<br /><br />So the key difference between business-agility and software-agility is the extra emphasis of the latter on "the people factor" and on the notion of dynamic self-organization of knowledge-workers as empowered, self-organizing teams. This difference between agility at the business-level versus software-level is also the key difference between Lean-vs-Agile:<br /><ol><li><b>Lean</b> focuses more on <i>flow</i> whereas <b>Agility</b> focuses more on <i>adapting to change</i> (this is true of both software agility <i>and</i> business-agility). As it turns out, focusing on flow requires being able to adapt to change; and focusing on adaptiveness and responsiveness requires a focus on flow. So here, the end-results may be quite similar</li><br /><li><span style="font-weight: bold;">Agile software development</span> emphasizes a very <span style="font-style: italic;">hands-off management style</span> of not just trusting and empowering the team(s), but often to the extreme of basically saying "<span style="font-family:verdana;">leave us alone and don't interfere</span>" to management (and in return promising extreme transparency and frequent tangible end-results).</li><br /><li>Much of this is due to the fact that the scope of <span style="font-weight: bold;">Agile development</span> is <span style="font-style: italic;">limited to software projects and teams</span>, whereas <span style="font-weight: bold;">Lean </span>is <span style="font-style: italic;">targeted at enterprise-wide scale across the whole value-stream</span>.<br /></li></ol><br />That is not to say that Lean (or business-agility) don't emphasize trusting and empowering workers and teams (they do). But they don't have the underlying inherent attitude of "just trust us and stay out of the way." The "trust" often doesn't seem to extend as far in the other direction with Agile development (e.g. not trusting management direction to the same extent that management is asked to trust the team).<br /><br />I think this stems from the fact that software agility started more at the grass-roots level, with developers and teams struggling to create good, quality software in the face of what was all too often a fundamentally broken management framework for the governance, visibility, and lifecycle of software development projects. Because they were working and trying to get support from the bottom-up, they needed to be shielded from and unshackled by all the dilbert-esque "pointy haired managers" and their big, bad governance framework with its "evil" waterfall lifecycle.<br /><br />And in that context, the advice of "just get out of the way and trust us and we promise to deliver working software every 2-4 weeks" is actually a very effective strategy to employ. When management doesn't "get it", their attempts to steer, direct and intervene are often the equivalent of "friendly fire" (which, despite well intentions, still yields calamitous results.)<br /><br />But Lean comes from a history of a much more enterprise-wide scope, often even using a top-down deployment strategy. So when it asks management to trust and empower workers and teams it expects the corresponding change in its leaders and their leadership-style, and for them to still play a strong, active and participative role with their projects and teams.<br /><br />Agile teams often get a "bad rap" for having this isolationist attitude toward management. And sometimes that "rap" is warranted. But when the leadership "gets it" and understands and values the "new" paradigm of why+how agile works, and why+how the "old way" didn't, then it probably is time for the leadership to play a different, more active role while still trusting and empowering teams (and still enabling self-organization). This is the view that Lean takes toward management, and is a big part of why it is better received by management and is more broadly applicable for scaling agility "up" and "out" in larger enterprises.<span style="font-family:georgia;"><br /></span></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com8tag:blogger.com,1999:blog-10280668.post-29251606153778799822009-06-10T01:17:00.012-05:002009-06-19T01:21:48.597-05:00Value Proposition for Agility<span style="font-family:georgia;">I'm sure I'm not the first person to think it, but I just came across the description of a newly published book whose title made me think about this subject. The book is:<br /><br /><a href="http://www.informit.com/title/0137032382"><span style="font-weight: bold;">Reading Minds and Markets: Minimizing Risk and Maximizing Returns in a Volatile Global Marketplace</span></a>, by Jack Ablin and Suzanne McGee.<br /><br />The title immediately made me think that this was the right language to use when communicating with business-people and senior management to describe what agility is in terms of its benefits to the bottom line.<br /><br /><a href="http://www.investopedia.com/">Investopedia</a> describes a "<a href="http://www.investopedia.com/terms/v/valueproposition.asp"><i>Value Proposition</i></a>" as: "<em style="font-family: times new roman;">A business or marketing statement that summarizes why a consumer should buy a product or use a service. This statement should convince a potential consumer that one particular product or service will add more value or better solve a problem than other similar offerings.</em>"<br /><br />So I think that "value proposition" is the right term to describe what is it about agility that I want to describe to a business-person or senior manager that should make them want to care about what agility is and why they should adopt it.<br /><br />With the above in mind, here is my "value proposition" for agility:<br /><blockquote style="font-family: verdana; font-size: 130%; color: rgb(0, 0, 153);"><em><strong>Agility is all about harnessing the power of <u>collaborative people</u> and <u>frequent delivery</u> to:</strong><ul><li><strong>learn & adapt to change,</strong></li><li><strong>minimize risk & cycle-time,</strong> and ...</li><li><strong>maximize returns & customer-value</strong></li></ul><strong>in a volatile global marketplace.</strong></em></blockquote><br />There! Top that! :-)<br /><br />Think you have a better value-proposition for agility that is more succinct while still touching on the minimally sufficient set of key attributes? (the people-factor, frequent value-delivery, cycle-time, responsiveness to change and risk/ROI)<br /><br />If so, then I want to see it! Leave a comment and let me know!<br /><br /><br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com6tag:blogger.com,1999:blog-10280668.post-55581569373638521502009-06-09T23:18:00.002-05:002009-07-19T02:35:21.991-05:00BOOK: The Art of Lean Software Development<span style="font-family:georgia;">In the June issue of <a href="http://www.agilejournal.com/">the Agile Journal</a> I reviewed Curt Hibbs, Steve Jewett and Mike Sullivan's <a href="http://oreilly.com/catalog/9780596517311/">The Art of Lean Software Development: A Practical and Incremental Approach</a>. Here is an excerpt ...<br /><br /><blockquote style="font-family: times new roman; color: rgb(0, 0, 102);">With <a href="http://www.leanssc.org/press-releases/2009-05-06.html">last month's announcement</a> of the <a href="http://www.leankanbanconference.com/">Lean Software and Systems Consortium</a> at the <a href="http://www.leanssc.org/">2009 Lean & Kanban Conference</a>, it seems fitting that this month's book is about Lean Software Development and how Agile development practices support Lean Thinking.<br /> <br /><a href="http://oreilly.com/catalog/9780596517311/">The Art of Lean Software Development: A Practical and Incremental Approach</a> is an introduction to Agile software development practices through the lense of <a href="http://en.wikipedia.org/wiki/Lean_manufacturing">Lean thinking</a>. The first thing you need to know about this book is who its target audience is [...] from the <a href="http://oreilly.com/catalog/9780596517311/">publisher's website for the book</a>: "This book has a very specific purpose -- it is aimed squarely at the complete novice. The one who has been hearing all the Lean-Agile buzz, really knows nothing about it, and wants to learn more quickly to decide if they want to dig deeper (without having to read a 500 page tome)."<br />...<br />Now that we've finally gotten that out of the way ... The <a href="http://oreilly.com/catalog/9780596517311/">Art of Lean Software Development</a> actually succeeds at its intended purpose. It is a very "lean" introduction to the subject of applying lean thinking to software development. (You can see for yourself by looking at the online excerpts of <a href="http://fyi.oreilly.com/2009/01/chapter-2-applying-lean-to.html">chapter 2</a> and <a href="http://cdn.oreilly.com/books/leansoftware/9780596517311_ch4.pdf">chapter 4</a>.)<br />...<br />I like just about everything that <a href="http://tedyoung.blogsome.com/2009/02/01/book-review-the-art-of-lean-software-development-1st-edition/">The Art of Lean Software Development</a> has to say. It is a bit of a dry read but a very quick one. ... For those more interested in the abridged version or the line-manager's equivalent of a technical overview, <a href="http://oreilly.com/catalog/9780596517311/">The Art of Lean Software Development</a> is a very quick and easy read that successfully introduces the history and essentials of Lean and Agile software development from a Lean thinking perspective.</blockquote><br />See <a href="http://www.agilejournal.com/articles/columns/column-articles/1746-featured-book-the-art-of-lean-software-development-by-curt-hibbs-steve-jewett-and-mike-sullivan">the full review</a> for more details.<br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-54395525709828241192009-06-07T09:08:00.005-05:002009-06-17T12:08:35.740-05:00The Dynamics of Leadership-Team Behavior<span style="font-family:georgia;">Interesting article in BusinessWeek from <a href="http://www.businessweek.com/magazine/toc/09_21/B4132jim_collins.htm">Jim Collins</a> on the <a href="http://www.businessweek.com/magazine/content/09_21/b4132026793275.htm"><em>Dynamics of Team-Leadership Behavior</em></a>. It's actually an excerpt from his latest book "<strong><a href="http://www.amazon.com/How-Mighty-Fall-Companies-Never/dp/0977326411">How the Mighty Fall: and Why Some Companies Never Give In</a></strong>."<br /><br />Anyway ... <a href="http://www.businessweek.com/magazine/content/09_21/b4132026793275.htm"><em>the Dynamics of Team-Leadership Behavior</em></a> is divided into leadership behaviors of teams on the way up vs. on the way down:<br /><br /><table valign="top" border="1" cellpadding="2" cellspacing="1"> <tbody valign="top"><tr> <td style="color: rgb(102, 51, 51);"> <h2>Teams on the Way Down</h2> </td> <td style="color: rgb(0, 0, 153);"> <h2>Teams on the Way Up</h2> </td> </tr> <tr> <td style="color: rgb(102, 51, 51);"> People shield those in power from unpleasant facts, fearful of penalties and criticism for shining light on the rough realities </td> <td style="color: rgb(0, 0, 153);"> People bring forth grim facts—"Come here and look, man, this is ugly"—to be discussed; leaders never criticize those who bring forth harsh realities </td> </tr> <tr> <td style="color: rgb(102, 51, 51);"> People assert strong opinions without providing data, evidence, or a solid argument </td> <td style="color: rgb(0, 0, 153);"> People bring data, evidence, logic, and solid arguments to the discussion </td> </tr> <tr> <td style="color: rgb(102, 51, 51);"> The team leader has a very low questions-to-statements ratio, avoiding critical input and/or allowing sloppy reasoning and unsupported opinions </td> <td style="color: rgb(0, 0, 153);"> The team leader employs a Socratic style, using a high questions-to-statements ratio, challenging people, and pushing for penetrating insights </td> </tr> <tr> <td style="color: rgb(102, 51, 51);"> Team members acquiesce to a decision but don't unify to make the decision successful—or worse, undermine it after the fact </td> <td style="color: rgb(0, 0, 153);"> Team members unify behind a decision once made, then work to make the decision succeed, even if they vigorously disagreed with it </td> </tr> <tr> <td style="color: rgb(102, 51, 51);"> Team members seek as much credit as possible for themselves, yet do not enjoy the confidence and admiration of their peers </td> <td style="color: rgb(0, 0, 153);"> Each team member credits other people for success, yet enjoys the confidence and admiration of his or her peers </td> </tr> <tr> <td style="color: rgb(102, 51, 51);"> Team members argue to look smart or to further their own interests rather than argue to find the best answers to support the overall cause </td> <td style="color: rgb(0, 0, 153);"> Team members argue and debate, not to improve their personal position but to find the best answers to support the overall cause </td> </tr> <tr> <td style="color: rgb(102, 51, 51);"> The team conducts "autopsies with blame," seeking culprits rather than wisdom </td> <td style="color: rgb(0, 0, 153);"> The team conducts "autopsies without blame," mining wisdom from painful experiences </td> </tr> <tr> <td style="color: rgb(102, 51, 51);"> Team members often fail to deliver exceptional results and blame other people or outside factors for setbacks, mistakes, and failures </td> <td style="color: rgb(0, 0, 153);"> Each team member delivers exceptional results, yet in the event of a setback each accepts full responsibility and learns from mistakes </td> </tr> </tbody></table><br /><br /></span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-66749443036695319422009-06-04T00:26:00.004-05:002009-06-15T00:56:56.283-05:00BOOKS: The Passionate Programmer and the Nomadic Developer<span style="font-family:georgia;">Gosh, when I write/say the titles of these two books together in one line it looks like the title of some kind of computer-geek romance novella. (maybe it will sell more books that way :-)<br /><br />Anyway, I'm mentioning these two books together because they both relate to subject of managing your career if you are a professional software developer, and they are both complementary to one another.<br /><br /><a style="font-weight: bold;" href="http://www.pragprog.com/titles/cfcar2/the-passionate-programmer">The Passionate Programmer: Creating a Remarkable Career in Software Development</a>, by <a href="http://chadfowler.com/">Chad Fowler</a>, is really the revised edition of an earlier work by him under a different book title. It's from the <a href="http://pragprog.com/">Pragmatic Programmers</a>, so that by itself practically guarantees its pretty darn good. The blurb for the book is pretty darn accurate too: "<span style="font-style: italic; color: rgb(0, 0, 102);font-family:times new roman;" >This book is about creating a remarkable career in software development. In most cases, remarkable careers don’t come by chance. They require thought, intention, action, and a willingness to change course when you’ve made mistakes. Most of us have been stumbling around letting our careers take us where they may. It’s time to take control. This revised and updated second edition lays out a strategy for planning and creating a radically successful life in software development</span><span style="color: rgb(0, 0, 102);font-family:times new roman;" >.</span>" Several excerpts are available from <a href="http://pragprog.com/titles/cfcar2/the-passionate-programmer">publisher's homepage for the book</a>.<br /><br /><a href="http://www.informit.com/store/product.aspx?isbn=0321606396"><span style="font-weight: bold;">The Nomadic Developer: Surviving and Thriving in the World of Technology Consulting</span></a>, by <a href="http://nomadic-developer.com/">Aaron Erickson</a>, is a must read for anyone considering becoming a software development consultant (or by anyone who recently became one). </span><a style="font-style: italic;" href="http://www.informit.com/content/images/9780321606396/samplepages/0321606396_Sample.pdf">Chapter 6 - Surviving</a>, is available as an online excerpt.<span style="font-family:georgia;"><br /><br />The "blurb" for this book is a bit long so I'll include only part of it here: "<span style="font-style: italic; color: rgb(0, 0, 102);font-family:times new roman;" >There are real advantages to being a consultant. You make contacts with a lot of different people; you get exposure to many industries; and most important, unlike a software developer in the IT department for a brick-and-mortar company, as a technology consultant, you </span><i style="font-family: times new roman; font-style: italic; color: rgb(0, 0, 102);">are</i><span style="font-style: italic; color: rgb(0, 0, 102);font-family:times new roman;" > the profit center…so long as you are billing. Consulting can be hugely rewarding–but it’s easy to fail if you are unprepared. To succeed, you need a mentor who knows the lay of the land. Aaron Erickson is your mentor, and this is your guidebook. Erickson has done it all–from Practice Leadership to the lowest level project work. In </span><i style="font-family: times new roman; font-style: italic; color: rgb(0, 0, 102);">The Nomadic Developer</i><span style="font-style: italic; color: rgb(0, 0, 102);font-family:times new roman;" >, he brings together his hardwon insights on becoming successful and achieving success through tough times and relentless change. You’ll find 100% practical advice and real experiences–his own and annotations from those in the trenches. In addition, renowned consultants–such as David Chappell, Bruce Eckel, Deborah Kurata, and Ted Neward–share some of their hard-earned lessons.</span>"<br /><br />I don't need to tell anyone that we are in tough economic times with cuts and force reductions abounding and new jobs being scarce. Seems to me that getting both of these books together makes just plain good sense for anyone in our line of work these days.</span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0tag:blogger.com,1999:blog-10280668.post-81430487747726432632009-06-01T02:21:00.008-05:002009-06-17T01:10:10.898-05:005S Qualities of Well Designed, Well-Factored Code<span style="font-family:georgia;">The other day I was trying to explain to someone the properties of code that is well-factored and found myself using aliteration with 'S' words. That made me wonder if they were equivalent to Lean's "5S", which is as follows:<br /><span style="font-family:times new roman;"><ul><li><i>Seiri</i> (<b>Sort</b>) - Organize the work-area, leaving only the tools and materials necessary to perform daily activities</li><br /><li><i>Seiton</i> (<b>Straighten, Set in Order</b>) - the orderly arrangement of needed items so they are easy to use and accessible for “anyone” to find.</li><br /><li><i>Seiso</i> (<b>Shine</b>) - Keep everything clean and swept. Don’t allow litter, scrap, shavings, cuttings, etc., to land on the floor in the first place.</li><br /><li><i>Seiketsu</i> (<b>Standardize</b>) - Creating a consistent approach for carrying out tasks and procedures. Orderliness is the core of “standardization” and is maintained by Visual Controls.</li><br /><li><i>Shitsuke</i> (<b>Sustain</b>) - the discipline and commitment of all other stages. Without “sustaining”, your workplace can easily revert back to being dirty and chaotic. That is why it is so crucial for your team to be empowered to improve and maintain their workplace. </li></ul></span><br />Does the above apply to the structure and content of the code itself? Have you ever come across code that is truly well-factored? I don't just mean correct and that it follows coding standards, I mean the structure of the code itself not only had such clarity of thought and order, but it also had all the qualities that we like to think of that make the code changeable/malleable with ease. Here is what I think those qualities are:<br /><ul><li><strong>Sufficient</strong> scope (content & functionality) – The code implements only that which is necessary. It doesn't have more content than needed, or more behavior or interfaces or abstractions than needed. It is "just enough" code to get the job done, while still possessing the other properties below. XP ensures this by taking the “next most important” requirement, creating only just enough content (spec, requirements, even branches) that can be implemented for current activity in the current workspace. Then write only “just enough” code to pass the test (then you refactor).</li><br /><li><strong>Simple</strong>, clean code – The code isnt just "Lean" in its content and functionality, but also in its structural design. Dependencies and duplication are minimized while clarity, cohesiveness, and conciseness are maximized. In XP, once the code result is “sufficient” in content & correctness, we refactor to simplify the structure and dependencies as much as possible.</li><br /><li><strong>Supple</strong> design – This comes from the chapter of the same name in Eric Evans Evans' book <a style="font-weight: bold;" href="http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215">Domain-Driven Design</a>. Supple means pliant, malleable, limber, yielding or changing readily. Code that is well-factored is at once so simple yet sufficient as to be firm yet flexible. Yet the flexibility comes not so much from what you added as from what you left out and how you organized it. It is more than just simple and sufficient, there is an inherent model or "theory" of the program inside the programmer's head, and that structure and intent are clearly conveyed and deeply realized by the code and somehow manages to incorporate the subject domain in it as well. Evans cites patterns of supple design like: <i>Intention-Revealing Interfaces, Side-Effect-Free Functions, Assertions, Conceptual Contours, Standalone Classes, Closure of Operations, Declarative Style of Design</i>.</li><br /><li><strong>Serviceable</strong> product – Making the code easy to change isn’t enough. Use coding standards too. But beyond that, ensure that what is delivered from the code is <i>serviceable</i>, so that it is ALSO quick & easy to (re)build, (re)test, commit/merge, stage, release, configure and install/upgrade/deploy. It’s not just the code that needs to be quick and easy to change, it is everything that needs to be done to deliver change to the consumer in order to realize its value.</li><br /><li><strong>Sustainable</strong> team velocity – Okay, I'm cheating a bit here because this last one is really about the process used to attain the other 4 qualities above. It's not just the code & product that needs to be sustainable (from a business-perspective and from a support/maintenance perspective) but the process that the programmers follow. On the one hand it must necessarily be disciplined, and yet it needs to be something that does not force them to work at or above their capacity for any significant time. The process should be sustainable and renewable so that the discipline is relatively easy to sustain and in fact gets easier over time, resisting "burnout" as well as the temptation to fall back into bad habits.</li></ul><br />So that's my "<span style="font-weight: bold;">5S</span>" for code/design structure! It's not quite as pithy as saying "lean, mean, keen, clean & green." The thing is, I'm not so sure my five S-words really do map all that accurately to the 5S of Lean (and I'm not sure I should try to make them either). What do you think?</span><div class="blogger-post-footer"><hr/></div>Brad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.com0