If you’re an engineer I can already hear you letting out a sigh.
As long as I’ve been in the world of building software I’ve heard the term “agile” and I’ve never really dug into it too much.
It’s always had connotations of “work” and project management and, to be honest, Jira.
Yuck!
It was only recently when someone shoved the core principles of the Agile Manifesto under my nose that I thought to take a closer look.
If you haven’t come across the Agile Manifesto before, you can find it on a website that appears to be unchanged since the 90s. It’s gloriously old school.
But the words are as relevant as ever. If anything they feel more relevant and important.
For convenience, here are the principles, with a little interpretation of my own.
Satisfy the customer
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Satisfy the customer. Satisfy the customer.
If nothing else, this is the most important principle of all. If this was the only principle, and every single organisation and individual adopted it, I think software would be perceived in a much more positive light by people. And I think we would perhaps have a lot less, but better, software.
Embrace change
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Changing your mind when new information emerges is a good thing.
Working software in weeks
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
I'd argue this should now be hours, or days, in the age of AI.
Don't ignore the business
Business people and developers must work together daily throughout the project.
By "business" people I'd include customer service, marketing, sales, and leadership.
Trust motivated people
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Speak to each other
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Technically Google Meet and Zoom are face to face. But nothing beats being in person.
Actual working software is the priority
Working software is the primary measure of progress.
Yes you can get a fancy dashboard to measure user numbers, activity, and more. In fact, I am inclined to believe analytics can be very helpful! But don't lose sight of the top priority: working software.
In an age of tokenmaxxing, and having witnessed previous phases of optimising for "lines of code written", this feels like a rather important goal to keep in mind.
Sustainable development is sustainable
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
You can only move fast and break things for so long.
Being agile doesn't mean shipping junk
Continuous attention to technical excellence and good design enhances agility.
Sometimes it pays to go a little slow to go fast.
Simplify
Simplicity — the art of maximising the amount of work not done — is essential.
I have believed for a long time that simplicity is a war and it's worth fighting for.
Top-down is rarely the right way
The best architectures, requirements, and designs emerge from self-organising teams.
I must admit I don't completely "get" this one in its entirety but I didn't want to leave it out!
Take a moment to reflect, then improve
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
If you work in a team you have probably done a retrospective at some point. The thing that often gets overlooking is to make adjustments and tune things for the future.
Go forth and be agile...
Are these ideas mostly common sense? Yes.
Do most companies and most individuals who build software truly and fully adopt these principles?
I’ll leave you to be the judge of that.