The number of developers in my team doubled in the last couple of months. Ok, well, we went from 2 to 4. The end result is 4 devs, 1 QA, 1 Engineering Manager, but still…
So, we started working together. After the initial ramp up and information overload, we were ready to finally work on a full-time initiative that came our way. And we did well… But some things just didn’t seem to click.
It’s not like we were a bad team. The opposite. We wanted to be better. Our engineering manager was planning to organize a team reset since I joined the team. He’s an amazing leader, but a busy man… And knows that it’s fine to delegate some stuff so… Somehow I volunteered. The team was fine with me facilitating the reset so I did it.
I was really looking forward to it. I hate processes (a bad process is an efficiency-driven innovation killer), which made me sort of a process freak. The minimal process that helps the team innovate, solve problems and be effective is what I really love.
But this sort of a process doesn’t create itself. And it’s not created by a single person either. The team has to work together on creating it and then follow through and held each other accountable if needed.
Steps to effective team reset
There’s a couple of steps to an effective team reset:
- Set the team vision
- Figure out team’s current state
- Set up the norms
- Generate the improvement backlog
- Retrospect and adjust as needed and as you see fit afterward
Set the team vision
Where are we going? Why are we doing our job? What’s out team purpose? What characteristics we want the team to have? What are our values?
This sort of questions has to be answered by everyone, and everyone has to share the same vision to be effective.
It’s good to start with the team vision because the team is not yet biased with its current state analysis and can easier answer the question “How do I want the team to look like?”
Figure out team’s current state
The team needs to know what’s working and what’s not before a full reset. This helps building and awareness and mutual understanding as well. What do we do the same? Where do we share the same principles and ideas? Where do we differ? Why?
Set up the norms
After the team has figured out the things that need instant improvements and agreements it’s good to set the norms around them. This way if there is some disagreement the team figures out the general rules everyone should follow. Some of the norms can soft norms, some have to be hard.
Generate the improvement backlog
It’s not like you’re going to improve everything within one (or a few in our case) team reset sessions. You may need to start from the most important things and work out your way through them in the coming weeks or months (for example during your retrospectives or whenever you decide the time’s right).
Retrospect and adjust as needed and as you see fit afterward
You don’t necessarily have to work in Scrum to retrospect on your teamwork or team process or a project. My team works in Kanban right now, but we still meet bi-weekly to look back and figure out how we’re doing. Some decision made in the course of a team reset may turn out to be dead wrong. If you see something doesn’t work after the reset – change it.
When to facilitate the team reset?
There’s a couple of scenarios when you may want to facilitate the team reset:
- when the team seems to disagree on a couple of things
- when the team doesn’t seem to work well together
- or even worse when the team is fighting
- when someone new joins the team
- when the team doesn’t have any norms or there are norms that aren’t followed by the team
- or whenever you wish to 😉
A lot of the team reset stuff can happen during the retrospectives. To not add yet another meeting we decided to use our retrospective time slot for that. So in a way, it was a “non-standard” retrospective. If you decide to reset only what’s not obviously working that just fine.
What I found most valuable during our team reset was a series of sharing our “what I do/think, when and why do I do/think this” on all sorts of topics. We learned about our approaches and improved our work processes and communication. And even though we’re still sort of “resetting” some stuff we already reached the performing stage I mentioned when I wrote that it takes time to make a team…