What does it mean to be Agile - survey results
The Values and Principles of the Agile Manifesto were written almost ten years ago in February of 2001. In the succeeding ten years, technology has continued to change, the environment has continued to change, and thousands and thousands or real people throughout the world have tried to apply these twelve agile principles to their daily work life.
Laurie Williams, associate professor of computer science at North Carolina State University, has been conducting research to understand how well the Agile Principles have stood the test of time and use?
She conducted a survey to obtain input from the international practitioner community on the original principles and their associated software development practices. Three hundred thirty five people from around the work (primarily North American and Europe) responded to the survey. Respondents were asked to say how important each principle was to agile teams in 2010 on a scale from 1-5 with a rating of 1 indicating not important and a 5 being very important.
Discussing the results, Williams states:
Essentially, the community still stands strongly behind all the twelve principles. In round numbers, 11 of the principle had at least 80% of the respondents giving the practice a rating of 4 or 5.
The Agile Principle that had the least support was "The best architectures, requirements, and designs emerge from self-organizing teams” with only 59% of respondents giving this principles a 4 or 5. The respondents who explained their answers in the comment section indicated that they felt that a high level architecture prior to getting started was necessary for larger teams and that having an overall product vision was beneficial.
Related to the principle, “Welcome changing requirements, even late in development.” trends in answers indicated that some felt that ‘changing requirements’ should only be embraced at the start of each iteration rather than at any time. Others felt that the use of kanban was making the notion of iteration obsolete among some agile teams and that change should, indeed, be welcome at any moment.
Increasing inevitability of distributed teams caused some to not support the practicality of the principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Finally, some respondents felt that the principle “Working software is the primary measure of progress” caused some teams to persist in the production of poor quality code that is not valued by the customer – as long as working code is produced, the team would get credit for their work.
She is continuing her research, and has posted two additional surveys building on the feedback and results from the first one. Announcing the additional surveys Williams made the following point:
I fully acknowledge that the Agile Principles belong to the signatories of the original Agile Manifesto but your commentary on the suggested changes will reveal important trends among and behaviour of agile teams.
One of the surveys focuses on the Agile Principles and the other on the Agile Practices. The survey on the Agile Principles obtains feedback on a slightly revised version of many of the Agile Principles intended to capture the sentiments of the initial survey respondents. The survey on Agile Practices primarily asks for reaction to the results of the initial survey.
These surveys will be available to respondents until Friday, 9 July.
She is inviting anyone interested to participate in the surveys and contribute to the evolving understanding of what Agile means today.
The full results from the first survey can be found here.
Hard to beat the original
Many of the proposed revisions had an unmistakable mission statement committee ring to them -- why because it was a commitee. The work Laurie Williams did is pretty cool, and it's a tough thing to capture a broad set of feedback. So, I'm not critizing her work specifically, but if you look at the collective sentiment to alter the original principles, I find the revised versions lacking.
Many of the extra words were redundant. IMO, there was a lack of recognition of the meaning of the core word in many principles. For example:
Original: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
Revised: "The most efficient and effective method of conveying information to and within a development team is through synchronous communication. Important decisions are documented so they are not forgotten."
"Synchronous"? Seriously? Sorry, but in this particular case the revision is just plain wrong. The original is correct. The MOST effective method is face-to-face. This is why people meet in rooms instead of having conference calls (a form of "synchronous communication"). When it REALLY matters, face-to-face is the MOST effective means of communicating, and that is the intent of the original statement. It doesn't say it is the only way, it says it is the most effective, or ideal way. In an era with video conferencing, sure that will be better than a phone call, and eliminate the need for physical face to face many times, but again, would face-to-face be ever better yet? Ideally, Yes. At the cost of a $1,000 plane ticket and an extra 4 hours for that one converstaion. OK, maybe not the most efficient, but the principle is suggesting that whenever possible, arranging for as much face-to-face as possible, will be the most effective.
Also, how does documentation have anything to do with this principle? That sentiment doesn't belong attached to this principle at all.
Also, I think way too many of the revisions got into implementation specifics that the original principles clearly tried to stear clear of.
At any rate, pretty cool survey. Very interesting work, but I think many people may have rushed to rewrite the principles in their implementation-specific interpretations intead of recognizing how the essence of each principle allowed that implementation to be valid -- in which case the original principle accomplished its mission, and as a result should be left alone.
-- greg willits
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014