Why Scrum works and Maurits is wrong
Mauritius writes in his blog about the Reasons why Scrum will never work. He tries to take the devils advocate position.
I think the complete post lacks the learnings of the last 10 years so I want to respond humbly to his inquiries 😉 (and have some fun in the process)
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!
The Book “Five Dysfunctions of a Team” highlights “Lack of trust” as the basis of a big number of other problems stemming from it.The Author says:
Dysfunction #1: Absence of Trust
This occurs when team members are reluctant to be vulnerable with one another and are unwilling to admit their mistakes, weaknesses or needs for help. Without a certain comfort level among team members, a foundation of trust is impossible.
This is pretty easy stuff and my comment on this is:
If you are working in an environment where someone pays you and stil is not giving trust you might wanna look for another job. Remember: the Jobmarket is a sellers market. 😉
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.
It is not only giving freedom. According to a smart guy, named Dan Pink it is: Equal payment +(Autonomy, Mastery, Prupose)
- Autonomy – Freedom to work on what, how, where, when and with whom. You might wanna give as much freedom as reality allows.
When it comes to payment: If you have the feeling you are not equally paid in comparsion to your colleagues and the “market”: Ask for a raise so that you feel to be paid according to your expectations or change the employer. But please: stop complaining, it wont help anyone. You might wanna think about your own laziness and if it attributes to the expressed wish to get better or equal payment.
You might wanna read the book http://astore.amazon.de/agiletools-21/detail/1594488843 from Dan Pink and enlighten yourself.
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.
If the reason for project management ever was to use the stick on the developers, it was wrong in the first place. If someone is too lazy to do what he signed a contract for and needs so constant attention that a complete line of work is generated around him … there is a more substantial problem.
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.
This constant believe in Joe Average is as wrong as all thinking that is in prejudices may they be around race, gender or your favourite MMO. Noone is average just because he is not paid enough, every human beeing is a special kind of mamal, individual, great and of endless beauty. nah .. ok not all but most of the are. And you know, you can select those when you hire people.
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.
If you are working for a customer who is not willing to contrinbute more than just money: Get a new customer. You know, the project market is a sellers market: You are the seller. The customer is the buyer.
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.
Improvement means getting things done easier. And in addition to it you might wanna read again
- http://astore.amazon.de/agiletools-21/detail/1594488843 (Dan Pink – Drive)
- http://astore.amazon.de/agiletools-21/detail/0749953357 (Seth Godin Linchpin)
And out of my own experience I have to add that it is the responsibility of teh person hiring to hire people who are able to inspect and adapt. The right persons improve and that is a majority of people, not a minority as so many management books tell us these days. Humans are delivered with apositive featureset and made bad by people not expecting any good from them.
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?
A Product Owner that does not care about quality has no idea that in software the longterm cost in 99% of the cases are much higher than the initial development cost. If someone spending a lot of money in development is in charge and has no idea about this face, you better leave the project/company. Why? Your boss has NO idea aka is not well educated enough to call the shots in a software project.
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.
No comment on this amount of generalizations and wrong things, go buy a better book with jokes please.
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!
Do not do fixed price/time/featureset contracts, this is what I learned when I grew up. Leave this to others who have lifetime to waste.
Dear Mauritius: Your black hat is very old. There is no doubt that the Internet is full of FUD, but just repeating old prejudices is not going to make anything better.