top of page

4 Ways to an Agile Operating Model

“We’ve done agile”. That was a quote from an IT executive in a large global company who was explaining how agile has been tried and tested successfully within IT software projects but something more was needed to bring this thinking to a larger audience within IT and over to the business.

What they were really saying is that they’ve done Scrum. In fact, we should expect that a very large percentage of enterprise companies around the globe who say they’ve done agile are really implying that they’ve used Scrum as an agile approach to deliver software projects. I’m tempted to say this is a generalization but it seems to be where most companies are in their agile journey and that isn’t a bad thing if you consider that agile, and for that matter Scrum, have essentially gone mainstream in the last few years.

But we have a new challenge, one that is underway in a small percentage of companies but is now growing in terms of awareness and interest. It’s this idea that agile practices and principles, and not just Scrum, can and should be applied in larger ways and even adapted into a framework or operating model that can improve a company’s current way of working.

In just the last two weeks I’ve had a handful of well-known global brands tell me that getting to an Agile Operating Model is now a major initiative within their organizations. These companies have dabbled, somewhat successfully with Scrum, and now have the courage and conviction to see where else this can work.

The truth is that this topic is not new and has been written about for sometime. I remember speaking on “Enterprise Agile” as early as 2007 and getting blank stares from audiences who wanted to believe it but were skeptical that using agile techniques to shape portfolio management or a company’s PMO could even be considered not to mention even possible.

But here we are, it’s 2012 and there is change in the air. Getting to an Agile Operating Model is very much about the removal of boundaries in traditional process and improvement of performance and outcomes, both as a company and as a group of people.

The road to get there, however, is not going to be the same for everyone. I want to point out the four ways we’re seeing companies take this journey. I want to emphasize that none of the four ways are better than each other, just different. I’m sure many people will have opinions about the four ways and whether one is better than another, that is completely okay and expected.

That said, regardless of our opinions, we need to recognize that each of the four ways are real and where several companies are today. All four ways relate to the organizational structure and acceptance of new thinking in a company. It’s about HOW they see change and WHAT they do to take it forward.

All four ways have to do with what we would call an “entry point” – meaning, that is the place in the organization where agile has been introduced, understood and tested. It also means that the understanding of it will be different in each of the four ways simply because the people involved will all have differing charters, mission statements, objectives, goals, etc.

Before we discuss these four ways let me also say that we should not get tripped up by the use of the word “Agile” in the context of discussing or describing an Agile Operating Model. An Agile Operating Model is more about agility, efficiency, effectiveness and all those buzzwords MORE than just about agile, or even Scrum. Dare I say it, Scrum is not the answer. It’s a strand, a spoke in a wheel that houses many spokes.

A great and useful Agile Operating Model will represent thinking from the world of Lean, Design Thinking, Systems Thinking, value equations and formulas and even core Project Management and Business Analyst competencies. In other words and as has been repeated often, it’s your way of working as a company.

The diagram below represents the four ways to an Agile Operating Model based on the organizational dimension it stems from. You’ll see that each way has differing motivators as expected.

Some of the very important and “not so obvious” takeaways when considering any of the four ways would include:

  • The “Time-to-Adapt” will vary greatly due largely to the support, level of funding required and perhaps more importantly the cultural and mindset shift that will need to happen. With the right level of support, enterprise companies should expect to see really good change within 12-18 months of starting the AoM

  • Typically, companies have used their IT suppliers for introducing agile. While this is the right approach for two of the four ways described, it is often limited to just IT thinking and may not represent the expertise required for leadership, change and process transformation involving non-IT personnel

  • An AoM is not a replacement of what the company is doing today – it is an enhancement, an improvement and an advancement that is significant enough to look at seriously and leverage

  • While patience is a virtue, profitability is a purpose and companies can’t afford disruption if it means delays, therefore once you have formed the AoM team, select a program or project that can bring quick wins and demonstrate success

  • Get help and get smart – understand what your options are for leveraging expertise from organizations that have done this for other companies and get the learning you need to stay ahead. Traditional consultancies won’t have all the thinking and today there are several good resources for advancing learning.

bottom of page