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.
These observations originate from the field of software development, but may be applicable in other fields as well. I will mainly focus on the areas of Scrum I believe are harmful to the end product, i.e. the ones you pay a hefty tax for.
What if you are primarily creativity driven?
Software development is inherently a creative process. Each given problem has a multitude of possible solutions. The programmer’s job is to find the best possible solution in a given context. Sometimes, the solution is fairly obvious. Either because following a standard makes sense, or because the problem itself just isn’t very complex.
However, more often than not the problem programmers are trying to solve are extremely complex. That’s exactly why they were hired: to solve complex problems.
Creativity doesn’t do very well when it is forced. Creativity is very much spontaneous, unique to the individual. It is precisely this creativity that is desired from programmers to fully nurture their problem solving capabilities.
Scrum is predictable. Every work item is strictly defined, estimated, and divided into tasks. There isn’t very much room for creativity in it, which can be very taxing on the resulting product.
“Seeing the bigger picture”
Because every feature is broken down into bite-size chunks, which can theoretically be completed by anybody, there is no bigger picture.
Let’s assume item
BD-24762 on the backlog can be completed by anybody. Scrum discourages proper design and/or consistency in the code by focusing on getting the work done as fast as possible, not on doing it properly.
This becomes problematic as the project matures. Inconsistent and poorly written code bases don’t necessarily encourage developers to take ownership of it. As a result, motivation to work on what is always “someone else’s code” will be hard to find.
Developers deliver their best work when they feel they are part of the project. When their expertise is aptly used, and when they can take pride and ownership in the work they do.
An endless stream of meaningless tickets gets very boring, very fast. Especially for more talented or seasoned developers. Having the most talented or senior developers be detached from your project is a very expensive price to pay.
What is this technical debt I keep hearing about?
Product Owners ultimately determine what makes it to the product backlog, and what doesn’t. Generally, these aren’t the most technically savvy people in the organisation.
Because of Scrum’s obsession with getting things done fast, and its inherent short-sightedness, teams will often find themselves taking shortcuts, racking up technical debt like there’s no tomorrow.
Technical debt usually comes in the form of hacky implementations, poorly written, incomprehensible code that no one in their right mind would want to touch, ever again.
Explaining what technical debt is to a Product Owner can prove a challenge on its own. It becomes even more challenging when you have to explain why it is important enough to spend time on. Time that won’t be spent on implementing those shiny new features.
You may get the Product Owner to agree that a specific piece of technical debt deserves a developer’s attention. But you’ll have to do this for every single instance. As a result, the risk of building the software equivalent of the Leaning Tower of Pisa is ever looming. Except we’re still building stuff on top of ours.
Accountants love bookkeeping.
Not many developers do. Yet, Scrum is often implemented with terrible tools such as JIRA. These tools impose a very hefty bookkeeping tax on your developers, as the small task size will mean they will spend a lot of their time recording what they worked on, instead of actually getting work done.
Every team has their own modus operandi, a way of working that works well for them. Regardless of how well this way of working works for the team, it’ll have to switch to use the tool’s. No matter how cumbersome. You wanted to be agile, after all.
The frequency of task management and random bookkeeping imposed by Scrum is almost always detrimental to the amount of work done. More so, it implies a lack of trust. Nearly all developers I have ever worked with use some sort of mechanism to track their work. Some use plain old pen and paper, some wrote their own tool in their spare time, and some of them use a specific product for it. The most important thing is they use what fits their workflow. Not the other way around.
Breaking all types of work down into tasks is extremely difficult
This one may be obvious, but not all valuable work can be represented as a task. Sometimes experimenting with a new technology can lead to meaningful insights that can add value to the project, or they may not.
There is this type of abstract work, or research if you will, that doesn’t lend itself very well to being captured in a task. The value of such work isn’t immediately apparent, nor is the amount of effort required. One could hit a dead end straight away, or keep going for weeks, accumulating relevant insight along the way.
Because Scrum focuses very much on measures, and this type of work isn’t very easily measured, let alone presented in a burn down chart, does that mean this type of work isn’t meaningful? I’d strongly argue the opposite.
Research and experimentation are extremely valuable. They could lead to the next break through that gives you a competitive edge, or could lead to significant cost reductions because there is a far more efficient technology you could leverage.
Reducing this to a line in a chart is severely undermining the value of such work. It gives a thoroughly wrong representation of value, valuing short term success at the cost of any and all future innovation.
Are you saying we should just abandon Scrum altogether?
No. There are definitely situations where project management tools like Scrum are effective, and perhaps even efficient. When it becomes a dogma however, it rapidly loses a lot of its strengths.
Let’s assume you are in a crisis situation of any kind, where time is extremely valuable, and a certain goal needs to be achieved as soon as possible. That is where Scrum would excel. Frequent reporting, tracking the status of any and all tasks, closely monitoring progress, reflecting, and improving. Narrowing down the “fix” to the crisis until inevitably you’ll get there. Actually, war room Scrum could very well be a thing.
But that’s the thing. If you are solving a crisis, you have a defined destination, because at some point the crisis will be solved. Most projects, and especially agile ones, don’t have a destination. They just keep going on indefinitely, because the process is iterative and we’ll get there eventually.
Considering the aforementioned quality taxes, as well as the fact that you don’t really want to be in a war room in a permanent capacity, I think there are better approaches to software development than Scrum. Cherry-pick the things that Scrum does well, but treating the whole framework as immutable is not doing anyone any favors.
There are a bunch of Agile Software Development Practices, maybe it is time we try some other ones?