I’ve been doing agile coaching for over two decades. If there were a Top 5 question I get when doing organizational and leadership coaching, it’s—
How do I set up my teams? Vertical, horizontal, hybrid.
What exactly is an x-functional team?
What about distributed team dynamics?
Are the roles full-time? Or can I share everyone?
How do I handle shared, service-oriented, or platform teams?
For a long time, I wished for a solid reference that I could send to folks when they have these sorts of “teaming” related questions.
Well, the good news is now I do, but it’s not one book. It’s a triplet of books.
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 spent about 3-years working at a company called iContact from 2009 – 2012. While there I reported to CTO – Ralph Kasuba.
Ralph was a wonderfully skilled leader and I’ve been reminiscing about him of late. Sure, we still stay in touch, but it’s not the same as working together each day.
Ralph had one “pet peeve” that I’d like to share and it involves interviewing. At the time, iContact was growing quite steadily, so it seemed as if we were always interviewing team members for our technical staff. We went through a period where no one seemed to pass our technical screens.
It was frustrating because the recruiters kept saying they were sending us qualified candidates, but the team-based interviews would just chew them up.
The language we started to use was that we were looking for Unicorn’s and not finding any.
I frequently get asked about the dynamics of building agile organizations from an organization structure point of view.
The most important point is that you don’t create a high-performance agile organization by the defined structure. Managers don’t do it; neither do VP’s or Directors.
Surely we set the stage. But the teams are the ones that create the organization. We don’t have to optimize the structure for every technical hurdle or risk. Or create a structure that perfectly balances skill-sets and experience across all functional roles.
Whew! I’m glad, because I never figured out how to do that perfectly anyway.
