Speck on a Whale

You see, teams are bigger than any one person. The group is collectively smarter, more clever, faster, and most capable than any of its members. This means that as part of an agile team you have to put your trust in your colleagues. You have to let go.

This is tough to do! Most PMs I know -- heck most technical people -- want to exercise control over where the team is going. Even if the project is total BS, by golly, you want it to be your BS.

So we're sitting around in the room. I missed the previous meeting, where the rest of the group had created a doc. Now we were doing what teams do daily everywhere -- we were asking "What's the problem". That is, what's wrong with the doc? So I made a key argument and spent an hour (!) thrashing around trying to make it stick.

No go. I raised a risk with the product that the rest of the group didn't vet. So we move forward.

It's really great when you trust a team like this. Liberating, in fact. You don't have to bear all the responsibiilty: we're all in this together. In a good team, if you're right and lose an argument, guess what? We'll figure it out later. It's not the end of the world. If you're wrong and win an argument, the same thing holds true. Agile teams are always testing out what works and what doesn't and changing appropriately. That means it's okay to be wrong. To give up control.

But oddly enough, the same attributes can make Agile Coaching a really, really tough thing to do.

I had a team once that was convinced that it didn't want to change the way it worked. Not that the way it was working was effective -- nobody, including the PM, liked the situation. But small timeboxes? Putting code into behavior-based stories that are tested each iteration? Making the architecture fit the project? It was just too much.

So the fun begins. When I stood up to explain one of these concepts, I get a dozen people in the room telling me how impossible it is to accomplish. Want to show a "Hello World" splash screen? Well gee guy, there's all sorts of things we must consider! Security, logging, data sources, layer configuration, privacy issues, astrological signs, etc. These are all very important! This is a very delicate situation!

I'm a technical guy. I can handle any and all of these problems.

But the team was throwing out things faster than I could keep up. In fact, it was faster than anybody could keep up. Turns out that the team was much better at coming up with reasons that I was wrong that I was at convincing them that they needed to change.

When you're in a group, it's like being a speck on a whale. If it all works well, you're in for a great ride! But even if it doesn't work so well, it's still going to be a lot of fun.

So what to do with my team? Same thing as anybody would do on an agile team: make a logical case, be humble, try to understand what people are telling you. Focus on identifying and attacking what's wrong with the project. Let your ego go. If you do that, it usually all works out.

If you want to be a good speck on the whale, you got to have faith in the whale.