In the old days, we could spend months planning a technology project and then months or even years implementing it. Not \n\nanymore. Strategies are far more dynamic these days, especially as we respond to these challenging economic times. When \n\nsomeone has a good idea, they want to see it come to fruition right away.\n\nMore on CIO.com\nHow One CIO Was Converted to Agile\n\nGetting Clueful: 7 Things CIOs Should Know About Agile Development\n\nAt Con-way, almost all good ideas require technology to implement. Yet historically, ideas would become cold by the time they \n\nmade it through IT steering committees, project planning and design reviews. Then we became agile\u2014that is, we adopted \n\nAgile development practices.\n\nUsing Agile, \n\nsoftware development is no longer accomplished through lengthy projects. Instead, the overall concept of the desired system \n\nis defined at a high level up front and then developed in short iterations. An iteration is typically no longer than one \n\nmonth, and the software is released for use after each iteration. As people use the software, they determine which features \n\nshould be built next, providing a feedback loop that results in the highest priority functionality being built.\n\nThe adoption of Agile requires significant change in the work practices of both IT team members and business users, and this \n\ncreated a change-leadership challenge for me as the CIO.\n\nOne big change for IT is that with Agile, there is always an impending implementation date: There is never a feeling of being \n\nable to relax on a project. Meanwhile, developers, used to having private space, can feel that space violated due to "pair \n\nprogramming," which has two developers constructing the same piece of code at the same time, and to colocation, which has \n\nteam members sitting as close together as humanly possible. As for the business users, Agile requires them to take a much \n\nmore active role through the entire process. They must work jointly with IT to determine the priorities for each iteration, \n\nand they must provide daily direction to IT on the needs for the functionality being built.\n\nSelling the Benefits\n\nThe challenges in transitioning the IT teams to Agile was primarily overcoming their resistance. They had become comfortable \n\nwith their old techniques, and they had been successful with them. In addition, they had heard about many failures of Agile initiatives, so they were \n\nskeptical. Selling it to the business executives was equally challenging because the price tag for consultants to teach us \n\nthe new methodology and for the new tools we would need to implement it was pretty steep. Plus, they had to accept that new \n\nprojects would take longer, temporarily, while IT people learned the new techniques.\n\nI made the case for change in IT by explaining how the business would benefit if we delivered the highest priority \n\nfunctionality faster. I also kept reiterating what was in it for them\u2014and there was a lot. Agile automates many of the \n\nmundane tasks that are not popular with software developers. For example, when changes are made to code, Agile techniques \n\nautomatically integrate the code with surrounding functions and execute predefined regression tests. Most IT professionals \n\nare not fond of performing these tasks manually.\n\nI made the case for change to the business by preparing a solid ROI that quantified the benefits of increasing the efficiency of \n\ndevelopment processes, delivering the right functionality more quickly and reducing the overall amount of work in progress. \n\nFor instance, I proposed that Agile would improve developer efficiency by 35 \npercent. In many forums, I repeated the \n\nbusiness drivers and showed my colleagues how we were tracking on achieving the ROI.\n\nEven though we have dozens of project teams and hundreds of developers, I made a commitment to spend time (during some \n\nperiods about a third of my time) with the development teams and listen to their concerns. From this I learned about their \n\nresistance to the strict adherence to the Agile definition prescribed by the consultants we hired. The developers especially \n\ndidn't like being forced to work in pairs or sit near each other, and they believed they should be able to decide \n\nindividually whether to adopt those practices.\n\nI was concerned we'd miss out on significant benefits of Agile if we didn't follow those practices, so I made a rule that \n\nevery person had to initially follow the practices precisely. I told them that as they became knowledgeable in the practices \n\nthey could tweak them, and when they really understood them they could decide which ones to adopt. So far most people who \n\nhave experienced the practices have decided to adopt them for the long term.\n\nCalming the Storms\n\nNot everything has gone smoothly. New teams typically go through four stages: forming, "storming," norming and then \n\nperforming. What I didn't know was that when you change an existing team's fundamental work practices, they start over again \n\nin the forming stage.\n\nTeams that had been working well together for years suddenly began exhibiting "storming" behaviors, including fluctuations in \n\nattitudes, arguing over trivial issues and excessive tension and concern about being overworked. Now I'm making sure that as \n\nteams go through the transition, they are conscious of the fact that they need to reset their norms and that they set aside \n\ntime to do it.\n\nThe change effort has been worth it: After nine months, Agile is delivering on its promises. The iterative approach to \n\nsoftware development is providing a feedback loop that results in us building the right functionality. We no longer have the \n\nwaste problem that was inherent in the old waterfall method. Agile is creating greater alignment between IT and the business \n\nbecause of the constant, daily interaction and because Agile techniques help IT personnel understand the business better.\n\nLike 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 \n\ntheir organization down the Agile path, it's essential to brush up on change leadership best practices. Most importantly, \n\ncreate an environment where your teams are comfortable with venting their concerns so you'll know what's working and what you \n\nneed to modify.