It used to be that 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, and historically, ideas would become cold by the time they made it through IT steering committees, project planning, and design reviews. But then we became Agile.
With Agile practices, the development of software 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 short iterations are used to develop it. An iteration is typically no longer than one month, and the software is released for use after each iteration. As the users utilize the software, they then 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 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, so there is never a feeling of being able to relax on a project. And a developer’s private space can feel violated due to pair-programming, which has two developers constructing the same piece of code at the same time, and due to co-location, which has the team 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, rather than their traditional roles at the beginning and end of projects. They must work closely with IT to jointly determine the priorities for each iteration, and they must provide daily direction to IT on the needs for the functionality being built.
The challenge in transitioning the IT teams to Agile was primarily overcoming resistance. They had become comfortable with their old techniques, which had been successful for them. 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 and new tools was pretty steep. Plus, they had to accept that projects were going to take longer while IT people learned the new techniques.
I made the case for change in IT by explaining to employees 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 pre-defined 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 lowering work in process. For instance, I proposed that Agile would improve developer efficiency by 35 percent. In many forums, I kept repeating the business drivers and showed the quantified results of 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 (at some periods about a third of my time) with the 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 pair-program or co-locate, and they believed they should be able to decide individually whether or not 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 set the rule that every person had to initially follow the practices precisely, but as they became knowledgeable in the practices they could tweak them. Once they really understood them they could decide which ones to adopt. This has worked well, and so far most people who have experienced the practices have decided to adopt them for the long term.
But not everything has gone smoothly. New teams typically go through four stages: forming, storming, norming and performing. What I didn’t know was that when you change the fundamentals on existing teams, 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. I’m now making sure that as teams go through the transition, they are conscious of the fact that they need to re-set their norms and that they set aside time to do it.
The change effort has been worth it. After nine months of transition, Agile is delivering on its promises. The iterative approach of Agile is providing a feedback loop that results in the right functionality being built, so 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 the techniques help IT personnel understand the business better.
Like anything that’s really going to pay off, Agile is a huge change initiative 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 venting their concerns, so you’ll know what’s working and what you need to modify.
Jackie Barretta is CIO and Vice President of transportation company Con-way Inc., and a member of the CIO Executive Council.
