Why Ranting That “Scrum is Terrible” is a Straw Man Argument

My good friend and colleague at Learning Tree, Doug Rehnstrom, sent me a link last month to a blog post by Michael O. Church entitled “Why ‘Agile’ and especially Scrum are Terrible”. My first reaction to it was that it was an entertaining if misguided rant, but in retrospect Michael says some important things. He talks of companies that have been “killed” by Scrum, and complains about what he calls the “humiliating transparency” required of programmers who he claims are treated as “interchangeable, commoditized components” by Agile. He makes the claim that Agile…”has engineers still quite clearly below everyone else: the ‘product owners’ and ‘scrum masters’ outrank ‘team members’, who are the lowest of the low.” Technical debt piles up in Agile organizations, he tells us, and is not addressed, and wraps all this up as a conspiracy theory in which Agile/Scrum “eradicates even the possibility of work that’s acceptable for a mid-career or senior engineer”, part of an age-discrimination culture aimed at “chasing out our elders”. As a 60-year old who has been a software engineer for most of my working life, and has been using Scrum for seventeen years, and who is yet to be chased out of the industry, I would like to respond.

Management Abuse of Scrum

There’s a lot of other stuff in the post where Church gives an even greater impression of someone trying to climb trees to catch fish – and I’ll address some of those absurdities later – but I want to start with what I’ve already listed because although many of who you are practising Scrum may already be scratching your heads, some of Michael’s observations are not imagined. I’ve posted before about pseudo-Scrum, and I’m delighted to see that Learning Tree is now offering a 1-day express bootcamp course  (4872) on Recovering  a Collapsed Scrum.

Many organizations claiming to have deployed Scrum have got into trouble. I worked with one company last year that was only saved from its software engineering dysfunctions by takeover. The VP Software Engineering told me it had been practising Scrum since 2009. Like in many organizations I’ve seen, the so-called “Scrum teams” were subject to micro-control by middle managers. Scrum Boards and Daily Scrum meetings were seen as opportunities by control freaks to intervene more frequently and bully developers. Church is quite right in complaining about this kind of scenario – the problem is, it is not real Scrum or Agile he is targeting, but a straw man impersonator. Scrum has a very small ruleset, but you can tick all of them off, and still not be applying Agile, unless you understand what they are about.

Facts About Scrum are Important

Church is passionate in his diatribe, and passion is a key ingredient in any well-formed argument, but you should never let it obscure established facts. “There’s no good evidence that any of this snake oil (i.e., Agile and Scrum – AOC) actually makes things get done quicker or better in the long run.” He says. Oh no? Well, how about the Standish Group’s CHAOS Manifesto which found as far back as 2011 that Agile projects are three times more likely to be successful than non-Agile ones, or the recent Project Management Institute’s (PMI) Pulse of the Profession report which has also found Agile projects delivering better results than those more traditionally managed. Neither the Standish Group nor the PMI are considered to be Agile evangelists. The fact, uncomfortable for Church, is that their survey results – amongst others – have validated the mountain of anecdotal evidence that has accumulated over the last fifteen years that Agile is indeed a better way.

Let’s be clear. If Agile was associated with the kind of micro-managing malpractice that Church rails against, there would be no way it could achieve the success that has been reported. But it would be strange if that was it was about, wouldn’t it? The Agile Manifesto was published in 2001, the outcome of an informal meeting of 17 thought leaders of what were previously called ‘lightweight’ methods. These methods, characterized broadly by low levels of documentation and ceremony, were themselves a reaction to the most highly-policed era in software engineering history: the period leading up to January 1, 2000 when the industry was traumatized by fear of the Y2K bug. That was a time of real micro-management. Church is too young to have experienced it. Unfortunately, I am a good bit older. I once had to collect thirteen different signatures for permission to fix a bug in my own code!

There is nothing in the Agile Manifesto’s values, or the 12 principles behind it, that justify the kind of abuse of engineers that Church reports. He makes no reference to the Agile Manifesto in his post and is perhaps ignorant of it. He certainly doesn’t seem to be aware that “technical debt”, far from being unaddressed by Agile, was a metaphor invented by Agilists (by Ward Cunningham to be precise) to emphasize what happens if you ignore bad design and code defects: the interest will pile up and eventually the effort of paying off the debt will bankrupt the project. Most of the patterns, practices and even the tools that software developers use these days to tackle technical debt were instigated by Agile developers. “Continuous attention to technical excellence and good design enhances agility” is one of Agile principles (the ninth) that somehow seems to have escaped Church’s attention.

Self-Managing Scrum Teams

Let’s now turn to the myths (I hesitate to call them lies) that Church uses to build his caricature of Scrum. Church claims that it forces experienced engineers to adhere to a reporting process that he seems to think is fit only for inexperienced, unskilled junior programmers. They are only allowed to work on assigned tickets and “spend 5-10 hours per week in status meetings”, he says. But again , if true, this would contradict the Agile principle that states, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Now, if you are in a Scrum Team, there are mandatory meetings in every iteration: the Sprint Planning meeting, the Sprint Review and the Sprint Retrospective, and on every day other than the ones in which those take place there is the Daily Scrum. However, all but the Sprint Review are meetings of the Scrum Team (of which the Product Owner and the ScrumMaster are also members, by the way) and none of them are status meetings.

