Aug 23, 2019
All politics about fake news aside (PLEASE!), I’ve heard a growing number of reports, sighs and cries about Fake Agile. It’s frustrating when people just don’t get it, especially when they think they do. We can point fingers and vilify those who think differently—or we can try to understand why this “us vs them” mindset is splintering the Agile community. After all, isn’t that what a true Agilist would do: take an empirical and collaborative approach?
Why this divide in thought within the Agile community? Quite simply, because someone has something to gain or lose. If the other guys aren’t Agile, then I’m the consultant you need to work with. Or maybe I have the certification you need to obtain. Or maybe it has nothing to do with following the money and revolves completely around my ego as a thought leader. Or maybe it’s as simple as pushing people beyond their comfort zones.
Sincere Agile practitioners can get caught in the crossfire as they defend the practices of their chosen framework. What we need to remember is that Agile is a mindset, fueling whatever toolset is needed to deliver value.
Understanding the Agile Mindset
What is an Agile mindset? Since the Agile Manifesto was penned in 2001, the general consensus is that this list of values and principles describes agility. Today, traditional Agilists are reluctant to steer away from the software development focus of the Agile Manifesto, despite a growing desire for business agility, the increasing availability of collaboration tools, and the ubiquity of video conferencing. This presents a serious problem—if Agile leaders don’t tweak the manifesto, something else will fill the gap, potentially creating a radical departure from the essence of the mindset.
Let’s look at “Understanding Fake Agile” by Steve Denning, published by Forbes in May 2019. In his article, Mr. Denning demonstrates his thought leadership ability as he tries to redefine the Agile mindset to encompass business agility. He suggests that the agile mindset is made up of 3 components, or “laws,” with Law of the Customer being the most crucial:
- Law of the Customer – an obsession with delivering value to customers
- Law of the Small Team – all work is carried out by small, self-organizing teams
- Law of the Network – an effort to eliminate bureaucracy in favor of an interacting network of teams
While these laws correspond with being agile, agility is not about these 3 laws; rather, the Agile mindset is about delivering value through the healthy interactions of people responding to a changing environment, and helping others to do the same. People create value, and people consume value. They are not mere resources as objectified like Henry Ford’s alleged comment: “Why is it every time I ask for a pair of hands, they come with a brain attached?”
The Pitfalls of Misunderstanding
After describing his (mistaken) idea of the Agile mindset, Mr. Denning writes: “The challenge of genuine Agile is how to descale big monolithic, internally-focused systems into tasks that can be run by small self-managing customer-focused teams.” While this conclusion is consistent with his re-definition of the mindset, it completely misses the mark in a couple ways.
First, Agility empowers people to determine their own tasks to accomplish a valuable goal, rather than simply implement tasks defined by others. The knowledge worker is a smart and capable person who needs to be unleashed in delivering value rather than relegated to accomplishing task assignments. Efficiencies are gained when people are empowered to solve a problem and implement a solution. Secondly, and looking back to the Agile Manifesto, the authors unanimously agreed that the highest value was “individuals and interactions.” Since enterprises are built around many individuals, who are reliant upon each other to execute a common mission, the real challenge is how large groups of people can interact to deliver value.
The Value of Alignment
One of the modern paradoxes of Agility is a natural tension between autonomy and alignment. A couple years ago, I had a long and inconclusive discussion with another Agile coach about this tension and which was more important. Neither of us could convince the other whether autonomy or alignment should be valued more. However, we had a healthy dialogue that allowed us to interact well with trust and understanding. His concern for the individual and the intrinsic motivation of the knowledge worker led him to value autonomy more than alignment. It’s a valid perspective, but I expect that the tension between autonomy and alignment will continue to exist in Agility just as it has within every culture through the ages. It’s like a joke I saw decades ago: “Individualists unite!”
My respect for people and their healthy interactions has led me to value alignment over autonomy. We are better together and can achieve greater accomplishments when we align on a common mission. When teams work in isolation, they are often working at odds with each other, which is neither healthy nor productive. This is where Agile at Scale addresses a need. One reason Agile took so long to reach critical mass was that the initial small-scale frameworks seldom considered interactions outside of the Agile team. It worked great in small start-ups or in teams that were given special license to work in isolation, but there was no way to help teams collaborate toward larger goals.
There are now different ways to scale Agile, and the Scaled Agile Framework® (SAFe) is one of them. I see value in the framework not because I’m a SAFe Program Consultant (SPC). Rather, I’m an SPC because I see the value of SAFe. It continues to evolve in order to address the needs of people in large enterprises, just as any custom software application evolves to meet a changing world.
Assessing Agility: Instantiation vs Framework
Mr. Denning makes a huge error in his estimation of SAFe, calling it out as “Fake Agile.” He states: “[SAFe] is now pervasive in large firms because it gives the management a mandate to call themselves agile and keep doing what they have always done.” An organization may call themselves SAFe, but his description of a SAFe implementation is more in line with what he rightly calls a “Stalled Agile Journey.” An incomplete instantiation of the framework would not be SAFe. It would be similar to looking at a team that waterfalls the iteration and concludes that Scrum is a poor framework.
The mistake of many Agilists on a stalled journey is to declare defeat rather than engage people on the continuing journey. So (1) a stalled implementation is not Fake Agile and (2) the stalled implementation needs to be re-energized. The transition needs to be put on the fast track to Agility.
Although Lean Portfolio Management (LPM) was part of SAFe before Mr. Denning’s article was published, perhaps he would have taken a different perspective if the SAFe LPM class had come out before his article. When the financial controls of an enterprise are stuck in old ways of working, management needs to correct the outdated system to facilitate Agility. The ever-evolving Scaled Agile Framework addresses this need with LPM rather than giving up in despair. Relentless improvement is a pillar of the Lean mindset in SAFe.
The Final Question
Finally, Mr. Denning ends his appraisal of SAFe with a question I’d like to answer: “why would anyone with a genuine Agile mindset be using SAFe in the first place?” Quite simply, because when SAFe is implemented correctly, it is not a fumbling set of hypocritical practices, but a Lean-Agile mindset fueling a framework to help groups of teams be transparent, align, execute with excellence and deliver quality solutions of measurable value. And if it hasn’t reached that point yet in the organizations you’ve worked with, how can we collaborate to improve?
copyright ©2019 Mitch Malloy (http://go.bw-e.com)
