Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
I interact with team members all of the time. They speak in terms of:
Their leaders have made them “go agile”;
That it’s not going the way they want it to be;
That things are worse than before;
Or that nothing has changed, they’re still underappreciated, overworked and stressed out.
You get the picture.
I’d like to start off this post with the following excerpt from the ProductPlan website. I think it sets the stage of things quite nicely:
“We’re agile, so why do we need a long-term product roadmap?” I hear this question regularly. At first blush, the terms agile and product roadmap seem like a contradiction, but they’re not. In fact, you should have an agile product roadmap.
In most agile product development organizations, the backlog is used by the development team to track what’s coming next, at least for the next few sprints or iterations. Many agile teams rely heavily on the backlog, as it maps out short-term initiatives. But the backlog in itself is not the roadmap. This post explains why you need both.
Product Roadmap vs. Backlog
A product roadmap is different from a backlog. The roadmap defines a strategic view of where the product is headed over the mid to long term, whereas the backlog defines the product features and initiatives for the near term. The roadmap is tied to the organization’s vision and strategic goals, often for the next 12 or more months. In an agile organization, the roadmap provides guidance rather than a strict project plan.
I also sometimes equate the word Portfolio with Product Roadmap. In my mind, the two are quite synonymous.
This was inspired to write this by the Music City Nashville talk by Faye Thompson and Charles Husemann. It was entitled: Coaching Katas - In Search of The Answer to the Agile Kobayashi Maru.
Essentially it was a series of coaching scenarios where we run thru Coaching Kata’s (very similar to Dojo’s as I’ve shared on them before). The scenarios were inspired by Star Trek episodes (original Star Trek I might add). In it, they emphasized using the 7-questions from The Coaching Habit book by Michael Bungay Stanier.
As we debriefed each of the scenarios, I heard attendees really struggling to apply the 7-questions effectively as part of a “normal” conversation.
It made me think that:
7-questions (from the Coaching Habit)
Powerful questions (from Co-Active Coaching)
Other question-based coaching models
Can set you up for failure if you don’t use them sparingly within the ARC of an overarching conversation model/framework. And we shouldn’t use them sequentially or artificially as well. They are also only for the coaching stance/role. For example, what about teaching, mentoring, or modeling stances/roles?
A coaching friend of mine came to me the other day asking for coaching advice about a team she was coaching. I’ll try to get the story right…
She was coaching a fairly new Scrum team. They were refining a story and decided to implement it in the front-end. Even though the “proper” solution was a backend one. It seems they’d done this before so there was a precedent.
The primary reason for this technical decision was speed. It would take them 5x longer to do a backend implementation and they felt the need to get this feature done quickly. They would then defer any technical debt clean-up to a future sprint.
The Product Owner weighed in on the side of the team but really didn’t have a strong opinion either way. They simply wanted the feature delivered as soon as possible.
The Scrum Master, as they were new, also sided with the team. So, the leanage was unanimous.
One of the functional managers in the organization, realizing that the team was making a mistake and implementing a hack or work-around, stepped in and tried to influence the team to make a better call, the right call, by implementing it in the backend.
The coach asked me about defending the team from the manager and how I might go about it…
Within the agile community, I’ve seen quite a few examples of folks doing a, how do I say it, Failure Bow. To be frank, I didn’t know what it was all about. Sure, I get the gist of it. But where does it come from? And what are folks trying to represent by doing it? I never quite knew the backstory.
I also discovered that there were also several forms of it. There was the in-person failure bow. For example, a speaker making a mistake in front of their audience would do it.
But I recently received some email from Scrum Alliance folks that had mistakes in them. The senders then did virtual failure bows via follow-up emails. I’ve even seen folks do it via #failurebow in the twitter (and other) streams.
It made me want to explore it a bit deeper. So, I did.
I received a LinkedIn message from an agile consulting firm asking if I’d be interested in an opportunity. The had two levels of agile coaching opportunities available.
They were:
Agile Coach with compensation up to $70/hour
Sr. Agile Coach with compensation up to $80/hour
I sat back and I sighed. I’ve never charged rates this low for any coaching I’ve done…ever. I’ve got somewhere between 15-20 years of agile coaching experience from team level to project/program level to enterprise level including leadership coaching.
When I looked at the specification for these roles, the Sr. Agile Coach role had Enterprise level coaching requirements at my level. But from my perspective, the compensation was at a level that would not fairly compensate qualified agile coaches, nor even Scrum Masters.
In other words, they wanted Filet Mignon at Burger King prices. (with all due respect to BK)
But what makes me even sadder is that there are people “agile coaches” in the world who will happily work for these rates.
Why?
Largely because they’re agile coaches in name only. They gain a bit of experience and then immediately call themselves an “Agile Coach”. For these folks, the compensation makes a whole lot of sense.
However, they’re leading with paper experience and bravado and not real experience. It’s a game of smoke and mirrors and the clients are the ones that lose in that game.
They are commoditizing agile coaching and driving down compensation rates for all of us. And the rate compression also minimizes the value of real-world experience and skill.
This is a true short-take on flow metrics. I want it to be a reference piece for other works…
I attended a Professional Agile Leadership class with Ryan Ripley not that long ago. Ryan is a colleague and friend of mine and I always appreciate (and learn new stuff) when we get together. If you ever get the chance to attend a Ryan Ripley class, take it!!!
But I digress.
Ryan was VERY enthusiastic about flow metrics in the class. He has moved on from a velocity position and then from a #noestimates position, and now believes that flow metrics that the most relevancy and value in agile contexts.
This is inspired by a conversation I had at our Vaco Agile coach’s guild.
We had a discussion around it being ok to fail is NOT simply leaders giving us space/safety to fail. It’s also about our internal willingness to fail.
For example, as I’m a strong and driven Type A, my personality isn’t that comfortable with failure. So, even if the ecosystem is “failure friendly” or encouraging…
Am I? and if not, why not?
Are other members of my team? And if not, why not?
Are members of my group or tribe? And if not, why not?
And if we’re not internally failure friendly, how do we get there? How do I/we move the needle?
This was a real short take post, but I hope it starts you thinking about your safety and failure friendly ecosystem.
While, yes, your leaders play a really SIGNIFICANT role in it. It’s not solely about them. It’s also about US and our WE walking our own talk?
How might we test it? Perhaps checking for –
When was the last time someone on your team failed…and shared it?
And, when was the last time you failed…and shared it?
Anyway, food for thought. Stay agile my friends,
Bob.
Let me start by saying that all organizations aspiring to be agile need an agile coaching presence. But the question is how many, for how long, and how much?
I’ve seen many organizations that invest too heavily in coaching and keep the coaches around for far too long. This often creates a dependency on the coaches and really doesn’t help the organization’s growth.
I came upon this article around 2016 that explained how one group at Walmart approached creating an internal agile coaching capacity. What strikes me about it is how lean it is. And how it leverages the entire organization for what is essentially self-coaching.
Anyway, I thought I’d share it. I don’t think many are aware of this approach and it’s a thought-provoking alternative to many of today’s strategies.
One of the things I appreciate about this article is the author’s willingness to share—what works for them. It may not work for every organization, but it’s a real-world approach that produced results.
And on a personal note, is that this strategy aligns with my own. Instead of embedding oodles of coaches for long periods of time, it confirms that you can make great progress with a more situational approach. Not only that, the results may be even greater than applying an entire army of coaches to the effort.
Stay agile my friends,
Bob.
I was teaching a class the other day and folks were very distracted. Even though the class had been scheduled for months and everyone seemed committed to it, the following happened:
People were running in and out of class to attend meetings
Many were checking email on their laptops and phones
Several leaders, who were scheduled to attend, totally bailed out
Several “emergencies” came up that needed immediate attention
Believe it or not, this often happens during my classes. And I’m not that bothered by it. Meaning, I try to ignore the interruptions and focus my attention to those who ARE present. And who do want to add more skills and thinking to their practice of agile leadership.
That being said, I’m not writing this article to complain. But instead to make a very clear point…
