Agile, Project Management and Software Testing in Spring 2011 Issue of Methods & Tools

Methods & Tools – the free magazine for software developers, testers and project managers – has just published its Spring 2011 PDF issue with the following articles:
* Automated Acceptance Tests and Requirements Traceability
* Managing Schedule Flaws using Agile Methods
* User-Centric Design and the Power of Personas
* Complexity Theory for Software Developers
* Build Patterns to Boost your Continuous Integration
* GivWenZen – Behavior Driven Development for FitNesse
* Celoxis – Web Based Project Management
* Tellurium Automated Testing Framework
* Apache CXF
* RSpec Best Practices
* Maven Plugins
Download 80 pages of software development knowledge

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.

My 10 Favorites Agile Project Management Articles

This is a (personal) list of articles dealing with agile project management that I like. I have chosen to include material that is longer than the usual (short) blog posting. I encourage readers to give more objectivity to this subjective set by submitting in the comments what they preferred ;o)

Agile, Multidisciplinary Teamwork by Gautam Ghosh

The Agile Customer’s Toolkit by Tom Poppendieck

Bridging Agile and Traditional Development Methods: A Project Management Perspective by Paul E. McMahon

Managing the Work in an Agile Project by Dan Rawsthorne

A Governance Model for Incremental, Concurrent, or Agile Projects by Alistair Cockburn

Measuring Integrated Progress on Agile Software Development Projects by Tamara Sulaiman & Hubert Smits

Visualizing Agile Projects using Kanban Boards by Kenji Hiranabe

The Pomodoro Technique (The Pomodoro) by Francesco Cirillo

Agile Fixed Price Projects part 1: “The Price Is Right” by Pascal Van Cauwenberghe
Agile Fixed Price Projects part 2: “Do you want agility with that?”

The Need for Agile Project Management by Mike Cohn and Ken Schwaber

Additional agile project management article resources

Agile Alliance Library
Scrum Alliance Library
Agile Journal
DZone Agile Zone
InfoQ Agile Section
Methods & Tools Articles Archive
Mountain Goat Articles
Software Development Articles, Agile Section

Has Agile Lost its Soul?

VersionOne has published raw results for the 3rd Annual State of the Agile Survey that was conducted in June and July 2008. Answers were received from 3061 participants in 80 countries. Participants working in agile projects are satisfied: they think that agile achieves a very good overall project success rate. They see improvements in productivity, quality and maintainability. Scrum or a Scrum+XP hybrid solution are the main approaches used. The objectives are to achieve shorter iterations and accelerate time-to-market. The mostly used practices are continuous integration and iteration planning. In the least used practices, you find on-site customer and pair programming

These results seems to tell us is that agile could be applied by organisations more like a new version of the RAD method of the 90s: a project management approach with short iteration that relies on smart people and increased automation to deliver software faster. We should not forget however that the second sentence of the Agile Manifesto starts with “Through this work we have come to value: Individuals and interactions over processes and tools”. Collaboration inside and outside the software development team is one of the main idea behind the Agile manifesto.

Does the fact that the practices linked to collaboration are the least implemented tells us that Agile has lost its soul to achieve a higher adoption rate? Change is always difficult, especially if it deals with organisational culture or personal behaviour. Agile adoption has to face the reality that developers are mostly introverted people. End-users often don’t think that developing software is a high priority or they cannot take more time for software projects, because they have a business to run. Is this bad? No. All approaches aims for a “perfect” execution context, whether it means to be 100% agile or that you can freeze requirements ;o) What we have to keep in mind is that creating this ideal context is difficult. It is therefore more important to cleverly adapt than blindly adopt. If developers (and users) think that project is successful, then a discussion about the “purity” of the approach used is meaningless.

Full data of the VersionOne survey

Third Annual State of Agile Survey Data Available

This survey was conducted and sponsored by VersionOne in June and July 2008. It received answers from 3061 participants in 80 countries; most of them (70%) were participating to the survey for the first time. The majority of the respondents were agile team leaders, coach or consultants. This could lead to a bias towards a perhaps slightly more optimistic vision of the reality of agile projects. Whether they are agile or not, managers stay managers ;o)

