Dropping Scrum and following your own Agile journey

I started with Scrum in 2008. Right from the beginning, we had a visible improvement on managing software projects. Before Scrum it was no man's land: planning was done only when a deadline was closing in, meetings were total chaos, with two people discussing about a single feature for a whole afternoon while the rest of the team looked on, bored out of their minds, and releases were done in short notice: at a customer's request out of the blue, or when the project lead realized (often at random) that it had been a while since the last one.

Scrum brought more visibility and predictability for our process, and helped us to see the value of agile practices.

But not long after, we started dismantling the process from some of its ceremonies:

• Release at the end of the sprint? Rarely was the stakeholder available to evaluate and give feedback on what had been done. We replaced it with releases every three months (though we do publish the main branch to a staging environment, so anyone can check the work as soon as it's done).

• Sprint Review? A 3h meeting where most of the team was falling asleep while two or three members were on an endless discussion about a single ticket. We replaced it with weekly meetings where each team member does a quick demo of the feature they are working on.

• Planning Poker? Interesting at first. Today the planning poker cards are buried in a drawer somewhere (together with Introducing .NET 4.0). Instead, we estimate epics for a three-month roadmap.

Yet, when customer or new hires asked about our process, we always answered "We do Scrum" (or Scrum, but…). At some point I started to get annoyed by that: why keep using just some Scrum ceremonies and artifacts if we aren't doing Scrum? Are these bringing value for our process and the fina product?

I then started to write a proposal for the team to drop Scrum once and for all, freeing us to think of alternatives to manage our projects in an agile manner. But before presenting the idea, I went to get external viewpoints on the subject to make a proposal that goes beyond my personal opinion.

Since Google Search results are just getting worse, I went into Hacker News and searched for the term "Scrum". Surprisingly (at least for me), most of the top posts were criticism towards Scrum or some variation of "why we abandoned Scrum". I read many of them, and after spending more time than I'd like highlighting the interesting parts to present to the team, I thought: maybe that would make a good blog post? And here it is.

No Sprints Attached#

In the first article, Scrum Is Dead. All Hail Kanban, the New King, Emanuel Marques writes about how sprints were reducing team morale and hurting quality:

In the last days of a sprint, everyone was rushing to deliver everything they had done in the previous two weeks to avoid carry-overs, frequently taking unnecessary risks… …People cared more about delivering in time than delivering with the desired level of quality.

A similar experience is reported by Grat Ammons on Ditching Scrum for Kanban:

Usually we'd carry over a story or 2 because a couple of tasks were still incomplete from the previous sprint. This occurred very often, and because of that, morale was a major issue… …Multiple times I heard, "Well, we know we can only do less than half of what we plan for." Gee, I wonder how that made everyone feel?

It's remarkable how many teams report identical situations. It's a perfect example of team managers being so attached to the process that they forget to consider how much value the process brings (if any). The perfect antithesis of an agile mindset.

The timebox aspect of Sprints can be beneficial in some contexts (e.g., on teams that are constantly interrupted by "urgent" matters, or in some very mature environments), but it is not the norm. Not surprisingly, there seems to be a sense of relief on teams that stop working with sprints, like described by Ammons after switching to Kanban:

No longer were we cramming at the end or feeling bad when multiple stories didn't get finished.

He goes on describing how they discovered that sprint deadlines were not a major motivating factor to get work done (don't you say?) - Our engineers already feel intrinsic motivation for a number of reasons.

On Why I'm done with Scrum, Jimmy Bogard also explains how he ditched Sprints for a "pull-based approach", where features are delivered as soon as they get done:

We still had regular checkpoints on schedule/timing/etc. but no longer were burdened by iteration boundaries to decide to do more work.

Jimmy also writes about how they ditch the Sprint Planning, calling them "wasteful". I feel his pain when he states - "I remember just getting bored to tears listening to discussions around stories I wasn't developing on to begin with". He goes on explaining that "yes, there is some value" on it, but not near enough to hold-on so many people for so much time. At the end, they replace planning meetings by something more just-in-time: "When a developer is ready… a quick meeting took place between the architect and developer on the story."

Bitter Criticism#

In one of the most provocative articles, How Scrum disempowers developers, Robin Message states:

we have this self-organised, cross-functional, non-hierarchical, essentially amorphous development team. They are meant to be self organising, with no one telling them how to build the product backlog. However, they have limited or no say over what is top of the product backlog, pressure to deliver something sprint-after-sprint, and no-one with the authority to balance the product owner and advocate for developing with higher quality.

In a controversial opinion, Robin claims:

The two day Scrum Master training course is probably one of the worst things Scrum has done to agile.

He explains:

a good scrum master needs to be a strong technical manager with a huge grasp of organisational change, but the role is often fulfilled by a non-technical person with limited management experience from the product side of the organisation who cannot fulfil all of those responsibilities. And the idea that two days of training is sufficient to perfect and advocate major organisational change is laughable.

More cautious, but also with strong arguments, Adam Ard on Why Scrum is the Wrong Way to Build Software says that Scrum start from faulty assumptions:

[Scrum] assumes that you can plan every facet of a software task by merely talking about it in sprint planning/backlog grooming; assumes that engineers cannot conduct a meeting effectively without a facilitator (Scrum Master); assumes that all engineers work the same way.

He also criticizes how Scrum incentivize dividing large stories into smaller task and let them sit in the sprint so anyone can be assigned to it:

By dividing every task into small items that can theoretically be completed by anyone on the team, Scrum discourages engineers from taking pride in and/or ownership of their work. This lack of ownership results in poor design and lack of motivation (“It isn’t my thing”, “It was broken when I started working on it”)

In an also controversial statement, Ard writes:

Scrum is designed to manage the weakest engineers and consequently dis-empowers the better ones.

At Big Tech#

Another big hit for Scrum came from Gergely Orosz article, How Big Tech Runs Tech Projects and the Curious Absence of Scrum. Orosz tells about Scrum implementation on his time at Skype: All engineers and product people were sent to best-in-class Scrum training, facilitated by one of the Agile manifesto’s founders. Implementation was considered a success, with teams going from shipping once-a-quarter to every 2–4 weeks.

But at the same time, a competitor started to win market-share, growing in a pace that Skype can’t cope with — WhatsApp, which would became the leading communication platform. Years later, early employees told that “Whatsapp never bothered with a framework like Scrum… …[they] deliberately ignored all heavyweight processes”.

Further in the article, Orosz claims that “talking to engineers at Facebook, Whatsapp, Google, Netflix and similar organizations, most of them have never used Scrum”. He presents the following reasons:

• Competent, autonomous people need less structure to produce reliable, high-quality output. Big Tech is able to attract, afford and hire these people.

• Leveraging competent teams comes through giving them freedom to choose how to operate. This is true for most types of engineering, and there’s good reason why the Skunk Works model of autonomy with reduced bureaucracy, is what many high-performing teams with high-caliber people end up following.

A Good Starting Point#

The final mention is from a podcast made buy the guys from Codurance. On the episode Shall we get rid of all Agile ceremonies? Mashooq Badar claims that “often, following the framework becomes the goal, and the conversation about value is diminished”. In the same discussion, Sandro Mancuso recognizes that Scrum can be a good starting point for teams initiating on agile practices — “as we learn a completely different way of working, it’ll be better to (start by) following something” — but as soon as the organization gets more mature on the process, and agile values get more established, the process can be customized and improved, and this often means getting out of Scrum. José Huerta sum up with a quote that I like a lot:

Scrum is a great place to start, it’s a terrible place to stay in.

The messages resonate with my experience and the articles cited previously. Ammons writes that things were good at first — Scrum forced us to get more disciplined about upcoming features… …The rituals, mainly the standups and grooming sessions, were fantastic. Emanuel Marques seems to agree: When I started working [with Scrum], I loved it all.

What Then?#

I recognize that much of the criticism expressed above can be solved by someone with a lot of experience leading the Scrum implementation. I’m also aware that the new Scrum Guide makes the process a bit more open and has answers to some of the questions raised here.

My point is to question the almost omnipresence of Scrum when we talk about agile processes and software management. The amount of articles, videos, certifications makes it seems that Scrum is the solution for any kind of project and organizational culture. And if it didn’t work for you or your team, you are probably doing it wrong, your organization doesn’t have the right mindset, or it is the Scrum Master fault (all on him). Maybe that’s why we see so many ScrumBut situations. However, these situations shouldn’t be viewed as dysfunctional if the Agile values are being kept.

I share the view of José Huerta on this: Scrum is a great place to start, but most teams and organizations need to find their own recipe to keep extracting value from their agile transformation.

Acknowledgments#

To Bruno Oliveira and Edson Tadeu for reviewing the text and encourage me to publish this piece.