Posted by: Doug Geiger | 2011/08/05

Learning to be agile (while learning to use Agile)


I was wrong about Agile

Rarely have I been so wrong as I was about the merits of Agile project management over traditional PMI or “waterfall” project management. As with most errors, this error was caused by mixing ignorance with hubris. Agile is a style of low-overhead project management that overlays a few key principles and practices around a general attitude of “we will figure it out as we go along.” What I had heard about Agile, before practicing it, made it seem like some sort of hippie inspired, systematic dismantling of accountability. I figured there must be something to it, but wasn’t exactly thrilled about it. There are no Gantt charts or PERT analysis. No work breakdown structures or signed change-orders. Instead, there was a lot of talking directly to the clients that will use the software and a lot of changes on the fly. Also, intriguingly, Agile welcomes change.

At least I was wrong for all the right reasons.

In my experience on a construction site, where I was responsible for the IT infrastructure and vendor management for a new hotel in Miami Beach, there were not a lot of warm fuzzies floating around between anyone. This was a high-pressure, low-trust, cover-your-ass project and required coordinating costs, timelines, expectations and tempers. Battle-scarred and worldly-wiser I came out of that experience committed to doubling down on documentation and planning, and sick of foamy pastels (the prevailing “style” of Miami architecture). If we had just had Marty sign the damned form on the first date this problem was noticed, we wouldn’t be dealing with this now! In my defence, you don’t work 14-hour stress-filled days, a thousand miles from your wife (who is in her second trimester), while dealing with a cantankerous Frenchmen for months without coming out the other end with a few ticks and twitches.

I needed new tools

When I transitioned to Quicken Loans, I knew that the culture was very different from that sweatbox project in Miami Beach, and I did my best to adapt to a healthy and positive culture by going easy on the bureaucratic side of project management, but in my heart of hearts there still sung a refrain, “if I could just plan it better, all will be well.” When our PMO team went to a PMI (Project Management Institute) styled training course, I was glad to bone up on some old school project management techniques. As a team, we strained the mud of PMI dogma through the sieve of practicality and were left with a few key nuggets of value. Later, we attended an Agile training course and I walked out a believer in the potential of Agile as a real-world approach. It took a couple months to relax and learn that shipping quality was more important here than politics.

Agility is having a big tool box and then choosing the right tool

As a professional problem solver–whether business consultant, tech writer, business analyst, or project manager–there are two sins we must avoid:

  1. Don’t make the same mistake twice
  2. Don’t fight the last war
In an effort to avoid sin #1, following my experience in Miami, and vowing to myself to never be unprepared or un-CYA’d again in a project, I subconsciously gravitated to sin #2 by eschewing a new toolkit, Agile project management. What I came to learn was that as a professional problem solver I must not only keep my old tools oiled and available, but also continually add new ones. The art of our craft is, and will always be, to know what this project or this stakeholder requires and provide that.
At the geometric rate of change is technology, in 10 years something will probably come along that solves problems Agile doesn’t handle gracefully. Will I make the mistake twice of blowing off new tools before I understand them? When that day comes, will I still be fighting today’s battle and fail to adapt? I hope not. I hope never to commit sin #1 again.


%d bloggers like this: