First, a little fun. I found this survey asking just that question, but in a humorous way. Here are the results, which were presented at the Agile 2008 conference in Toronto. I also found (through LinkedIn) a post on Peter DeYoe’s blog with a humorous job posting for a Scrum Master.
Now for a real live case study. In my job hunting, I discovered this article by Damon Pool on Litle & Co. The reason I like this story so much is that not only did the push for Agile come from the top, but they started out that way. They didn’t adopt Agile, they were born with it. That eliminates a lot of problems that come along with trying to adopt Agile later on:
- You don’t have to convince your employees, because you don’t have any yet. You simply hire those who already drank the Kool-Aid.
- Upper Management sometimes tentatively agree to try Agile without fully buying into the concept of not having solid long-term timetables. When [the developers] talked to Tim Litle, the founder and Chairman, about using Extreme Programming (XP) they told him “you’ll have to accept that we won’t be able to tell you exactly what we will deliver in 9 months.” Tim said, “That’s fine with me, I’ve never gotten that anyway!”. This was one of the major points I accentuated when I rolled out Agile practices at Aptima; there’s nothing lost in giving up planning out the next year or so of a project, because the numbers and dates are all lies anyway. Having confidence that you know roughly when things should be done, and that when it’s done it will be exactly what’s needed at the time it’s done, is much more valuable.
- You don’t have to spend a lot of seemingly thankless (at the time) energy writing unit tests for existing legacy code. It’s not just that writing tests for code that you think already works can be “unfulfilling”, but legacy code that wasn’t written with unit testing in mind can be hard to write unit tests for without refactoring, possibly adding bugs. Sometimes legacy code is not broken up into small enough functionality to unit test easily, or don’t offer enough exposure to what they’re doing to accurately compare the expected and actual results.
- When Agile starts from the Software group and works its way out, it can be very hard to get the rest of the company to work the same rhythm. While this article points out that it took some time to work smoothly, it wasn’t like most of the uphill battles I’ve heard about.