When we were developing the Rapid Learning Cycles framework, we intentionally chose to create our own terminology for the elements of the framework instead of leverage them from the Agile methods we were using.

We did that because we didn’t want to confuse all the Agile “purists” out there, and because we had already seen some groups twist themselves into pretzels because concepts like the “user story” didn’t translate well into the spaces where teams need Rapid Learning Cycles. They were doing that because their Agile coaches had told them to do it, and they almost universally found it to be worthless effort.

Some Agile methods — and some Agile authors and experts — are just too rigid because they encourage teams to follow Agile — and only Agile — declaring all other program management methods to be obsolete or ineffective in all circumstances.

Rigidity Is the Antithesis of Agile

“Agile” implies the ability to move quickly from one place to another with ease. If one thing isn’t working, then the agile team can quickly move to something that works better, with flexibility and responsiveness. Agile practices build this ability within software teams by breaking up large batches of design/code/test into much smaller ones, and then striving to make those small batches as independent of each other as possible. That enables teams to work on the parts of the system that the users need the most, or that will contribute the most value.

The Agile methods themselves are tuned to help teams make this happen. I can see why Agile experts don’t want a team deviating from the methods that they teach. Like all tuned systems, they can break when they’re changed, especially by teams that don’t understand them. I have the same challenges with Rapid Learning Cycles: people will try to change or avoid the stuff they don’t like or don’t understand and then wonder why they don’t see the value that others do. The solution is rigor — but rigor can lead to rigidity when you’re operating in areas where the assumptions behind Agile don’t apply.

Modern Products and Services Need True Agility

Today’s products incorporate software more often and in more ways than ever before. Smart factories use software to control automated equipment and feed live production data back to eliminate defects at their source. Smart products add connectivity and remote control to more categories of products every day, to create smart homes and smart offices. The smart phone has become the ubiquitous interface for these devices through apps.

These products have pieces that are easy to change, and hard to change. They have parts that are well-understood and not understood well at all. Customers know how to use the traditional aspects of the product but may shy away from using new features if they’re not well-implemented. Implementation problems can arise in the hardware, software, connectivity or the cloud. Not all of these problems can be fixed with Agile Software tools.

Modern Product Teams Need Leaders with True Agility

As a result, more and more companies need well-rounded innovation leaders who understand how to run teams that are agile — flexible and responsive — without being rigid. Such Innovation Leaders can embrace the full range of program management methods: pure Agile Software Development, traditional tools or Rapid Learning Cycles, depending upon the type of work being managed.

Just as we wouldn’t consider a football player to be flexible and responsive if he or she could only run one type of play, we can’t consider an innovation leader to be agile if he or she only knows how to run Scrum or SAFe. If such a person advocated ONLY Scrum or SAFe all the time, for every problem, that would be like a football player who could only succeed against one defensive strategy.

Yet our football opponents are rarely so inflexible themselves, just as the many things that can happen with innovation don’t all fall into the neat categories of problems that Agile methods solve. A good football team has a playbook that can handle lots of different defensive strategies, and a good player can run them all.

The Agile Innovation Leader’s Playbook Has More Than Agile Development

The agile innovation leader knows how to:

• Use Rapid Learning Cycles to structure learning in the “fuzzy front end” so that the big picture decisions made here set up the program for success.
• Use Agile Software Development for areas of the program that can be easily changed, and that especially benefit from rapid feedback cycles with users / product owners. These areas include things like user-facing software (apps, touchscreen interfaces) and some control software that doesn’t need to be finalized until the product is ready for final testing. Services also fall into this category.
• Use Rapid Learning Cycles to structure learning as the team begins to design the product. Here, the team uses Rapid Learning Cycles to improve the confidence of their decisions around things that are new, unique or difficult — and also not easily changed.
• Use traditional tools to manage the flow of execution work, understand dependency chains and the critical path, manage risk and ensure that changes are minimized and controlled in those parts of the product that are hard to change, once decisions have been put into execution.

The way to build agility is for the innovation leader to know when to go to Agile Software Development — and when to use a different section of the playbook.