It’s the Small Things

One of the things I’m noticing with some of my fellow coaches is their desire to work at the program and enterprise level. It seems there’s nothing like coaching a bunch of teams at once to really get your feet wet. Things look better at scale!

Well yes, and no. I’ve been fortunate to have several work experiences with teams and organizations of all sizes. Last year I worked with a team of two guys in a broom closet. A couple of years before that, I worked with an organization that had over 20K IT folks working almost a thousand projects. On six different occasions I’ve had the pleasure of helping to set up and run programs — teams of teams. A couple of times more than one program at a time.

I’m not trying to brag, just let you know that I have had the relevant experience to talk about this. I’ve been there, done that. While yes, it’s kinda cool working with groups of teams, it’s also very easy to make a lot of mistakes that you never realize you are making. Here are the most common ones.

  1. Premature optimization. The first thing large groups of teams want to know is: what’s the standard? Because you can’t manage a lot of people without processes and standards. (At least in their minds)


    Coming from Agile, many of us know better than to focus too much on process, but clients insist. They want job aids for everything from stand-ups to sprint closings. They expect coaches to all deliver identical advice on any topic.

    This is a really bad trap, because the entire premise of Agile is that individual teams and situations are so varied that we must push a lot of process decisions onto the individual teams. The purpose of our Agile rituals and delvierables is to identify the work and possible paths for solutions: what problems do we face? What types of actions might help the most?

  2. Us versus Them. One of the worst things that happens, often without the coach even knowing it, is that they begin to fall into an “us vs. them” attitude. Who are these teams? How come they keep doing stupid stuff? Why won’t they listen? Over time, you subtly stop being a servant for the teams and start wondering why the nincompoops just won’t do what they’re supposed to do.
  3. Tools will fix anything. Once we get sufficiently detached from the actual problems the teams are facing (and this can happen inside the team, you don’t need a program for it) we start buying into the idea that the tool can fix the behavior problem. Need folks to start making comments when checking code in? Just force it to happen! It’s magic — because you’re not actually dealing with the problem, just the symptom. You’re using a hammer that’s close-by to pound on a problem that’s close-by. Many times the thing you are pounding on is fitting a square peg into a round hole.

The more I work with both large and small groups, the more convinced I become that the vast majority of problems organizations face are at the team and individual level. If teams don’t provide timely and accurate information to people outside the team who need it? You’ve got junk. If teams don’t manage their quality and testing? You’ve got junk. If teams don’t communicate and problem-solve effectively? You’ve got junk. If teams keep trudging along punching the clock without creatively re-framing their problems in order to make life easier? You’ve got junk.

So yes, it’s lots of fun to be helping and working on a 100,000-hour+ program. It’s even more fun to be helping set enterprise policy. But those things are way less important — and way more likely to actually hurt things instead of helping — than the small things that the teams and developers do everyday.

Trust me, it’s the small things.



Note: One of the things most people fail to understand about groups of people is how naturally decentralized they are, even in highly-centralized organizations. People think “We’ll just make a policy to do X” without any idea of how it actually is going to play out. People think if somebody is in charge of a large group of people that they can just tell folks what to do. There’s a ton of myths about how large groups of people are actually led — enough for another entry!

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy this password:

* Type or paste password here:

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>