Why political candidates can’t do agile

Regardless of who the candidate is or how competitive the race might be, the political animal is a creature of habit. If you took those habits and applied them to an agile software project, there’s almost no chance that things would turn out well.

• Politicians live in a world where they need to make promises that they have no idea how they are going to keep. Who’s going to pay for that bridge to nowhere? Not my taxpayers. Agile projects need a world where almost no specific promise would ever be made until it’s right on the cusp of being delivered with quality.
• Politicians love to give pretty the same speech over and over again: once they’ve found what whips up the crowd, they’ll push that button until they wear it out. Agile projects require priorities to be re-thought with each sprint, and talking points to evolve.
• A politician’s promises are additive: the new ones don’t replace or supersede those made during the last debate. So the collective pile of promises ratchets ever upward. Agile projects call for constant tradeoffs, and each new sprint tries to start with a fresh priority list. A new “promise” can’t be made without de-prioritizing (read: sacrificing) some of the old ones.
• Political promises are made with the idea that any obstacle can be overcome (or simply removed) if only we had a change of leadership. Since each politician’s personal leadership is the solution, they tend to be very poor delegators. Often, they don’t really trust the people underneath them. Agile can’t do its magic unless the leaders trust the scrum team to make really good decisions and consistently delegate to them.

What’s ironic about all this is that the day after the election, the winning politician suddenly lives in the ultimate agile world:

• If the Congressional session is interpreted as a sprint, then the Speaker of the House and leader of the Senate are the scrum masters.
• In a Congressional session, there is no promise of performance or deliverables. There are only two things that you can state with certainty before or during a Congress: The sprint will take exactly two years and they will spend about 10 percent more money than they actually have.
• The output of the sprint is only as good as the effective intelligence of the players and the teamwork of the Congress. The challenge is to make the effective intelligence the “high water mark” rather than the “lowest common denominator” among 435 “adults.” Good luck with that.
• If you don’t accept the idea that compromise and horse-trading are part of the process, nothing can be produced.
• All the bloviation in the world will not get anything done. The politician depends upon his/her staff and the underlying bureaucracy (read: the scrum team) to make things happen.

It’s no wonder that the popularity of Congress is below 10 percent: the things that made congresspeople attractive as candidates make them unable to achieve anything concrete in session.

Now, very few people reading this article want to become politicians, but quite a few would like to become effective at leading agile teams. The thing is, you need political savvy for project management success. Here are my top five lessons:

• Agile projects are rarely able to flourish without significant political/managerial air cover. Agile isn’t inherently sexy, doesn’t fit well with politically charged environments and, if anything, veers to the nerd side of things. Without powerful championship, an agile project is doomed.
• Agile projects succeed because they do less “make work” and deliver more of what really matters. So promises should be framed in the light of “we’re doing only what’s essential right now, and anything that is optional must get delayed to later phases.” You must deftly and consistently notify people that some of their favorite-but-silly-items won’t be done until there’s budget for it. Use this line of thinking to form alliances and support from the CFO.
• A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. Agile should inherently involve frequent 1:1 contact with users: use that time to lower expectations! Without this habit, the inevitable scope creep and the impulse to believe “of course the system will do X for me” will get you.
• A key success factor of an agile project is the project lead’s ability to move quickly, glomming on to whatever hot topic is going to be easy to sell to corporate leadership. Agile’s proclivity for producing demos can make it downright sizzle-icious. So make sure there’s a cool demo for each sprint.
• Agile projects are most effective when the environment is changing quickly and a big-bang release — any big-bang release — will involve a lot of waste. Agile project teams should focus everyone’s attention on delivering quickly and incrementally, and any impulse toward perfectionism or a slower release cycle must be firmly resisted.

It’s true that agile was conceived of as a way of bypassing bureaucracy and internal politics. But without the right kind of political reflexes, agile teams have a seriously uphill battle.