If you talk about agile to a developer you often hear the reply “oh you mean Scrum” – the two have become synonymous. By any measure Scrum is the most well known of the agile methods (is Scrum a method is for another blog), search results, blogs, books or surveys – its top of the agile hit parade. There are a lot of reasons for this; first it works when done right and within the right type of organization but success’s is only part of the story. Other methods like FDD, Crystal have had their success too but do not have the same status as Scrum. A strong community has helped to popularize Scrum, but DSDM has a strong community however it does not come close to Scrum’s fame.
So what else is there? Well it comes down to a mix of marketing, push for certification, consultancy self-interest and let’s be honest, its cool. Scrum is the Apple of the methods world, what I mean by that is yes it does the job but often coolness and peer status plays a role in adoption. (Just in case your thinking I am knocking Apple I just switched from PC to MacBook Pro and am very happy even with the dent in the lid after I dropped a radio on it).
The big question is does it matter how Scrum has been popularized as long as it is moving agile into the business and bringing success? I think yes.
If a single agile method get’s a monopoly it has the potential to stifle innovation. But the chance of any one method getting a monopoly is unlikely; there are just too many variables to ever have a single silver bullet approach agile or otherwise.
My bigger concern is I am starting to see a lack of due diligence when selecting an agile approach. Scrum is being adopted within many organizations by osmoses. That’s fine if the organization culture is a strong fit for Scrum but if it is not we reach a crisis point, a point where Scrum fails. Now this is true for any approach if misapplied but the hype around Scrum often means its adoption is not questioned until there is a problem.
“I don’t know why we are having problems we are using the best approach!!” I hear client’s cry. And when I ask what evaluation process they used before adopting Scrum 90% of the time I hear “none”. They adopted Scrum because it was already used ad-hoc within the organization, or they had some ScrumMaster certified developers, or Fred-Blogs consulting recommended it.
As agile becomes more and more poplar and is applied to bigger projects, outsourcing, package development and legacy the “Scrum effect” will start to be a real problem. In 2010 I saw a number of failures of Scrum in SOA projects and two SAP implementations. None of these failed projects had done a good job of the method evaluation; they where driven by a real business need to deliver fast and in their haste jumped to Scrum. These failed projects would have been better suited to DSDM, FFD or Agile Modelling given the organizations types, architecture and technology.
So will 2011 see a move away from Scrum, no. But it will see more organizations run into problems with Scrum and either result in a hybrid approach or worst-case dropping agile. It would be to easy to say a Scrum failure is a result of the organization not implementing it correctly and therefore not a failure of Scrum at all – the classic “It was not Scrum that was the problem it was the company”. And yes many Scrum failures and issues will be down to the organization not really embracing Scrum practices but just as many will be down to selecting the wrong method.
So before you go down the Scrum road ask yourself are we adopting it for the right reason, and will it work for us? And if the answer is yes (and in most cases it will be) you have at least asked the question and looked at the options.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.