Agile is a state of mind
we are not beyond agile, we never actually did agile to begin with
Agile is a state of mind
This post is part of a series of post I am writing about my first year as CTO, you can find here part 1.
I initially learned about Agile during my university studies, we had a class about “Quality of Software” and in there there was an extremely brief mention of Agile, in particular of Kent Beck’s role in it.
My basic mental model of Agile Development is rooted into the idea that “nothing can be known for certain, especially in business”. And Agile tries to fix that by introducing the idea that the “cone of uncertainty” can be reduced if we ship small increments of work and show them to the customers as soon as we can.
Everything else (Scrum, SAFe, Kanban, Lean, etc) is just an attempt to formalize working methodologies that worked at a specific company some time ago or branding for consultants.
A toolbox not a framework
The difference between a toolbox and framework is that the toolbox doesn’t prescribe what you do with your tools. It doesn’t *force* you to use an hammer if you don’t want to.
That is not a trivial difference when it comes to organizing the way an agile team works, in fact I believe that using an agile framework is contrary to the spirit of agile.
So when I see a company implementing Scrum (or SAFe or whatever is the latest fad) in a very dogmatic and text-book way I ask myself: “why? god why?”
From that detail alone I know for certain that something at some point went terribly wrong, but what exactly isn’t relevant for us. We only care about destroying the rigid frame around our teams.
Sprints
Before continuing, a side note on sprints. I understand why those were invented: to constrain teams into delivering smaller increments and meet stakeholders more frequently. But years of cargo culting have changed the meaning of sprint into "two weeks" and that's not how this works.
Not all companies release on set intervals. In some cases, the definition of "interval" is meaningless, or the cost of releasing is very high (think of sending your app to the app store, or regulated industries).
But if you have nothing to show to your customers because the feature is really big, is that really a meaningful sprint?
The basics
To contradict myself a little bit. With experience I have realized that there are a few things that each team must do, especially in a remote setup:
Standup meeting
Planning
Backlog prioritization/grooming
Retrospectives
You might be wondering why I picked those 4, and I know of some people that dislike most of the ceremonies I listed but I found them very helpful for a number of reasons:
Connection, they help the team connect and give energy to each other. Any manager will tell you that motivation is infectious and that teams will self-motivate or self-destroy.
Rythm, you can make it very clear where the start and end of a release are.
Visibility, instead of going around asking questions to everyone every day you can just listen to your colleagues or direct reports.
Autonomy, planning and improving are a shared responsibility.
Now the million-dollar question, how often? I have no answer for you, it depends on your business, your culture and your team.
My suggestion is to start frequent and reduce frequency afterwards, because is very hard to increase but very easy to decrease.
What did we end up implementing?
In the last year we did a lot of experiments to understand what worked for Aidence, iteration after iteration we got rid of Scrum and transitioned to a different model in which the “sprint” or unit of iteration is the “release”.
Why the release?
As a regulated company, we cannot have continuous deployments or even weekly deployments. It would be either infeasible or too costly. Our customers also expect a proper release announcement and translations so, unless you have some very high bugfix to ship, you want to organize your work starting from “what are we going to ship to our customers in this release?”
A consequence is that our intervals are not fixed, they depend on the size of the release. That is of course extremely dangerous without careful planning, and that is why a release starts with a release planning exercise.
In this exercise we decide which features or fixes or minor improvements must go into the next release, which are nice to have and what has to wait for the next release. Aiming at an average release time of 6-8 weeks.
Not all stories in the backlog might be ready at this point in time but that’s ok, those can be written later as we learn more.
Teams have their daily standup meetings, in which they discuss progress and impediments and crack some jokes, and keep their backlog grooming/planning on set intervals as they see fit.
After a release is finally signed off, they also do a retrospective on the past release to understand what to improve. The retrospective doesn’t have to be big, one hour is more than enough. All of this is supported by Jira and the automations around it that help us automate a lot of boring tasks.
Finally, in more traditional frameworks you will have the sprint review, one of the most boring meetings I have attended in my life. Instead, every two weeks, we have a one hour “demo day” in which teams can showcase what they are working on or what they have already shipped.
This is important, your customers don’t care about the number of points you achieved in your sprint, while everyone cares about what you have done and how that moves forward the customer experience.
Can an infrastructure team do a demo? Absolutely! In fact you should be worried if one of your teams cannot articulate how their work benefits the final customers.
Is Agile dead?
No, I think agile is healtier than ever. But I really hope that eventually, as these concepts go mainstream, people will stop copying from books or other companies and start asking “what works for me”.