Perhaps it’s just me, but I’ve been indoctrinated into the Tuckman Model as THE view or model when it comes to team maturation and overall health.
You all remember Tuckman, don’t you?
He presented the following stages:
- Forming,
- Storming,
- Norming,
- and Performing
- sometimes Adjourning
that teams go through in their evolution to a solidly performing state.
One of the things that it’s influenced in my coaching and leadership style is the predilection to honor the team. That is, once a team is formed and performing, I am loathed to break them up for whatever reason. Even good reasons like the business priorities have changed or there is a desperate need for the skills of one team member in another team. Or even, the team has some dysfunctional relationships brewing.
I attended the Mile High Agile conference in April. One of the keynotes was Michael Feathers. He did something interesting in the opening moments of his presentation.
https://www.youtube.com/watch?v=3AMzRAjA0-o
First, he asked how many non-coders there were in the audience. And about 80% of the group raised their hands. MHA was very well attended with approximately 850 folks – so that manes about 600 folks raised their hands.
The second thing he did was show us some code on the screen. And he asked how many folks were comfortable with it. For example, showing it (code) in a sprint review. I think there were even more folks that raised their hands.
I hate to admit it, but I’m a relatively ad-hoc agile coach. I don’t use a lot of frameworks or tools. I mean I have a few that are well used and well worn, but I don’t have a toolbox the size of Montana (that’s big for folks outside of the United States).
I compensate for the tools with my overall experience. I’m coming up on 40 years of overall experience and 25 years of leadership experience in software development, so that helps me quite a bit in my coaching. And I’ve been leveraging agile approaches since the mid-to-late 1990’s.
That being said, I’m aware of this gap and I’m frequently looking for powerful tools to add to my coaching arsenal.
In several previous posts,
I’ve explored agile metrics as a set of 4 KPI areas that are typically monitored in agile instances. In this particular post, I want to drill into team health or “happiness” as a viable and important agile metric area. In fact, I might argue that it’s your core metric.
Let’s look at a couple of approaches.
Crisp – Team Barometer
I was watching ESPN today. It’s spring in North Carolina, early April to be specific, and the Masters golf tournament is scheduled for later this week. So there’s a build up of golf buzz related to it.
I’m not much of a golfer, but even I pay attention to the Masters. It seems to be one of those golf tournaments that have seeped into the fabric of American life. And the Augusta, GA course is incredibly beautiful as well.
But enough of that.
There was an interview today with Bubba Watson. Bubba is a 2-time champion and he won the tournament last year – 2014. Early predictions from the pundits give him a more than reasonable chance to repeat.
As I listened to the interview, I became more and more intrigued with Bubba Watson – the person. And I started to see a correlation between some of his answers and the agile principles and mindset I’ve come to know and love.
In my last post we explored a situation where a Product Owner had a long-term challenge with their performance that was weighing their team down.
But as I finished that article, I realized that there might be something else going on that I wanted to explore here.
In that situation, the teams’ coach assured me that conversations and escalations had happened between herself, the team, and the Product Owner. She even said she’d escalated things to the PO’s boss. She made it sound like there was a huge amount of clear feedback over the course of two full years.
Given this, they seemed to be at an insurmountable obstacle—a poorly performing Product Owner and nobody willing to do anything to improve the situation. In other words, they were stuck.
I was talking to a fellow coach the other day and she was venting a bit about one of her teams and their Product Owner.
Bob, she said, I have an outstanding agile team. We’ve been working within our product organization for nearly two years. In that time, we’ve delivered an application upgrade that everyone has viewed as simply fantastic. Now we’re onto a building a critical piece of new system functionality for them—so we’ve earned everyone’s confidence in our abilities.
We work hard, we work well together, we deliver high-quality working code, and we have fun doing it.
Ok, I asked. That sounds like a fantastic situation. To be honest, I’m a bit jealous.
I came across a wonderful post about changing the daily stand-up meeting. It aligned incredibly well with how my own thinking has evolved of late. It’s by Cheryl Hammond from Northwest cadence. She makes some points around reframing the questions and/or focus of the daily standup meeting.
While I don’t agree with the entire premise of her recommendation, she did make me think some more about it and most of what she said aligned with my own evolving position.
In the late 1970’s I worked on an assembly line at Burnham Corporation in Lancaster, PA. This was after I separated from a stint in the US Army and during my tenure pursuing a BS degree in Computer Science.
Believe it or not, I was a “Boiler Maker” at Burnham. I was a member of an assembly line that assembled boilers from parts manufactured in the plant.
I know what you’re thinking. At last, Bob has “lost it”. He’s regressed back to the early roots of his working career, which has nothing to do with his focus today. He’s now become an “old man” telling “old man stories”.
Well I will admit that I’m not as young as I used to be, but I’ve been thinking a lot about this job recently and the similarities or lessons there from an agile perspective. I hope I can connect the dots sufficiently for it to make sense to you too.
