Don’t Judge Agile by the Cover of Its Certification Exam Booklet
There is a distinct difference between something’s form and its true function. To really understand if a technology, tool, method or framework is useful for you, it is critical to study its function, because the form can always change (and in some cases, become misleading). Agile is not immune to such corruption.
Gary Hoberman, the CEO of Unqork, a low-code/no-code development platform, claims Agile is dead. Tech CEOs are known to make bold claims, but the strong unconventionalism of a claim should not be confused with its logic.
Hoberman said:
The reality of agile is that it works for very small deliverables and nothing else. It fails miserably. It fails because business doesn’t know what it needs until it’s in production. There’s always a backlog and it’s always ‘coming’. Also, once they see what’s in production, the problem is time to market. If we use the ‘building a house’ analogy - if they need to move the window to get the exact right lighting, the barrier to moving that window is code.
The interview was taken by diginomica.com, and you can read the full interview here.
How wrong are thee? Let me count the ways.
The reality of agile is that it works for very small deliverables.
This is an accurate statement, but the conclusion being pushed is as far away from practicality and logic as the North Pole is from the South. Agile suggests that larger, complex projects should be the evolutionary outcome of smaller steps, each realigning the immediate reality with eventual purpose, leading to a system which is greater than the sum of its parts.
To understand the essence of Agile, imagine how a good chef prepares a signature dish. They add an ingredient, stir the pot, throw in some spices, and stir some more, all the while paying attention to the aroma, the thickness, and the look of their creation-to-be. The first sign of any deviation from what they expect makes them either start all over again or make the corrections necessary to bring things back on track.
I encourage anyone who believes Agile is for small deliverables to google Google (no pun intended). Anecdotal evidence suggests Google started off with Agile by “doing” it – i.e. following a framework, holding scrums that lasted long, creating documents that wasted time – but one of the most innovative companies in the world realized it was not “being” Agile. It dropped the long scrums, the documentation, and the unnecessary structure it imposed on itself. Google followed the spirit of the concept instead of assuming Agile was a one-size fits all solution. No one in their right mind can ever say Google works on small deliverables.
It fails because business doesn’t know what it needs until it’s in production.
Businesses usually don’t start out on a whim. There is always some profit-bearing value proposition they intend to provide. Any business that steps into the competitive market without having a semblance of its True North will suffer. However, by “being” Agile, a business has an opportunity to go to production with a starter service and, depending upon market response, it can alter its path quickly.
“Being” Agile versus “doing” Agile: Is there a difference?
Yes. “Doing” Agile is the same as following fad diets to lose weight, while “being” Agile is like realizing the truth that a healthy weight requires a lifestyle change and an understanding of the metabolic (and psychological) system.
“Doing” results in blindly following the Scrum, SAFe, XP, DSDM, FDD or (insert term here) Pied Piper. “Being,” on the other hand, forces us to understand the underlying principles of a concept and argue for some of its virtues and against some of its fallacies.
It is human nature to build up heroes to have something/someone to tear down when they become what we wanted them to be. Our contradictory attitude doesn’t change for technology trends, but the beauty of sound logical ideas is they stand the test of time until a truly superior usurper dislodges them. Agile is going through its version of a hero’s journey, having touched its nadir but now being beckoned by the road back.
Above: A Hero's Journey.
Source: Michael Brizeli, Wikimedia Commons. Public domain.
Our Take
Sometimes the only way to explain a concept is to start behaving like an irritating broken record and keep playing it on a loop. I am willing to do that in this instance and will repeat (perhaps for the umpteenth time) a fundamental truth about Agile: It is not a framework, or a tool, or a check list, or the panacea that some might claim it to be. The philosophy of Agile is based on simple yet verified principles of close communication between teams, frequent check-ins on progress, and course correction if needed.
At ITRG, we have worked with many teams that thought they had their Agile basis covered, but working with us showed them they could shed some more restrictive structure yet. They realized they were “doing” Agile when they should have been “thinking” and “being” Agile.
Want to know more?
Implement Agile Practices That Work: Guide your organization through its Agile transformation journey.
Modernize Your SDLC: Strategically adopt today’s SDLC good practices to streamline value delivery.
Connect with one of our analysts to understand how your organization can benefit from:
- Robotic process automation
- Low-code/no-code development
- Automating your SDLC