What is my role as a team leader? A continuous improvement guide to help you grow as an Agile Manager

What is the role of management? As an agile coach and as a line manager I’ve gotten or asked that question several times over the last 10 years.
When you introduce agile into an organization, middle managers (typically techs who climbed the management ladder) are faced with an identity crisis. I was also. I mean, if the teams are supposed to be self-organizing, supposed to solve their own problems, supposed to cross the “silo” and communicate with teams they need to cooperate with, what is a manager to do?
Annual performance reviews? I don’t know about you but I don’t see these are a useful use of my time. I’d rather be helping the teams excel, deliver great products! So, what is my role as a line manager for a team, or a few teams, in an R&D organization? What should I do every day to justify my office and high-salary? Or, if you are so inclined: what can you do that makes you feel the belonging that comes from achieving something together with your fellow human beings?

Managers have a different perspective

As a line manager I remember sometimes disagreeing with what the team was doing, I had a different perspective on the problem. But how can I bring that to their attention without affecting their sense of ownership and initiative? Intervening would make me happy, but affect the team’s sense of ownership and responsibility over their own work.
How to bring my perspective to their efforts to solve a particular technical, process or cooperation problem?
I decided to apply facilitation and I tried to have short conversations with teams only regarding the definition of the problem. A background analysis of current state as well as observed causality (a leads to b that leads to c, etc.) that led the team to face the problem they were struggling with.
What I learned by doing this was that I was right: often the teams did not have the full picture of the problem. But I also learned that I was wrong: during these conversations we would uncover observations and situations that we did not think about before having this conversation. It was a very important learning experience that would greatly influence my career in the future.

Managers have experience

During these short conversations we ended up discussing different perspectives on why the problem had surfaced and what the underlying causes were. Here I often gave my contribution, so that they benefited from my own experience in the company or in the particular domain.
At that time the team was dealing with technical problems I did not have enough experience in, but I did have a lot of experience with the organization where we worked, as well as with customer needs. My experience was useful to them. They would ask me questions regarding stakeholder expectations, customer needs and company politics. I would answer their questions and use my experience to ask other questions. I did not want to impose my views, but I wanted to challenge theirs, so that they could see beyond the surface of the problem they were facing.

Managers can help the team focus on the right things

Teams have the tendency to jump immediately into defining solutions, at this point I would ask them to try to focus on understanding better the problem and its root-causes. Instead of trying to solve every possible symptom or problem that they identified, I’d ask them to select one possible cause for the problem (identified through root-cause analysis) and tackle that.
Once they had selected a possible cause to address they typically would want to spring to action immediately, here I asked: “how will you know you’ve solved the problem?”. Very often teams want to spring to action without first creating an experiment that could validate their assumptions, they just assume they are right. I tried to be the skeptic in the process, asking them to state their assumptions and create ways to validate that they were right (metrics, experiments, etc.) or discover where their assumptions failed.
When they started implementing a particular solution, I followed what was going on and asked if they were still trying to solve the problem they’d identified before. When that was not the case, I asked: “why did you change? Have you listed your updated assumptions?” But I think that the most important contribution in these cases was to regularly ask them to define short-feedback cycles for their experiments. I challenged them to have something to check every day. The longer they went without feedback the more likely it was that they would fail to tackle the problem and know about it too late.

A new role for managers

Through this approach I defined a new identity for me as a manager. I shaped my role to be one of helping the teams take ownership and solve the problems they faced through the application of a simple problem-solving process. From there to being called an “agile coach” was just a question of the term becoming popular ;)

Help teams improve regularly

That is how I define my role today: someone who helps teams constantly improve. This is true for me, whether I am in the role of Agile Coach (which is my current role) or in a manager role. I help teams, and organizations walk the improvement path consciously and using a deliberate approach.
My experience is that teams can handle most day-to-day situations without my help. They can easily find who are the people and teams that they need to interact with. They can deliver software products on their own. But to deliberately improve they need coaching and support. This is not a lack on the part of the teams. In my view this is needed because teams are naturally driven by day-to-day events, and it takes them considerable energy and effort to deliberately focus on improvements in a way that delivers results and drives learning. Teams can solve problems on their own, we just need to help them do it deliberately and reflect on the knowledge they uncover during the process.

The process steps

Here are the steps I try to follow when working with teams on improvements:

• 1. Background / current state: Observe what defines our current situation. Focus on observations, avoid judgments at this point. Just describe the situation.
• 2. Consequences: What does the team or the organization need to do to keep the work flowing despite what you described in step 1? What work happens as a direct consequence of the current state?
• 3. Dream state: What would the perfect world look like? Consider only the context of step 1.
• 4. Benefits/Goals: How will your work be better once you have solved the problem? What steps will be removed or considerably reduced?
• 5. Select root cause to tackle / Solution: What is the specific component of the problem that you want to tackle first? Think back to Consequences, Dream state and Benefits. Pick one benefit you seek, walk the causality chain back to determine root-causes and select one of those root-causes to tackle.
• 6. Action points and follow-up: Now that the team knows what root-cause to tackle, how will they do it? Help them be very specific by listing concrete actions and having team members pick which they want to be responsible for. In this step try to help the whole team speak. Remind them that an important action point is to collect the necessary data to evaluate the effectiveness of the solution they picked.

Once the action points are defined don’t let the team forget about them. The team can (and will) change those actions, but they should review them and reflect on what they have learned.
The goal of this process is to help the team jump out of the day-to-day buzz of work and focus on problem solving, even if only temporarily.

Try it out and let me know how it worked for you. Photo credit: Drachmann @ flickr