How to Instill Agile Development Practices Among Your IT Team
The CIO at transportation company Con-way took her development team on a nine-month ride to implementing Agile—a journey that required well-honed change leadership skills
Wed, January 14, 2009
CIO — In the old days, we could spend months planning a technology project and then months or even years implementing it. Not anymore. Strategies are far more dynamic these days, especially as we respond to these challenging economic times. When someone has a good idea, they want to see it come to fruition right away.
At Con-way, almost all good ideas require technology to implement. Yet historically, ideas would become cold by the time they made it through IT steering committees, project planning and design reviews. Then we became agile—that is, we adopted Agile development practices.
Using Agile, software development is no longer accomplished through lengthy projects. Instead, the overall concept of the desired system is defined at a high level up front and then developed in short iterations. An iteration is typically no longer than one month, and the software is released for use after each iteration. As people use the software, they determine which features should be built next, providing a feedback loop that results in the highest priority functionality being built.
The adoption of Agile requires significant change in the work practices of both IT team members and business users, and this created a change-leadership challenge for me as the CIO.
One big change for IT is that with Agile, there is always an impending implementation date: There is never a feeling of being able to relax on a project. Meanwhile, developers, used to having private space, can feel that space violated due to "pair programming," which has two developers constructing the same piece of code at the same time, and to colocation, which has team members sitting as close together as humanly possible. As for the business users, Agile requires them to take a much more active role through the entire process. They must work jointly with IT to determine the priorities for each iteration, and they must provide daily direction to IT on the needs for the functionality being built.
Selling the Benefits
The challenges in transitioning the IT teams to Agile was primarily overcoming their resistance. They had become comfortable with their old techniques, and they had been successful with them. In addition, they had heard about many failures of Agile initiatives, so they were skeptical. Selling it to the business executives was equally challenging because the price tag for consultants to teach us the new methodology and for the new tools we would need to implement it was pretty steep. Plus, they had to accept that new projects would take longer, temporarily, while IT people learned the new techniques.
