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…
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.
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:
What makes my Certified Agile Leadership training valuable and different?
I’ve been delivering my version of the CAL-I class for approximately 3-years. I deliver it mostly as a private class, nearly 80% of the time, to client leadership teams. I’ve heard feedback from many attendees that my CAL class is a game-changing experience and quite different from other leadership classes they’ve taken. I’ve even heard this feedback from attendees who’ve attended other CAL classes and been disappointed with those experiences.
I’m not saying I’ve got all the answers or that this will be the best class that you’ll ever attend. But what I am saying is that, within the scope of becoming a better agile leader, I think this class “nails it”. Let me share some of the key differentiators.
My colleague Dana Pylayeva has created something really interesting in the agile community. One of her research interests is fear in the workplace. Not in some academic fashion, but in how it shows up, that is what are the types and personas of fear in the workplace?
Dana enjoys creating interactive experiences, so she developed a series of cards (a game) that can help a team surface the various fears they may be experiencing. And, once they (the fears) see the light of day, the team can then discuss how they wish to deal with them.
Here’s some additional information on Fear in the Workplace (FITW):
Estimation FEAR Cards
In the November 2019 Kazi stream, Josh and I talked about teams often pushing back on estimating and some of the root causes. It seems like estimation is one of the hardest things for agile teams to get right (be balanced, feel comfortable with, do effortlessly).
Josh Anderson and I recorded a shared podcast with Jeff Bubolz & Jeff Maleski of the AgileWire podcast.
While we rambled a bit (mostly caused by me) across a variety of topics, it was a lot of fun.
One of the tangents we went on was understanding the agile maturity (readiness, culture) of an organization by the presence of certain words in the overall culture. This would cross everyone…teams to senior leaders.
There would be words or phrases that would indicate a less mature/ready culture and other words that would indicate more maturity. It would be the overall usage and trending of all of the words that would be most interesting and indicative of overall maturity.
(and please don’t get hung up by the word maturity, you could just as easily say readiness or receptiveness or fertility)
