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 was in one of my Moose Herd (virtual Lean Coffee, coaching group/guild) meetings the other day and one of the folks asked a question about a team member they were coaching. I’ll try my best to capture it—
I have a team that I’m coaching who suffers from lots of WIP and they carry over between 30% and 40% of their stories per sprint. I’ve tried bringing up various ideas to help with this, but the team lead, a very strong character, always disagrees with any of my suggestions/ideas. They simply override me and consider it a non-problem. What coaching ideas do you have to change this?
The Herd group brought up quite a few suggestions, for example:
Better backlog grooming
Smaller stories
Discussion around WIP, Lean, and the importance of getting things done
Impact on forecasting and stakeholder trust
Talking to the persons manager
Perhaps trying Kanban, etc.
Everything we said the coach basically replied: Done that, tried that, didn’t work, give me something else…
Many agile folks have been talking about the dynamics and need for T-shaped skills when it comes to their agile teams. My colleague, Mary Thorn, has been a proponent, coach, and explainer of the notion for many years.
And, Kenny Rubin wrote a short and effective explanation in 2012 that you can find here - https://www.scrumexpert.com/knowledge/t-shaped-skills-and-swarming-make-for-flexible-scrum-and-agile-teams/
But, What about Leadership?
But rarely do we talk about T-shaped skills from leadership (or leadership team) perspective. So, I thought I’d spend a little time exploring what T-shaped leadership skills might look like…
If you know anything about me, you know that I’m a Rush fan. So, this article plays a bit of a homage to the song—Big Wheel. RIP Neal Peart.
This is a relatively short post, but an important one. I want to highlight an initiative that’s been going on for a while by Mark Summers and a bunch of other smart folks to define a model or tool for what solid, robust, and professional Agile Coaching skills look like. They call it the Agile Coaching Growth Wheel.
They’ve established a website called http://whatisagilecoaching.org/ Where you can find a description of the Wheel and other supporting information.
What I like about the tool is the depth and breadth of it. For example, the service-oriented aspects. Or the fact that it contains a consultative or advising component that I think is missing from some other models. Let me explore my previous go-to models before highlighting the differentiators in the Wheel.
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.
About 10 years ago I was an agile coach at a client organization and I was also acting as a Scrum Master for two teams.
I remember a director coming up to me and asking me, as the Scrum Master of a team with folks who reported to him, how was a specific engineer performing. He explained that he had concerns that the engineer wasn’t pulling his weight and he wanted some specifics to confront him with.
I remember my reaction viscerally to this day…
I got a sick feeling in the pit of my stomach;
I even felt a little weakness in my knees;
I struggled with what to say, knowing that the engineer he was talking about was indeed struggling;
I didn’t know if this was part of my role as a Scrum Master or not;
I wondered how he would take it if I declined to give him feedback;
I worried about the impact my feedback would have on the engineer…
It was a horrible experience because I wasn’t sure what to do. If I gave him the feedback, it would certainly compromise my role within the team. I guessed that it would get out and that I’d never really be trusted again.
AND, I was a part of the Scrum Team, wasn’t I? It would be like becoming a “snitch”. And nobody likes a snitch.
But if I didn’t give him the feedback, would it put me at risk?
In the end, I respectfully declined. I said that he’d have to observe the team in our sprint to sort out how everyone was performing. To my surprise, he accepted that reply. But I left feeling incredibly vulnerable and physically shaking.
I just read an article by Luiz Quintela, otherwise known to me as ‘Q’. I think I met Q when he attended one of my Certified Agile Leadership classes in Dallas. He has since moved to LitheSpeed in DC, but that’s another story.
Anyway…
In the article, Q shares some of his experiences, learnings, and advice related to conducting powerful Scrum sprint reviews. I love all of his advice, so I won’t be nit-picking at any of it.
But I was inspired by his perspective. You see, it was from the point of view of the Product Owner and the team level responsibilities for conducting efficient, effective, and informative reviews. Ones where you get lots of feedback.
But the inspiration was that the role of the ATTENDEE was not really highlighted and that’s where I want to augment the article a bit.
The Role of Sprint Review Attendees
While the Product Owner and team members certainly play an important role in successful Sprint Reviews, the attendees are not simply innocent bystanders. They have a job to do as well. Or a responsibility or a role to play.
There are literally three things that come up in any of my training adventures—
How to handle estimates and forecasting with fixed-date projects?
What are “Good” agile metrics?
How to be “Agile” with distributed teams?
I thought I’d explore the last question on distributed teams in this post by listing some references that you might find helpful.
First, I think the Jutta Eckstein was the first author in this space. She wrote—Agile Software Development with Distributed Teams: Staying Agile in a Global World in 2010 and updated it in 2018. She was probably one of the first folks who started sharing her experiences in distributed agile and her work has stood the test of time.
Next, Johanna Rothman and Mark Kilby have written perhaps the most complete work on the topic in agile contexts. From Chaos to Successful Distributed Teams: Collaborate to Deliver is an incredibly useful look at how to make distributed teams work in agile contexts. Written by two seasoned coaches from their work in the real world. And here’s an Agile Alliance article they wrote about collaborating on the book.
And here’s Johanna and Mark’s contribution to Comparative Agility’s assessment tool.
I got into a debate with a coaching colleague the other day. Well, debate, disagreement, argument, and other terms could apply. We kept it respectful and, in the end, I believed we agreed to disagree.
I’ll call my colleague, Ken.
We used an analogy as part of our discussion that I’d like to share. Here’s the analogy—
Meniscus vs. TKR?
I’ve got a problem with my knee. I’ve done the web research and self-diagnosed that I have a partially torn meniscus and I want some simple surgery to clean-up my knee and fix the meniscus.
So, I start looking for the best surgeon I could find. The best “knee-person” out there. And I found her. She’s expert at all sorts of knee surgeries from the meniscus to total knee replacements. Having performed thousands of successful surgeries.
I scheduled a visit to explore the surgery. And she runs some tests (X-rays, MRI, etc.) on my knee in advance of our discussion.
I enter the discussion telling the doctor what I need. I even go so far as telling her when to schedule it. As, clearly, I’ve determined what wrong and what to do about it.
She listens patiently but tells me clearly and firmly that I need a total knee replacement. That my knee is irreparable with anything other than that sort of corrective procedure.
I argue with her. And I insist that I simply want the meniscus repaired. I’ve made up my mind AND I want her to do it…
Ask vs. Need
Clearly, in this example the doctor has a decision to make. And I don’t think it’s that hard. The options are:
Tommy Norman is an agile coach in Nashville and he recently posted the following on LinkedIn:
As a Product Owner, do you know how much it costs to run your team per week/sprint?
Having this information can re-frame many of your discussions. When talking to stakeholders you can ask questions like "That would take about 1 sprint, is it worth X dollars to you?". With your teams it can help them understand the impacts of process inefficiencies by showing them how much they cost the company/client.
It does not even have to be super accurate, just a decent representation of the cost. If you have a dedicated team, it's pretty easy. Get a blended salary across team members, add 35% for overhead costs, then figure out how much that comes to per day. Even without a dedicated team you can use rough percentages.
Knowing the cost of delivery is a good first step towards moving discussions next to value delivered and return on investment!
Ever since I read it, I’ve been thinking about the notion. Believe it or not, it’s not something that I’ve thought about much in my agile journey. And I’m stewing over the implications.
While I think it’s a good idea, it might have a Yin and Yang nature to it. Let’s noodle on each side:
