The good folks at Scaled Agile, the SAFe® community, Agile agnostics, consultants, and some in the “Agile” community are onto something incredibly important in defining the elusive and dynamic Agile End Game for organizations. As organizations move towards the tipping point through their empirical process they will explore and experiment with different ways of working. Or not. Some get stuck. It is our job as leaders and change agents to set those organizations free. Once an organization discovers “Agile” they begin to study and define it from various sources. Unfortunately though there is a reality that is cluttered and confusing to neophytes. Agile thought leaders, businesses, coaches, consultants, and practitioners across the agileverse are in many ways hurting adoption of better ways of working. The progressive and relentless improvement of ways of working and collaboration are being damaged by (our) zealots religious wars and 70+ competing and/or overlapping flavors of “Agile” and/or “high-performance teaming.”
It is important to have meaningful, valuable discussions and debate about thought leadership in “Agile.” But I observe quite often (over many years) some very, very bad behaviour by many people caught up protecting their own turf, business, and profits rather than truly supporting relentless improvement. One need only scoot over to the nearest water fountain a few years ago to overhear strenuous debates about which project management methodology/framework is best (PMBoK, Prince2, and “agile project management” [cough cough]). I don’t want to get into a debate here about which “project management methodology” is best. Mostly because I disagree with boxing up value delivery into a fixed scope and time box called a project. But here we are in the agileverse doing the same thing again. PC vs. Mac. iOS vs. Android. Flip flops vs. dress shoes. Trump vs. Hillary – well you get the picture. For those of us that have moved past the project paradigm into value delivery focus we have to move on to the next step, beyond Agile.
All this observation led me to thinking a lot about The Agile End Game. Which is to point out that we all have spent considerable brain power creating, selling, implementing, and fretting about various frameworks, processes, and methodologies to guide people and organizations. To guide them to ever higher quality, continuous learning, relentless improvement, R&D, experimentation, predictability, innovation and ultimately more successful outcomes. To what? For the Agileverse there are a few big players doing this quite well. The Manifesto for Agile Software Development. XP. Scrum. The SAFe. DSDM, LeSS, Nexus, Lean, Kanban, RAD/JAD, TDD/BDD/FDD, Crystal, DaD, Scrum@Scale, Enterprise Scrum, et cetera. I’m certain all of these have had varying degrees of success across many organizations. Some more success than others. All have also been implemented poorly and failed. None that I can think of are inherently and absolutely terrible.
However, none of the scaling frameworks, methods or processes out there discuss the Agile End Game. The very nature and purpose of their existence is often cited as getting people and/or the organization to a better place. But they never describe the “better place” very well. I feel like I need a Dave Snowden moment – that’s crap!
At the end of the day, businesses exist to create wealth (good and services) and profit for shareholders. And we can presume that most if not all of the “Agile” frameworks, methods, and processes exist to help businesses. I don’t know of anyone working for free in the business. As a business owner and consultant I am sure to want to know the ROI of anything that my businesses resources are invested in. This brings us back to the Agile End Game. Agile prescribes a value system and principles. It doesn’t describe the end game. The Agile End Game for organizations [businesses] should be about the creation of a dynamic, complex, simultaneously simple and most importantly – ever changing adaptive system. With the inherent ability to behave and act in simultaneously simple, complicated, and/or complex ways while consuming simple, complicated and complex problems. And in the end generating high-quality, and successful outcomes for customers.
We should be helping our Agile customers define their unique Agile End Game. First, before we choose a tool. And not fighting over which size of hammer to hammer the nail in with. I’m looking at you, tool. Each customer is going to have different needs, resources available, and commitment. Choose wisely.
As for specifics, I believe the SAFe is one of a few great tools to scale agile in an organization. In Dean’s own words (paraphrased), “We’ll keep doing it this way until we learn a better way.” The evidence of this is proved in the versioning and commitment to community development of the framework. The SAFe has modularity built-in with the creation of Essential SAFe and the optional three level SAFe (collapse the value stream). The fractal patterns of scaling are built into the framework with Agile Scrum, Kanban, backlogs, cadence and kanbans. These are critical for organizations adapting and innovating beyond the SAFe. Lastly, the SAFe provides best practice guidance — not prescriptions. While allowing for less experienced organizations to start with the models in the framework as prescriptive guidance, they can adapt and innovate (Shu Ha Ri) as they mature in skill and experience with Agile. The SAFe doesn’t have to be complex to implement with Essential SAFe addressing the team and program levels.
I am interested to learn more about The Agile End Game from you and your thoughts. Please have the conversation. Respectfully. Collaboratively. Working together on the idea. Acknowledging that our thoughts may, and probably should change as we move forward to the end game.
Enterprise Agility Coach
Big Lake Software
A fractal is a mathematical set that exhibits a repeating pattern displayed at every scale.