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 [email protected].

--------------------------------------------------------------------------------

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 [email protected].

--------------------------------------------------------------------------------

*** 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
([email protected]).

--------------------------------------------------------------------------------

I hope this newsletter has been informative and helpful. Your comments and 
feedback are most welcome. Send me your feedback ([email protected])...

Thanks,

Steve Rakitin
[email protected]


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