I saw a post the other day on LinkedIn where someone made the case on how to show value as Agile coaches, consultants, trainers, and leaders.
The article was very math-focused, basically boiling everything down to the following—
Value = (The benefits a client/customer/leader receives – Total cost of ownership)
Then, they provided some value ROI calculations for various roles. All in all, it was a nice, tight argument. The numbers were precise, and the conclusions were telling.
The numbers don’t lie
We’ve all heard this argument or position when folks are speaking about organizational leaders and how they determine value. It’s often arithmetic, algorithmic, and quantifiable. The phrase, the numbers don’t lie or the data doesn’t lie, is usually attached to their perspective.
The Scrum Alliance and the Business Agility Institute partnered on a client survey focused on—Skills in the New World of Work released in October 2023. You can get a copy of the report here.
As a follow-up to the last article I shared on this topic, I thought I’d share something that Jesse Fewell wrote reacting to it.
His reaction was posted on the Scrum Alliance blog, so seemingly in full support of the report.
In it, Jesse highlights three fundamental pivots that agilists should be considering based on the report’s findings. I’ll share my thoughts on each pivot next.
Pivot #1 – Broadcast your bottom-line impact.
This recommendation aligns with the number one human skill recommendation from the report—Communication skills.
The Scrum Alliance and the Business Agility Institute partnered on a client survey focused toward—Skills in the New World of Work that was released in October 2023. You can get a copy of the report here.
The key question on the cover – Which agile skills are most in demand in today’s workforce?
But on page #20, the key question is reframed to – Which skills are most in demand in today’s workforce?
While the questions are close, I’m imagining the “agile” drove most of the respondent thinking.
I would encourage everyone to read it, as it contains some interesting findings and insights. That being said, there are some things in the survey (assumptions, commentary, shared data, and conclusions) that I want to challenge a bit. While the overall tone of this article will be constructive feedback, I don’t want to diminish the effort behind the report.
In a recent Moose Herd the discussion surrounded the release of the report and the impact and relevancy of the findings. How it was something interesting, thought-provoking, insightful, and new. I honestly didn’t read it entirely that way. Instead, I felt it also a bit contrived, self-serving, and old news. Now let’s serially walk through the report for my more detailed reactions…
I’ve been doing agile coaching for over two decades. If there were a Top 5 question I get when doing organizational and leadership coaching, it’s—
How do I set up my teams? Vertical, horizontal, hybrid.
What exactly is an x-functional team?
What about distributed team dynamics?
Are the roles full-time? Or can I share everyone?
How do I handle shared, service-oriented, or platform teams?
For a long time, I wished for a solid reference that I could send to folks when they have these sorts of “teaming” related questions.
Well, the good news is now I do, but it’s not one book. It’s a triplet of books.
I saw this post on LinkedIn the other day from Brian Orlando. I read it and a few comments, which motivated me to write this post.
Here’s Brian’s initial post—
I've been thinking...
In the latest Arguing Agile Podcast podcast where Hemant (Om) Patel and I discuss Peter Drucker's three different types of teams, right near the end we started to talk about aligning #management with/to the appropriate team model.
Anyone who has been involved in an #agile transformation knows organizational design changes are likely required for success (in response to product challenges, changing markets, etc).
I'm wondering why the obstinate resistance to responsive #organizationaldesign and #organizationaldevelopment?
I was coaching someone new the other day. I knew they had a broad and deep non-software background and were pivoting into a Scrum Master role. It was their first job as a Scrum Master, and the hiring company was taking a leap of faith in hiring them. But I knew they had deep skills that would translate into the Scrum Master role and that they would do well.
That is…if…they would stay in their lane.
They had ~20 years of experience and had held organizational leadership roles in their previous companies. Given that, I knew it would be a challenge for them to, how to say it, be a Scrum Master. Especially when they encountered organizational, leadership, and broadly impacting impediments.
They also seemed to have a very proactive, fix-it mindset. I thought this would be hard to throttle in the context of Scrum Mastery in an early-stage and chaotic agile transformation, mainly if they were focused on doing things “right.”
The chicken or the egg
It’s a bit of a chicken and egg problem. Which comes first when transitioning to agile ways of working? Do you re-organize or restructure your organization first – setting teams and roles up for more agile execution? Or do you align your product, application, and workflows into value streams to feed to your teams? What a conundrum.
Ten years ago, I saw most organizations leaning into organizational changes and not putting much thought into the value streams their teams would be working on.
Now it’s flipped a bit, and there’s a strong focus on value streams, probably influenced by SAFe, amongst many factors. And then, the executing organization is composed as an afterthought.
There has been a drumbeat for many years that we need more diversity in the ranks of corporate leadership—particularly women. It’s been increasing in tempo, loudness, and duration, but we still struggle. In this 2021 McKinsey report, women make up only 24% of C-suite roles, and women of color, only 4%--while we’re making progress, indeed, there is much work!
10 Bitter Pills to Swallow About Agile for Leaders
1. Customers don't care if you're agile, waterfall or otherwise.
They care about their experience & that your product helps them. Focus on the quality and frequency of your interactions with customers.
2. It won't solve all of your problems.
Agile isn't a panacea. It'll just expose your problems quicker. The core of Agility is that it builds in feedback loops. It's up to you to learn from them and adjust from there.
3. Telling people, they have psychological safety isn't enough.
You need to demonstrate that people are ok to fail through action, not just words. Celebrate failure, be intentional about creating a safe environment.
