3 steps management needs to consider before using Scaled Agile for innovation

How well does Scaled Agile processes and Innovation play together? Since Agile is designed for iterative and evolutionary development with short feedback loops and efficient communication, the fit with innovation seems obvious. Unfortunately, I continuously meet managers struggling with scaled agile in their innovation projects. So what do we need to consider to make this work? 

Always consider the agility of the ongoing business.

Most innovation projects are the combination of new business models, applied using technology and design principles in a market context. They, therefore, need to be developed with the assistance of parts of the organization not suited for working in the Agile sprint framework. In many industries, new products require marketing planning months ahead of time and production involves tooling which is an expensive and time-consuming process. Decide on ways for these units to feed information into the Agile process without disturbing their operations. 

Be careful of diluting ownership.

In large organizations with several multidisciplinary teams working on parts of the same project, ownership becomes diluted because it is often spread out over several managers and their teams. Making somebody the owner of a set of product features is easier than making somebody the owner of larger business decisions which are often harder to track. Declaring somebody “Global Product Owner” or some other title and having them fight it out with multiple agile teams without true authority is not going to solve this problem. Fortunately, knowledge from years of research into new product development tells us that the way through this issue is to have direct involvement from top management and somebody with true high-level organizational authority in charge of the project. Managers higher up in the food chain are often in charge of more strategic decision making, but for Scaled Agile to work business decisions needs to be resolved at the same pace as product features are developed, tested and decided upon. That requires authority and ownership.

Build Better Agile processes for management.

Build intuitive systems for synchronizing deliverables across multiple teams some of which might be feeding deliverables to the Agile process without working within the framework. Getting an overview of the project's status by looking at gigantic Kanban board is not helpful when several teams are involved, and neither is having to consolidate several teams kanban boards mentally. Also, build better data collections methods for the business side of the innovation project. Where the developers have the opportunity to test features and assumptions on an ongoing basis, management is often stuck with no way to prove their assumptions. If management does have data, it is usually in the BI systems, which is historical and therefore not representative of the innovation context. Organizations need to develop practical, data-driven, test methods for their business assumptions as well as their technical operations. 

Summing up.

Trying to make large established organizations adhere to Agile principals of self-organizing, ownership and flat organizational structures is all well and good. Realistically, to succeed in this, they need to shield the units with longer timeframes and higher transformation costs from the Agile processes. Make sure the ownership falls on somebody with true authority within the organization and, finally, help these people with frameworks to manage the project and test the business assumptions that drive innovation projects. 

Thanks for reading. If you found this helpful, please give it a thumbs-up and feel free to connect.