Agile Zone is brought to you in partnership with:

I am an experienced software development manager, project manager and CTO focused on hard problems in software development and maintenance, software quality and security. For the last 15 years I have been managing teams building electronic trading platforms for stock exchanges and investment banks around the world. My special interest is how small teams can be most effective at building real software: high-quality, secure systems at the extreme limits of reliability, performance, and adaptability. Jim is a DZone MVB and is not an employee of DZone and has posted 98 posts at DZone. You can read more from them at their website. View Full User Profile

Why Scrum Won

01.08.2013
| 16069 views |
  • submit to reddit
In the 1990s and early 2000s a number of different lightweight "agile" development methods sprung up.

Today a few shops use Extreme Programming, including most notably ThoughtWorks and Industrial Logic. But if you ask around, especially in enterprise shops, almost everybody who is “doing Agile” today is following Scrum or something based on Scrum.

What happened? Why did Scrum win out over XP, FDD, DSDM, Crystal, Adaptive Software Development, Lean, and all of the other approaches that have come and gone? Why are most organizations following Scrum or planning to adopt Scrum and not the Agile Unified Process or Crystal Clear (or Crystal Yellow, or Orange, Red, Violet, Magenta or Blue, Diamond or Sapphire for that matter)?

Is Scrum that much better than every other idea that came out of the Agile development movement?

Simplicity wins out

Scrum’s principal strength is that it is simpler to understand and follow than most other methods – almost naively simple. There isn't much to it: short incremental sprints, daily standup meetings, a couple of other regular and short planning and review meetings around the start and end of each sprint, some work to prioritize (or order) the backlog and keep it up-to-date, simple progress reporting, and a flat, simple team structure. You can explain Scrum in detail in a few pages and understand it less than an hour.

This means that Scrum is easy for managers to get their heads around and easy to implement, at a team-level at least (how to successfully scale to enterprise-level Scrum in large integrated programs with distributed teams using Scrum of Scrums or Communities of Practice or however you are supposed to do it, is still fuzzy as hell).

Scrum is easy for developers to understand too and easy for them to follow. Unlike XP or some of the other more well-defined Agile methods, Scrum is not prescriptive and doesn't demand a lot of technical discipline. It lets the team decide what they should do and how they should do it. They can get up to speed and start “doing Agile” quickly and cheaply.

But simplicity isn't the whole answer

But there’s more to Scrum’s success than simplicity. The real trick that put Scrum out front is certification. There’s no such thing as a Certified Extreme Programmer but there are thousands of certified ScrumMasters and certified product owners and advanced certified developers and even more advanced certified professionals and the certified trainers and coaches and officially registered training providers that certified them.

And now the PMI has got involved with its PMI-ACP Certified Agile Practitioner designation which basically ensures that people understand Scrum, with a bit of XP, Lean and Kanban thrown in to be comprehensive.

Whether Scrum certification is good or bad or useful at all is beside the point.

Certification helped Scrum succeed for several reasons. First, certification lead to early codification and standardization of what Scrum is all about. Consultants still have their own ideas and continue to fight between themselves over the only right way to do Scrum and the future direction of Scrum and what should be in Scrum and what shouldn't, but the people who are implementing Scrum don’t need to worry about the differences or get caught up in politics and religious wars.

Certification is a win win win…

Managers like standardization and certification – especially busy, risk-adverse managers in large mainstream organizations. If they are going to “do Agile”, they want to make sure that they do it right. By paying for standardized certified training and coaching on a standardized method, they can be reassured that they should get the same results as everyone else. Because of standardization and certification, getting started with Scrum is low risk: it’s easy to find registered certified trainers and coaches offering good quality professional training programs and implementation assistance. Scrum has become a product – everyone knows what it looks like and what to expect.

Certification also makes it easier for managers to hire new people (demand a certification upfront and you know that new hires will understand the fundamentals of Scrum and be able to fit in right away) and it’s easier to move people between teams and projects that are all following the same standardized approach.

Developers like this too, because certification (even the modest CSM) helps to make them more employable, and it doesn't take a lot of time, money or work to get certified.

But most importantly, certification has created a small army of consultants and trainers who are constantly busy training and coaching a bigger army of certified Scrum practitioners. There is serious competition between these providers, pushing each other to do something to get noticed in the crowd, saturating the Internet with books and articles and videos and webinars and blogs on Scrum and Scrumness, effectively drowning out everything else about Agile development.

