Agile software development, which emphasizes collaboration, self-organizing teams and iterative or incremental releases, is starting to gather steam. Forrester Research reported earlier this year that 45 percent of 1,300 developers and IT professionals surveyed now use agile methods.
Why all the interest in agile development?
The Standish Group reports that the success rate of software development projects is only about 32 percent. One often-cited reason for project failure is that functional requirements change during the course of a project, reflecting the continuously evolving business practices and opportunities of the sponsoring organization. It's difficult to predict what the organization might need 12 to 18 months in advance. And even if you could, why would you want technology that's more than a year old?
One of my goals has been to take the principles associated with agile software development and apply them to broader IT functions. Based on my experiences at SUNY Delhi and now at UMassOnline, here are some tips for getting started with agile project management:
The percentage of software projects that fail because the requirements originally set were unattainable
Source: Forrester Research
- Release services and systems incrementally and strive for continuous feedback. The first rule is to release early and release often. Think Google: Initially they rolled out Google search and then slowly added and retained new services based on what people actually used. Especially at the outset of a project, remember that neither the users nor the developers have a complete understanding of what the organization really needs, so trust that as you release incremental enhancements over time, further solutions and direction will emerge. This strategy reduces risk because if an update doesn't meet your needs, you can take it offline without exhausting your entire budget.
For example, when we rolled out security cameras at SUNY Delhi, rather than undertaking a campuswide site survey and defining specific functionality for each camera location, we started by asking campus police to identify crime hot spots, and we installed basic cameras at those locations. Only after the cameras were in place could the officers see what was possible and what was missing. If we were wrong about a location or the functionality, it was easy to shift the camera to another spot. We didn't have campuswide coverage until several months later, once patterns began to emerge.
- Foster transparency and collaboration. Here's where you can use a Web 2.0 tool such as a wiki. Rather than confining development to a front-loaded plan or limited internal resources, tap your organization's knowledge base by opening up the project to everyone through a wiki. At SUNY Delhi, we deployed a new learning management system and had an ongoing discussion about how to provide integration with a student information system on our wiki. A developer from the University of Oakland found our discussion and provided the solution.
- Promote self-organizing teams. Traditionally, campuses have operated hierarchically with centralized decision-making, or within silos based on functional areas. Self-organizing teams can find projects of interest throughout the enterprise based on professional or personal affinity. Once a team forms, roles and responsibilities are determined by the group members themselves and may be different from those listed in their job descriptions.
Clearly, something has to change at today's budget-constrained colleges and universities where the costs of failed IT projects are increasingly difficult to absorb. Using agile methods, SUNY Delhi realized savings of more than $425,000, all the while expanding IT services to the campus.
As author and agile proponent Jim Highsmith recommends, development should occur at the same pace that users can articulate needs. It's easy to say, but difficult to execute. Start by rolling out services incrementally and fostering a culture that embraces collaboration.