In a recent blog post by Mike Cohn, he wrote about Establishing a Common Baseline for Story Points. He explores the technique of getting estimators in a room from many teams. Perhaps a pair of individuals per team.
The entire room uses Planning Poker to estimate stories. The focus is on getting all of the folks in the same ballpark when it comes to estimating their stories level of effort.
The idea is not to have everyone become a clone of each other. But to get the story points close enough so that forecasting can be done across the teams. So, consistency without normalization or fixed rules.
Not only do I like this approach, but I’ve also successfully used it with several companies where I’ve coached. Not as an external coach, but as an internal coach. And it works quite well.
I was reading an article from Mike Hall of Agile Velocity entitled The Most Important Question to Answer for Successful Agile Transformations. I’ve known Mike for quite a while and he’s an incredibly practical and skilled agile coach. So, I really wanted to explore the question. Point being…he had me “hooked”.
In the article he talked about how establishing a Business Objective was a crucial first step in any agile transformation effort. I’ll reframe it to be—your Compelling Why.
9 Typical Business Objectives
Mike spoke about Agile Velocity’s, Path to Agility framework having 9 business objectives that they typically try to uncover with their clients:
Employee engagement
Customer satisfaction
Quality
Speed
Predictability
A while ago, I was talking to my colleague Mary Thorn about the notion of agile “playbooks”. Mary had been working with a client in NYC and had developed a playbook for their agile adoption and practices. From her perspective, developing these sorts of:
Guidelines
Rules
Methods
Standards
Guardrails
Were invaluable for helping a large organization effectively transforming with agile approaches.
During the development and deployment of the playbook, she asked me to share my playbook. And the very question caused me to pause.
I’ve been an agile coach for ~20 ears, so I certainly have the chops. But upon reflection, I realized that I’d never, ever developed a playbook for a client. And I sort of busted Mary’s chops a bit around the idea.
Why you might ask?
I read a post by Scott Dunn that inspired this talk. I’ve known Scott for a while. He’s the principal coach/founder of Rocket Nine Solutions, an agile coaching & training firm. He recently moved from Orange County, CA to Nashville.
Since he’s now closer to me, and since Vaco’s headquarters is in Nashville, I’m hoping to collaborate more with Scott in the future.
But I digress…
The title of Scott’s post is – Your Culture is What’s on Your Walls. In it he talks about observing cultures by physical evidence and gleaning the culture by observation. I agree with his perspective and I liked the personal nature of the story. He also inspired me to extend the idea.
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.
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…
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:
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)
Even Sadder
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.
I periodically do a coaching circle as a service to our agile community. I invite anyone to it and it’s free. Think of it as a Lean Coffee format discussion with folks looking for coaching advice.
This question came up the other day:
I'd like to hear how your teams handle spikes - do spikes have acceptance criteria - yes/no? Do spikes have story points yes/no?
And it generated quite a nice discussion around the idea of spikes. And it made me think about whether I’ve ever written about them before. I was shocked to realize that I really hadn’t done a deep dive into my thoughts on spiking. Well, here goes nothing…
I engaged a contractor to come over to my home the other day to give me an estimate for doing some external work on my house. I needed some carpentry repairs to my siding, a few windows replaced, and a few repairs to my screened-in porch.
The weather has been challenging lately in NC so the house has taken on some damage. Not too much, but I like to stay ahead of things regarding maintenance.
He gave me an estimate for his time (hours) and costs to repair each item.
I was sort of taken aback by the estimates. They seemed much longer/larger than the ones I had done on my own so I shared them with him.
When I did, he gave me a sideways stare. He said that if I wanted to do the work, then my estimates were valid. But if I wanted him to do the work, then mine were irrelevant. He noted that this is what he did for a living, that he had glowing recommendations (he did!) and that he stood by his estimates as valid.
He also mentioned that, with all due respect, I was biased. I was the customer so I saw things in a different light (easier, quicker, lower cost) then he did. He also mentioned that I had little (recent) experience ;-)
In the end, he said that I either trusted him or not. And he asked – did I want him to do the job?
I quickly apologized for my presumptuousness, and wholeheartedly said YES.