And the standardization of Scrum has also helped create an industry of companies selling software tools to help manage Scrum projects, another thing that managers in large organizations like, because these tools help them to get some control over what teams are doing and give them even more confidence that Scrum is real. The tool vendors are happy to sponsor studies and presentations and conferences about Agile (er, Scrum), adding to the noise and momentum behind Scrum.

Scrum certification is a win win win: for managers, developers, authors, consultants and vendors.

It looks like David Anderson may be trying to do a similar thing with Kanban certification. It’s hard to see Kanban taking over the world of software development – while it’s great for managing support and maintenance teams, and helps to control work flow at a micro-level, Kanban doesn't fit for larger project work. But then neither does Scrum. And who would have picked Scrum as the winner 10 years ago?

Published at DZone with permission of Jim Bird, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Vijay Nathani replied on Tue, 2013/01/08 - 2:07am

Everything that has certification does not succeed. Also, if certification is the only reason for popularity, then the process will not last long.

Scrum succeeds because it works. Scrum has lasted for a long time and its popularity continues to grow. This is not because of certification.

Jilles Van Gurp replied on Tue, 2013/01/08 - 4:02am

Scrum definitely displaced a few other methods a few years ago when it was at the peak of its popularity. We're well past that moment now and at this point Scrum is the conservative option chosen by people who in the past would have insisted on something other that was mainstream like rational unified or waterfall. It won in the sense that it is now sort of the lowest common denominator in the industry. That used to be waterfall. 

The most common implementations of scrum involve basically doing two or three week waterfalls (aka sprints) with a lot of ceremony/ritual around them. I don't call that progress. Iterative development has been common since the early eighties. It's not new at all.

I'm actually a certified scrum master. As in: I did the two day (!!!) workshop coached by Ken Schwaber himself. He shook my hand, gave me a big wink and pronounced me a certified scrum master. That's the whole certification process. 

So, Scrum certification is absolutely meaningless; just like most other certificates in our industry. Certified scrum masters, product owners, etc. are junior employees with generally very little practical experience and nothing more than (hopefully) a semi academic background in a vaguely engineering related field. That's not a solid basis for running complex software projects and you'd be wise to hire somebody instead that actually has some experience and track record to prove it. If certificates are the only evidence: run away.

The alleged advantages of scrum over any other method are actually largely unproven, overstated, baseless bullshit. There have been no scientific studies whatsoever that allow one to any conclusions about scrum stating that "it has won", "it is better than foo", or indeed "it is better than having completely untrained college dropouts run your project". 

There are plenty of anecdotes that suggest the last option is not a great idea but no prove whatsoever that a two day scrum training does any good in such a situation beyond the laboratory experiments that Ken Schwaber performed with a small amount of students and that he documented in his papers on software methodology. By the way, these are solid papers with carefully stated conclusions and a well articulated summary that basically state that it would be interesting to study whether his conclusions are more broadly applicable. That's how science works. Backing up big sweeping statements with evidence is hard work and in the case of Scrum that never actually happened.

Now certification in our industry creates an illusion of professionalism that is frankly complete bullshit. I've dealt with certified  jboss, spring, scrum, rational, java, etc. individuals that were completely useless for the stuff they were certified for. Most people around me that I actually value for their skills don't have much relevant certifications at all (beyond a university degree). For me a long list of certifications is a clear sign of mediocrity. It's evidence of someone trying to compensate for a lack of skills. Generally the barrier for getting certifications is very low. You get your boss to pay for them, disappear for a few days and you come back with a useless piece of paper stated that you did some shitty course and passed the idiot proof exam. Frankly, the last thing I'd want on any of my projects is a freshly indoctrinated scrum evangelist. They're the worst.

The best certification is evidence of the ability to learn. A master of science or phd degree in any field provides weak evidence of that skill. That combined with a CV that demonstrates that experience is what you need to look for. I don't need somebody with certified outdated skills for yesterday's hype but I do need people that can catch up in a hurry with whatever is coming our way tomorrow.

 


Loren Kratzke replied on Tue, 2013/01/08 - 1:45pm in response to: Jilles Van Gurp

 Very well put. Excellent.

Gregory Ledenev replied on Tue, 2013/01/08 - 5:24pm in response to: Jilles Van Gurp

Gorgeous, well thought and writen reply!

Otengi Miloskov replied on Tue, 2013/01/08 - 8:43pm in response to: Jilles Van Gurp

Mr.Jilles Van Gurp responce is much better and accurate than the article. Awesome responce and +1.

