#14 A quote by “Uncle Bob” Bob Martin.
Original video here: https://www.youtube.com/watch?v=hG4LH6P8Syk
Transcript taken from: https://www.aaron-gray.com/a-criticism-of-scrum/
It was the year 1999. The world was dominated by waterfall. There were a few papers about strange things called Scrum, by Ken Schwaber. It caught a little attention, but not much. Then Kent Beck came out with another weird thing called eXtreme Programming… Kent had a vision – a vision to heal the damage between business and development. With just the right disciplines, and just the right minimal process, trust could develop between developers and the business. The business would begin to trust the developers, instead of thinking they were lazy, venal, nasty creatures, and the developers would begin to look at the business, and realize they were reasonable, rational beings, not from some other planet.
When [the three of us, along with many others] created the Agile Manifesto in 2001, Kent Beck reiterated his vision to heal the divide between business and development. Kent created the website, and we were stunned when thousands upon thousands people signed this website. So we decided to form an organization – the Agile Alliance. I was the first chairman of this organization. The next chairman was Ken Schwaber. He decided he wanted to do something else. He wanted to make the alliance a revenue making machine…
Ken came to me some time later, telling me he was going to make a class called Certified Scrum Master Class. I thought it was a dumb idea. But a dumb idea that works is not a dumb idea. People came and liked it. The more he charged, the more people came. He started giving out certificates, and he made a little organization off to the side – the Scrum Alliance. Lovely thing to happen.
Who do you think was taking these courses? Was it developers? No. See, I was a developer, and I thought it was stupid. All the developers you talked to thought it was stupid. So who was it that was taking these courses? Project Managers. They didn’t think it was stupid at all, they’ve been doing this thing for years. These project managers started to line up for these courses, and the amount of money that was gathered from that was truly astounding.
This had the effect of legitimizing Agile. Without that Certified Scrum Master course, Agile would be nothing. That caused Agile to cross the chasm and go mainstream. But the problem was that it was not developers that were taking the course – it was Project Managers.
Initially, a Scrum Master was a coach – not a manager. They were responsible for defending the process, but nothing else. He did not defend the schedule, the budget, the backlog, the stories – he only defended the process, and the role was supposed to rotate between the team members. The idea of the role was to slowly kindof fade away so that in the end you wouldn’t need a Scrum Master. I don’t think the Project Managers who took the Scrum Master course liked that particular interpretation. I think they wanted to be Scrum Masters!
So it turned out that businesses got the idea that the critical element in making a Scrum team successful was to pick the right Scrum Manager. Notice how similar this was to pick the right Project Manager. It maps very nicely. And the Scrum Master who did a really good job could stand at the end and say, “My team succeeded!” Who would get the glory and success? The team would stand behind the glorious Scrum Master! (Poses for triumphant effect)
That was not supposed to be the way. Do you think that helped to heal the divide between development and business? Noooooo, no it helped to worsen the separation between business and development…
Scrum makes you go fast – so does any Agile method – because every couple weeks, you’re delivering something. Can you imagine how foreign that was in 1999? People started getting stuff done very very fast. Scrum teams, when you tell them to deliver every two weeks, they will deliver every two weeks. They won’t deliver everything they promised, but they will deliver something, and stuff will get done. They can move very very fast at first. But, something happens.
What was it that was not taught in the certified Scrum Master course? Software development practices. All that stuff that was in XP – all that stuff about pair programming, simple design, refactoring, test-driven development – that was all in there for a reason. Because when you are going fast – and you can go fast – you need something that keeps you clean. You need something that keeps the code from rotting. When you go fast, and you are focusing on getting stories done, and stories done, and stories done, the code can rot just as fast as you are moving. So what happens after a year is that the rate begins to slow… Martin Fowler coined a term – Flaccid Scrum – to describe Scrum used without any technical principles.
There came an us vs. them attitude – developers vs. project managers. It got to the point that if you went to an Agile Conference, there would be 90 talks about project management techniques, and no talks about development techniques. Or one. Or two. There was a huge bias in favor of the project management techniques. And the developers who had spawned this process now felt left out, they felt disenfranchised, they started thinking, “This has gone off to a bunch of guys who are getting pieces of paper for spending a lot of money to go to a 3 day class while the rest of us, who have been busting our butts making these Scrum projects work, are getting jack out of it. Kent’s vision had failed. The divide between business and development, had re-opened. And it had re-opened right in our midst, right in the midst of the Agile community itself, manifested by the Agile Conference, Kent’s vision of a healing of that divide had been torn apart.
What happens to a Scrum team as it begins to slow down? Velocity starts to go down. What does the business do? What does the Scrum Master do? “Guys, you keep your velocity up.” “Guys, you gotta keep getting stories done.” “Guys, we’re letting the business down.” Notice this pile of guilt that starts to grow on top of the developers, and notice who is not bearing it. The Scrum Master who is saying to the guys, “We gotta go faster.” Is actually saying, “Guys, you gotta go faster.” The team starts to falter, there are factions that grow in the team, and people start to leave in disgust, and eventually, if that’s allowed to continue, the team will go back to doing waterfall, because at least in waterfall, you have these long periods of rest.
What Scrum forget was that you cannot have speed without quality. You cannot have speed while you are carrying technical debt. And the more technical debt you will carry, the slower you will go. And this is a horrible wicked circle, because the slower you go, the more technical debt you will acquire.
Because of this, another movement was born – the Software Craftsmanship movement. This is an evidence of a split in the community. A group of us felt it was necessary to re-assert the values of eXtreme Programming into this world that was now dominated by Project Manager Scrum Master Scrum. We hope that is a reawakening of Kent’s vision. I’m not sure there is any evidence to this effect.
Today, many people are doing Scrum. Few people are doing TDD.
In some ways, Scrum feels like it goes against core ideas of Agile. The Agile Manifesto says, “Individuals and interactions over processes and tools.” Scrum is a highly structured process, with lots of overhead. Instead of optimizing for individual developers and good development practices, it lays out a heavyweight process that actually gets in the way of craftsmanship.
It’s well known that creative people lose their creativity if asked to explain themselves while they are working. It’s the same with software. Programmers often have to work in an environment of one-sided transparency. These Agile systems, so often misapplied, demand that they provide humiliating visibility into their time and work, despite a lack of reciprocity. Instead of working on actual, long-term projects that a person could get excited about, they’re relegated to working on atomized, feature-level “user stories” and often disallowed to work on improvements that can’t be related to short-term, immediate business needs (often delivered from on-high). This misguided but common variant of Agile eliminates the concept of ownership and treats programmers as interchangable, commoditized components.
Next up is retrospective. Frequent feedback meetings (in which also the estimates are reviewed) are actually a great idea, because the best opportunity to learn from something is right after it happened, but in Scrum, the retro is explicitly supposed to be about the Scrum process itself, not about the codebase, the technology stack or development patterns. So you have this hour for the team, and you are supposed to use it to talk about Scrum itself. Blergh.
The whole point of Agile was “people not processes” However because at my company we have professional scrum masters, everything must be religiously Agile.
This means that we must have a standup, everyday. we must have a retro, we must have planning.
almost half a day a week is lost to pointless meetings. I just want to get on with my job. Trust me to use the ticketing system to figure out what I’m doing and raising blocking issues.
I have once been in a company where agile was done “right”. It was refined to the point where we had one meeting a week(effectively a retro).
Feedback was done through jira, which provides rich metrics. Collaboration was expected to happen as and when it was needed. If you couldn’t figure it out, then you were in the wrong job. you needed to be able to talk human.
Why is that agile? because the process was mapped to the company, and tweaked until it produced measurable results. Not the other way round.
Everywhere else it feels like agile is a religion that must be observed, never questioned. Woe betide anyone that dares question the knowledge of the vicar as they mumble the softly spoken spells during stand up.
Empower people to act responsibly and they generally will. Exercise empathy and people will trust you. Give people the information they need and they will reciprocate. Agile development was an attempt at doing these things better, but it has been reduced to a collection of code words and empty rituals by managers who don’t realize that it is actually their philosophy about the purpose and nature of management itself that needs to change, and not merely their choice of techniques.
I see the benefits with agile, but I cant help feeling that something is lost in a process that so completely controls the employees … it is probably great to churn out good software, I doubt however that great software happens in that environment