The right way to do Agile

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

The best implementation of Agile that I’ve seen was when I was at ShermansTravel.com and Mark Herschberg was CTO. The system went like this:

Herschberg reckoned that each developer could get 5 hours of real work done each day (the rest of the day got eaten up by email, conversations, research, and other incidentals). We had a crew of 5 programmers, so we had 125 hours a week of real programming. The sprints were 2 weeks long, so we had 250 hours in a sprint.

Each department could submit requests, and as soon as the request came in, one of us developers would estimate the time it would take. So, for instance, the Editorial team might complain about the images being mis-aligned on the blog, and a developer would estimate that it would take 1 hour to fix. And the Advertising team might tell us we have a new client who wanted us to add some massive amount of Javascript to our site, to load a particular ad, and a developer would estimate the work at 5 hours. And the Finance department might complain that our measured click-through rate was in major disagreement with what neutral 3rd parties were reporting, so a developer would estimate that it would take 12 hours to crawl through our reports and find the error.

There would be a great backlog of requests. Advertising might easily have 150 hours of requests pending, and Editorial might have 220 hours of requests pending.

Herschberg gave each department a budget of hours. Perhaps Editorial got 80 and Advertising got 60 and Finance got 70 and Sales got 40. The departments could negotiate among themselves, and trade hours back and forth, just so long as it added up to 250 hours for a 2 week sprint.

We didn’t waste much time on estimation. We didn’t waste too much time on process. This was a fairly lean implementation of Agile.

The crucial thing was that we used Agile as a tool for honesty. We had explicitly political goals: to manage the expectations of the other departments. We weren’t especially focused on measuring our own progress; the biggest benefits was that each department was forced to see that the other departments all had compelling demands, and therefore no department deserved to get the exclusive attention of the tech team. We thus avoided that terrible political situation, which I’ve seen elsewhere, where Presidents of various departments sneak over to the tech team and secretly ask “Please make my department your #1 priority”.

In other words, we used Agile as a tool to promote an honest understanding of what was going on with tech. Each department saw our finite limits, and each department saw the demands of the other departments. The transparency was beneficial to the whole organization.

Source