I’ve been thinking a lot about project management lately, given that we are about to dive head-first into another release of Geocortex Essentials. During this development cycle, we’ve decided to adopt a number of Agile development practices. For those new to Agile, Agile Development is best characterized by a number of development practices which include
- Frequent and sustained customer involvement with developers.
- The use of automated tools including Continuous Integration and Revision Control Systems.
- Short development iterations that are normally 2-3 weeks in length.
- The use of the Test-Driven development methodology.
- The adoption of simple designs that get the job done.
Of course this is an over simplification as there are many Agile methodologies, however, most of these practices are common to each of them.
I must admit that at first I was a little sceptical that Agile would really work in practice, but then I re-read a chapter from a textbook used in a project management course I recently took. In it I found a list of success factors for successful software projects which include
- Executive Support
- User involvement
- Clear business objectives
- Formal methodology
- Minimized scope.
It’s not hard to see the parallels between Agile practices and these success factors. Given that, it seems to me that many Agile practices can only help make the execution of a software project better.
I’ll let you know how it works out
If you haven’t already run across them, the guys at 37signials (http://www.37signals.com/svn/) post some pretty interesting thoughts on this subject. I highly recommend their eBook “Getting Real” (http://gettingreal.37signals.com/toc.php) to anyone working on web-based applications.
@James-Yeah, good recommendation. I too am a fan of 37signals. I bought/downloaded a copy of Getting Real a couple years ago, and I’d say I got something out of pretty much every chapter. One thing; some of their snappy, counter-intuitive rules sound good, but I wonder if some of them are maybe a little too pert and/or oversimplified if not taken in the right context. Nonetheless, we apply many of the great ideas and concepts discussed by 37signals to our product development. For me, Getting Real also drove home the point that in software development, bigger isn’t necessarily better, and being relatively small can actually be advantageous if you approach things right.