Arie Van Bennekum is one of the original signatories of the Agile Manifesto. So, he’s got significant experience and credibility in the agile space. He’s also the founder of a company called Wemanity, based primarily in the Netherlands, but spread across several European countries.
Arie recent shared on InfoQ about two models or approaches that’s he has invented and used in Wemanity’s journey that I thought might be interesting to share.
https://www.infoq.com/articles/future-ready-organization
The Integrated AgileTM Transformational Model
Arie and his Wemanity team have created the following 6–step approach to introducing agile approaches and changing organizational culture. It’s intended to be a round-trip, iterative approach to incremental organizational and cultural change.
I’m often caught up in a pattern with clients.
They’ll come to me and ask me to help them either start on their agile journeys or improve / accelerate their current efforts.
But then, when the actual logistics are discussed, we try to minimize everything. That is coaching and training time. The primary two reasons are budget and the time investment. I guess folks are focused on getting the max for the minimum. (sounds like a department store doesn’t it?) https://m.tjmaxx.tjx.com
So, I keep reducing my recommendations and approaches until at some point it fits the budget and time tolerances. But often that comes at a cost. 10 years ago, I would minimize to the point where the results would be impacted, but I try not to do that anymore.
Now, I’m much better at holding the line. At negotiating, by keeping their needs and the ultimate outcome in mind. At keeping everyone focused on the goals.
So, where are you going with this, Bob?
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.
This is something I personally struggle with as a coach.
Quite often, my default style is to push my clients beyond their comfort zone. In so doing, I run the risk that it becomes MY vision over THEIR vision. Or that I may be pushing them too hard, far beyond their capacity to change.
But at the same time, meeting them entirely where they are strikes me as a wimpy approach. One that will, at best, succeed in their transformation taking many years. But it’s a common philosophy that I hear repeated by many agile coaching firms who seem to be looking more at long-term revenue flow over client adoption acceleration and ongoing success.
So, the question is – what is the right stance or posture when meeting a new client?
Should we meet them where they are and apply very little change pressure (where and when needed)? Or should we take a risk and push them out of their comfort zones?
And of course, the general answer is – it depends and context matters. But still, we need a general strategy. So which way do we lean? Let’s explore the extremes of that question…
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…
It’s funny really. One of the key points of the agile methodologies and the manifesto is heavy collaboration, with the best being face-to-face collaboration. But one of the things I see happening in teams all of the time is, how can I say this delicately, over collaboration.
In other words, the teams, ahem, talk too much. There, I said it And I’m referring to open-ended discussion that takes too long if ever to narrow down towards a decision. Folks seem to be talking to hear themselves talk. Often it’s not everyone, with a few heavy talkers dominating discussions and the rest seemingly along for the ride. So it can be quite unbalanced.
In facilitation terms, there are two types of discussions going on when a team is trying to make a decision. There are divergent conversations, where options and ideas are getting put on the table. This is the brainstorming side of the discussion. And then there are convergent discussions, where the team is narrowing down options in order to make a decision.
I have some coaching acquaintances who’ve joined a relatively large firm. They’re tasked with being the internal agile coaches and leading the organization’s agile transformation.
Several times members of the organization’s leadership team have reached out to me to come in and discuss various aspects of high-performance agility. Topics like culture, scaling, and leadership agility was of heavy interest. I think they were simply looking to get an outside, experienced coach to come in and provide insights. Not undermine the internal coaches.
But each time the internal coaching team squashed the inquiry and insisted that they do the session. In fact, in other cases of invitation, they wanted to go over my “talking points” to ensure that I wouldn’t say something that differed with their guidance or perspective. Given that level of scrutiny, I respectfully withdrew any interest.
This is an actual example. But I’ve seen and heard it repeated many times in my own agile journey.
I wrote a coaching article a while ago that illustrated an agile coaching anti-pattern. It was quite well-read and I received quite a bit of feedback on it.
One of the folks who responded was Mick Maguire.
https://www.linkedin.com/feed/update/urn:li:activity:6345281715686166528
A great article by Bob Galen, he shines a light on an all too common pattern, especially among the late adopter market that we are in these days... My advice... If you are about to engage agile coaching, and you don't want to waste (a very big pile of) your money, make sure the first conversations are "what does success look like?" and "How will we know if we are getting there?...”
I’m not focusing on the coaching part of his reply, but more so reacting to this entry level statement:
“Especially among the late adopter market that we are in these days…”
Mick’s comment has stuck with me since I read his reply. Making me think about Geoffrey Moore’s, Crossing the Chasm and where the agile (movement, methods, frameworks, etc.) might be on that scale.
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…
