Last year, I sat in on a team’s very first retrospective. After two weeks of wrestling with agile, this team was pleased with some aspects of what they were doing, but not with everything by any means.
These people were pretty frustrated. I had them pick the top five issues and figure out what they were going to do with them. (On one of them I intervened to suggest a solution, but the others they addressed themselves.)
At the end of the session, I stood up and told them they were doing great, and I was really proud of them.
You can imagine the looks I got. But I meant it. Sure, they had a long list of things they didn’t like. But there were two amazing things about that list.
First, the problems they had were the right ones. I’ll say more about this on another day. For now, let’s say what I mean is that the problems were focused entirely around real difficulties, not theoretical or personal.
And the second thing?
The solutions came from inside the group mind. This is the beginning of releasing a team.
Releasing Means Freeing A Team To Move
In the beginning of the relationship with the team, there are three types of restrictions on their ability to think for themselves.
Negotiated restrictions are the ones that the team takes on voluntarily at the start of transitioning. For instance, I can usually get a team to commit to a minimum of one 90-minute pairing session a day. Similarly, we say, you can’t work microtest-lessly unless the lead and coach are first given a chance to get you started. Negotiated restrictions are easy to change, because it’s just you and the team.
External restrictions come from outside the team. A typical one is a company-wide coding standard, constructed some time during the Korean War. Often as not, external restrictions are only kinda sorta followed. The Shakespearean expression ‘honored in the breach’ says it pretty well. Believe it or not, restrictions that are ignored are more dangerous than ones that are blindly followed.
Internal restrictions are the hardest ones to deal with. The typical internal restriction is just plain nerve. A team that has lost its confidence in itself over time needs a lot of successful group-inspired changes to rebuild its freedom. As a coach, you want to attack these internal restrictions without mercy. Catch them doing something right is essential.
Acts of Releasing
I start releasing a team on day one, just by getting them to make negotiated restrictions with me. It sounds paradoxical: how can any restriction also be a release? The answer is that agreements the team makes itself, without undue pressure from above, are themselves a way of releasing.
Here are some other acts of releasing to try:
- any time you lead the team in taking an unreal deal and reframing it as ‘for real’;
- forging a new in-team coding standard serves several purposes, and releasing is one of them;
- places where you or the manager agree to protect the team from outside forces release them;
- teaching them to stop promising things they’re not sure they can do;
- exposing them to healthy in-team debate about what to do or not;
- …and so on.
Why Release Teams At All?
You know, this is a real question. What’s so great about having a team that bucks the company traditions, makes its own decisions, and is generally humorously cantankerous?
Easy: a released team is a team that can more readily connect geek joy with business value.
A released group mind is smarter than any individual one, even yours. It is creative, it blends ideas, it seeks to find every glitch in routine and eliminate it. Free-moving groups are why kanban systems came to exist.
A few weeks ago I said that coaching is helping geeks produce. Nothing, and I mean nothing, will help a team like growing into its confidence and capability.
This is what it’s all about.
Coaching Means Helping Geeks Produce
Releasing Means Helping Geeks Produce
Coaching Is Releasing
Next up: I’m Not Sure.
The pillars are nice, but I’ve all these other ideas boiling along.