Position Statement for Panel on Agile People Issues

I'm a member of a panel Jul 23 for the Boston Agile Bazaar meeting, and am attempting to articulate my two-minute position statement to the question:

How would you characterize your approach to handling people problems on agile teams?

My problem is that I don't do anything any differently for agile or non-agile teams. I still provide feedback. I still offer coaching. I coach or teach how to give feedback and coach. I sometimes offer mentoring, if that's appropriate and requested. I still help people break their tasks into smaller chunks (new-to-agile people tend to have a lot of problems with that, unless they are practiced at inch-pebbles). I still help people see the process and ask whether they are using the process to their advantage. To me, it doesn't matter what lifecycle people use, I do similar things, although the process is different.

So, what's different about agile teams and the people issues? For me, it's the transparency. People can hide in a serial lifecycle. There's less hiding in other lifecycles, but only in agile do you get the transparency that helps everyone see what the people issues are.

At the team level, the daily standups, burnups, burndowns, and cumulative flow diagrams all show you if there's a person-problem, an interpersonal problem, a  team-problem, or a project problem.

Agile doesn't just show project-level problems; it's also exposes management problems.

  • Emergency projects could be a sign of insufficient project portfolio management, as well as technical debt (what does done mean?).
  • Not knowing which project to devote your energies to is a lack of strategic direction or a lack of project portfolio management. It shows up in projects as many unrelated tasks on cards, or just plain interruptions.
  • Teams with obstacles that they can't remove because the obstacle is imposed by management, or the furniture police, or corporate policy is a management problem. Don't kid yourself–this is a people problem.
  • Teams that never quite have enough people–and there are open reqs–have a management problem that is a person-problem.

Management problems are people problems. I work in the realm of management problems. Most managers don't know what they need to do: decide which products to deliver when;  take the lead on strategic planning, manage the project portfolio, create an environment in which people can do their best job, and take the  lead on hiring. This is hard work. And, if you're accustomed to command-and-control, you may not have done these things before. At the very least, you did them differently than you need to do them now.

I'd love your comments: is this coherent to you? Does it make sense? Did I leave anything out that you've heard me say/write before? Thank you.

7 Replies to “Position Statement for Panel on Agile People Issues”

  1. Much of what you discuss is cultural. The organizational culture must change to support agile development as you describe it. Manage must actually “manage” or “lead” the organization. Many managers don’t have a clue about how to do this. However, this problem is not isolated to the agile world. I have dealt with the same issues in trying to implement quality improvement, CMM, etc.

  2. To address your question, I think you are spot on, as usual, in how to deal with people problems. However, the bottom line is still that we get paid by the hour (to cite Weinberg’s third rule of consulting).

  3. I like that you highlight transparency. Pair programming may not be for everyone, but I like it at least as a choice. But in that case, how can we help managers understand the visibility and team vs individual asseesment needed with pair programming? i.e., I heard one manager say “If you pair program I won’t know how to rate you”. How can we guide such managers?

  4. This intrigues me: “Agile doesn’t just show project-level problems; it’s also exposes management problems.”

    Do you find that managers resist implementing Agile for this reason?

  5. Hi, Johanna — I also agree with your statement but it seems long for 2 minutes. I have managed both new teams (unfamiliar with each other, or with agile, or both) and seasoned teams (with either agile, or each other, or both. Based on that, a short reply for discussion goes this way:
    * Tactical:
    “one-minute management” may seem like a stale metaphor, but whatever term you want to use, the idea is more important and beneficial on agile projects than waterfall and other project approaches.
    Every needs to be informed immediately about stumbles and resolve quickly whether they are, or not.
    * Strategic: Covey’s principles may also seem outdated (or some other dismissive term) but they are tools that speak to the comments about managers’ responsibilities and capabilities. Especially on agile projects, managers need to understand clearly *why* each project objective exists, *agree* to it, and how to *assess* being on track — or not. That kind of knowledge/competence grows with experience on each project. A common source of misjudgement is to think that previous projects’ experience (as you understand it) applies automagically to a new project.

    Just my $0.02 worth, there are various ways to make it seem more contemporary, if that’s important. Great question, though.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.