Following the Charles Darwin's statement “To change is difficult. Not to change is fatal,” application development professionals always seem to be in the process of change. Changing technology, adopting new practices and methods, and introducing new organizations are just a few of the things that most application delivery shops are changing at any time. But how is that change being undertaken? How do these change programs get managed? And more importantly, how does all this change fit together? During 2010, Diego Lo Giudice and I asked these very questions and have recently published a report describing our findings. This blog describes our findings at a high level:

Where does change come from?

Having interviewed 75 companies that were in the midst of change, we found that, perhaps not surprisingly, change was being driven from a multitude of sources. Bottom-up change was coming from practitioners. Technology Populism seems to be rampant in most companies, with individuals bringing in their favorite technology or practice. In parallel with this grass-roots adoption model is top-down, executive-driven change. The majority of organizations we interviewed had executive-driven change programs around process, organization, or technology. Rarely did we see the bottom-up change being integrated with the funded, top-down approaches. The result was often confusing, with ideas clashing and change initiatives running against each other. At best, the practitioners ignored the top-down ideas; at worst, they blatantly undermined these ideas because they were different from their own ideas.  

How is change managed?

Again, a varied collection of answers, but consistently we found that even if change was not planned, the most-effective change programs had clear leadership and a strong communication plan. Also, another interesting characteristic of successful changes was that they were associated with a brand, such as Agile, or Lean, or SOA. The association with a brand helped define the scope of the change but also helped market it to other groups. Even with clear leadership, many change initiatives found measuring their value difficult. For example, we heard of many poorly quantified Agile adoptions. Managing without a clear benefit that could be measured may undermine the change program.

A holistic approach to change

Though every change initiative was different and every organization used a different name to describe its approach, there were enough commonalities to draw together a framework to allow application development professionals to integrate their ideas into a holistic approach. Lean, the central theme of our change framework, provides an underlying paradigm or context that provides a useful general strategy and techniques that can be used to make the change work. Lean also has a strong community, which offers opportunities to post ideas and take advantage of commentary. The other four elements of the framework are: 

  • Management framework for strategy. The first key element of the change approach. Included in this area are measurement, communication, understanding the value streams, and using a change framework. The value stream element we took from Lean Thinking is in direct response to the need to understand the different processes that a software delivery organization needs to support. Too many times we saw change being applied across the board without any consideration to the flows it was changing and the fact that these flows were different. For example, one client we talked to wanted to apply Scrum to all work without considering that some work cannot be undertaken by a team or planned into sprints.
  • Align with the business. Sounds simple, but most organizations do not consider how they connect to the business. By approaching the problem from a value stream perspective, it is possible to define the best engagement model for that value stream. For example, streams that are in support of high-risk and high-value business processes will often require embedded development teams. For flows where the pace of change is much slower and the business is fragmented, a more traditional approach to delivery would work.
  • Agile processes and HEROes. A large number of the change programs that we encountered focused on process and, in particular, Agile processes. But process change also requires the identification and empowerment of HEROes to drive the process.
  • Enabling technology and infrastructure. The final part of our framework, which links technology to the other elements. During the research, we often found that technology change was poorly linked to other aspects of change; process, people, and alignment were often afterthoughts to the adoption of a new approach. By linking technology into a broader change program, not only does the technology make more sense but it is also possible to exploit its value to a much greater extent.

 
What application delivery professionals can do today

Adopting the complete framework looks like a daunting task, but instead app dev pros should look to the framework to help make their change more effective, using the framework to ask questions of their change — and from those questions build a plan that reduces risk and encourages success. In particular app dev pros:

  • Should not consider change in isolation. Look to how change can take advantage of change programs that are already in place. By building bridges between change initiatives and other initiatives, it is possible to share resources and build a more complete approach.
  • Must remember that technology and the softer areas need to be paired. Just focusing on technology or process is not as effective as grouping them into an integrated approach.
  • Must remember that measurement is important. Though measuring things is often difficult, change programs without a clear measurement plan are not as effective as ones that have a measurement plan. Measurement provides credibility to any change program.

Diego and I are continuing our research on change and transformation and would love hear from you.  

If this is an interesting topic to you, we suggest you access the following related resources the research has spurred:

  1. Attend Diego and Dave’s Application Delivery Transformation Workshop in Las Vegas

May 24| Las Vegas:http://www.forrester.com/events/eventdetail/0,9179,2529,00.html

2.   For clients only: Read the transformation report.