Agile in the age of Scrum
[Edit, 1st of September 2025: Philippe I'll pointed out to me that the artifacts I attribute to scrum have been addressed or removed in the latest scrum versions.]
When you tell someone that you work in an agile team, or that you want to be more agile, chances are that they hear:
We do Scrum-like things
That is good and bad.
On one hand, most companies will have some inflexible rituals, applied without thought. I am looking at you stand up!
On the other, at least they changed some things. (hopefully in a deliberate manner).
While your team’s way of working and personalities will probably not be uncommon, their combination and circumstances are probably unique.
As such, following a prescribed practice, static in time will not optimize for most important things.
What is important in software teams:
This is an opinion, but I hope it is a shared one.
Priorities that should be shared among all or most software teams are, in order:
Producing software that solves our user's needs. (And makes enough money)
Producing software that has few, if not none, defects.
Producing software fast.
Being able to adapt the software to changing needs.
Being able to sustain it indefinitely.
There are other sub priorities, but I think they are encompassed by the above ones.
And your team might have other specific priorities as well.
How to address these priorities:
I understand it would be quite ironic if I were to prescribe a list of practices here that you must do after having complained at people following prescribed practices.
But people have been thinking about these problems for a while, good places to start would be to look towards Lean, eXtreme Programming, DevOps and the DORA report
What I would say is that to address these priorities you must be willing to adapt, to change how you work regularly, in small increments and with buy in from the team.
Something that worked for us is to have frequent retrospectives, that might work for you. But in any case, you must be able to change when something is not working.
Doesn’t Scrum address that?
[The practices I describe below have been addressed in the latest versions of Scrum. I will leave the original version below annotated with square brackets, as a self reminder that jargon matters and I should research things better. I invite you to see the scrum guide 2020 here: https://scrumguides.org/scrum-guide.html before continuing.]
I am not a Scrum expert. But everywhere I worked at, Scrum artifacts have existed. They might be a good starting point, but I don’t see them as an end goal.
The most common ones I have seen are:
Some type of estimation/betting table [The Sprint Planning]
A team cycle of two weeks (I refuse to use sprint) [a maximum of one month, but static in size]
Daily Stand Ups, what you did, what you will do, what is blocking. [No mention of that format in the guide]
Some type of cycle closing/starting [sprint closing and sprint retrospective]
These solve specific issues, and might be worth keeping, or changing, or removing depending on your circumstances:
Estimations/betting table
These usually are there to avoid scope creep, we agree on what we are going to do for the next two weeks, that way we can say no to those other things that want doing.
They are a good starting point, it at least gets you to establish some priorities.
In my limited experience they tend to show their limits quite fast. Bugs want to be debugged, our estimations/guesses are incorrect, etc.
Two week cycles with a close/start
The idea here is that you at least will have things to show after two weeks. To be fair, it’s at least better than longer periods. But I do tend to see a mad dash at the end to fit to the schedule. And things don’t always fit a two week schedule.
At least it gets people talking twice a week, as they are usually accompanied of some sort of retrospective.
Daily Stand Ups
I mean, sure, they might make you talk to your team?
It’s better than nothing, I guess?
They tend to go to a state where they feel repetitive because they are a chore and most people wont read from other people.
[As described by the scrum guide, they feel somewhat more useful]
So, no Scrum?
I don’t have too much of a beef with Scrum per se. I think it is a fine starting point. For some teams it might get them closer to where they need to be.
But, it is often implemented rigidly, when you want to teach someone you teach practices, as it’s harder to teach principles. So, people learn the practices, and they stay, they loose meaning, they start impeding further progress.
Start with Scrum if you want, just don’t stay there. (Or start with XP, or with watever, as long as you keep adapting)
So, how can I do Agile then?
[While I ‘pick on’ Scrum here, my critique can be applied to any framework you treat as if it was ‘the final form'. Most frameworks exist to address issues that are more or less common, but the work your team does and the way they work is unique. Treat them as a starting point and adapt to your circumstances]
You can’t do agile. But you can be agile.
Agile is a lot of things, it's vague for a reason. But it's about having the right priorities and changing the way you work to address them.
Pick a starting point, see if it gets you closer to the goals stated above and change and tweak as needed to adapt to today's circumstances.
