I was having an email conversation with an agile coaching colleague the other day. In one of her replies, she said the following:
BTW I really like the way you articulate your concerns about the agile community at large. It’s helpful to share with my leadership and customers as we try to navigate a very messy space of certifications, frameworks, and competing agile voices
The final point she made really struck a chord with me. The notion of competing agile voices.
It made me realize that, YES, there are many, many agile voices today. And one of the real challenges is to figure out who to listen to. Where’s the value and the experience? And how to avoid the “noise” or how to separate the wheat from the chaff?
I want to share some ideas around this challenge. No, I’m not sharing any secret filter or the 1-person to listen to. They don’t exist.
But I do want to share some advice for handling the high voice count and how to become a more discerning listener when it comes to the noise.
And it’s getting worse…
Joshua Kerievsky recently wrote a post entitled Eliminating the Product Owner role. As of December 3, 2018, it had received 766 likes and 162 comments on LinkedIn.
https://www.linkedin.com/pulse/eliminating-product-owner-role-joshua-kerievsky/
The opening premise of Joshua’s article is here:
Before I get into who or what would replace the PO role, let me offer a bit of background on this group. Three coaches, including myself, had assessed this group prior to beginning work with them. Our findings were typical:
Too much technical debt was slowing development to a crawl
There was insufficient clarity on what needed to be built
The developers spent little time with their Product Owner
The team was scattered around a building, not co-located
etc.
When you perform numerous assessments of teams or departments in many industries, you tend to see patterns. The above issues are common. We've worked out solutions to these problems eons ago. The challenge is whether people want to embrace change and actually solve their problems. This group apparently was hungry enough to want change.
So, springing from this problem statement, Josh makes the point that if you:
Dan Mezick wrote about the Agile Industrial Complex in this article. It’s inspired me to respond with this one.
Personal Aside
I really like Dan’s work. It’s truly inspirational to me. There are folks who are leading some different thinking in the agile community, swimming upstream if you will, and Dan is certainly one of them.
Dan is expert in Open Space. He’s also introduced the notion of Open Space Agility as a means of introducing agile to organizations. One of the hallmarks of OSA is the aspect of invitation. In OSA, folks are not told to be agile, they are invited to be part of crafting the organization transformation to agility.
In other words, they’re a part of it. It’s inclusive.
Now moving on from my bromance with Dan…
There is the notion of – The ONE Metric that Matters. I want to translate that metric into the agile transformation space.
You could also replace agile transformation with:
Lean Change Initiative
Agile Adoption
Digital Transformation
DevOps Strategy
Organizational Agility
I know, you’re heavy with anticipation. What IS the ONE Metric?
It’s engagement vs. disengagement. That is, how are your leaders affecting the engagement of your teams as they shift the organization towards more of an agile approach?
Another way of looking at it is this,
If the leaders are engaging and pulling their team members into the process of the transformation. Asking them instead of telling them, then they are engaging;
However, if the leaders are more telling them what to do, deciding which specific agile frameworks and tools will be used, and then telling them from “on high”, then they are disengaging.
Of course, it’s not quite as simply as this, but you certainly get the idea.
I read an article by Angie Jones the other day entitled - 7 Habits of Highly Effective SDETs. If you know me, you know how enamored I am of Steven Covey and Angie, so I read it with great anticipation.
And indeed, it was a great piece that focused on the evolution of testing and the testers role.
But it also made me think about testers in a different way. A melancholier way. It reminded me of the song, Where Have All the Flowers Gone, by Pete Seeger. It’s a very dated folk song written in 1955. A year before my birth ;-)
Not that long ago, I wrote a blog post that was inspired by Kim Scott, the author of Radical Candor. She had written a very brief note around a leader’s responsibility to receive feedback, as well or better than, they are at giving feedback.
And many leaders, to put it mildly, suck at receiving feedback.
And you want to know another surprise? Most of them are unaware of this blind spot. They think they’re great listeners. But they’re not.
They are simply not self-aware!
Frankly, I’m tired of all of the scaling frameworks. They’re mostly driven by three needs:
Creating revenue for the firms creating them;
From a company or organizational perspective, they’re indicative of lazy, buy agile in-a-box, thinking;
And they feed the “certification happy” nature of our community.
And yes, I too am guilty of falling into the above traps.
I think the introduction of Scrum@Scale has ticked me over the edge and inspired me to write this post. That and reading this article by Neil Perkin, which takes a more reflective view to leveraging useful bits from the various scaling frameworks.
There are individuals who have influenced my professional journey significantly. Sometimes, by working with me directly. Other times, by their writing or position in our software community. And other times, simply as a role model.
I've started a segment on my blog called – My Heroes. I’ll post intermittently, perhaps every 1-2 months. But it serves as a reminder to me to be thoughtful and appreciative of the folks who’ve influenced my growth and skills. And of course, they get none of the credit for my many foibles.
The fifth one up is actually a pair of individuals.
In 1994, close to 25 years ago, Dorothy Graham & Tom Gilb authored a book entitled – Software Inspection. It became the de facto standard guidance for how to conduct artifact and code reviews for software development.
Now that doesn’t mean we “got good” at inspections. No, for decades following the books writing we still basically sucked at it. But it means that we had no good excuses for that. Dorothy and Tom had provided a wonderful recipe that many (most) failed to follow.
