As with all abstract solutions, expectations are always set too high toward unachievable goals with Agile, SCRUM, and DevOps. In the absence of a definitive endpoint, requirements management and application development are simply stepping stones along the way. Agile is a mindset, not a certification exam.
It’s always more exciting than it really is…
Agile, SCRUM, enterprise architecture, digital transformation and even cloud computing are all talked about as if they will save the company a fortune, generate new revenue and, oh my god, change the world. Non-technical executives are sold business cases written by technologists, and they proceed with unjustified optimism – SCRUM and DevOps, Agile’s cousins, are the focus this time.
It’s safe to say that agile projects fail more often than any other type. Despite this, we continue to promote “Agile” as a panacea: “Everything would be perfect if we only had an Agile environment, an Agile team, and executives who supported Agile transformation.”
There have been numerous Agile failures, and a cottage industry has sprung up to try to explain why this keeps happening so frequently. SCRUM and DevOps are the next two options. Their failure rate is also high.
What’s Wrong With Abstractions?
Nowadays, everything is an abstraction. Is there a limit to the number of “existential threats”? Relativism, one of abstraction’s enforcers, is always present, making things better or worse depending on the goal of the solution of the day. Let’s not forget that. Consider the case of COVID-19. The US has done a great job based on the assumption that the US knows how to solve “enterprise” problems. Relativism, on the other hand, destroys abstraction: the United States is home to 4% of the world’s population and 25% of its deaths. Even though they sound great on paper, how many technological solutions actually fail to live up to their promises?
In the Agile family, requirements management and timely, cost-effective software development are addressed in an abstract way. It is, however, far too common for the context to fail. As a result, the field has been constantly inventing methods, tools, and techniques to manage requirements and develop applications, including rapid application development (RAD), rapid prototyping, the Unified Process (UP), and extreme programming (XP), to name a few. The Manifesto for Agile Software Development absorbed all of the “new and improved” requirements/development methods, tools, and techniques into a new and improved requirements management and applications development methodology. Another approach to software development, SCRUM, was developed in the mid-1990s as a subset of Agile. There are a number of SCRUM techniques that developers have tried for years (or even months) but have had mixed to poor results in their efforts. Even in the current era of managed services and the proliferation of “software as a service” delivery models and low code/no code delivery platforms, DevOps – Agile’s second cousin – has a history of failure.
Then, where does that put Agile?
It’s important to maintain a disciplined mindset, and being agile is a great way to do that. Requirements and development are assumed to be volatile. It acknowledges the difficulties of growth. As a result of this lack of understanding, application design and development is a near impossibility, and it should be acknowledged as such. Please, can we just admit that we have no idea how to create perfect or even near-perfect software applications? Do you believe that applications, like vaccines, get better with use and time? What if the next step toward an imaginary destination is just another step in the process of getting there? Perfect or near-perfection are the goals of every method, tool, and technique we’ve devised over the years. The desire for perfection, on the other hand, is downright destructive due to the fact that it is both time-consuming and draining, to say nothing of the other unpleasant realities that come with it. There are a lot of misconceptions out there about how to use tools, techniques, and frameworks, and they will continue to be misunderstood until they are contextualised as just steps toward “better.”
No, Agile should not be like a CPA exam in which every step must be followed to the letter. All abstract solutions, including Agile, SCRUM, and DevOps, suffer from unrealistically high expectations, making it nearly impossible to meet them. In the absence of a definitive endpoint, requirements management and application development are simply stepping stones along the way. It’s important to remember that each step is merely a step in the process of gaining an understanding of ever-changing requirements and developing software applications that meet additional requirements that, over time, may approximate improvement. Because of the uncertainty, uncertainty, and high cost associated with the current requirements management and software development processes, it is possible that Agile can help alleviate some of these issues. In order for it to be effective, it must be broken down into a simple formula that can be easily understood. Rather than being used as a tactical guidebook, Agile should be used as a long-term commitment to incremental discipline. A top-down approach to agile is preferable to a bottom-up approach. Companies that use “Strategic Agile” have a better chance of success, but those that insist on “Tactical Agile” are more likely to fail. The term “masters” is often used to refer to architects rather than engineers.
No Comment! Be the first one.