Agile In Name Only
Or lovingly abbreviated as AINO, is a label branded unto an organisation that is perceived to be practicing waterfall in the Agile clothing. This usually came out of frustration from the people within said organisation when it imposes things that have waterfall-ish aura to it (deadlines, I’m looking at you…👀).
While the stem of the anxiety does have its merit, it may not necessarily mean that all is doomed.
Yes, it does seem concerning when your manager is trying to control all of the time, scope, and resource dimensions like in the olden days of project management. Isn’t the point of Agile is to embrace uncertainty in software development? (I chuckled a bit writing this as it made me remember one of my colleagues' joke, why IT falls into “exact science” domain, there’s nothing exact about it!).
But more often than not, it is part of the journey, as there is actually no spectrum spanning from waterfall to Agile methodologies. Heck, there are even many Agile methodologies out there; XP, Scrum, Kanban, Scrumban, SAFe, Lean Software Development. Can any of them claim to be more Agile than the others? Be the true heir of Agile throne? If you see where I’m going to, the notion of AINO itself is misplaced to begin with.
So let’s turn this about, and go through some of these perspectives before you give in to the dark side. Remember, only a Sith deals in absolutes.
Agile Is A Journey… And It’s Still Evolving
Do you remember the first sentence of the Agile Manifesto?
No, it is not “Individuals and interactions over processes and tools”.
It is:
“We are uncovering better ways of developing software …”
Notice that the sentence is in present continuous form? It is not in a past tense or past perfect tense which means people have already done it. The notion of the sentence itself is embracing the very spirit of Agile, to progressively, iteratively make something better.. and better.. and better.
This is an infinite game which, borrowing the term from Simon Sinek, means there is no end to the progression. Rules can change in the middle of the game. Players, known and unknown, can join at any time in the middle of the game. And the objective is not to satisfy a certain finite goals, but to stay in the game as long as possible. Meaning, as long as you keep uncovering better ways of developing software, you’re in the game.
Take for example Scrum. It was first published as a paper by Ken Schwaber and Jeff Sutherland in 1995 (after a few years of testing in on the field), made into a book in 2001, institutionalised as Scrum Alliance in 2002, made into a public document The Scrum Guide in 2009, which to date has been revised 5 times.
There is no definitive final form of Agile… nor will there ever be.
There’s No One-Size-Fits-All Method
One thing that people must realise, Agile is not a cure-all, a silver bullet for software development to solve all of its problems. There wouldn’t be many kind of Agile methodologies if it is, right? There is no one-size-fits-all method for everyone. Even the birth of Agile is coming from the realisation that there is no single tried-and-true methodology in software development unlike building construction projects. It is a problem inherent with software development due to the nature of it being a discovery work, not a delivery work.
What the established, institutionalised Agile methodologies can offer is just the crystallisation of best practices tried on the field from several of their contributors and set it out as guidelines or references. Familiar with the Spotify model of Squad-Chapter-Tribe? Well, Spotify isn’t using it anymore. But many other organisations use it as a reference model. Some succeeded, some others were not so successful.
Every organisation is facing different and unique challenges over the time. You have to tweak here and there and see what works and what does not.
“…uncovering better ways of developing software...”, remember?
So perhaps the organisation find it build better software by doing longer ideation phase as if in the old days of waterfall’s Analysis phase? No worries, if it is actually better, coming from your organisation unique experience. It is part of the valuable learning your organisation has gone through to come up with those new, better ways of doing things to overcome its unique challenges.
See, practical Agile is always “AINO” in nature, since it will somewhat differ in practice compared to theoretical Agile, always depending on the organisation's unique situation. But if it works, it ain’t stupid…
Trademarks of Agile Organisations
“But my manager put a deadline to a certain feature release! By no means it is a better way of developing software?”
Now, this is a good time to uncover whether your organisation is actually an old-fashioned factory-minded software development company in the Agile clothing -or- just merely in the middle of its journey towards bettering itself.
Let’s review some of these pointers:
- Do you know why a certain thing is being done in a certain way? Is there shared goals and visions?
- Does your organisation give you enough trust to pave your way to your objective? Is your team empowered to do the same?
- Is there a clear iteration cycle towards improving the way of working over time? Is your organisation continuously learning?
- Is there a channel where you can give feedback? Does your leader act as a servant leader?
- Does your organisation keep evolving its technology architecture, system and tools in order to help with the software development challenges?
Those pointers are briefs from McKinsey’s 5 trademarks of an agile organisation. If the answers are more yeses than noes, then take a relief breath, you’re in for a great journey.
Like to tinker and learn through trials and errors? We might use your quirky mind in our team! Join us in making the next life-centric digital solutions!
References
- https://www.mckinsey.com/business-functions/organization/our-insights/the-five-trademarks-of-agile-organizations#
- https://en.wikipedia.org/wiki/The_Infinite_Game
- https://medium.com/columbus-egg/dear-agile-im-tired-of-pretending
- https://en.wikipedia.org/wiki/Scrum_(software_development)
- https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model
- http://radar.oreilly.com/2013/04/agile-in-name-only.html
