Scrum, scrum and scrum everywhere. I read this article and found a comment to be valuable, open and honest.

Why Scrum Won?

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?

DZone also published the same article and the comment from Jilles Van Gurp is very interesting.

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.

Scrum is seen as a panacea for all problems we face in software development. Scrum is just a process – the success of any process depends on the people who adopt it. How can a process change people? We shouldn’t think that there is a silver bullet.