|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/srakitin/OLD/newsletter/vol5/no3/ |
Upload File : |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Food for Thought: Agile with a Lowercase “a”</title>
<link href="/newsletter/StyleSheet.css" rel="stylesheet" type="text/css">
</head>
<OpenTracking/>
<!-- Do NOT delete previous line if you want to get statistics on the number of opened emails -->
<body>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0">
<tr align="center" valign="top">
<td colspan="2"><img src="/newsletter/images/FoodForThoughtLogo.gif" alt="Food for Thought" width="600" height="105"></td>
</tr>
<tr class="Reference">
<td align="left" valign="top"><p>An e-newsletter published by<br>
Software Quality Consulting, Inc. </p>
</td>
<td align="right" valign="top"><p>March 2008, Vol. 5 No. 3 <br>
[<a href="/newsletter/vol5/no3/vol5no3.txt" target="_blank">Text-only Version</a>] </p>
</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td align="left" valign="top">
<p>Welcome to <em><strong>Food for Thought™</strong></em>, an e-newsletter from <strong><a href="/index.html?Intro" target="_blank">Software Quality Consulting</a></strong>. I've created free subscriptions for my valued business contacts. If you find this newsletter informative, I encourage you to continue reading. Feel free to pass this newsletter along to colleagues by clicking this <strong><a href="http://ui.constantcontact.com/roving/sa/fp.jsp?plat=i&p=f&m=sctz69n6">Forward Email</a></strong> link. If you’ve received this newsletter from a colleague and would like to subscribe, please click this <strong><a href="/newsletter/Subscribe.htm?Newsletter" target="_blank">Enter New Subscription</a></strong> link. If you don't wish to receive this newsletter, click the <strong><a href="#bottom">SafeUnSubscribe</a></strong>™ link at the bottom of this newsletter, and you won’t be bothered again.</p>
<p>Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to <strong><a href="mailto:[email protected]">[email protected]</a></strong>.</p></td>
</tr>
</table>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/InThisIssue.gif" alt="In This Issue" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p>In <a href="#article"><strong>This Months’ Topic</strong></a>,
I discuss the need for agility in software development processes...<br>
<br>
Regular features to look for each month are:</p>
<ul>
<li> <a href="#morsel"><strong>Monthly Morsels</strong></a><br>
Hints, tips, techniques and reference info related to this month’s topic</li>
</ul>
<ul>
<li> <a href="#calendar"><strong>Calendar</strong></a><br>
Conferences, workshops, and meetings of interest to software engineers, QA engineers and anyone interested in software development</li>
</ul>
</td>
</tr>
</table>
<br>
<br>
<a name="article"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/ThisMonthsTopic.gif" alt="This Month's Topic" width="114" height="37"></td>
<td width="15"> </td>
<td width="471" align="left" valign="top" class="BodyText"><p align="center" class="Headline"> Agile with a Lowercase “a” </p>
<p><strong> </strong>The dictionary defines the word <strong>agile</strong> as:</p>
<ol>
<li> quick and well-coordinated in movement; lithe; </li>
<li> active; lively; </li>
<li> marked by an ability to think quickly; mentally acute or aware; </li>
</ol>
<p>Many software development organizations confuse the<strong></strong>need to become more<strong> agile</strong> (with a lowercase “a”) with <strong>Agile </strong>(with an uppercase “A”). In case you’ve been living under a rock, <strong>Agile </strong>with an uppercase “A” refers to <strong><a href="/newsletter/vol2/no7/vol2no7.html" target="_blank">Agile Development Methodologies </a></strong>and includes eXtreme Programming (XP), Crystal, Scrum, Lean, and others...</p>
<p> Before we get into a discussion of <strong>agile vs. Agile</strong>, it would be appropriate to answer one key question first, and that is...</p>
<p><strong> What types of projects are good candidates for Agile with an uppercase “A”?</strong></p>
<p> Agile Methods are particularly well-suited for IT projects where:</p>
<ul>
<li> software is being developed for use solely within the company </li>
<li> a real, live “customer” (end user) is on the project team 24x7 </li>
<li> risk of failure is low </li>
<li> project team is highly motivated and led by an experienced leader </li>
</ul>
<p>For other types of projects (i.e., where software is intended for use by people outside the company), Agile Methods often aren’t the best choice. Why? Because as we will see, for Agile Methods to work effectively, you need to follow <strong>all</strong> of the key practices associated with an Agile Method. And in many cases this is not possible for the types of projects that don’t meet the criteria above.<br>
<br>
</p>
</td>
</tr>
<tr>
<td align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><img width="110" height="107" src="/newsletter/vol5/no3/vol5no3_clip_image002_0001.jpg"> </td>
<td> </td>
<td align="left" valign="top" class="BodyText"><p>Further, as Roger Pressman observed:</p>
<blockquote>
<p> “I contend that software engineering principles <em>always </em>work. It’s never inappropriate to stress solid problem solving, good design, and thorough testing (not to mention the control of change, an emphasis on quality,..). A specific software process might fail because it is overkill, or the work products it requires are unnecessary or burdensome, or a person or team becomes overly dogmatic in the application of the process. But <strong>history is on the side of a solid engineering approach</strong>.” [3]</p>
</blockquote>
<p> And for projects that are high-risk or life-threatening, Mark Paulk said: </p>
<blockquote>
<p>“Should organizations use XP, as published, for life-critical or high-reliability systems? Probably not. XP’s lack of design documentation and de-emphasis on architecture are risky.” [4] </p>
</blockquote>
<p><strong>Agile with an Uppercase “A”</strong></p>
<p> In talking with software development and SQA folks at many companies, the message that I have been getting is that many organizations are already using either Agile Development Methods or are planning to. There has been tremendous interest in Agile Development Methods since most businesses believe they need to become more <strong>agile</strong> (with a lowercase “a”). And wouldn’t you know it, there just happens to be a development methodology called “Agile”. However, becoming<strong></strong>more<strong> agile</strong> and <strong>using Agile</strong> are very different...</p>
<p> An observation I have made is that companies who say they are using an Agile Development Methodology are often not using the methodology as it was defined in the literature. Many have changed the methodology to “suit their needs”. For example, it seems that some companies who claim to be using <strong>eXtreme Programming (XP) </strong>aren’t using the following key <strong>XP </strong>practices:</p>
<ul>
<li> Pair Programming </li>
</ul>
<ul>
<li> On-site customer 24x7 </li>
</ul>
<ul>
<li> Collective code ownership<strong></strong></li>
</ul>
<p>I’m not the only one who has seen this. Others have made this same observation. In a recent <strong><a href="http://c2.com/cgi/wiki?XpAndTheCmm" target="_blank">Wiki blog </a></strong>posting, <strong><a href="http://alistair.cockburn.us/index.php/Main_Page" target="_blank">Alistair Cockburn</a></strong> said:</p>
<blockquote>
<p> “Well, from my experience, most teams that say they're doing <strong>XP</strong> don't actually do the practices.”</p>
</blockquote>
<p> And, Matt Stephens observed that:</p>
<blockquote>
<p> “As <strong>XP</strong> increases in popularity and hits the mainstream, more and more teams will attempt <strong>XP</strong>, probably without a clear understanding of what is really involved. They will most likely be drawn in by<strong> XP</strong>'s ‘low discipline’ practices (such as no big up-front design and minimal documentation), but without applying the high discipline practices that act as an essential safety net (such as unit testing, pair programming, collective ownership and constant refactoring).” [2]</p>
</blockquote>
<p> Let’s review the list of <strong>XP</strong> Practices as defined by <strong><a href="http://en.wikipedia.org/wiki/Kent_Beck" target="_blank">Kent Beck</a></strong> [1]</p>
<table width="471" border="1" cellpadding="5" cellspacing="0" bordercolor="#000000" class="BodyText">
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> Planning </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> Quickly determine scope of next release by combining business priorities and technical estimates. As reality overtakes plan, update plan. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> Small releases </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> System into production quickly, then release new versions on short cycle. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> Metaphor </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> A simple shared story of how the whole system works. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> Simple design </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> Extra complexity removed when discovered. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> Testing </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> Developers continually write unit tests, which must run for development to continue. Customers write tests for features. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> Refactoring </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> Restructure system without changing its behavior to remove duplication, simplify, etc. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> Pair Programming </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> All code is written with two developers at one computer. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> Collective ownership </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> Anyone can change any code anywhere in the system at any time. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> Continuous integration </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> Integrate and build the system many times a day, every time a task is completed. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> 40-hour week </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> Work no more than 40 hours per week as a rule. No overtime two weeks in a row. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> On-site customer </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> Include real customer on team 24X7. </p></td>
</tr>
<tr>
<td valign="top" bgcolor="#FFFF99"><p><strong> Coding Standards </strong></p></td>
<td valign="top" bgcolor="#CCFFFF"><p> Developers agree to standards. </p></td>
</tr>
</table>
<p>Some obvious questions are:</p>
<ul>
<li> Can you claim to be following <strong>eXtreme Programming</strong> if you’re not doing <strong>ALL</strong> of the practices above? </li>
</ul>
<ul>
<li> If you’re not doing <strong>ALL</strong> of the practices above, can you expect to see the same benefits from those that do use them? </li>
</ul>
<p>Let’s look at some examples of other software development methodologies that have identified key practices:</p>
<p align="center"> <img width="471" height="272" src="/newsletter/vol5/no3/vol5no3_clip_image002_0000.jpg"> </p>
<p> In my experience with many of the software development methodologies shown above, you need to follow <strong>ALL</strong> the individual practices of a given methodology in order to see benefit.</p>
<p></p></td>
</tr>
<tr>
<td align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><img width="110" height="145" src="/newsletter/vol5/no3/vol5no3_clip_image002.gif"> </td>
<td> </td>
<td align="left" valign="top" class="BodyText"><p>This is a lot like choosing a diet. If you pick a diet and follow <strong>ALL</strong> the rules for that diet, you’ll usually lose weight. If you’re like me and choose to ignore some of the rules, you usually won’t lose weight.</p>
<p> To derive benefit from Agile Methods, you need to follow them as they were defined. You can’t pick and choose which of the key practices to use and which to ignore. </p>
<p><strong> Agile with a Lowercase “a”</strong></p>
<p> There is a basic principle that businesses of most every type need to follow to be successful - reduce costs and increase efficiency. This principle can lead to improvements in your bottom line.</p>
<p> If you routinely work on projects that don’t meet the criteria for Agile Methods defined above, there are several ways that you can improve the effectiveness of your development process, and as a result, become more <strong>agile</strong>.</p>
<p> For inspiration, I recommend reading the Poppendieck’s book [6] on Implementing Lean Software Development. The concepts in their book are excellent examples of how to become more <strong>agile</strong> (with a lowercase “a”) without all of the hoopla of <strong>Agile</strong> (with an uppercase “A”).</p>
<p> For example, their Seven Principles of Lean Software Development are derived from the lean manufacturing practices developed by Toyota. I find these principles to be extremely valuable in assessing effectiveness, even though I don’t always agree with the Poppendieck’s interpretation of these principles.</p>
<p> Let’s look at the Seven Principles [5]</p>
<ul>
<li><strong> Principle 1 - Eliminate Waste</strong></li>
</ul>
<blockquote>
<p>In Lean Manufacturing, waste is broadly defined as anything that doesn’t add value. For software development, I define waste as anything that <strong>doesn’t contribute to meeting the needs of customers</strong>. We need to look at all of the tasks, activities, artifacts and other things that happen on projects and determine which things can be eliminated based on this definition of waste.</p>
</blockquote>
<ul>
<li><strong> Principle 2 - Build Quality In</strong></li>
</ul>
<blockquote>
<p>Build Quality In means getting it right the first time and focusing on what it is that provides value to your customers. You want a process that helps prevent defects from creeping into the code. How can you achieve this? The source of most defects is poorly written, ambiguous requirements. Removing ambiguity from your requirements can go a long way to getting it right the first time and building quality in...</p>
<p><strong><a href="/training/requirements.html" target="_blank">Learn more about writing better requirements...</a></strong></p>
<p>Sometimes we can build quality in by detecting defects earlier in the development process. To do this requires effective peer reviews and inspections.</p>
<p><strong><a href="/training/peer_reviews.html" target="_blank">Learn more about peer reviews and inspections...</a></strong></p>
</blockquote>
<ul>
<li><strong> Principle 3 - Create Knowledge</strong></li>
</ul>
<blockquote>
<p>Creating knowledge is all about learning and sharing information. For software development, this can be done by following a few key recommendations [6]:</p>
</blockquote>
<ul>
<ul>
<li> Release a small subset of key features early for review and evaluation </li>
</ul>
</ul>
<ul>
<ul>
<li> Perform daily builds and provide rapid feedback from on-going testing </li>
</ul>
</ul>
<ul>
<ul>
<li> Find a project/team leader with experience and instincts to make good decisions </li>
</ul>
</ul>
<ul>
<ul>
<li> Use a modular architecture that enables features to be added more easily </li>
</ul>
</ul>
<blockquote>
<p>“It is important to have a development process that encourages systematic learning throughout the development cycle, but we also need to systematically improve that development process.” [5]</p>
</blockquote>
<ul>
<li><strong> Principle 4 - Defer Commitment</strong></li>
</ul>
<blockquote>
<p>The principle here is that the more information we have, the better able we are to make an informed decision. The Poppendiecks recommend deferring irreversible decisions until the last possible moment so that you have the most information available to make that decision. </p>
<p>I have found an estimating and scheduling technique that can help accommodate this principle. It’s called the Yellow Sticky Method...</p>
<p><strong><a href="/training/schedules.html" target="_blank">Learn more about the Yellow Sticky Method and estimating and scheduling best practices...</a></strong></p>
</blockquote>
<ul>
<li><strong> Principle 5 - Deliver Fast</strong></li>
</ul>
<blockquote>
<p>“Companies that compete on the basis of time have a huge advantage over their competitors: they have eliminated a huge amount of waste and waste costs money.” [5]</p>
<p>The ability to deliver fast is, in my opinion, determined by how predictable your organization is. Unpredictable organizations tend to be much slower in delivering because there is much more waste and confusion. Predictable organizations tend to be well-organized and led by experienced managers who know what needs to get done and how to make it happen.</p>
<p><strong><a href="/training/predictable.html" target="_blank">Learn about helping your organization become more predictable...</a></strong></p>
<strong><a href="http://www.ieeeboston.org/edu/2008spring/course_predictable_sw.htm" target="_blank">Attend a Predictable Software Development workshop...</a></strong></blockquote>
<ul>
<li><strong> Principle 6 - Respect People</strong></li>
</ul>
<blockquote>
<p>I often coach managers in management skills and respecting people is a key topic that I cover. As a manager, you need to trust your people to make good decisions. You can’t undermine them and you can’t think for them.</p>
<p><strong><a href="/newsletter/vol5/no1/vol5no1.html" target="_blank">Read more about managing, coaching and mentoring...</a></strong></p>
</blockquote>
<ul>
<li><strong> Principle 7 - Optimize the Whole</strong></li>
</ul>
<blockquote>
<p>When we look at software development practices, we often tend to micromanage and focus on the parts rather than the whole. To improve software development, we need to take a holistic view and focus on the whole process, not just the parts. </p>
<p>One really good way to do this is via a Project Retrospective. This activity can help identify where problems are and how they can be addressed from a holistic perspective...</p>
<p><strong><a href="/training/retrospectives.html" target="_blank">Learn more about Project Retrospectives...</a></strong></p>
</blockquote>
<p><strong> Summary</strong></p>
<p> Becoming <strong>more </strong><strong>agile</strong> is critical. Eliminating waste and improving efficiency are essential to survive in today’s global economy.</p>
<p> You don’t need to follow an <strong>Agile Development Method</strong> to become <strong>more agile</strong> especially if your projects are not IT software developed for use in-house. There are many ways any software development method can be improved to minimize waste and improve efficiency. Becoming <strong>more agile</strong> should be the goal regardless of the software development methodology you use...</p>
‘Til next time...</td>
</tr>
</table>
<br>
<br>
<a name="morsel"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/MonthlyMorsels.gif" alt="Monthly Morsels" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Every month in this space you’ll find additional information related to this month’s topic.</p>
<ul>
<li><strong> References <br>
<br>
</strong>
<ol>
<li> Beck, K., <em>Extreme Programming Explained</em>, Addison-Wesley, 2000.<br>
<br>
</li>
<li>Stephens, M. and Rosenberg, D., <em>Extreme Programming Refactored: The Case Against XP</em>, Apress, 2003.<br>
<br>
</li>
<li>Pressman, R., “What A Tangled Web We Weave”, <em>IEEE Software</em>, Jan/Feb 2000, pp. 18-21.<br>
<br>
</li>
<li>Paulk, M., “Extreme Programming from a CMM Perspective”, <em>IEEE Software</em>, Nov/Dec 2001, p. 19-26.<br>
<br>
</li>
<li>Poppendieck, M. and Poppendieck, T., <em>Implementing Lean Software Development - From Concept to Cash</em>, Addison-Wesley, 2007.<br>
<br>
</li>
<li> McCormack, A., “Product Development Practices that Work: How Internet Companies Build Software”, <em>MIT Sloan Management Review,</em> Winter 2001, Vol. 40, No. 2.</li>
</ol>
</li>
</ul> </td>
</tr>
</table>
<br>
<br>
<a name="calendar"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/Calendar.gif" alt="Calendar" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Every month you’ll find news here about local and national events that are of interest to the software community…</p>
<ul>
<li><strong> Software Quality Calendar</strong></li>
</ul>
<blockquote>
<p>There are many organizations that sponsor monthly meetings, workshops, and conferences of interest to software professionals. <strong><a href="/links/upcoming.html" target="_blank">Find out what’s happening…</a></strong></p>
</blockquote>
<ul>
<li><strong> Workshops Offered by Software Quality Consulting</strong></li>
</ul>
<blockquote>
<p>Software Quality Consulting offers workshops in many topics related to software process improvement. <strong><a href="/seminars/courses.html" target="_blank">Get more info…</a></strong></p>
</blockquote></td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/AboutSQC.gif" alt="About SQC" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Software Quality Consulting provides consulting, training, and auditing services tailored to meet the specific needs of clients. We help clients fine-tune their software development processes and improve the quality of their software products. The overall goal is to help clients achieve Predictable Software Development™ – so that organizations can consistently deliver quality software with promised features in the promised timeframe. </p>
To learn more about how we can help your organization, <strong><a href="/index.html?AboutSQC" target="_blank">visit our web site</a></strong> or <strong><a href="mailto:[email protected]">send us an email</a></strong>.</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td align="left" valign="top"><p> I hope this newsletter has been informative and helpful. Your comments and feedback are most welcome. <strong><a href="mailto:[email protected]">Send me your feedback…</a></strong></p>
<p>Thanks,</p>
<p> <img src="/newsletter/images/BusinessCard.gif" width="270" height="121" align="right"><img src="/newsletter/images/Signature.gif" width="90" height="68"><br>
Steve Rakitin<br>
<br>
<strong><a href="mailto:[email protected]">[email protected]</a></strong></p></td>
</tr>
</table>
<div align="center"><br>
<FONT class="Reference">Food for Thought, Predictable Software Development, Act Like a Customer,<br>
and ALAC are trademarks of Software Quality Consulting, Inc.<br>
Copyright 2008. Software Quality Consulting, Inc. All rights reserved.<br>
Graphic design by <B><U><FONT color=blue><a href="mailto:[email protected] ">Sage Studio</a></FONT></U></B></FONT></div>
<a name="bottom"> </a></body>
</html>