Agile development practices can greatly benefit any software development effort. By its very definition, an agile practice allows teams to switch gears with relative ease compared to earlier methods such as the waterfall design process. However, for a team — or even an individual — making the change to agile practices can be quite intimidating. Here’s some tools and tips to get you started.
One of the cornerstones of any successful project is ensuring changes don’t break the build. Incorporating a continuous integration system automates the build and testing process so that developers can make their changes to a project and find out fairly quickly (usually within minutes) whether or not they broke other parts of the application.
The Hudson Continuous Integration System is an open source Java-based build server. It includes a large core feature set capable of handling most projects, and also has a large set of community developed plug-ins to extend the system in ways that make it virtually indispensable.
Other good build systems to check out are Cruise Control (also Java-based) and it’s related .NET project, CruiseControl.NET.
There’s several other decent continuous integrations servers available; be sure to test out a few before committing to one, as they all have different strengths and weaknesses.
One of the core requirements of a good agile environment is keeping track of what’s requested, what’s planned, and what’s being worked on. There are countless ways of tracking different project features, ranging from simple Word documents and Excel Spreadsheets to full-fledged, high-end commercial management systems.
A good application to start with for a new agile team is the ScrumWorks system. It’s available in both a paid professional version and a limited free version, both of which offer a good feature set to
get your agile process off the ground. It allows keeping track of iterations and releases, a backlog of items planned for future development, and individual tasks required for each feature implementation.
Again, there’s a lot of great software available for project management, and even though ScrumWorks is a good starting point, you would be well served to look around for other systems. Every team is different, with different strengths and weaknesses; find one that plays well to your needs.
A lot of developers hate meetings, mainly because it takes away from what they love to do: write code. Unfortunately, regularly scheduled meetings are necessary to keep development teams on task. Certain agile practices, such as Scrum, recommend short meetings every day to cover what each developer has worked on previously, what they’re planning on working on that day, and what (if anything) is holding them up.
In most agile practices, development is normally broken up into sprints or iterations. These are normally 2-3 weeks, though they can be any reasonable length of time. At the beginning of each sprint, the team holds a fairly lengthy set of meetings. These cover what was accomplished in the previous sprint — normally involving non-developers who have an interest in the work — and what the teams are planning on accomplishing in the next sprint.
These regular meetings will definitely seem to be a waste initially, as most developers who aren’t used to an agile environment will see little point in them. After some time, however, the benefits will be noticed as developers begin to get better understandings of what the features are supposed to accomplish, and the rhythm of the iterations will keep the team focused in delivering usable functionality on a regular basis.
This is by far the most important requirement in converting to an agile development method. In the initial stages, it will be hard to keep to the schedules, as most of those involved are used to delivering functionality on a mostly random basis (generally "as soon as humanly possible, if not sooner"). It’ll take time for everyone to get used to having to wait. It’ll also take time to get used to the procedures involved, and to using different management tools — especially if the primary management tools had always been email and notepads.
Depending on the size of the development team and those involved in the development process, getting used to the agile procedures can take months or even years. But it will pay off, and the development process can start to see noticeable improvements in even a couple of sprints if the development team is committed to converting to the new process.
A lot of managers and companies have a hard time bringing themselves to start the conversion. There’s always a "better time" in the future — after this project is finished, or we’ll do it for this other project coming up. The best time to start with agile development is now. It won’t be any easier in the future — there will always be another project that needs to get finished, or another project that might be a "better" candidate for agile processes. If you keep waiting for the "right" time, you’ll never get started, and you’ll never get to reap the benefits that agile development can bring for you.