“The Business” vs. “Scrum” — Image via Midjourney from an author prompt.
Blaming “clueless” business people simply won’t cut it any longer
“Agilists Will Need To Embrace a New Strategy If Agile is to Survive” originally appeared on my Medium channel.
I’ve been involved in five Agile Transformations over my 10 years as an Agile consultant, coach, and trainer.
The engagements spanned multiple consultancies, and these are some reflections as I’m now on my third Agile Transformation in the past 5 years in-house at KeyBank, one of the top-20 U.S. banks.
I started my Agile journey by focusing on all the wonderful things Agile and Scrum could do for an organization.
Just start “being Agile,” and everything would be great!
Agile off-track?
But I wondered why many of the organizations that had undergone Agile Transformations weren’t doing much “better.”
Despite the fact that Agile processes may or may not have been present to a greater or lesser degree, it was clear the same business problems were still there.
Agile’s grounding in Extreme Programming (“XP”) started from a focus on technical excellence. But over time, I’ve seen Agile lose its grounding in the craft of coding, and become just another project management method.
Worse, I’ve also seen it veer down a path towards a form of “faith,” where “true believers” tirelessly quote “doctrine” — The Agile Manifesto & The Scrum Guide.
Why Agile?
In early 2023, perhaps taking their cue from Elon Musk’s radical staff cuts at Twitter/X, CapitalOne eliminated every “Agile” role, cutting over 1100 jobs, sending shockwaves throughout the tech world.
Coupled with this, there continue to be scores of layoffs across all Agile roles.
And this leads me to wonder whether Agile practitioners have been focusing on the right problems.
Becoming “Agile” was never the point
And I believe we’ve all been asking the wrong question all along.
One only needs to look as far as Nokia’s spectacular failure even as they achieved the largest “successful” Scrum transformation ever. It’s painfully obvious just “being Agile” won’t help organizations achieve anything.
Agilists typically start by seeing every business as “cursed” by a Waterfall mentality, waiting for them to come and “save” them. For an agilist, there’s no bigger problem facing business than their “non-Agile” delivery method.
But despite what many people selling Agile certifications, SAFe implementations, training, coaching, and services will tell you:
Businesses don’t have any “Agile” problems –
But they DO have business problems that agility may be able to help solve.
Quite simply, if Agile is to have a seat at the table, it needs to start pulling its weight. How?
They can begin by taking a cue from Design Thinking, and build trust by understanding their customers.
Read this, and maybe you’ll understand
Agilists’ most frequent complaint is how the business people they work with don’t get “it” — while neither giving them credit for what they do know, nor trying to understand and learn from them.
I’ve witnessed some fairly surreal situations where Agile practitioners have quoted Agile literature to stressed business leaders working on tight timeframes, saying:
“You’re doing it all wrong — your dates mean nothing. You have to forget everything you know and do it the way I’m telling you. Here, read the Scrum Guide, watch this video.”
Or are Agilists not listening?
In a misguided attempt to “set them straight,” many agilists share information with business leaders that only appeals to other Agile practitioners.
To most business people, these baffling shares only serve to confirm how out of touch Agile people are with their true needs, further eroding trust.
But if you ask agilists what role senior leadership should play, they’ll say some variation of “sign the checks, empower the teams, and get out of the way.”
Not only will business people be put off by this kind of message, it hardly seems a good way to build trust and collaboration.
Building trust to gain credibility
I would invite agilists to go first and prove they deserve the trust and can be a collaborative part of solving real business challenges.
To do that, they’ll need to make three important shifts:
- Start with empathy for the business leaders they’re supposed to be helping
- Be open to what business leaders do know
- Learn the mental models & language of business
#1 Start with empathy for the business leaders they’re supposed to be helping
As part of Agile’s shift from technical excellence to human-centered ways of working, Agile practitioners have long emphasized caring and empathy.
But how much effort have agilists put into understanding the very real business challenges senior executives and middle managers face daily?
The hungry HiPPO?
I think Productboard is a great app, and they have a top-notch team, but this section of their website is actually devoted to “The Dangerous Animals of Product Management.”
While amusing on some level, it unfortunately represents exactly the kind of thinking that further divides the Agile and Product communities from the business people they need to collaborate with on a daily basis.
No attempt is made here to understand why business leaders might be responding in these ways.
Cultivating Empathy
Instead of condemning with name-calling, we would all be better served by connecting with them as people and listening.
This can go a long way towards helping us understand why business people react as they do, and open the door to greater trust and collaboration.
“…we need to cultivate controlled empathy– a purposeful and directed attempt to understand others and their experiences. A curiosity about others, and a desire to see the world as they do, is key if we hope to truly collaborate and to leverage a diversity of views.”
Riel, Jennifer; Martin, Roger L.; Creating Great Choices (p. 49–50). Harvard Business Review Press.
Seek first to understand
Instead of dismissing these leaders because of they’re not “being Agile enough,” this is an opportunity to step back, listen, and learn from their perspective.
What problems, pressures, constraints, and concerns are they under? What have they seen work? What doesn’t work?
Generative interviewing
Asking simple generative questions like
“Tell me about a time you were able to bring the teams together to deliver great software that met your user and business goals on a tight timeframe.”
Or even,
“Tell me about a time when you had a Program that wasn’t delivering, and some things you tried.”
And then sit back and listen.
Provided you’ve done the initial work of connecting with these leaders as people, deeply listening to them share these insights will provide both a wealth of information as well as build trust.
#2 Work to learn and understand what business leaders do know
How work really gets done
From their vantage point in the organization, senior leaders can see how different parts of the business come together to deliver larger chunks of value.
The fact they’ve arrived at that level means they’ve also demonstrated the ability to nurture and manage relationships both horizontally with their peers, and vertically, with their leadership across the organization,
Every company lays out their hierarchy in an official “org” chart.
And then there’s how work really gets done in business, the “shadow” organization. It’s all built on networks of relationships, trust, and favors.
Learn who the right people are, what they do (and don’t) respond well to, and how to develop effective working relationships with them.
#3: Learn the mental models & language of your business
This is probably the biggest gap I’ve seen with many Agile practitioners.
They claim authority to “coach” business leaders and executives, but are unable to relate to how these leaders see the world, or speak in ways that connect with their reality.
Here are two ways to do that.
How does your business produce value?
One important perspective experienced leaders or managers can give is to help understand how value is created in their industry.
For example, after five years in banking, I’ve learned there are just four key ways banks create value through:
- Storing capital and value
- Lending capital and value
- Moving capital and value
- Providing advice around financial matters
Understanding that provides a helpful foundation for the countless decisions that go into designing, building, and delivering great software-enabled user experiences.
Learn what value looks like for your industry
While it boils down to a simple set of ideas, it’s a crucial starting point.
Understanding this, together with caring about and understanding leaders’ deeper day-to-day challenges, is crucial to anyone’s ability to coach people and teams across all levels of the organization.
Value matters. What’s it look like for your industry/vertical?
Understanding levels of empowerment: The Ladder of Responsibility
While many agilists lecture business leaders to “empower the teams” without any clarity on what that means, there’s actually a framework for understanding what that levels of empowerment can look like in practice.
One clue can come in understanding the Ladder of Responsibility.
Originally shared in his book “The Responsibility Virus,” Roger L. Martin evolved this model to address one of the most dysfunctional dynamics in business:
Either you’re in charge, or I’m in charge.
For the first time, Martin offered another way to understand gradations of responsibility, while laying out what the next step upward might be to open the door to higher levels of both collaboration and empowerment.
The ladder of responsibility for software teams
I’ve adapted Roger L. Martin’s original ladder for a software team environment:
Here, where we’re assuming you have a fully-staffed, cross-functional team including Product Management, Tech Lead, and UX designer, together with engineers and anyone else necessary to continuously design and deliver increments of working, tested software.
The benefits of laddering
By laying out a Ladder of Responsibility designed for your context, we’re able to do three key things:
- Take advantage of the leader’s business expertise, horizontal alignment, and understanding how larger parts of the organization come together to create value
- Take advantage of the team’s closeness to the end-user client
- Make the most of the team’s expertise in Product Management, UX Design, and Technical Architecture
There may be details of software interface implementation or technical architecture the UX or Tech Lead might be better suited to make.
By understanding where the individual members of the team might be, and what they might be ready for, allows both the leader and their teams to collaboratively arrive at higher-quality decisions that can actually be implemented.
Some teams, for certain decisions, may be immediately ready to be higher up on the ladder, closer to #1 on the ladder of “empowerment.”
But it’s not a situation of blanket empowering all teams and “hoping” they’ll figure it out
Orchestration, conversation, and collaboration and visualizing these ladders can provide huge benefits to get the best of both leadership and team efforts.
Most aren’t ready
Many Agile teams, and the “Agile” roles that lead them — Product “Owner,” Scrum Master, Agile Coach– are simply unready to take on the responsibility of empowerment.
Your Ladder of Responsibility may look different, given your leader’s area of expertise, and the nuances of value creation in your industry, and software design and delivery.
Learning this mental model, and designing what it looks like for your context, will help both leader and team to understand what the next step in your “Ladder of Responsibility” looks like, and the true path to empowerment.
Give us $$ & “Trust” Us
And it’s not telling teams to go off and take months to figure out what to build.
Remember the team’s closeness to clients gives them the advantage of understanding what clients will respond to, and can quickly test and iterate ideas and review and validate or disprove assumptions through Dual-Track Continuous Discovery and Delivery.
Regular Client contact is key
But teams that don’t have regular cadence of client exposure and feedback won’t have anything for them to base their work on.
It doesn’t matter whether your client is internal or external — a foundation of better decision-making is grounded in creating regular client touch points, listening, and adapting.
Share regularly what you learn upwards to leadership in structured ways.
Show how it’s informing and improving the quality of choice-making.
Show you’re empirically basing your decisions on better understanding how your solution addresses client problems so you can take a step up to the next level on the Ladder of Responsibility for you and your team.
TL:dr;
Ultimately, the goal isn’t for business people to get out of the way, and their organizations to drop everything and magically become “Agile.”
The goal is for collaboration to solve business problems and create agility.
We can enhance decision-making through regular client contact to inform experienced Product Management and UX design. This will allow us to collaboratively discover and deliver better client experiences and ultimately, value delivery.
We can start by understanding where we are, and targeting the next level up in our Ladder of Responsibility.
References
Roger L. Martin: The Responsibility Virus
https://rogermartin.medium.com/strategy-and-leadership-3-f8a219bc403c
https://www.producttalk.org/2022/12/customer-interviews/
https://www.linkedin.com/pulse/guaranteeing-failure-your-agile-devops-transformation-mik-kersten/
You must be logged in to post a comment.