Business

CIO en VO : comment un CIO devint agile

Le CIO de Con-way, une compagnie de transport américaine, témoigne du passage de sa DSI au développement agile.

Publicité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. I made the case for change in IT by explaining how the business would benefit if we delivered the highest priority functionality faster. I also kept reiterating what was in it for them-and there was a lot. Agile automates many of the mundane tasks that are not popular with software developers. For example, when changes are made to code, Agile techniques automatically integrate the code with surrounding functions and execute predefined regression tests. Most IT professionals are not fond of performing these tasks manually. I made the case for change to the business by preparing a solid ROI that quantified the benefits of increasing the efficiency of development processes, delivering the right functionality more quickly and reducing the overall amount of work in progress. For instance, I proposed that Agile would improve developer efficiency by 35 percent. In many forums, I repeated the business drivers and showed my colleagues how we were tracking on achieving the ROI. Even though we have dozens of project teams and hundreds of developers, I made a commitment to spend time (during some periods about a third of my time) with the development teams and listen to their concerns. From this I learned about their resistance to the strict adherence to the Agile definition prescribed by the consultants we hired. The developers especially didn't like being forced to work in pairs or sit near each other, and they believed they should be able to decide individually whether to adopt those practices. I was concerned we'd miss out on significant benefits of Agile if we didn't follow those practices, so I made a rule that every person had to initially follow the practices precisely. I told them that as they became knowledgeable in the practices they could tweak them, and when they really understood them they could decide which ones to adopt. So far most people who have experienced the practices have decided to adopt them for the long term. Calming the Storms Not everything has gone smoothly. New teams typically go through four stages: forming, "storming," norming and then performing. What I didn't know was that when you change an existing team's fundamental work practices, they start over again in the forming stage. Teams that had been working well together for years suddenly began exhibiting "storming" behaviors, including fluctuations in attitudes, arguing over trivial issues and excessive tension and concern about being overworked. Now I'm making sure that as teams go through the transition, they are conscious of the fact that they need to reset their norms and that they set aside time to do it. The change effort has been worth it: After nine months, Agile is delivering on its promises. The iterative approach to software development is providing a feedback loop that results in us building the right functionality. We no longer have the waste problem that was inherent in the old waterfall method. Agile is creating greater alignment between IT and the business because of the constant, daily interaction and because Agile techniques help IT personnel understand the business better. Like anything that's really going to pay off, Agile is a huge change for IT and the user community. For CIOs who want to lead their organization down the Agile path, it's essential to brush up on change leadership best practices. Most importantly, create an environment where your teams are comfortable with venting their concerns so you'll know what's working and what you need to modify. Jackie Barretta - © 2008 CXO Media Inc.