Comprehensive software reviews to make better IT decisions
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.
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.
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
Is it true that everything that can go wrong will go wrong? Don’t bet on it to not.
While Microsoft is not a prominent player in the RPA space now with its Power Automate solution, compared to Blue Prism, UiPath, and Automate Anywhere, its latest acquisition of Softomotive, maker of WinAutomation, demonstrates Microsoft’s dedication to mature and expand its RPA offerings.
Test data management tools offer you the ability to provision, mask, and govern the access and use of your test data, alleviating these manual, laborious and error-prone tasks from your testing, operations, and DBA teams.
When trying to implement Agile as a defined process, Scrum turned BAs or other roles into order takers with the title “product owner.” This undermines the entire value proposition of product management.
Agile systems delivery (implemented through Scrum) is quickly becoming an accepted norm in IT. But using Scrum successfully in an organization requires a deep understanding of how it works and why. For example, many of our members don’t understand the importance of selecting a Product Owner who has three ears.
Reeling from the pandemic response executed by governments all the over world, companies are accelerating their implementation of low-cost automation. That bodes well for UiPath – a leader in RPA aiming to go public this year.
Thor, the Norse God of Thunder, tells Jane Foster, the woman he’s trying to impress, that on his home world of Asgard, the realm eternal, science and magic are two sides of the same coin. Had Jane been a part of the operations teams at Google (or other mature online service providers), she would have immediately realized we have a similar technology right here on good old Earth. We call the science site reliability engineering (SRE), and service level objectives (SLO) is the magic behind it. SRE is a powerful concept for organizations that are serious about keeping their customers happy. It is therefore important for them to develop well-thought-out SLOs and make certain that management is intellectually equipped to derive valuable business perspectives from them.
Hell hath no fury like a customer not being able to access an online service when they want to. They expect the online services to always be on, always be accessible, and always treat them like there’s no one else in the world who matters more. Thank heavens then for giving these online services the ability to use site reliability engineering (SRE) to keep their customers happy, engaged, and most importantly, feeling valued.
Info-Tech members moving to Agile are frequently unsure of the role of PMs and the PMO in an Agile environment. Any organization used to traditional (Waterfall) project management will need to make adjustments in support of Agile or risk losing the benefits.