I consider myself an Agilist. I have been working within the Agile software development realm in different capacities/roles since 2008 and I whole-hardheartedly believe in the potential of Agile and Lean to dramatically improve, not just software/systems development, but also organizations that sponsor IT capabilities development. I believe that the success and ongoing effectiveness of any Agile implementation depends on closely hewing to the Agile Manifesto and the 12 Principles of Agile Software.
Now that I have firmly declared my commitment to Agile principles, I differentiate myself from those whom I refer to as “Agilistas.” In my definition of the term, an Agilista is someone who takes a binary, black or white view of what is and is not “Agile.” Believing that deviations from Agile practices they have learned and practiced cannot be Agile, some Agilistas stifle change and innovation in the Agile domain.
Others are strict literalists who treat published Agile best practices as instruction manuals that must be followed, to the letter, in every situation, regardless of the realities/constraints imposed on/by projects and organizations. They wish to ignore or change factors external to software/system development concerns to fit their “pure” Agile implementation.
Still others confuse attempts to enforce engineering discipline and address complexity in large-scale software/system development efforts with establishing burdensome and unnecessary processes and documentation (i.e., bureaucracy).
Many Agilistas decry “Agile frameworks” and “Agile transformations,” feeling that methodologies that go beyond the established canon of team-level Agile practices and techniques are inherently anti-Agile. In their minds, “proper” application of the canon, in the “proper” spirit, with coordination across teams via Scrum-of-Scrums (in the case of Agile-Scrum) is all that is required and desirable.
Too often, this desire to keep Agile simple and pure leads to exhortations that others “think” and “be” more Agile, without proposing how to do that in the face of technical, programmatic, compliance, and fiscal realities that constrain and shape all non-trivial system development efforts.
I am sympathetic to the frustration that leads to this brand of reactionary thinking. For a couple of decades, Agilists have had to witness and, sometimes, take part in failed Agile implementations misinformed by Waterfall software/system development prejudices and undermined by an unwillingness on the part of organizational leadership and stakeholders to embrace what I call Agile Zen:
The primary role of management is to empower those who actually deliver value to the customer and to create work environments and customer relationships within which these “value providers” are able to succeed and flourish.
No amount of Agile process mechanics, training, management tools, DevOps tooling, etc. will bring the benefits of Agile to organizations that ignore this maxim. Unfortunately, often it is not just ignored; it is outright rejected by leadership incapable of shifting towards a “servant leadership” orientation. Adoption of an Agile software/system development approach within an enterprise requires alignment between the work performed by Agile software teams and the program and portfolio level organizations that form and sustain them. In other words, Agile development becomes a forcing function for change throughout the enterprise.
This is why I am excited about SAFe. It is a framework for scaling Agile practices to the scale of hundreds of teams while adhering to Agile principles, enforcing engineering rigor through systems thinking, and ensuring long-term continuous improvement and ROI through the application of Lean principles. It includes and fosters approaches to Agile program management and governance based on Agile principles and addresses real-life enterprise/organizational concerns without sacrificing those principles. The future of Agile is in Agile scaling. I hope the Agilistas will embrace it.
Last Updated on February 2, 2022