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:
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.
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?
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.
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:
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.
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.
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:
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.
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.
Each of these eight Cs of transformational change raises questions about how to implement them. In other words, principles are great as a framework, but how can we make them work for us?
Customer insight must be expanded to discover unarticulated customer needs:
Collaboration happens more effectively in smaller Agile teams and stand-up meetings than monolithic projects and traditional death march meetings.
Compensation models need to be modified to incentivize business creativity and accountability:
Agile Innovation: The Revolutionary Approach to Accelerate Success, Inspire Engagement, and Ignite Creativity
Part 1: What is the story of Agile Innovation?
Part 2: Starting at Sprint Zero: A better way to innovate
Part 3: The Secret Sauce of Innovation
Part 4: Becoming Agile Rapidly and Painlessly
Part 5: Adaptability and Collaboration for Sustainable Business Growth
Part 6: Transforming How We Work
Part 7: Translating Unseen Needs into Innovations
→Part 8: The Eight Cs of Transformational Change
Since 2001, Langdon Morris has led the innovation consulting practice of InnovationLabs LLC, where he is a senior partner and co-founder. He is also a partner of FutureLab Consulting. He is recognized as one the world’s leading thinkers and consultants on innovation, and his original and ground-breaking work has been adopted by corporations and universities on every continent to help them improve their innovation processes and the results they achieve. His recent works Agile Innovation, The Innovation Master Plan and Permanent Innovation are recognized as three of the leading innovation books of the last 5 years.
Photo: Mature cocoon transform to Tawny Coster butterfly from Shutterstock.com