Revisiting Agile TeamsThis post is inspired by this article by Derek Huether - https://medium.com/@derekhuether/stable-teams-should-be-non-negotiable-59af0972f77
His is the sort of the position I used to have. However, I’ve been rethinking my position over the last few years. Not that I’m moving away from honoring the team. I’ll always do that.
But I’ve started to think that a little adversity isn’t necessarily bad for a team.
I want to use this post as an update to my writings about agile teams. The following post best captures my thoughts – http://rgalen.com/agile-training-news/2018/3/5/stop-norming-performing
Back to Derek’s point
Derek makes 3 key points in the article:
Teams that stay together are more productive. (more stories)
Teams that stay together are more predictable. (higher throughput)
Teams that say together are more responsive. (less time in process)
And he supports those conclusions with data from Larry Maccherone while he was with Rally/CA and reviewing data collected through their tooling. Another key point Derek makes is against the frequent reorganizations that run rampant in many companies. That they undermine all three aspects.
I’m not going to challenge the data or Derek’s key point. Let’s assume that everything is right. That we want to focus on team productivity. However, I think there are things to consider equally (and perhaps even more importantly) than productivity.
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 was talking with someone at a conference a few weeks ago and he asked the question:
What do you think about the concept of “Elastic Teams”?
To be honest, I’d never heard teams referred to in that manner, so I had to admit that I didn’t know. I asked, what do you mean by an “Elastic” team? He went on to explain.
He said that these are teams who are formed, dissolved, and reformed around business needs and priorities. For example:
If you had 3-5 teams working on a set of products in your portfolio and the overall business priority changed. Then you could possible shrink each of those teams by 3-4 individuals and assign them to another team (or group of teams) for 2-3 months.
If something else shifted, perhaps something smaller. For example, a customer escalation of a performance problem. Then you might shift members amongst teams to address the situation. In this case, it would hopefully be a shorter-term reassignment, and then things could go back to normal.
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 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.