For example, Daily Scrums are often open but it is only developers who are obliged to attend. It is a 15-minute timebox in which each one reports on what they did the previous day to achieve the Sprint Goal, what they expect to do that day, and what blockers are hindering themselves individually, or the team, in their attempts to achieve the Sprint Goal. They are reporting to their fellow team members: no-one else. No-one outside the Scrum Team even has voice. As a ScrumMaster if I’m working with a new team that is nervous about such visibility, I’ll invite the team to make the Scrum’s private. After all, no-one else’s presence is needed for it to fulfil its purpose.The aim is to allow the development team to synchronize and to pivot, if necessary, and adjust its own development plan.

And that’s the main point of course. One that Church, either through ignorance or malice, completely ignores. Scrum is a framework for self-managing teams developing complex products. And it does what it says on the tin. No-one in Scrum is allowed to tell the development team how to do its work. Only the development team is allowed to estimate the amount of work that can be done in a Sprint. And not only senior engineers, Michael, but juniors too are exempt from providing individual status reports to the ScrumMaster or anyone else. The ScrumMaster has no formal authority within the Team, by the way, she is a servant leader, and Church’s suggestion that it is her job to “impose the toxic micromanagement on other people” is just perverse. The Scrum Team as a whole is responsible for all the work of the team, and the Team as a whole is accountable for every team member. The Scrum team wins or loses together.

What is the Real Gripe with Scrum?

“The best architectures, requirements and designs emerge from self-organizing teams.”. So says the eleventh of the 12 principles behind the Agile Manifesto. I am currently reading a book about Jose Mourinho, the Portuguese Manager or Head Coach of Chelsea FC (my team, by the way). For a young coach, Mourinho has an unprecedented record of achievement. In 13 years, in two of which he was unemployed, his teams have won 22 trophies, including League titles in Portugal, Spain, Italy and England, two European Championships (with different teams) and a whole bundle of cups. His coaching methods were once considered revolutionary, but are now becoming widely adopted. Like much of Agile theory, Mourinho’s philosophy rests on complexity theory. Until he came along most soccer coaches trained individuals to be great players, but Mourinho builds teams. The world famous African striker, Didier Drogba, says he didn’t learn how to play football from Mourinho, he learned how to become a team player.

I have a strong suspicion that Michael Church isn’t much attracted to the concept of a team player. In his post he constantly demands that senior engineers (like himself) be treated differently from juniors. It is not for “high-talent programmers who have less stressful and more enjoyable options.” When he says there is no role for senior engineers in Scrum, what he really means is that they have no prior status in relation to other members of the Team. In Scrum there is no rank (or title other than developer) in the development team. Leadership has to be demonstrated and earned – just like in a sports team.

Another complaint that Church makes is that Agile is explicitly value-driven. He resents the idea that business people should decide what developers should do. He hasn’t even got that one quite right, by the way.

While it is true that the development team selects items from the top of the Product Backlog, and that those items are ordered by the Product Owner, there is nothing in The Scrum Guide that says the Product Owner needs be a business person. I’ve worked with a number of teams when the Product Owner has been a senior Systems Engineer and has done an excellent job. Who best plays the role is a context-sensitive decision. It will differ company to company, product to product.

But the point is, irrespective of the approach taken, the job of the engineering team is to deliver value-laden product to their customers. So, the Product Owner, whatever their job title, certainly needs to understand the business objectives of the product, and the relative value of the required features. But she also has to be able to converse with developers about technical dependencies, and make judgements about how to balance quick wins with the kind of work needed to ensure long-term value as well. The role demands intensive collaboration with all stakeholders: and remember, the development team, indeed the entire Scrum Team are also stakeholders.

Jose Mourinho says “Man is a complex being and…we have to understand that eleven men (sic!- AOC) chasing an objective is completely different from one man doing it”. Setting clear, achievable objectives is a fundamental part of team-building. Captivating every team member with the hope of meeting those objectives, and focusing always on what has not yet been achieved (in football: the next 45 minutes, the next game, the next competition, the next season…) is exactly why the Product Owner, and the ordered list of the Product Backlog are indispensable in Scrum. That’s how clear objectives are set that the Scrum Team can believe in and set about achieving.

There are engineers, such as Michael Church seems to be, who will never buy into the team ethics of Scrum. So be it. There are others who don’t want the responsibility of self-management. Fine. If you are not prepared to be a team player, you shouldn’t be part of the team. Scrum is not for you. Michael O. Church dreams of the day Scrum dies. But be clear. It’s here to stay. It’s not going away. And it’s growing – faster than ever.

To learn how to effectively and responsibly use Agile and Scrum, education is needed.  Learning Tree has a curriculum of close to 30 courses covering the spectrum of Agile and Scrum training.  Many sessions are 1-day online courses that can be taken from the convenience of home or office.

 

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.