Jeff Smith replied on Wed, 2013/01/16 - 5:08am

Success in this article relates more to the sell than the validity of the practice... the only data we have is mindshare, not effectiveness. How many people bought it.... embraced it... adopted it. What are the chances that the easiest and most popular answer was also the best answer? The discipine of XP would lead to better code... and better productivity... but since there is not really any normalized real-world productivity or quality data, there is no way to claim technical victory. That more people merely feel good about their decision is not proof of decision quality... we commonly choose to believe in our decisions regardless of the data. No process compensates for a lack of technical practice. Scrum is simple as a set of practices  - and is certainly not value-free; but the idea that you train one individual (a certfied ScrumMaster) and he transforms the team - is more prayer than reality. It can work - but it does not as a rule. There are many CSMs without the personal character to coach or lead; its a communication job and a patience job - and these qualiities do not emerge thru a few days in class. Scrum as the ultimate answer is more faith-based than proven; combining Scrum and XP practices is a profoundly better way.... but it requires more discipline. To believe that Scrum alone will get you great code is to suggest that you don't need technical competence at all - that people from off the street without training could be a solid development team. That the practice of coding has improved made much of the difference - that we are tougher in interviews and have more science in our practice - this was the only path toward better technical implementations. Feedback and collaboration help, but you still have to do something with the feedback; Scrum alone would only deliver more of the same faster without a corresponding improvement in tooling, technique. and/or thinking, Scrum was the easiest to sell... it was the simplest for management to buy... and it was quick to implement. This does not mean it to be better. The Hawthorne effect - the mere implementation of something new and team-focused - might reasonably produce and explain improved results and good feelings for some teams... because I have seen too many people who claim Scrum - but do not do Scrum - and have still convinced themselves Scrum made all the difference. Belief .... popularity... are evidence of better marketing or a simpler idea, but not necessarily better thinking.

Jeff Smith replied on Wed, 2013/01/16 - 5:19am

Maybe the idea that anyone has won also needs review. Lean is emerging... and solid process thinking has always meant better judgment, better tools, better ideas. No two "implementations" of Scrum are ever that alike - it is not a defined process at all - That it is a proper noun has perhaps obscured that fact.  No process out of the can ever suits the need... And claiming a winner means the game is over. Let's hope not - I think we can do a lot better still - and shaking off the religion by getting back to the tools, people, and ecosystems in front of us dogma-free  - still leaves a lot of open road.

Eric Breitholtz replied on Wed, 2013/01/16 - 6:52am

Fantastic reply from Jilles Van Gurp. You more than nailed it! I actually had to dig up my old account details, log on and say this



Wade Chandler replied on Wed, 2013/01/16 - 8:46am

I agree with what Jilles says except for the emphasis on academics and seemingly subtle slight of drop outs. Many dropouts have been leaders in the industry. I think if a junior can prove their programming chops by example you give them a shot. Plenty of master degree holding, resume and cert toting individuals have caused me sleepless nights fixing their crappy designs and code. So, similarly a track record of leadership is a better indicator for senior developers and leads on a successful project. Success and on the spot proof of knowledge is a better way in my experience to find good leaders and developers. I like code examples and small but revealing tests of skill, and this can be done without a big waste of time. It flushes out credentials and knowledge deception or over estimation.

There are certainly good qualities of scrum,  xp, and other agile approaches. There are good qualities of other methodologies and practices. To me the sign of someone capable of a leadership role along with people skills is knowing how to use the components in different combinations for various teams and projects, and to be able to adjust and evolve a project or teams processes to aid in success along with managing other factors and stakeholders. Some degrees other than technical can help one prepare for such things, but the person has to be a self learner regardless of degree to apply such things, evolve, and not be rigid.


Clinton Begin replied on Wed, 2013/01/16 - 11:33am

