The Eight Cs of Transformational Change

By: Innovation Management

Agile Innovation is an execution-based model, not a control-based model. This means that the focus is on what you do (execution) rather than on what you are instructed to do. Hence, this approach requires inner motivation, and it’s not going to thrive in environments characterized by extrinsic, hierarchical, or fear-based motivational schemes. In this final excerpt from Agile Innovation, Langdon Morris discusses approaches necessary to transform organizations to achieve innovation actions and outcomes.

Transforming Execution – From Assumptions to Evidence

Agile Innovation generally takes as its goal to turn product visions into reality as soon as possible, not by developing voluminous plans and schedules to explain, defend, justify, or comply with the demands of external authorities. To enable this shift from compliance to performance, consider the next three principles:

• Constructive leadership takes appropriate risks by adopting incremental business cases to enable faster product cycles.
• Collaboration happens more effectively in smaller Agile teams and stand-up meetings than in monolithic project teams and traditional death march meetings.
• Continuous learning is implemented through retrospective reflection, analysis, and feedback. We learn from what we did, and we conduct sincere and open dialog to maximize the learning.

The shift from focusing on comprehensive documentation to delivering software that works resulted in programmers who were liberated to get better at execution. Programmers were freed from death-by- meetings and could instead concentrate on the thing they loved (programming). However, accomplishing this required a new social contract, a new way of organizing, because it changed the nature of accountability and coordination.

Because coordination is still necessary, the Agile movement addresses this with a single daily meeting. To keep it from becoming a long and drawn-out affair, it’s a very brief stand-up session, lasting about 10 minutes. Programmers also agree to daily self-reporting of their work results, which enables daily tracking of their progress. This approach provides much greater visibility into their work, which as a side benefit is also a very effective way to identify which programmers really produce and which are the laggards.

The result is an increase in both productivity and accountability, and programmers themselves gain a welcome sense of autonomy and control over their own time.

From this perspective, which shows us Agile as the design of a social system, one has to admire the subtle and effective use of logic and innovation. A process that was clearly broken—writing large-scale software systems—was transformed from within by people who had direct experience with what worked, what didn’t work, and what they wanted to achieve. The phenomenon of Agile and its rapid growth is, in fact, a great example of the power of design thinking to transform work and life.

Applying these same insights to the broader process of innovation leads us to these key insights.

First, moving from advance preparation of comprehensive business cases to the progressive development of incremental business cases that evolve during a project liberates innovation teams to move faster and with greater agility to deliver working prototypes, prototypes that can then be tested to gain genuine market insights.

Second, from such insights can then come much better business cases, more accurate market assessments, and substantiated revenue models. This is enabled because—and this is important—instead of working from assumptions and desires, the innovation team has accumulated real data, real prototypes, real experience, and real evidence from actual customers about their genuine behaviors, attitudes, and willingness to buy.

The transformational shift from assumption-based decisions to the evidence-based decisions is a fundamental theme in Agile Innovation.

Transforming time: from meetings to productivity

A similar transformation concerning time management is also embedded in the Agile approach. In particular, Agile is adamant that meetings are generally undesirable time wasters, so the Agile approach consistently strives to minimize time spent in meetings. (The same concept is applicable not only for software developers, but also for employees throughout the organization, particularly by using techniques that we describe later.)

Evidence suggests that typical American managers have an average of three meetings per day, and many who deal with complex and interdisciplinary projects are often forced to handle five or six. This means that essentially the entire day is spent either in meetings, or responding to e-mail, which is, in fact, a form of virtual meeting.

What are the consequences?

For one thing, it’s a very reactive work style. Proactive initiatives are rare if not impossible when we spend all day reacting to the constant stream of new inputs and requests. Where is the thinking time? It’s gone.

Not long ago we worked with a manager, someone exceptionally talented and overseeing massive and steady growth, who organized her schedule into 15-minute blocks. Because her associates had access to her calendar, 9 hours of her 8-hour day were regularly booked. This was obviously not sustainable, although she had somehow managed to survive with this schedule for about three years. We suggested she take the radical step of reserving 2 hours each day for no meetings at all. Stress went down, and somehow all those important decisions still got made.

However, is reducing meeting time sufficient?

We don’t think so. What’s really needed is not just fewer meetings and shorter meetings but an entirely different way of working, and Agile shows us this is possible and desirable and can be entirely effective.

How about conducting quick stand-up meetings instead of grueling sit-down meetings?

Why not measure all work with burn down charts (please see the sidebar) that show what’s been done, what remains to be done, and the rate at which progress is being made?

What work can be better organized in teams?

Can we use brainstorming sessions more productively?

What organizational functions should be shifted to project teams?

Are we engaging enough people in the role of facilitators to expedite the work?

The burn down chart

A burn down chart is a tool that’s typically used on programming projects to forecast completion. Simply put, it shows how much work is left to do. By plotting the work done each day, over time it tracks the progress rate and is therefore quite useful for predicting when all the work will be completed. However, burn down charts are also useful beyond software programming, because they can be applied to any project that achieves measurable progress over time.

