The Dark Agile
As an individual contributor or a manager if you happen to find yourself battling with the question “are we really Agile?” you may feel like this post has been crafted just for you.
DISCLAIMER:
Fair warning! The tone and pattern of this article could be perceived like it is strongly opposing Agile as a practice, but having been in the thick of things myself, working alongside various teams from 17 years up until the last year, there is no room for ridicule here as the advantages are very obvious and unmatchable and they manage to outweigh the negatives hands down.
If anything, this ought to be considered as a prod at the very vitals of teams & members who seem blinded by what those methodologies / frameworks say adhering to it like a gospel truth leaving no room for change or adaption - which in reality happens to be the cornerstone of success for teams
– to emphasize that I’m passively quoting the manifesto here could come in as a pretty rude shock to some...
As much as software products have evolved over the years, the process / manner in which they get built also have been undergoing constant changes, some welcome and accepted worldwide, some not very welcomed and being dropped unscrupulously.
Here’s a timeline chart for your reference:
So, as is evident from this excerpt of an amazing illustration by Tomas Henseler one could only imagine what the journey would hold and how the road would turn out to be going ahead for product development teams henceforth.
Elaborating on the process that’s followed by teams building these products, I don't think I need to get into the nitty-gritty and go down that path describing what “Agile” is, as it is pretty evident and happens to be widely accepted across orgs. early / growth stage startups and multinational corporations alike.
As simple as it is, the motivation behind the Agile manifesto was to coin a novel way to eliminate the lapses in time and cover for variances in schedule over the waterfall model of software development whilst maintaining a sharp focus on delivering value over every release.
But why do you need a framework like Agile?
What’s the chief value addition in adopting to it?
Well! I know how some of the religious followers who meticulously preach Agile would instantly retort & also argue that "it is not a framework, it is more of a mindset".
Well, totally agreed to that train of thought as well.
But, how easy is it to change someone's mindset?
The argument may continue on the lines of, well, that’s why we look for a culture fitment during interviews eliminating those who don’t know what the framework is or haven’t had any experience employing it on a day to day basis.
And if that was the case then the ones who have had first-hand experience working in Agile teams ought to be an instant fit without facing any sort of hiccups (leave alone the problems) in adhering to policies as they join a new organization and become a part of a new team.
But as it turns out, there are plenty of problems reported on a daily basis in adopting to and adhering to Agile principles even if someone carries prior experience.
Why’s that?
Looking at the IT / software / product development market from an Agile lens you’d find it largely divided over 2 major sections carrying contrarian beliefs:
1. Agile practitioners, preachers, followers
For these folks here, mornings start off with thinking about Agile, whether they are Agile or not about anything and everything they tend to do irrespective of the size of the task or impact when the some phrases doing the rounds here may be:
2. Agile non-believers
The non-believers are another lot who don’t think Agile is anything close to a framework, they just hate the very sound of the word and they could be united over terms like:
The basis for the split in mindset of these 2 groups is pretty simple & straight forward:
→ “the focus of teams”
It will be problems galore sans any possibility of reaching a workable solution when the focus of teams shift from “outcomes” to pinning entirely on “process” much like the thoughts covered over this post here.
NOTE: The ones marked❌ are major anti-patterns faced worldwide and ought to strike you as a red flag if you happen to join an organization and get to hear anything on those lines.
Let’s dive down into each of the points using a very basic and common analogy…
1) Following the mandate
Yes, it is only but natural that there is a mandate dictating how people ought to adhere to and follow it, which may as well be the prominent idea the person who drafted it wanted to convey. But how fair would it be if the entire mandate or the individual rules of the mandate were to preempt each and every task that was to be carried out?
Analogy: horse blinders / blinkers
Firstly, did you know the horse has an amazing 350° vision range given the position of the eyes on either side of the face?
These are small pieces of leather usually round, oval or rectangular in shape that go on the side of the horse beside the eyes so as to limit the vision of the animal to a mere 45° in front and enforce it to streamline and maintain focus ahead only on the road, cutting off any sort of diversions whatsoever.
Is that good for the animal?
Ignoring all other issues (employing animals as slaves) and purely given its purpose and the way it has been utilized by humans for years now, may be, yes.
But extrapolating the same example to Agile teams, following the mandate blindly may most certainly prove to be like the horse tack albeit with an unpleasant result that is to divert one’s focus from the main goal. Purpose lost would most certainly mean focus lost, putting one beyond the reach of those outcomes irrespective of what effort goes into it thereof.
Absolutely nothing wrong in following the mandate, but its terrible if work starts and seems to be statically centered only around that mandate leaving absolutely no opportunity whatsoever to incorporate changes, as demanded by the situation.
2) Maintaining velocity
Being agile is sometimes terribly misconstrued to being fast, being quick. No teams or clients would want to wait for an eternity for a delivery or a task to be completed so that they can reach a milestone over their outcomes. Of course, speed matters but should definitely not be the only thing that ought to matter.
Analogy: whips & spurs
The manner in which these artificial aids were used reeks of medievalist traits displaying a brand of authoritarianism.
As is evident the rider whips the animal on the body to forcibly condition it pressurizing or threatening it to move faster which could merely represent the aggressiveness and enforcement of some control.
Extrapolating the same to Agile teams now, it is possible that some managers pin on velocity as a primary metric and tend to judge performance pushing team members forward to either hit a threshold or reach a certain expected number or try and benchmark previous performances engaging them to beat their own record which then transforms into this mad rush leaving everyone celebrating or whining over the relative speed, translating to no tangible advancement towards the actual outcomes and being able to add value to the users.
Speed & quickness is an essential trait to possess, no doubt, but that ought to be a tertiary trait at best for teams to pin on and never should be primary.
Driving fast could literally mean nothing when one doesn’t know where they are heading for.
3) Are we Agile?
When there’s no denying the discipline and stricture adhering to a methodology or internally following a protocol would enforce, there could be far more important questions that are crucial and ought to be asked given the onus teams have on direction, strategy, strategic initiatives & alignment.
Analogy: an obedient well-trained horse
With an enormous focus on a vigorous training routine, the horse would get so accustomed to waiting for instructions all the time becoming a total slave to their commander and may not even move a limb on its own independently.
Love for the animal, petting it is on a totally different scope here, a rather parallel one. The amount of training the animal is imparted to it, the better the level of conditioning one could expect it to hit. But sadly, that could bring with it a few other traits like becoming entirely dependent on its master or trainer.
Extrapolating that, it could never augur well for a person whatever be the team they are on. Given the onus on outcomes for product teams this may as well put them into a deeper retrograde as they may be eventually rendered passive akin to machines that wait for instructions (GIGO), swallow them hook line & sinker, doing nothing else but executing just that weeny bit of a command.
Instead teams & members ought to be starting off with questions like:
what are the outcomes here?
why is this important to us right now? &
what would the impact be / what would this change and for whom?
Outright obedience over nodding “yes” to everything is never appreciable in general and more so product teams in particular for the boss-subordinate relationship between team members & their managers could never augur well & is never the order of the day here
NOTE:
If you happen to be a leader, just a few clarifying questions to understand the things that your internal stakeholders care about chiefly & what teams consider really important ought to be a great start, enough to gauge them & help you make all those necessary tweaks to set them off on the right path.
Remember:
Dark Agile is a reality & the problem here in this case is your teams won’t even know that they have been smitten by that bug, fooled & stung by that serpent & that is going to prove to be more than just enough to lose focus, getting them to stray away from things that ought to really matter & pinning on some vague vanity metrics to say in the least, setting off on a quest to improve them thereof.