The survey doesn’t try to measure agile adoption, but it gives interesting information on how agile is adopted. A majority (55%) of the participants works in rather small organizations with less than 100 people involved in software development. For most of them agile is also relatively new, as only 34% of the companies have been practicing agile for more than 2 years. The percentage that has adopted agile in the previous year is 36%. We could see that adoption is often partial in software development organizations as 65% of the participants use agile in less than 50% of their projects. Full adoption is realized in 17% of the companies, a similar number that was found by a Methods & Tools survey conducted at the end of 2007.

Scrum is the most followed agile methodology. Amongst the practices, iteration planning, unit testing, daily standup, release planning and continuous integration were adopted by more than 2/3 of respondents. Surprisingly, pair programming, an emblematic practice of the XP approach, is ranked near the bottom of practices adopted with only around 31% of adopters. On-site customer is also poorly adopted. This shows that practices concerning people interactions seem to be the most difficult to implement, as people are the most difficult elements to change in software development processes.

An interesting question deals with the rate of success for agile projects. For 55% of the participants, close to 100% of agile projects are successful. On the other side, 24% estimate than one project out of two fails, mainly due to conflicts between the company culture and agile values or because of the lack of experience with agile approaches. A final part of the report gives interesting information about the tools used in agile projects. We can see that agile and traditional tools are currently used at the same level to manage projects.

Version One Survey Data

Methods & Tools Survey

More than 1000 articles in Software Development Articles Directory

The Software Development Article Directory has now more than 1000 articles in its database. This directory references knowledge-providing articles related to all software development activities (programming, testing, configuration management, process and project management) selected from the best sources on the web.

Some of the last interesting additions to the directory are
* Must-have tools for HTML, JavaScript and AJAX development and debugging
Use the best open source tools to work with Web pages, scripts, and styles, and make development of new sites and pages easy.

* Schedule Adherence: A Useful Measure for Project Management
This article utilizes the new practice of Earned Schedule (ES) to discuss a proposed measure for further enhancing the practice of EVM. The measure, Schedule Adherence, provides additional early warning information to project managers, thereby enabling improved decision making and enhancing the probability of project success.

* Focus on Value: How to create value-driven user stories
Agile has a tool that can help organizations re-focus on return on investment: value-driven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea.

Agile Software Development: True Adoption or Just a Label?

At what stage is the agile approach (XP, Scrum, TDD, …) adoption at your location? (2005 results)

Not aware 13% (26%)
Not using 13% (16%)
Investigating 14% (14%)
Analysed and rejected 4% (3%)
Pilot projects 8%(4%)
Partial implementation (adoption of some agile practices) 17% (17%)
Partial deployment (some projects are using this approach) 14% (12%)
Deployed (all new projects are using this approach) 17% (8%)

Participants: 512 (232)

Ending date: February 2008

Source: Methods & Tools

Comparing the 2008 and 2005 results, we could notice that the level of ignorance of the agile movement has decreased, as only 13% of the organizations are ignorant of it. Full deployment numbers have doubled in the recent years to reach 17% and total rate of various adoption levels is now 56% compared to 41% in 2005. This growing adoption rate has also been confirmed by other surveys on this topic. Some critics will naturally discuss the “scientific” nature of this kind of surveys, but I believe that they are useful to give us an idea of the evolution of the software development world. The increased popularity of agile is also visible on the Indeed job request trend.

The recent improvement in agile software development process visibility and acceptance should however make us cautious with the current results on agile adoption surveys. When software development practices are more widely accepted, the number of adopting organizations increases, but the substance of valid usage of this practices decreases. The answers to surveys tend then to be biased towards what should be the correct answer instead of reflecting the reality of the software development context. The tendency of upper management to “push” new approaches to people who are more reluctant to change their old habits does usually not produce good results. This is even truer when projects will not be given additional resources to support the transition.

We are therefore transitioning from a period where agile adoption level may have been underestimated to another where it could be overestimated. Previously, some developers would not define their practices openly as agile or extreme programming because manager would have considered it a “cow-boy process”. A 2006 Forrester’s report found that agile adoption in the US and Europe was 17% according to a survey of 1078 IT decision-maker. They however precised that ” because Agile processes are often adopted at the grassroots level, they frequently fly below the radar. This makes it unlikely that a single IT decision-maker knows what methodology every development team is using. For this reason, Forrester believes that Agile adoption is actually higher than reported in this study.” Today, some companies will pretend that they are agile, but without implementing the essence of the approach.