This post from Jim Bird is so misguided I almost wonder if he's trolling.  Jilles Van Gurp and Jeff Smith are right on.  Scrum certainly did "win" for the reasons that Jim said (simplicity and certification).  But those are absolutely the wrong reasons and there's nothing good about it. If anything, modern day Scrum, its certification and de facto implementation hurt agile methodology and give it a bad name.  I am also a CSM (2002 from Ken Schwaber).  I take key elements from Scrum and (while they're not unique to Scrum) I give it credit for those where due (backlog, daily stand-ups, retrospective, I use 1 week iterations though).  But  without the practices of XP at the implementation level and the values and principles of Lean at the executive, management and team leadership levels, Scrum is hardly enough to claim any significant change for the better.  To only do Scrum is a lazy way for a typical legacy waterfall organization to claim "Yay, we're doing agile!", when really they haven't changed a damn thing other than to add more meetings.

Jim Bird replied on Wed, 2013/01/16 - 11:45am

Lots of interesting comments.  As Jilles Van Gurp points out, Scrum is becoming the conservative option for companies looking for a SDLC, replacing the waterfall model. To me, this is evidence that it has won, for good or for bad. The point that I was trying to make is that simplicity and certification drove this success.

I specifically didn't want to get into an argument over whether certification is bullshit or not, because it has already been discussed to death elsewhere, and like many of you I know how little the CSM really means, having also spent a couple of days in a room with Ken Schwaber to get "certified". Certification created a virtuous circle however, building the momentum behind Scrum and pushing it past the other little Agile methodologies. What would the software development world look like today if one of the other methodologies had pushed certification first - XP or Crystal or DSDM? Would we all be following them instead, and would we be better off?


Jilles Van Gurp replied on Wed, 2013/01/16 - 12:22pm in response to: Jim Bird

I think actually most companies only pay lip service to whatever process flavor they implement. Mostly that sort of boils down to vaguely iterative with some ceremony once in a while. The better companies do what all the agile coaches suggest, which is to fine tune and customize a process that works for them. 

Calling that scrum is a bit like putting lipstick on a pig but I agree that it is sort of the flavor of the moment; Kanban is another popular one and you don't hear many people talking about XP or rational unified (thankfully). 

I don't really think certification matters much here although I guess you are right it does help sell people on change. XP used to have extensive certification and consultancy as well. I had a agile workshop once with Alistair Cockburn where he promoted his agile process as well. Most of the people involved in the agile manifesto made good money doing consultancy, courses, etc. 


Peter Harrison replied on Wed, 2013/01/16 - 12:51pm

One of the most disturbing tendencies I have seen is for development methodologies be used to justify lazy thinking. Too many projects blindly following a set of practises without having a deeper understanding of why. Certifications do little more than certify that someone has been able to parrot back the thoughts of the instructor.

Too often I see this kind of approach used as cover, aka "we are following the process". The early adopters of agile methods all had an ethic that they were always prepared to review and adapt what they were doing. Always thinking about how they might do better. When Scrum or any other process becomes codified, certified and static it discourages the central ethic of continuous improvement and evaluation.

After all, the 'retrospective' is really about that reflection and adaptation process. We should be less concerned about whether we are 'doing Scrum' and more about whether we are being the best we can be, thinking about and adapting to new conditions and challenges. Different projects call for different approaches.

Gregory Ledenev replied on Wed, 2013/01/16 - 1:17pm in response to: Peter Harrison

Yeah, it just looks like nowadays "nobody can be beaten for contracting IBM" mantra.

Michael Moser replied on Wed, 2013/01/16 - 1:24pm in response to: Vijay Nathani

Spot on Vijay.  However certification gets management buy in, something that is very necessary in a lot of development shops.

Araceli Mercado replied on Wed, 2013/01/16 - 2:27pm in response to: Jilles Van Gurp

 Very wel said!

In my experience, certification is simulation, no more. We've been building a world of simulation in almost every aspect.

Araceli Mercado replied on Wed, 2013/01/16 - 2:43pm in response to: Eric Breitholtz

 Me too! hahahaha

Oleksandr Alesinskyy replied on Tue, 2014/07/01 - 9:36am

Scrum is successful because :

  • it is the least agile from all agile methods (even if properly implemented)
  • it has the highest overheadsб so managers may easily found their place in it (by "real" agile many of them become simply unnecessary)
  • it is the easiest way to make an agile impression without moving to true agile.(even to the true Scrum)

Despite all said above a properly implemented Scrum is much better than nothing and a good starting point.

Mrugesh Panchal replied on Tue, 2014/07/01 - 8:04am

"You can explain Scrum in detail in a few pages and understand it less than an hour." - True. Agile scrum can be briefly explained in a couple of pages of text. However, as far as scrum is concerned, it's the practical aspects pertaining to scrum implementation which makes it very difficult to achieve the desired project results - at times - for many organisations. Implementing scrum can be a daunting task if the framework is not properly understood and followed. The intricacies involved with scrum implantation  need to be properly understood. Experience and time are needed to become conversant with the scrum process, before implementing the framework. Scrum becomes simple once understood and comprehended. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.