Agile methods do, in fact, require documentation, because the need for it is inevitable and it can provide significant value, so it’s really a question of emphasis. Agile methodology also calls for the tracking of progress, which is certainly a necessity. The answer is to approach both from a simplified, lean, good-enough-for-now (GEFN), just-enough, and just-in-time perspective, rather than creating a massive overhead-driven bureaucracy. Streamlining compliance processes and being aware of the difference between compliance and delivery activities is the key to success.

Transforming organizations

Not surprisingly, organizations exhibit behaviors similar to that of people. Corporations even age like people do. When they’re young, they’re willing to take risks and follow their dreams. But with age they slow down, gain weight, and become risk averse out of sheer habit, and in the name of stability and order they actively resist change and make excuses to protect their illusions. Bye-bye agility, hello stagnation.

From this we take away the awareness that an innovation culture is very hard to sustain.

To help your company maintain its youthful spirit, you can implement these three principles:

• Compensation models must incentivize business creativity and accountability.
• Comprehensive software tools and systems must be deployed to enable management and measurement of idea creation, idea sharing, and idea execution (because you cannot manage what you do not measure).
• Cultural norms must encourage leaders to inspire new behaviors and new competencies.

Because they are very smart, employees have the astute and well-known tendency to organize their work according to what is measured and what is rewarded. So, if we measure activity, then people will find ways to stay active, whether they’re producing anything of value or not.

How to appear productive and get nothing done

When I was young and working on a large construction project, I was surprised to see that a few members of the crew could spend hours looking for a particular power tool that was highly specialized and relatively scarce. In fact, they could pass nearly an entire day wandering around and asking if anyone had seen it. They didn’t get much work done, but they did spend a lot of time hunting for these rare tools. It took me a while to realize that their goal was to be highly visible and appear engaged, even if they were actually doing as little as possible and accomplishing nothing of value to the larger goal of the construction project itself. But by showing up at various places on the job site, and catching the attention of the project supervisors during the course of the day, they could continue their masquerade.

Of course, this story is interesting only because it’s a common behavior not only on construction sites but also in all types of organizations. Some people are adept at getting next to nothing done while maintaining the appearance of engagement and productivity. We’ve got to root those people out.

As we noted earlier, Agile solves the problem of measuring productivity and actual work accomplished, as opposed to busyness that accomplishes little or nothing, by defining specific production targets weekly and then tracking each person’s progress toward his or her individual and team goals.

However, the downside of this causes Agile to be not quite so brilliant on the creative side of things. Because once people know that their productivity really is being tracked, and they get grooved into production mode, they tend to be a little less willing to pause and come up with new ideas.

This is a key issue, because rapid prototype development often translates to time pressure to kick out the next thing, even if it’s not the right thing, because people strive to deliver something tangible and measurable instead of taking time to think or collaborate more deeply. One way to address this is to focus on the step between iterations, the reflection phase.

In the reflection period after an iteration has been tested, which Agile refers to as the retrospective, the time to look back and learn, a team should conduct an extensive and intensive debrief process. This can be conducted like a brainstorming session, where everyone adds his or her input without critiquing or judging. After this input is recorded, a second session is held to sort through the feedback and determine what direction the next iteration might take. The focus is on might, because the goal is to entertain multiple options rather than merely selecting the next idea that comes along.

In this context, Agile Innovation is therefore subtly different from Agile (Software) development. For the software developers, the kind of creativity necessary is different, because they are typically working with known tool sets and discovering clever, new ways to assemble and apply their tools, whereas for Agile Innovation we often have to discover and invent new tools. This underlines the importance of the continuous learning step, because the tool set itself continually evolves.

Eight organizational principles

Throughout this chapter we’ve been discussing the approaches necessary to transform organizations to achieve innovation actions and outcomes. These can be summarized in eight principles, the eight Cs of transformational change:

• Customer insight must be expanded to discover unarticulated customer needs.
• Creativity must be amplified through continuous brainstorming.
• Constructive leadership takes appropriate risks by adopting incremental business cases to enable faster product cycles.
• Collaboration happens more effectively in smaller Agile teams and stand-up meetings than monolithic projects and traditional death 
march meetings.
• Continuous learning must be implemented through retrospectives.
• Compensation models need to be modified to incentivize business 
creativity and accountability.
• Comprehensive software tools and systems that can provide measurement and management of both ideation and execution must 
be deployed.
• Cultural norms must encourage leaders to inspire new behaviors 
and new competencies.

Although these principles are straightforward, it’s important to remember that the task of transforming a company may be arduous. Just throwing an innovation tool into the mix or asking the chief technology officer to launch yet another innovation challenge probably isn’t going to get meaningful results. The effort is a systemic undertaking, akin to growing up, quitting smoking, or losing a lot of weight. It requires a serious level of commitment and a comprehensive and systematic approach to ensure success.

By Langdon Morris

Excerpted with permission of the publisher, Wiley, from Agile Innovation: The Revolutionary Approach to Accelerate Success, Inspire Engagement, and Ignite Creativity by Langdon Morris, Moses Ma, and Po Chi Wu. Copyright (c) 2014 by Innovation Labs LLC. All rights reserved. This book is available at all bookstores and online booksellers.

 

Photo: Mature cocoon transform to Tawny Coster butterfly from Shutterstock.com