Agile development books/tools?

February 9, 2008 8:40 AM

What books and tools would you recommend to a first-time manager of an agile development project?

Big upcoming development project that I will likely have the luxury of managing. This will be our company's focus, and I want it done right. I've worked on projects as a dev using Agile and found the iterative approach to work well. What books can you recommend to someone managing it for the first time? Also, what kind of tools would you recommend? I was thinking of looking at Basecamp or somesuch.

Our team will be about six people. I'm excited for the opportunity, and looking to really nail it.

posted by xmutex to technology (9 answers total)

One thing: I'd prefer the book to be technology agnostic. I'm thinking best practices. We're using a LAMP stack and (probably) CakePHP but this stuff can change, y'know?
posted by xmutex at 8:41 AM on February 9, 2008

The Pragmatic Programmer

There are a wide variety of books in their bookshelf line. Many of the books are focused on the developer as opposed to the manager, but you might want to take a look at Agile Retrospectives for more of a management focus. I have not read that particular book, but every other Pragmatic book that I own has been invaluable to me as a developer.
posted by Lokheed at 9:02 AM on February 9, 2008

I actually don't know the difference between what we used to call Extreme Programming and what is now referred to as Agile (but I confess, I just checked). I also found the principles laid out on extremeprogramming.org to be really useful. I know that since I was really into that stuff a lot of books have been published. My favorite software development book is probably still Steve McConnell's Rapid Application Development (not that I've read it cover-to-cover), because rather than just provide nice rules-of-thumb he backs it up with actual data (as I recall).

I suspect it's not considered an "agile" tool per se, but in terms of "XP" I have found that having a daily stand-up meeting is an extremely valuable aid to increasing productivity.
posted by thomas144 at 9:09 AM on February 9, 2008

Johanna Rothman's Manage It! covers bits of Agile and a lot of useful stuff around the edges. Lots of solid, practical advice.

From a manager's perspective, the interface between the team and the rest of the world involves a lot of planning and tracking, and dangerous stuff like "visibility". Mike Cohn's Agile Estimating and Planning will give you tools and language to develop and defend plans.

And ditto on Agile Retrospectives. Retrospectives are a great tool for keeping the team healthy.
posted by dws at 9:24 AM on February 9, 2008

I've used VersionOne for Agile Project Management.
posted by Doohickie at 11:27 AM on February 9, 2008

On the tools side, a large whiteboard, big post-it notes, a few packs of 4x6" index cards, and some Sharpie markers can carry you a long way if the team is all in the same place.
posted by dws at 2:46 PM on February 9, 2008

My friend works for one of the top Agile consulting companies - Thoughtworks.

I just asked and he recommended:

• The Manifesto for Agile Software Development
• Lean Software Development: An Agile Toolkit
• User Stories Applied: For Agile Software Development
• An article from Martin Fowler

posted by icheyne at 3:39 PM on February 9, 2008

Somehow I screwed up the User Stories Applied link.

http://safari.oreilly.com/0321205685
posted by icheyne at 4:19 PM on February 9, 2008

For sheer pragmatics, we tried using some of the TFS plug-ins to do burn down charts, but found that using FogBugz worked fine to track sprint items. I ran/run the daily SCRUM meeting and it starts absolutely on time -- those who are late pay a dollar to the Yoda bank. The actual burn down chart is done in Excel. I have a template I use that I put in the total hours for the sprint, the ideal linear burn, and a slot for each day. I enter hours remaining from FogBugz and it updates the chart with actual, ideal, and linear regression. To make things entertaining, I pick an amusing picture for the background of the chart at the start of each sprint.

It has worked very well for us as a means to find out who is doing what. From a managerial perspective, I find out who has impediments and I work to make sure the meeting moves at a brisk pace. At various times, mostly due to surprise resource conflicts, I've held stand up meetings instead of the daily SCRUM pattern, but they're a nice change.
posted by plinth at 4:25 PM on February 9, 2008