It is always with amazement that I find looking at my statistics, that the set of key words that brings most of random visitors to this humble blog is “Dilbert Scrum”. This is so ever since I’ve commented on an episode of Dilbert in which agile is mentioned. Based on it I’ve moved on to discuss Scrum – and probably no one else did exactly that, because if you type “Dilbert Scrum” into Google that post of mine is now number 1. I suspect this post will strengthen that effect.

Interestingly, I’m not sure Dilbert ever referred to Scrum directly but even so people think he must have – so they look for it. Also, this shows that people want to find an image, not a text. Texts are boring, you have to concentrate (which is hard) and think sometimes (which is even harder). Images are much much easier. Which is, probably, why Dilbert brings so many visitors to my page who come for only one thing: the link to the comic strip (BTW: It was wrong, I just fixed it).

In one of the recent episodes of Dilbert agile gets mentioned (not for the first time). One of my friends said that “Dilbert turned against us” but in fact I think this cartoon very pointedly shows how much a typical manager (Pointy-Haired Boss) knows about agile. Managers like the PHB from Dilbert cartoons do exists in large corporations for real, I’ve met some. But much more managers, accustomed to reporting, WBSs, Gantts, PMSs, 3 months requirements analysis, specifications documents, acceptance documents etc. do think that getting rid of all that means complete chaos and lack of all rules.

That the rules are scaled down it doesn’t mean they don’t work. In fact, rules have a much higher chance of working if there is just a few of them, not a whole 200 pages handbook. Same goes for documentation and almost everything else. Things have to be scaled down so that the rules and information are manageable to humans.

Take Scrum – it is just three roles (the Team, the Product Owner, the Scrum Master), two lists (the Product Backlog and the Sprint Backlog) and three meetings (the Sprint Planning, the Daily Scrum and the Sprint Review). That’s all, not much to tweak around, simple to introduce and then follow. Same goes for XP – simple ideas, easy to understand directions.

But simple doesn’t mean easy. Building unit tests for everything also does require labor, though most who don’t know agile regrettably don’t associate it with extensive testing. Same about management -Scrum may be simple but being a Scrum Master is a demanding work – and requiring certain personality traits PHBs usually don’t have.

This ignorance about agile I’m sure leads to many failed projects when people don’t read up, don’t learn and really believe agile is the same as “cowboy coding”.  This gives agile a bad name, but I’m sure this will change with time.