Agile development books/tools?
February 9, 2008 8:40 AM Subscribe
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.
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.
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
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
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
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
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
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:
posted by icheyne at 3:39 PM on February 9, 2008 [1 favorite]
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 [1 favorite]
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
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
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
« Older How can my current hair become David Tennant's... | intramedullary nails versus plating Newer »
This thread is closed to new comments.
posted by xmutex at 8:41 AM on February 9, 2008