Food for Thought—An E-Newsletter Published by Software Quality Consulting, Inc. April 2007, Vol. 4 No. 4 Just Enough Process What topics would you like to see in this newsletter? Each month, this newsletter tries to provide you with useful information. This is a two-way street and your feedback is important. Please send your thoughts and comments to steve@swqual.com. -------------------------------------------------------------------------------- Welcome to Food for Thought(TM), an e-newsletter from Software Quality Consulting (http://www.swqual.com/index.html?Intro). 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 Forward Email link (http://ui.constantcontact.com/roving/sa/fp.jsp?plat=i&p=f&m=sctz69n6). If you’ve received this newsletter from a colleague and would like to subscribe, please click this Enter New Subscription link (http://www.swqual.com/ newsletter/Subscribe.htm?Newsletter). If you don't wish to receive this newsletter, click the SafeUnSubscribe(TM) link at the bottom of this newsletter, and you won’t be bothered again. Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to info@swqual.com. -------------------------------------------------------------------------------- *** In This Issue *** In This Months’ Topic, I offer some suggestions on selecting an appropriate development methodology... Regular features to look for each month are: - Monthly Morsels Hints, tips, techniques and reference info related to this month’s topic - Calendar Conferences, workshops, and meetings of interest to software engineers, QA engineers and anyone interested in software development -------------------------------------------------------------------------------- *** This Month’s Topic *** JUST ENOUGH PROCESS For many software engineers, the “P-word” is something that isn’t discussed in polite company. Regardless of your particular views on process, every one of us uses some “process” to do real work. Even if you are using an Agile Methodology, you are following a process. Ideally, we’d like to use “just enough” process [1] to meet our objectives. What I find often though is that: - Each project has different objectives. - Most development teams have one “process” with which they are comfortable. - Often project teams suffer from either too much process or not enough process. Recognizing that we all need to have some process in order to do work, the question I would like to discuss this month is: HOW DO WE DEFINE WHAT “JUST ENOUGH” PROCESS IS? So instead of debating which process is better, let’s see if we can figure out how to determine when we have just enough... WHAT WE LEARNED FROM THE METHODOLOGY WARS... During the 1980‘s and 90’s, there was much debate about methodology because software engineering discipline was going through intense growing pains. We didn’t have a lot of history with process so discussing process became the focal point of many a discussion... What I learned from the Methodology Wars was that: - Each methodology has its own set of strengths and weaknesses. For example, even though CMM and CMMi are heavyweight processes, their strengths include discipline, consistency, and documentation. These methods are well-suited for projects where discipline, consistency, and documentation are important. CMM and CMMi also have several weaknesses – they tend to be overly bureaucratic, are not responsive to change, and don’t work well in organizations that are chaotic by nature. At the other extreme, Agile Methods are much more responsive to change, but often require technical and managerial skills that may be lacking... - Not every methodology is appropriate for every project. If your company is developing life-supporting or safety-critical software, you need a development methodology that has been proven successful in developing these types of products. For example, I would argue that Agile Methods are not an appropriate choice if you are developing software for an implantable pacemaker... Alternatively, if you are developing web-based applications or video games, then lightweight processes would certainly be appropriate. - Software development teams also have strengths and weaknesses and we need to pay close attention to this when selecting a methodology. Since project teams are staffed by humans, every project team has its own set of strengths and weaknesses. When selecting a development methodology, we need to take this fact into account. For example, before you decide to use Extreme Programming, you should know if your developers can work closely together because Pair Programming is an integral and required practice of the Extreme Programming method... These days, people are less interested in debating methodology and more interested in doing real work. I interpret this as a sign that the software industry is slowly maturing. THE “GOOD ENOUGH” QUALITY PARADIGM... For software that is not safety-critical, mission-critical or life-supporting, there is a school of thought that says this type of software doesn’t have to be perfect; it has to be “good enough”. Stated another way: “Our task is not to blindly eliminate all problems, but to understand the problems and benefits of a situation well enough to eliminate (or prevent) the right problems and also deliver the right benefits.” [2] The “Good Enough” principle defined by James Bach states: “To claim that any given thing is Good Enough is to agree with the following propositions: - It has sufficient benefits. - It has no critical problems. - The benefits sufficiently outweigh the problems. - In the present situation, and all things considered, further improvement would be more harmful than helpful. Each point is critical. If any one of them is not satisfied, then the product, although perhaps good, cannot be good enough.” [2] What we need then is Just Enough Process that will enable us to deliver Good Enough Quality. How then do we figure out what Just Enough is? I believe we need to focus our attention on these four items: By understanding the needs of the Project, the Business, your Customers, and the strengths and weaknesses of the Project Team - we can identify the Just Enough Process that will allow us to deliver Good Enough Quality... - Project Needs Every project has different needs. For example, a maintenance release project has very different needs from a new product release in terms of documentation, design approaches, coding, testing and release mechanisms. Clearly these two different types of projects need different approaches – different methodologies. I have often seen project teams applying the same approach time and time again - even when that approach has not been successful. What we need are indicators that can help determine if the methods we are using are Just Enough... Are there indicators that the approach or methodology you’ve been using is not meeting the needs of the project? Sure. Look at the results of your most recent Project Retrospective and see if anything on the Things to Change List relates to process. Read more about Project Retrospectives... (http://www.swqual.com/newsletter/vol2/no6/vol2no6.html) Plan a Project Retrospective for your next project... (http://www.swqual.com/training/retrospectives.html) - Business Needs Your development process also needs to meet the needs of your business. For example, are you developing an application that is expected to be actively enhanced and supported for at least a few years? If so, your development process ought to take this into consideration so that the maintenance burden is not as high as it might be if you ignore this business need. What indicator can be used to determine if your development process is meeting the needs of your business? Predictability is a key business indicator. Organizations that can accurately predict when key events (such as release to QA, first customer ship, etc.) are more competitive than those organizations that are not predictable. Read more about Predictable Software Development... (http://www.swqual.com/newsletter/vol2/no3/vol2no3.html) Learn how your organization can become more predictable... (http://www.swqual.com/training/predictable.html) - Customer Needs Clearly your customers have some very important needs as well. For example, some customers place a lot of value in the timely release of software with as few defects as possible. Other customers may be early adopters and as a result, are much more tolerant of defects. One indicator that your development methodology is (or is not) meeting the needs of your customers are Customer Reported Problems. The more Customer Reported Problems you have, the more likely it is your development methods are not meeting the needs of your customers... Read more about getting to the Root of Customer Reported Problems... (http://www.swqual.com/newsletter/vol2/no5/vol2no5.html) Train your team in performing Root Cause Analysis... (http://www.swqual.com/training/root.html) - Project Team Strengths and Weaknesses Every team has its own set of strengths and weaknesses. If you are using Agile Methods, for example, you need a team that has excellent verbal communication skills since much of what happens is only communicated verbally. Other methodologies might require that the team have excellent written communication skills. So what are some indicators that your development methodology reflects the strengths and weaknesses of your project team? I would look at things like churn and defect rates. Churn is a measure of how often things (documents, code, tests, etc.) are changing. The higher the churn the more things are changing. The more things are changing, the more likely it is that your development methodology is not consistent with your project team’s strengths and weaknesses. Read more about churn... (http://www.swqual.com/newsletter/Indicators.pdf) SUMMARY Every organization that produces stuff follows some process. Sometimes the process is written down, sometimes it isn’t. Too much process is not good. Too little process is also not good. We need to find just the right amount of process that will satisfy all of the stakeholders involved. Selecting a development methodology should be a conscious decision that takes into consideration the needs of the business, your customers, and the project and is consistent with the strengths and weaknesses of the whole project team. When this happens, you’ll have found process nirvana - Just Enough Process that will lead to release software that is Good Enough. ‘Till next time... -------------------------------------------------------------------------------- *** Monthly Morsels *** Every month in this space you’ll find additional information related to this month’s topic. - References: [1] Phillips, D., “Show Me How To Do That: ‘Just Enough’ Software Process For the 21 st Century”, Cutter IT Journal, September 1999. (http://home.att.net/~dwayne.phillips/CutterPapers/process/process.htm) [2] Bach. J., “Good Enough Quality – Beyond the Buzzword”, IEEE Computer, August 1997. (http://www.satisfice.com/articles/good_enough_quality.pdf) -------------------------------------------------------------------------------- *** Calendar *** Every month you’ll find news here about local and national events that are of interest to the software community... - Software Quality Calendar There are many organizations that sponsor monthly meetings, workshops, and conferences of interest to software professionals. Find out what’s happening... (http://www.swqual.com/links/upcoming.html) - Workshops Offered by Software Quality Consulting Software Quality Consulting offers workshops in many topics related to software process improvement. Get more info... (http://www.swqual.com/seminars/courses.html) -------------------------------------------------------------------------------- *** About SQC *** 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(TM) – so that organizations can consistently deliver quality software with promised features in the promised timeframe. To learn more about how we can help your organization, visit our web site (http://www.swqual.com/index.html?AboutSQC) or send us an email (info@swqual.com). -------------------------------------------------------------------------------- I hope this newsletter has been informative and helpful. Your comments and feedback are most welcome. Send me your feedback (info@swqual.com)... Thanks, Steve Rakitin info@swqual.com Food for Thought, Predictable Software Development, Act Like a Customer, and ALAC are trademarks of Software Quality Consulting, Inc. Copyright 2007. Software Quality Consulting, Inc. All rights reserved. Graphic design by Sage Studio