Pondering the Agile “Don’t Know” Methodology

If you haven’t already heard the buzz, the State of Agile Development Survey 2011 is now out and it is packed full with some great information.   The survey is a helpful resource to quantify what people are doing and the value they have realized or have not realized through their particular agile implementation.  As part of teaching agile methodology and speaking to the delivery methods used, I often reference this pie chart, which shows the Agile Methodology Used, and I just updated my training materials with these latest results.  One thing really jumped out at me and made me go, “huh?”  It was that 8% of the respondents answered “Don’t Know” to the question, “what agile methodology do you use?”  That’s roughly 500 of the 6,000+ respondents.  And like any good agile metric, seeing this only made me ask questions and hypothesize as to why so many folks answered “Don’t Know.”

The first thought I had is training.  Yes, coming from a guy who does coaching, that is the first thing I thought of.  But not for the reasons you may think.  If you think about it, the number of teams applying agile methods is climbing the blade of the hockey stick. As someone who has seen the benefits in product outcomes and overall organizational morale, I think this is great!  But the challenge is, with adopting agile it does require training the team members so that they, the TEAM, can make the transition successful and help adapt, adjust and evolve the agile methods used to fit their development environment.  In agile development, the TEAM owns the process and the TEAM is empowered to make it successful.  This is much different than traditional project management where you can focus training on just the project managers and folks in leadership positions.  The team just needs to know where to report time, and how to write up their status reports.  So, if the team has not been trained on what agile is, and the surrounding methods and processes, then I can understand when you ask them, “Do you do agile?” … “Yes.” “What agile method do you use?” … “I don’t know.”

The second reason I can think of why folks answered, “Don’t Know” is that they are leveraging multiple concepts from the various agile methodologies – including agile project management and traditional project management.  The survey did allow folks to answer “Hybrid” (9% of respondents answered), but in my discussions with teams lately – the application of Agile principles is the beginning focus with the adopting and adapting processes is much more flexible.  Teams are starting with one method and morphing to another, and in some cases leveraging a little bit from everything.  This approach can be good and bad, depending on the maturity of the team and the ability to continuously improve.

Besides the answer of “ignorant blissfulness,” the only other thought I had for the “Don’t Know” response are those that work at organizations that have heard about this Agile thing and decided that they will become Agile.  So they leveraged Find and Replace to put the word Agile in place of whatever methodology they were using before.

So, what are your thoughts?  If you participated in the State of Agile Survey this year, why did you answer “Don’t Know”?

This entry was posted in Agile Adoption, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology, Scrum Software. Bookmark the permalink.

5 Responses to Pondering the Agile “Don’t Know” Methodology

  1. Daniel Tanner says:

    Any chance you could post the results with a key? I’m always curious what everyone else uses and why. =-]

  2. Matt says:

    Hey Daniel, Thanks for giving this a read. You can check out the full results, legend and all here: http://www.versionone.com/state_of_agile_development_survey/11/. The methods used are about half-way down. It is interesting, custom hybrid and “Don’t know” is 17% – pretty significant indicator of adaptation. What do you think?

  3. Daniel Tanner says:

    I would think that those who selected “Don’t Know” aren’t actively using one of the methodologies, but their managers might be. In my opinion, empowering all members of the team will give them control over what they do and give them direct feedback on their output as well as manage their own expectations. I’ve found that doing Scrum tremendously lessens the burden of the mountain of work you have before you, keeps you on task, and seriously reduces overall stress. You’re not trying to do everything last minute and everything flows smoothly.

  4. Matt says:

    Hey Daniel, Great Points — I agree that in order for success to follow, the team members need to be empowered; thus, information and knowledge is shared.

    To AgileScout’s (Peter), this would be an interesting context to track. State of Agile Survey 2012 :).

    Matt

  5. Patrick McMonagle says:

    I first read the Agile Manifesto in 2009. It describes what I have been doing since 1980. Since that works, really well, I keep doing it, and keep sharing it with teams. But I have not gone to enough of the courses to determine what new labels the experts applied to what I do. “Don’t know” is thus the 2nd best description. I believe “Common Sense” is the best; but that choice was not offered.

    Step one of this “Don’t Know” Agile process is to state the goals totally in business terms. Maybe; handle 30% more orders with the same staff while shipping 80% of orders more quickly, those averaging 40% of our current cycle time. Agile jumps out, with or without a name, when someone on the team says; “Look, if we actually fix these two known issues, which cause a fifth of the manual overrides, they get 12%, 23% and 21% in two weeks. And we can do that in our preliminary review phase, before the platform and DBA teams decide….”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>