The original post on this topic was one of my more popular posts. As of, August 14th, 2019, it’s received:
On LinkedIn, ~9,500 views, 86 reactions, and 40 comments
On my website, ~2,500 views and 18 comments
What’s particularly noteworthy for me is the number of comments and the overall depth, breadth, and thoughtfulness of them.
Here’s a link to the LinkedIn post - https://www.linkedin.com/feed/update/urn:li:activity:6561537228772831232/
And here’s a link to my original blog post - http://rgalen.com/agile-training-news/2019/6/23/the-trap-of-being-an-embedded-agile-coach
As I review the comments and thought about the article and my original intentions, I realized that a follow-up would be helpful.
I want to react to some of the comments, but I also want to clarify some of my intentions in the article. As I think some folks might have misinterpreted them. And this is mostly due to my writing.
That being said, I’m not apologizing for the original article. I think it represented my thinking…and still does. I’d just like to clarify a few things.
I was having dinner the other evening with a few agile coaches after teaching a CAL class all day. I think we all wanted to “trap” each other into either:
Revealing our coaching secrets
Checking to see where out passions lie
Challenging each other on our “agility”
And simply, learning from one another
It was a small group and we engaged in some serious discussion and debate around our agile experiences and how to help our client engagements.
Sometimes my clients ask me which are the best organization structures that support a move to agile approaches. There are many ways to characterize their organizational structure and focus, but a common view I use is this:
Are they aligned as a Project-based organization or a Product-based one?
You can move to agile methods with either focus, but I think a Product-based focus makes it much easier. Let’s explore the dynamics of each. This will help you determine where your organization currently resides AND how you might want to shift your focus if you’re thinking about agility.
I might be the first one to complain about bad managers. Heck, throughout my career, I’ve had more than my share of incompetent, self-centered, and poor-intentioned leaders. So, it would be easy for me to jump on the bandwagon in the agile community that lambastes managers on a daily basis.
No, you say. This doesn’t happen. We in the agile world embrace and respect all roles and all people.
Well here’s an example from the Larman & Bodde – Large-Scale Scrum (LeSS) book. The reference is from Anton Zotin, an agile coach, and it was published on LinkedIn. And no, I’m not picking on Anton or the LeSS guys. I’m just using this as an example. There are countless others.
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…
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 ;-)
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.
Hi everyone.
I have a confession to make. I’ve fallen into a trap and I need to get out of it.
Gosh, Bob, what’s wrong? What is it you might ask?
I’ve been saying: “The Scrum Guide says” way too frequently. It’s almost a daily mantra and I suddenly realized that I need to stop it.
This is a bit uncomfortable for me to admit, but I have some confessions to make…
I’m a SAFe SPC;
I’ve attended a 2-day Nexus training;
I plan on attending / co-teaching Scrum @ Scale with Don MacIntyre in September;
I’ve studied (I mean studied!) and contrasted DAD and LeSS;
I’ve actively coached SAFe organizations;
I’ve been leveraging simple scaling techniques (Scrum of Scrums, bits of SAFe) for well over a decade.
So, it’s fair to say that “agile scaling” is in my bones, in my DNA, and that I’m fairly experienced. And it’s incredibly easy for me to meet a larger scale client and begin discussing scaling aspects quite early in our coaching relationship.
I’ve been teaching and coaching Scrum for nearly 20 years. During that time, I’ve always tried to stay true to the basic Scrum guidance and the Scrum Guide. But I’ve also shared my own practical experience.
One of the things that I’ve been consistent about in my guidance is that the ScrumMaster is NOT a manager or HR role. That is, they should not be “mucking around” with personnel performance issues. At least not directly.
For example, they should not be writing/executing Performance Improvement Plans (PIPs) or removing folks from teams or firing folks.
So, you can imagine my shock & chagrin when I saw an article by Barry Overeem that seemed to be saying the opposite. Now I’ve followed Barry for many years and I normally align with his recommendations. Or at least I see the soundness in his perspective. And often he simply makes me think about things in new ways. Which I appreciate.
But in this case, I think this is a very dangerous point of view and flat out wrong. So, let me share my thoughts…
