"People won't self-organise around systems they don't understand. People won't make experiments if they are afraid of breaking invisible things." - Kenny Baas-Schwegler (Agile 2019)
ABSTRACT
The Agile Alliance never specified a one-size-fits-all methodology for "doing Agile". Isn't this just a technology story that mirrors the old fable, "The Emporer's New Clothes"? What is the purpose of the Agile Alliance and it's principles and values if there is no underlying methodology? It was not the intent of the Agile Alliance to dictate a specific methodology. Every methodology is unto itself an exercise in planned obsolescence. Waterfall methods supplanted more earlier structured methods and Agile has mostly supplanted Waterfall methods throughout organizations across the globe. It is clear that the agile alliance's goal was to create something that would transcend methodologies and never yield to the next thing, and perhaps even avoid the pitfalls of someone coming along to broadcast to the world, "I have something better: Agile 2.0!" After all, a philosophical school of thought doesn't get replaced or updated any more than a library is updated. The library houses a set of books -- Some good, some not so good -- regardless, a compendium of knowledge is found in the library. Similarly, Agile is rather like a library. It contains ideas, principles, values and some facts, but no specific methods. The methods may come and go, ebb and flow, but the philosophy and mindset of agile is intended to remain constant.
Since Agile is not a methodology, one may want to know what is the value of agile? Can an organization truly change it's value proposition and improve productivity and results by adopting agile methods, by adopting Scrum, Kanban, XP or Lean? Let's decompose and examine the introductory quote of this paper:
1) "People won't self-organize around systems that they don't understand."
2) "People won't make experiments if they're afraid of breaking invisible things."
This is a sage wisdom that many fail to understand. Why is this important? Clearly the statement is intended to emphasize the importance of understanding the subject product or system. There are a few corollaries here:
1) A team is unlikely to succeed with agile methods if they were failing with a prior methodology.
Allowing expert software engineers to self-organize and thereby succeed in their endeavors requires that there is a foundational understanding of the product(s) or system(s) that they build, support and maintain. To succeed with agile, the team must grapple with the underlying and structural challenges that they experienced before transitioning to an agile practice. Failing that the team is rather destined to fail with agile.
2) Simplifying relentlessly is crucial for success in any software engineering endeavor.
Overly-Complex systems are difficult to understand, difficult to build, difficult to maintain and difficult to support in a production sense, thus relentlessly Simplification is crucial for success in any software engineering endeavor. The same is true for agile efforts. There are far too many software organizations that have built needlessly complex software products, simply because the customers have driven the product's complexity over time, and the engineering team has failed to pay attention to the increasing complexity.
As this complexity increases, the product becomes progressively less supportable and ultimately trends toward an inevitable obsolescence.
The above is crucial knowledge for those who would like to adopt Agile methods. Keep in mind that Agile is a philosophy, the characteristics of the Agile philosophy are flexibility, adaptability, and yes, agility. The questions that must be answered are:
1) How can we achieve agility within our team and our project?
2) Are we succeeding with our current approach?
3) If not, what can we do differently?
4) Have we simplified relentlessly?
5) If not, what can be simplified?
In conclusion, it is clear from studying many organizations efforts in adopting agile practices that one of the most significant challenges that organizations face in agile adoption is application complexity. In fact, application complexity is a crucial problem if it appears within any software engineering team. Software Complexity kills team performance, team morale and invariably leads to a myriad of software quality challenges.
If the complexity of applications is a problem within an organization, the enterprise will likely fail with agile adoption.
