The tax you are paying for using Scrum

Photograph courtesy of StartaeTeam on Unsplash

In the past few years, the way work is done in companies has changed radically. Suddenly, planning and subsequently carrying out work was not good enough. It had to be agile. Long gone were the days of waterfall, where work was planned out months — or even years — ahead, and carried out by horses with blinders on, completely oblivious to their ever changing environments. Well not literally blinded horses. But you get the point.

It certainly sounds good, working agile. It sounds a lot better than working lumbering or clumsy. Only a fool wouldn’t want to adapt to their environment, deliver a relevant product at short intervals, improving on the previously delivered product in rapid iterations. It looks great on the outside.

The word agile was chosen very meticulously. Working agile just makes sense. There’s this inherent goodness to the word. It is something you want to do, even if you don’t fully understand what it entails. It’s extremely clever marketing. And it worked, because in 2018, there are a whole lot of organisations and teams working “agile”.

There are various manifestations of the agile manifesto, though the one most frequently used is Scrum. It has taken the software development industry by storm, and even caused some collateral damage in other business sectors.

The way the Scrum process is carried out varies widely, but usually it’s some flavour of the following:

• Work is defined in the product backlog
• Work is grouped in (bi)weekly sprints by means of a sprint planning, resulting in the sprint backlog
• Work is carried out for the duration of the sprint, with a daily scrum (often called daily stand-up as well) at the beginning of each day to inform team members of progress and obstacles, if any
• After the sprint is done, a sprint retrospective is held, in which team members reflect on the past sprint, and find room for improvement

Each sprint results in a deliverable, incremental product. Repeat ad nauseam.

While this is the de facto standard for software development, there are some rather large implications scrum has on your team and product. I’ll outline a handful in this article.