Potemkin Village Agile



An interesting trend I’m noticing as Agile becomes more popular is seeing teams that say and do things that look good, but don’t seem to be accomplishing much or going anywhere. There are two types of these teams: Cargo Cult teams and Potemkin Village teams. You’ve probably heard of the first one, but the second one might be new to you.

“Potemkin Village Agile” is where everything is set up to appear as if the team has a high level of agility, but in fact it’s just another old-school project. Note that this is different from Cargo Cult Agile. Cargo Cult Agile is where teams go through the motions of doing stuff because they think that by going through the motions without understanding what they’re doing that somehow magic will happen and things will get better.

Potemkin Village Agile is under no such illusions. The goal here is just to create a nice-looking facade so that managers or whoever else will get off the team’s back so they can “get some real work done”.

These are the guys that show up at the nightclub in the cool car and expensive clothes — all of it rented. They’re the ones who want to appear smart online on a certain topic so they Google something and just rehash what Wikipedia says. These are Agile posers. In some ways, as long as they’re honest with themselves, they’re actually much better off than the Cargo Cult guys, because at least they’re under no illusion that any of it is going to amount to much.

Cargo Culters, on the other hand, are true believers who want to make it look like X because once it looks like X all of our problems will be solved. Potemkin Villagers are just putting on a puppet show for anybody who comes by to visit.

    In either case, it’s not unusual to be presented with a team that looks like it’s doing the right things but where performance sucks and folks outside the team don’t understand why. I thought it would be interesting to put together a quick list to sort out the Cargo Cult/Potemkin Village folks from the folks who may just be having a bad sprint or two. [Standard Disclaimer: As with any other list, I'm not saying teams have to conform to any of this. I'm not saying these things describe the perfect Agile team.] If you’re presented with a team that’s supposed to have a lot of agility but isn’t getting the results they’re supposed to get, take a look at this list and see what matches up and what doesn’t. You might have a CC or PVA situation on your hands.

  1. Is the team physically working alongside each other, or are they retreating to cubes or solo areas?

  2. During whatever daily chat the team has, are they focused on advancing the work, or finding work to fit whatever job roles each of them thinks they have?

  3. Do people code together, writing tests before they write solutions? And by “together”, I mean: is there a customer in the room working along with everybody else?

  4. Is the room quiet, like a library, where everybody is in their own cave, or is there a constant low-key burble while people are having a good time?

  5. Are these people you would want to hang out with?

  6. Does the team talk about important things like helping people, or are they focused on tooling and process tooling? Does most of the conversation revolve around solutions and benefits?

  7. Is everybody automatically “sharpening the saw” — making the build faster, refactoring old code, figuring out how not to have the same config issue twice — or is everybody just doing whatever is directly put in front of them without thinking of the bigger picture?

  8. Does this team look like a team that should be trusted by the people who are paying them? James Bonds or stapler guys?

  9. Does one person dominate everything, or do team members switch off during the day, leading or following as necessary to keep momentum going?

  10. Do team members easily admit ignorance and weakness to each other?

If you’re working with a Cargo Cult team, there’s a ton of literature out there about things to do. No need to rehash that here.

Oddly enough, I’ve seen several PVA teams that eventually turned out to be teams embracing real agility. It kinda goes like this: if they’re honest enough to make a goal of simply making it look good without lying to themselves or others, then they usually end up doing some things like standups or mobbing to make things look good. Funny thing, if you have an open mind and don’t actually expect anything, good or bad, pretty soon good things will happen — and you’ll be in a good mental place to take advantage of them. Whereas if you’re a Cargo Cult team, you’re thinking very rigidly. Many times are unable to see good stuff right in front of you because you’re focused on the wrong things.

If you’re working with a potential PVA team, you need to take some time to figure out whether or not they’re BSing all outsiders, i.e. a true PVA situation, or whether some folks are posers and some folks are Potemkin Villagers. The two groups have completely different ideas of where they are and what needs to happen — and each group needs to be treated differently. Complicating things is the fact that it’s not unusual to have a mixed team. (A naive suggestion would be something like “Well just sit them down and ask them all to identify with which group they’re in”. Problem: PVA folks, by definition, just want to make it look good to outsiders. They are unlikely to want to confront other team members, much less some outsider, with their belief that it’s all just a charade.) Fun times.

And if you’re on a team full of posers? The trick with being a poser is just to have fun and be honest about it! The more honesty and fun you bring to it, the better chance you might accidentally end up doing some pretty cool stuff.


Follow the author on Twitter

August 26, 2015

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>