Why Scrum Sucks

Since I started working in 2011, agile software development has gone from early to late majority adoption. Being at the peak of the adoption curve, it effectively became mainstream, with the different frameworks sparked from the agile principles in the frontlines and Scrum leading the charge.

With Scrum being the most visible agile framework, it is often taken as a de facto standard. For better or worse, a lot of organizations currently undergoing their digital transformation take Scrum has a synonym for agile.

Why are frameworks so successful?

To answer this question, we must first look at why organizations are adopting these frameworks. For some, its a genuine need for better development processes, higher customer satisfaction and more happiness at work. However, I feel that for most its a pure question of image. With all the cool kids doing this agile thing, organizations feel compelled to move from their usual V-cycle or waterfall processes. They are trying to 'be agile', without necessarily adhering to the agile principles and with a fairly rigid hierarchical structure.

From this point of view, agile frameworks are the way to go. They chew agile principles down to easy-to-digest rules and processes while reinsuring the managing hierarchy in their controlling position. Teams get imposed the chosen framework (Scrum), assigned an 'agile coach' with a lot of certifications for a few months, throw all their working practices out of the window and report their performance through velocity measures. The first few months are very chaotic, then things stabilize again between, sprint planning and as-short-as-possible retrospective.

I had a discussion a few months back with friends of mine, working for a big national company, who just felt that agile coaches are a big bunch of useless bullshitters and agile methodologies a good way to make everybody lose a lot of time.

The state of Scrum

Scrum is at a particular place in the agile community. In the late 90s, it was a precursor to agile development, and its founders, Jeff Sutherland and Ken Schwaber are both amongst the authors of the agile manifesto. They produced guides and rules for Scrum, in the hope of helping other people achieve the same success they did in their respective companies, ultimately resulting in the Scrum guide, published in 2009.

By doing so, they boiled down the essence of Scrum to 'The Rules of the Game'. And the Scrum guide, which people use as there only input for using Scrum, is essentially only that. Rules. It contains very few explainations on the why of these rules and is mostly mechanical execution.

The introduction to the Scrum guide states that 'Scrum is lightweight, simple to understand [but] difficult to master'. Yet the guide gives no clues as to how one would master Scrum. 'Specific tactics for using the Scrum framework vary and are described elsewhere'. I'm still looking for them.

Should Scrum be banished from the agile development world? I don't think so. Without Scrum, agile software development would not be where it is today, and it is a fantastic introduction to agile development for inexperienced team.

Scrum should not be considered more than an introduction.

Going further

I still think Scrum is a good place to start with new teams. It would still be a solid option for existing teams, if it fits the team's needs and if it's not hammered into them like a ton of bricks. Its structure allows for quick results over the first few months, its tools are effective at exposing and solving team-specific problems for teams at a relatively low level of maturity.

If Scrum is working for a team, its members should aim to go further. I would start the discussion by asking the team members what Scrum did for them and what they expect from agile software development.

I would then take the discussion to the 12 principles behind the agile manifesto and how they relate to Scrum events and rules. Getting a team to a high level of maturity requires experimenting. Experimenting needs understanding of the underlying principles.

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This discussion should end up in expressing the level of adherence of the team to these principles, as well as identifying the areas where progress could (should?) be made.

A word on scaling agile

Scaling agile is the new craze in the agile world. Frameworks like SAFe or LeSS, as well as the Spotify model are the new cool kids around the block. They suffer from some the same problems Scrum does: they are merely recipes and tools, but are often seen as be-all and end-all agile methods.

Scaling agile raises a lot of questions in my head. Why would you want to scale your agile development? What are the benefits you expect of it? Are the teams mature enough? Aren't there easier ways to improve?

Be agile

Don't stay within the borders of Scrum (or any other framework). Be curious. Read books, blogs, talk with people. Tap into lean, kanban, V-cycle, other frameworks to get ideas. Experiment. Measure. Adapt. Be agile.