http://maurits.wordpress.com/2011/07/13/why-scrum-will-never-work/

Why Scrum will never work

July 13, 2011 at 11:22 am | Posted in Agile, Programming | 37 Comments

With such a slightly provocative title I will probably have to start with the disclaimer first: what is written here is my own opinion and not necessarily that of my employer. That is, if I still have one after posting this blog. What’s more: I’m a big fan of Scrum and other Agile methods. It pays my bills. Uh wait, let me rephrase that a bit more accurate: I’m totally 100 % convinced that Scrum works for software development.

Now with these formalities behind me let’s get a bit more serious: I really like Scrum. I have been using it for the last 5 years, I haven given several presentations about (distributed) Scrum at several conferences, I’ve written an article about it together with Scrum guru Jeff Sutherland, etc. However now that the Agile Manifesto is 10 years old I thought it would be fun to put on Edward de Bono‘s black hat and explain why Scrum is never ever going to work.

Reason 1: the cornerstone of Scrum is about trusting people. Creating a safe environment so that we can be open to each other, learn from our mistakes. And all that other touchy-feely hippy back to the 60′s stuff. That is not going to work! Did you notice my disclaimer when I started this blog? I had to put it there because quite a few people read my blog, including customers and my boss. There are a lot of pointy haired bosses out there (oh no, another disclaimer: by boss isn’t one, he is a nice friendly guy, bla bla bla). This world is full of alpha males (and females?) who are not at the least interested in you, your process, the outcome, etc. Being open is only going to hurt your career. Room for mistakes, taking risks? Don’t be naive!

Reason 2: according to Scrum ‘people do the best they can’ if you give them enough freedom. What the hell is this based upon? They don’t. They will probably do the least they can because in general most software developers are underpaid, especially compared to their managers. That’s why they want to become managers or software architects as soon as possible, since they can then still be lazy without anyone noticing and the added bonus that they are getting better paid.

Reason 3: because of the previous reason we still have to put project management on top of Scrum teams, so at least it has some output. So this is probably going to be business as usual. Assigning tasks to team members, micromanaging developers, demanding progress reports, etc. All the usual actions to slow your team down as much as possible.

Reason 4: Scrum is just a process. I have seen many processes (like CMM which is nowadays called CMMI) and I have seen them all fail and leave a lot of frustrated people behind. So if you are stuck (like most companies) with a bunch of average people then nothing is going to change. Scrum doesn’t improve your software, good people do! And by definition, you don’t have those good people since you just have Joe Average (or worse) as a programmer because your company doesn’t want to pay a decent salary.

Reason 5: Scrum delivers ‘business value’. Well no, actually it doesn’t. For many reasons. The guys or girls that know about business are not going to be involved in your project. They like to lunch with customers, not work on this weird thing called backlog to explain a bunch of introvert nerdy software developers what to do. So your team ends up with a junior help desk employee as a product owner. And besides, your whole ICT department is a cost center anyhow. So don’t start about business value.

Reason 6: an Agile team is supposed to continuously improve. That is why Scrum has retrospectives to see what went well, what can be improved and to define actions. Now do you really think people want to improve? First they have to think of possible improvement actions. Next they may even have to execute them, which might well take them way out of their comfort zone. People resist change, and therefor improvements. Your old working habits may suck, but at least they kinda work and it gets you through the day.

Reason 7: the Product Owner focusses on the ‘what’ and ‘why’ questions, the development team decides ‘how’. Nicely separated so the team can go for quality and thus high velocity on the long term. However, this is not going to work. Your product owner wants this functionality right now and doesn’t care the least about software quality. Just deliver those features as fast as possible because there always is a deadline, promises made to this important customer, etc. And don’t think you can blow away this junior product owner, because behind him is this business manager ranked high in the companies hierarchy. You as a developer are just part of a cost center and probably going to be outsourced soon anyhow. Now how is that for motivation and trust?

Reason 8: my previous point was about quality. There is some evidence that pushing productivity lowers the quality of software. On the other hand, when you focus on quality, you will get higher productivity. However Joe Average programmer doesn’t care about software quality. If the quality is poor, developing some piece of software takes more time, but why care? He is getting paid between 9 and 5. The project manager (or Scrummaster!) will take the blame for missed schedules. Even worse, if this developer is hired from another company it is in his (and his company’s) interest to stay as long as possible. So this all means that your productivity in Scrum isn’t going to be the least bit higher than with any other method.

Reason 9: “yes, but if we only build the necessary features, then at least we will have a lower total cost, right?” It never stops to amaze me how naive people are when they say something like that. You don’t build necessary features. Most of the time you are on a fixed-price contract for a major banking or insurance company. Or even worse: a government contract. They have selected you because you offered the cheapest bid (which is pretty naive in itself) but they are going to make sure that you will deliver all the requirements they have stated up-front. Of course at least 50 % of these requirements have no business value at all, but hey, you aren’t going to fool the project manager that handles the project from the customer side. He is an alpha male and you are going to deliver that last bloody feature as well!

Wow, wearing that black hat was even more fun than I thought! Must…. take…. it…. off.. now…