This blog article or at least the evocative title caught my eye.
There’s the irony of friendly, nimble agile being cruel and oppressive. It’s an interesting read about business doctrines and the “tyranny” that is created when misapplied methodology gets enforced through authoritarianism.
In the post, author and former Deputy CTO for the White House Jennifer Pahlka makes the observation that agile, in its original and purest form started out as a framework or a collection of common sense principles to guide. But Pahlka points out that in some contexts, agile is evolving into a strict corporate standard that must be carefully adhered to.
What we're seeing
Our own experiences would echo this, agile, like its popular forebear, waterfall, is morphing into another standard that must be prescriptively and slavishly followed.
Debate about whether projects, teams or companies are adopting “proper agile” and the sometimes trite adoption of scrum, stand up meetings and sprints as evidence that agile is being practiced “properly”. Rather than skillfully applying agile concepts at a project-by-project level, there’s talk of what sort of agile should be adopted, company-wide as a mandatory standard. The very nature of agile is that it can’t be consistently applied.
The very nature of agile is that it can’t be consistently applied
One of the tactics suggested by agile guidelines is sprints. The essence of the sprint is to create time pressure with an arbitrary deadline. The theory is that the milestones stop the project sliding and any problems can be flushed out and rectified. This can be a useful technique when other milestones or disciplines aren’t in place.
But if agile is regarded as a set of enforceable rules to be applied to every situation, would sprints work in an operating theatre? Imagine if operating theatres worked in 30 minute sprints. After half an hour the operation is stopped, the patient is sown up, woken up and stood back on their feet before lying back down, opened up again and the operation continued. It's an extreme example to highlight the ludicrous suggestion of enforceable rules when it comes to the indiscriminate adoption of agile.
Designed to fail?
A recent experience for us highlighted the unnecessary cost and risk that is created when enforceable rules don’t work with achieving the best outcome. We participated in a project that was run by a design company. Our role was to re-architect a complex and decade old backend to liberate it from the old UI, positioning it for a new multi-channel future.
The design company was a recent and rigorous convert to their corporate standard version of agile - two week sprints were the declared standard and key to project success.
We understood that with a front-end design, sprints can be an effective way of checking in regularly and bringing everyone along for the journey. When it came to our piece, we were told we also had to deliver the project in two week sprints. When the case was made for a four week sprint it was rejected because it was not company standard. The irony about having “standard agile” was completely missed.
The problem was that the task and resource plans for the IT elements didn’t align with the arbitrary two weeks given.
Most important is being vigilant in ensuring that methodologies do not become replacements for thinking
Our project design was optimised to minimise risk, deliver a bug-free release and minimise elapsed and total time and cost. By stopping development, temporarily patching the loose ends together, conducting a build, and provisioning proved nothing. No one looked at it or tested it because, well, it was unfinished. After spending needless time and money we got back to work. It echoes the operating theatre example - although no human was harmed in this case.
Be agile with agile
At Sandfield, we use methodologies with great care. Most important is being vigilant in ensuring that methodologies do not become replacements for thinking. Misapplied doctrines can easily turn into ideological arguments, which in turn create a fertile environment for expensive mistakes.
The very nature of agile means there is no such thing as “proper agile” or a standard way of executing agile.There are still situations when the waterfall methodology might be the best way of executing a project. An agile mindset values the most important element of any IT project - and that is the people - and trusting their experience and expertise to do the job they have been trained to do. Agile is not a rigid ideology or religion to be enforced through the exercise of power.
