Tuesday, 31 March 2009

Spring 2009 issue of Methods & Tools

Methods & Tools is a free e-newsletter for software developers, testers and project managers. Spring 2009 issue’s content:

* How to Build Articulate Class Models and get Real Benefits from UML
* When Good Architecture Goes Bad
* Finding a Partner to Trust: The Agile RFP
* Database Locking: What it is, Why it Matters and What to do About it
* Code Generation for Dummies

80 pages of software development knowledge that you can download from
http://www.methodsandtools.com/mt/download.php?spring09

Tuesday, 17 March 2009

Thinking Tools for Scaling Lean and Agile

This book from Craig Larman and Bas Vodde is a classic example of the fact that it is better to teach somebody to fish than to give him fish. It emphasizes that it is important to “be agile” more than to “do agile”. Approaches like Scrum or Lean are more frameworks to think about continuous improvement than tools that should be applied blindly like cooking recipes. The book will therefore tell you that “large-scale Scrum is Scrum” or that lean is not just kanban or waste reduction. The first part of the book is focused on thinking tools (systems thinking, lean thinking, queueing theory) that are presented with software project management related examples. Those who are looking for practical advice should not believe that the book remains only at the conceptual level. The authors distill many “try…” and “avoid…” recommendations that will help you implement agile and lean ideas in your organization. The second part of the book is devoted to organizational tools and the final chapter proposes frameworks to adapt Scrum to larger contexts.

This book is a must for those who believe that software development project management goes beyond the simple application of “silver bullet” recipes. It is a rich source of both thinking and practical content that is well suited for non-linear reading. A very good “Scrum primer” chapter at the end of the book will provide an introduction for those who are not familiar with this approach and a large number of “recommended readings” items will allow readers to explore more in details each concept.

Get more details on this book or buy it on amazon.com

New Videos and Tutorials Directory for Java Developers

Java-TV.com is a directory of videos, interviews and tutorials focused on software development activities with the Java programming language.

Monday, 2 February 2009

CMMI: Less Hyped Than Agile but Equally Popular?

A recent Methods & Tools poll examined at what stage is the CMMI approach adoption in software development organizations.

Not aware 13%
Not using 29%
Investigating 8%
Analysed and rejected 4%
Trying to reach Level 2 12%
CMMI Level 2, 3 or 4 20%
CMMI Level 5 14%

Participants: 392

Ending date: January 2009

Many software development concept of the 80s and 90s have left the spotlights of the professional press and the blogging world, either because they are soooooo obvious, as in “of course everybody is doing object oriented programming today…”, or because they didn’t meet the expected success, as the object oriented database that were supposed to replace this old relational SQL technology of the 70s….

CMMI is the successor of the Capability Maturity Model (CMM) or Software CMM. The CMM was developed from November 1986 until 1997 as part of the software process maturity framework project. Then the CMMI, where “I” stands for Integration, replaced the CMM. This is certainly not currently a hyped concept. You will find no CMMI category on dzone.com or infoq.com and the CMMI channel on reddit.com has two subscribers. I was therefore surprised to see that the adoption, ignorance or rejection rates for the CMMI were very close to the results achieved by a similar survey on Agile approaches ended at the beginning of 2008.

I didn’t find any former statistics about the CMMI adoption, so it is difficult to compare the results of this survey with other numbers. These survey results are telling us that formal process adoption is growing in software development organization. The importance of CMMI numbers can be explained by the geographical diversity of Methods & Tools readership: an important percentage is coming from Asia where the CMMI label is important to sell outsourcing services.

Knowing that CMMI adoption rate is close to the Agile rates, I wonder also if there were some overlap, thinking that there are many companies without a formal process. I found a survey on Dr Dobb’s with some numbers on companies doing both CMMI and Agile. According to this survey, the rates of success of Agile and CMMI projects are very close, just above 50%. You could interpret the results as whatever the process, as long as you have one, you improve your success rate, which would mean that some discipline bring rewards. These numbers also tell that you have still close to 50% chances of failure, which could mean that discipline is not easy to achieve in the software development world. Please note that the Version One Agile survey seems to indicate a higher rate of success for projects, even if the type of questions makes direct comparison difficult.

Although there are some evidences that CMMI and Agile can coexist, the overall impression of people dealing with process improvement is that there are still important cultural differences between the two communities. Even if the non-prescriptive nature of the CMMI is recognized by agile developers, the overall impression is that this approach are still leaning heavily on plan-oriented and documentation processes, thus conflicting with the lightweight aspects of Agile. To contradict this culture incompatibility, there is the example Systematic, where a CMM level 5 company has added Scrum on top of their process, gaining a 50% cost reduction. This maybe not so astonishing if you realize that CMMI and Agile both try to achieve process improvement and both require discipline. Managing one week Scrum iteration with daily meetings should provide a strict control of project progress. Therefore organizations that followed the CMMI way for a good reason, that is not just for having a label to sell their services, should be naturally attracted by the process improvement tools contained in Agile. Other organizations than Systematic have also added agile practices above CMMI, but the opposite doesn’t seem obvious.

Maybe the software development world would be better if people could see approaches like the CMMI or Agile as toolboxes and not cult-like concepts that should be embraced with a blind faith… and a tendency to see other movements as “heresies” that can only be condemned. As Chris O’Brien (Software Capabilities Manager at Gen-i) says “So CMMI and Agile are complementary, but the use of either should to be based on business needs. I believe both have an immense amount to offer and co-existence will make sense for many organizations – particularly those that are capable of applying learnings from their industry with intelligence and care, to achieve results.”

References

CMMI Main page at SEI

Software and systems firms embrace CMMI - India Trends - Express Computer India

CMMI or Agile: Why Not Embrace Both!

Dr Dobb’s article: Agile CMMI?

Mature Agile with a twist of CMMI

Scrum and CMMI Level 5: The Magic Potion for Code Warriors

Systematic Gains Chart

Methods & Tools Agile Survey

CMMI articles list in SoftDevArticles.com

(r) Capability Maturity Model, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
(sm) CMM Integration is a service mark of Carnegie Mellon University.

Monday, 19 January 2009

From Finger in the Air Estimating to Finger Pointing Tracking

As Giovanni Asproni says it “estimation is a fundamental activity of every project”. Or at least it should be. The meaning of “estimation” varies however often for the different participants to software development projects. For the customer, “estimation” means an almost accurate amount of money he will spend and time it will need before he gets what he wants. For the project manager, it is an early commitment to the customer and from the developer to do something for a deadline. For the developer, it is the amount of time that he thinks he could do the stuff, if everything goes right.

The experienced developer will often add a 50% cushion to his estimates, knowing that not everything goes right. You can have an additional meaning in the case of outsourcing. For the salesperson, the estimation is the maximum price he can ask, while still having a lot of chances to sign a deal. A lot of young engineers will remind with astonishment hearing in a pre-sales meeting a salesperson answering to the customer that everything he wants is indeed possible… and for a cheap price too ;o)

For a developer, estimation is often equaled to fixing deadlines. He could then feel trapped by the original commitment that created expectations for management and customers. Customers have often two fixed expectations: delivery date and functionalities. Therefore, the effort is the only variable left to adjust the project activity. You can often witness a poor transition from estimation to planning with project managers that dream to have a baby in one month, if only they could manage a team of nine women. Because initial expectations cannot be achieved in many projects, the finger in the air used for estimating get then pointed downwards for blaming people: first from customers to project managers, then from project managers to developers. So print Giovanni’s article and give it to your customer before your next project planning meeting.