Coaches, Managers, Collaboration, and Agile: Part II

In Coaches, Managers, Collaboration, and Agile: Part I, I wrote about circumstances under which a team might want a coach. It wasn’t an exhaustive list. It had several questions defining when coaches might help the team to become Agile, not be cargo cult Agile.

One of the reasons we might need coaches for a team is because of the changed manager role in Agile.

In functional organizations, managers coached the team members on how to do their jobs better. (OK, some managers did.) Development managers coached developers, test managers coached testers, project manager managers coached project managers, etc. Each functional manager coached the people in their functions on how to do their functions better.

Some managers learned how to coach the functional people to perform better in teams. To be honest, that was often quite difficult. The organization rewarded the function, not the teamwork. Agile is changing this mindset of “coach the function, let the teamwork take care of itself.” (Yes, that’s a generalization, and not fair. However, I see a lot of it.)

In Agile, we want a product as a result of team effort. That leads us to think about the role of managers and teams and coaching in different ways. (Well, it does for me.) If you are not aware of Human Systems Dynamics, let me introduce you to the ideas of Containers, Differences, and Exchanges. I read about this in Adaptive Action: Leveraging Uncertainty in Your Organization.

When people and projects choose Agile, the managers have new and different roles. People no longer affiliate with managers (the container part); they affiliate with projects. This means that manager-as-coach changes in any number of ways.

Instead of being able, or even having the time, to coach people on their functional roles, the manager might create communities of practice or other ways of encouraging people to learn about their role better. If the manager knows about the function, the manager can coach the people.

And, many managers only know about or have experience in their own functions, such as strictly development or testing or writing. I call these managers ignorant. That’s because unless a manager can see the entire picture (including the dynamics of a project), the manager might not realize the problem with the impediments the team faces.

Ignorant managers cannot create the environment in which a team can deliver working product. Yes, the team has responsibility for a significant part of that environment, especially working as a team to move features across the board, and the manager creates the container in which the team works.

I’ve seen ignorant managers create these problems for the team:

• They don’t realize the effect of multitasking on the people or the team.
• They don’t realize that a team being able to go fast is a result of technical excellence and getting to done on small features.
• They want guarantees (often in the form of estimates) instead of seeing the learning that teams require.

You might see other problems in your organization. An ignorant manager cannot help the team or the team members at all because the ignorant manager does not realize the problems these impediments cause.

The Agile manager’s role changes, especially managers who “manage” technical teams. I wrote about this years ago in Agile Managers: The Essence of Leadership.

Agile managers help facilitate the environment for the team (possibly along with an Agile project manager/Scrum Master or a program manager). They are servant leaders. They provide coaching and feedback and meta-coaching and meta feedback. The manager’s role is about facilitating what the team members can deliver to the team, to the product, and to themselves. It’s about inspection and adaption for team members.

That’s where we encounter the affiliation problem. Who do we want the team members to identify with: the functional manager (who, with good intentions, asks a team member to do work not on the board) or the team? I vote for the team. (I vote for the team regardless of the approach, Agile or otherwise.)

Managers might need coaches so that they learn about what the team members do. Then, managers can provide feedback and coaching and meta feedback and meta-coaching as someone who can see from the outside of the team. Managers can learn what the impediments are for Agile (too-long duration commitments, resource vs. flow efficiency, HR, and finance issues). Managers can help lead the organization’s Agile approach.

Many managers need coaching to understand Agile coaching and how the functions work in an Agile team. That’s because we want managers to be the best managers they can be to help the organization move to Agile.

When managers change what they do, they might need coaching to learn how and to get the feedback to see the possibilities of their decisions. Management coaching is not about weakness. It’s about the realization that if we want to change culture, we change behavior. Not just team behavior. Management behavior is a key part of the Agile transformation.

In Part III, I’ll address coaching and collaboration for middle and senior managers.