Time after time, probably since the popularity of Scrum and its derivatives, one saw posts about the ills of working in an Agile or Scrum like environment. The complaint often being about attending meetings intended to make one feel like something is happening, but the results are just not there, and/or one would rather be coding/designing/testing/… than attending them.
And for cause. The Agile Manifesto was always more about values and principles then methodology. It is something that is not always easily grasped, particularly in operations management.
This resulted in the development of Agile ‘frameworks’ to help translate what was first and foremost a ‘mindset’ into something operationally oriented people could get their heads around.
More recently with the advent of AI and its fast rise in software development, Agile’s continued value is being doubted because it feels like Claude, Codex, etc., can pretty much do it all.
They are very impressive.
I believe people who think that way are still misunderstanding what Agile is about. I have repeated many times in my career that if you are ‘doing Agile’, you are doing it wrong. Meaning you are probably not doing what you are supposed to do, because it surely is not about meetings … though they do come in handy.
Whatever your business, if your Agile practices are not improving your delivery AND your work/life balance, try to measure what’s not working and go back to the values and principles of Agile.
It is about quality first
First and foremost, Agile is about delivering quality.
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
What does that mean?
It means that whatever you are delivering you must be thoughtful about it, about how you build it, and may be most importantly about how it will be used.
I think my friend and former boss, Rich Loen, founder of InGenius, said it best when he always urged us to build something that is ‘delightful’ to use. That requires thoughtfulness.
What matters most?
The last of the 12 principles behind the Agile Manifesto states:
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Well … that’s nice … but concretely what does it mean?
This is the part about process management. What? Agile includes process management? Only when necessary.
If you are a startup or a very small business with less than 8-10 individuals working in the same office, or close enough to meet regularly face to face (or video conference), you probably don’t need much of a process if you are all aware of everything that is going on.
So, meeting at ‘regular intervals’ is not a thing or a need. You already know or can find out by turning your chair around, and you can address issues as they come up.
If you work in an environment with more people, remote work, multiple teams, …, that is when this last principle becomes crucial to delivering quality on time.
Hey! You’re skipping a lot of principles!
Yes, I am. Not that they are not important, they are. Particularly this one:
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Burnouts are just not good for people or organizations.
Process Management
Over the years, while developing an ‘Agile mindset’, I’ve distilled this down to just a few things that worked well for me and my teams.
Define the process
The truth about process is that the more complex it gets, the more it reduces productivity. In fact, the more people you must coordinate the bigger the loss in individual productivity. And that is because you must introduce overhead to keep everyone in sync.
To reduce the overhead, it is important to formally define the process with the understanding that a process must adapt to changing circumstances and that it should be as simple as possible. Don’t set it in stone, it will most likely change over time.
You will gain productivity if you can develop processes that are task type specific. Some tasks might by nature require more steps than others.
Measure each step in the process
Capture things like how long it took for each step to advance to the next step, capture the actual amount of implementation time as best you can.
Capture what went wrong
Typical retrospective dogma instructs to list what went well and what went wrong. In my experience, listing what went well is far less valuable than capturing what went wrong when it happened.
Cashing in on the problems
If you have clearly defined processes and are capturing time in step and implementation time, charting these values helps surface the bottlenecks in your processes. I also track skipped steps, which can identify steps that provide little value and should be reevaluated.
When your team develops the habit of capturing what went wrong it supercharges your retrospectives because you have something to address right away. And if none are reported then you just cancel or shorten the retro and move on. No wasted time, just doing what is needed lean style.
Wrapping up
The Agile mindset is about quality, speed, pacing, and keeping things as light as possible without compromising on that first principle.
I spent years solving problems and improving processes, building engaged teams that flourish, and delivering quality on time.
I have now put all that experience in building a tool to support this approach that was so successful for me, it is called Louis and if you look it up, I hope you will find it ‘delightful’.