It is also interesting to notice that the rate of rejection is similar in both surveys. This means that the percentage of companies completely opposed to agile practices is still very low. We could also see that the proportion of companies that are in a partial implementation state is still superior to those who are in partial deployment. This confirms that organizations prefer to adopt agile practices by gradually shifting their process towards agility instead of choosing a big bang implementation. Agility is about iteration and incrementation and this should be also applied to process changes.

When compared to other surveys performed in 2007 on agile adoption, the results of the Methods & Tools poll are equivalent. The adoption rate of participants is slightly inferior with 56% (48% without pilot projects) compared with 73% for the VersionOne survey and 69% for the Scott Ambler survey. Our percentage of organizations having deployed agile approaches in all projects stands at 17%, which is very close to the 15% rate that VersionOne presents for 100% agile adoption.

The importance of the agile approach is surely growing in the software development community. It remains to be determined, with an unbiased perspective, how this evolution will translate in the rate of software development project successes, because at the end, this is what matters the most.

Other agile deployment surveys and agile adoption material

Indeed.com Job Trends for: agile, scrum, “extreme programming”, “test driven”

VersionOne 2nd Annual “State of Agile Development” Survey (2007)

Scott Ambler Surveys (2007)

Scott Ambler Surveys Presented in Dr. Dobb’s (2007)

Scrum Alliance Membership Survey Shows Growing Scrum Adoption and Project Success (2007)

TDD Survey Results by Stelligent (2007)

Boston Roundtable Survey Results by Stelligent (2007)

Agile Project Management Tooling Survey by Trail Ridge Consulting (2006)

Corporate IT Leads The Second Wave Of Agile Adoption by Forrester (2005)

Waterfall Manifesto Agile Software Development Adoption Poll (ongoing)

Slowdown in ScrumMaster (CSM) Certifications?

Low Scrum Adoption Rate in German-speaking world?

Adopting an Agile Method

Agile Delivery at British Telecom - A case study on Agile process adoption

A "Bones" Approach for Dead Projects

Rest In Peace (from Latin requiescat in pace) is a sentence that typically appears on christian tombstones. Software development projects have usually the same destiny. Once they are finished, often the best thing that will happen is a little celebration for the project team. Nobody will formally look back at a project to understand what went well or wrong and why those things happen, so that this project can actually rest in peace and lessons learned could be used for the next projects. There is however an activity to analyze project after their completion. It is called "post mortem" analysis (so the RIP reference is not far) or "retrospective" in the agile approach. If you have not heard about this practice or never performed such activity, you should not be ashamed. I have never seen its implementation in my software development life. Even in the last Agile survey published by Version One, where a large majority of respondents are using an agile approach, only 39% of the participants are using this practice. Why?

The first explanation is that time is a rare resource in software development organizations. It is often associated to money in budget-driven companies. As there is a sense of urgency, people try to use their available time for the more essential (for them) activities. It is sometimes already difficult to justify taking some time to think before coding, that trying to have time to think after coding could seems an utopia. It is also difficult to tell as a project leader that you will spend some man/days after the project's completion to think about what went wrong. Are you not supposed to do things right in the first time?

Our difficulty to create a context for constructive criticism is another issue faced when you try to institute some "post mortem" reflections. This is mainly due to the difficulty to separate the problems from the people that are associated to them. This is an important issue in organizations where professional excellence is a driver for monetary gains and career evolution. Will you speak openly about project problems if part of your (or your colleague) salary is a bonus linked to achieving certain professional goals? Maybe not...

There are however techniques that could help you to profit from lessons learned without creating personal issues, so that your past projects could really rest in peace and everybody could improve from a shared experience. You will find more resources about post-mortem or retrospectives for software development projects in the following articles:

* Refactoring Your Development Process with Retrospectives by Rachel Davies (HTML)

* Retrospective Agility by Tim MacKinnon in Objective View issue #8 (PDF)

* Plan of Action by Bas Vodde (HTML)

* Project "Post Mortem" Review Questions by Michael Greer (HTML)

* A Review of Small and Large Post-Mortem Analysis Methods by Mauri Myllyaho1 et al. (PDF)