The Problem Solving PM and Agile

I had been thinking about this topic and making notes periodically.  Then, earlier today, I was reviewing a chapter from a book (in progress) on coaching. Some of what it says reminded me of the topic of what a well-regarded Project Manager may face in becoming involved with an Agile effort. The chapter describes, among other things, the need for Agile coaches to restrain themselves from immediately trying to solve team problems.

Now the chapter seems to be written mostly from the perspective of how a coach would view their own behavior based on having been a “go to” person when problems need solving. Such problem-solving skill is something valued in project management. Indeed, success in solving problems helps make a Project Manager valuable and well-respected. So what happens when this is true, i.e., in their work, their problem-solving, fix-it ability helps define their organizational value, and they become involved with an Agile team/project?

One thought I have heard expressed is that, of many traditional roles on projects, PMs can be good candidates to become ScrumMasters or Agile coaches. The book chapter deals very nicely with advice to a person finding themselves in such a role when it comes to their own behavior. It provides good examples of occasions when a coach might be tempted to try to fix a problem right away based on their experience and their view of how the issue should be addressed. The “take it to the team” theme is covered nicely in the chapter.

That addresses the inward looking aspect of the “fix-it” approach. What about the outward looking one? That is the inward looking view of those around and above the new coach in the organizational hierarchy? If part of a coach’s organizational value has been based on their problem-solving initiative, what happens when they begin not to dive in and solve problems but work to help the team(s) to do so in most cases? Will they be viewed as failing to meet expectations, even “dogging it” in their new role by not having ready answers when issues arise in the team or are brought to them (or the team) from outside the team?

One of the things a person moving into a coach role needs to realize is that they have to coach in both directions. Coaching outwardly to the rest of the organization seems to me to be at least as hard, if not harder, than coaching a team. Presumably, teams are expecting to get coaching and, if trained reasonably effectively in Agile concepts, have heard that they, as a team, will be expected to identify impediments and do what they can, first, to address them before expecting others to do so. So a coach that holds back a bit and tries to point the team toward their own solution is probably not going to be looked upon too strangely by the team.

What about coaches who have been viewed as the “fix it” people and now must deal with people used to bringing them problems from outside the team? Now, the problems are really for the team, hopefully the coach is aware of them (and the team). If not, that’s an issue the coach should be addressing. But what if the problems aren’t team issues but organizational ones thrown their way which will impinge on the new Agile approach, yet which others expect the coach and team to “adapt” to somehow and “fix”? (By the way, I have heard folks latch on to the “adapt” word and assume it means the team figures out how to deal with whatever gets thrown at them.)

What will it be like for the new coach to have to coach those that were previously their peers or managers? When those folks, used to bringing the coach problems to solve, find the coach using an Agile approach with them, it may be a shock initially. This may be more true if the other people are not expecting to be involved in any Agile process, There may even be resentment and a feeling that the new coach is trying to “manage” them. (I know there’s a lot of material or “managing your boss,” etc., but the openness of an Agile approach seems somewhat more direct than much of this advice often suggests.)

Most of my experience in coaching has involved being brought in from the outside, so I have had no prior PM fix-it expectations about my role. However, I will say that one thing that has helped me when I have coached other coaches who are in this position has been to work at least as much with the management and peers of these other coaches to help them understand the Agile approach. This includes the roles and responsibilities of teams and coaches (and management) as well as how issues and impediments are handled.

In particular, I try to get peers and managers to understand two things:

1) to get the most value out of a team’s effort, those outside the team should be prepared to become involved in more problem-solving (i.e., impediment clearing) than they may have previously expected, so teams can focus on meeting iteration functionality expectations;

2) an important goal of an Agile approach is to build teams that can effectively solve their own problems (but not all the organizational ones thrown at them), developing larger numbers of people who are, in fact, problem-solvers.

Indeed, this last point is a key reason the coach does not jump in, even if they can solve the problem. Having the team do it is usually a valuable experience in the team working to manage their own environment (to the extent they can). Agile or otherwise, relying on single individuals to be “problem-solvers” may mean you set up a number of single-points-of-failure should such people leave, transfer, etc.

None of what I have said, though, should be interpreted to mean that having individuals who can “get things done” is a bad thing. But my belief is that an Agile approach hopes those are the people who can, if they do not already, come to achieve this through the teams. This can lead to multiplying the number of people who develop skills in problem-solving that can be spread further through the organization. A benefit of taking an Agile approach is uncovering/developing people who are, after all, the kind companies say they want in the first place. Agile helps do that, but only if teams are given the chance to learn this. The temptation to find the “fix it” people and expect them, in the name of efficiency, to get it done faster rather than developing teams who can will, at the very least, retard Agile’s contribution to organizational improvement/growth and may, indeed, kill it.