Many organisations have adopted agile but how many ask the obvious question: What is the ROI on our investment in Agile and how will we measure it?

There are two ways I’d like to explore this topic: from the perspective of delivering an initiative (a product or project) with agile, and from the perspective of scaling this to an entire organisational (Enterprise Agility).

The ROI of Agile Delivery

fast agile

On a project or product level, the ROI on agile is without doubt orders of magnitude greater than traditional methods. There have been a number of studies, the most notable by the University of Maryland, all of which provide extremely compelling evidence.

The University of Maryland study found that agile projects were 20 times more productive, had five times better cost and quality and had a 7 times earlier breakeven point. Furthermore, agile projects had an 11 times greater ROI, 11 times higher NPV, and a 13 times higher ROA when expressed as a percentage.

This research has been backed up by several private studies.  Without doubt, the ROI on agile projects is compelling and an order of magnitude improvement over traditional methods.

The ROI of Enterprise Agility

Naturally, this has led companies to want to scale these benefits beyond single initiatives and reap the organisation-wide benefits. Who wouldn’t want significantly improved breakeven, ROI, time to market, quality and NPV – and the ability to change course as required!

At an organisational level, the ROI becomes harder to measure. This is because Enterprise Agility is about improving the entire system for all future outcomes, not just one specific project. In other words, this is a core infrastructure investment, and these types of investments take many years to pay off.

An investment in Enterprise Agility tends to yield the following benefits:

  • Customer engagement – putting the customer front and centre of our efforts and testing the validity of our assumptions by regularly releasing work and obtaining their feedback.
  • Better solutions - when complex problems are solved by interactive, cross-functional teams, the solutions tend to be more robust and of higher quality. This is because we have taken in many different perspectives on the problem – technical, sales, marketing, quality, commercial, operational, plus we have baked quality in from the outset and tested it every iteration.
  • Culture and engagement - the research on intrinsic motivation is compelling – when teams can shape the work and work in a self-directed way, engagement, creativity and productivity go through the roof.
  • Adaptability – the ability to continually adapt our strategic direction, based on evidence of what we see in front of us. Agile brings transparency and empirical data. We can use this focus on only what is important and limit having too much work in progress, thus creating the ability to pivot.
  • Value - When the above four benefits are combined, we can focus on only delivering what is of value to both the customer and our business. While this seems obvious, what is often overlooked is our ability to cull a significant number of features we assumed customers wanted. Research into feature usage shows customers often only use 25-50% of the features delivered. Imagine if you could cut your investment in features by 50%!
  • Reduced Total Cost of Ownership – TCO accounts for the lifetime cost of the product, including maintenance, enhancement, and support. In many cases, this accounts for 60-90% of TCO, making the development cost looking minimal. By only developing features customers care about, we can repurpose investment into more product places.
  • Market share – combining all the above effectively tends to result in increased market share and eventually market dominance if done well.

Clearly, these are all long-term investments in the infrastructure of our businesses, based on designing it for agility.

ROI on this sort of investment take years to measure, not months. But this doesn’t mean we shouldn’t measure it. On the contrary.

One useful approach for measuring the ROI of Agile is Evidence Based Management (EBM). Many organisations lose sight of the real goal of agile ways of working as they get stuck focusing on improving activities and outputs instead of business outcomes.  Agile is a means to an end, not the end itself! EBM helps prevent this by focusing on the value delivered to the organisation from an investment in agile. This enables organizations to make rational, fact-based decisions, elevating conversations from preferences and opinions to empirical evidence,  logic, and insight.

If you are interested in EBM, please contact me.

Otherwise, you may find the approach and the metrics as a useful way of considering how you are going to measure your Return on Investment in agile.

Good luck!

Throughout my career I have helped many leaders adapt their style to one that better supports teams reach a high-performing state. Across a wide range of different industries the patterns of high-performing teams, and how leaders help shape them, have some striking consistencies.

I can clearly recall one of the highest performing teams I ever worked in. It was during my first career as a chef. The Head Chef quit, and the owner of The Ruptured Duck (yes, that was the pizzeria name) asked me if I would take over. I was only 23 years old and felt totally daunted, but figured I had nothing to lose so gave it a go.

Throughout the following two years, I somehow helped shape an incredible team of people who felt they could literally achieve anything. The lines between work and fun blurred. We were all “in the zone” – that incredible space where everything around you seems to fade into the distance and you are utterly present. We were somehow there nearly 100% of the time.

The team could handle massive, unpredictable waves of customers and work under incredibly intense pressure for prolonged periods of time, often during extremely trying conditions. Yet we consistently delivered an incredible experience and regularly had customers commenting how obvious it was that we all loved what we were doing. I would regularly have staff coming to work early, working unpaid, just because they liked being there.

How on earth did we achieve this?

Reflecting back, I can see some clear patterns:

  1. Goal: We had a clear objective – to provide the most awesome casual dining experience in Christchurch in a friendly, fun environment.
  2. Leadership: at 23 years old, with less than a year of practical chef experience under my belt, I was not in a position to tell others what to do. I had never done this before, so how could I? All I could do was lead by example. I worked hard and expected others to also. We were largely self-managing.
  3. Culture: we created a culture of extreme teamwork by always having each other’s backs. If the chefs got a lull in work, we helped the front of house staff, and vice versa. This was never questioned. It was how we rolled. When introducing new staff, we’d focus on the team culture and would only introduce one or two new people at a time. It created trust and courage as a core group value.
  4. Continual improvement: we would hold what I would now call a retrospective every night. We’d have a couple of beers and talk through how the evening had gone, what worked, what hadn’t and what we could do better.
  5. Transparency: the entire operation, kitchen, dishes and all, could be viewed by the public the entire time. Nothing was hidden.
  6. Rapid experimentation – we would constantly try new ideas as “specials”, gaining valuable customer feedback as we went.
  7. Fun – we had a lot of fun together as group.

The result was a team that could turn over an 80-seat restaurant 6 or more times in a single evening without a glitch. That’s close to 500 people and we could do this 7 days a week if needed.

Agile Ways of Working

Fast forward to my current world: helping knowledge workers achieve similar outcomes. Radically is helping organisations transform the way they work, applying new ways of working, autonomous teams, a high-performance culture and a relentless focus on customer value.

While the setting is different, the themes are the same. High-performing teams have those same characteristics: goals, appropriate leadership, culture, continual improvement, rapid experimentation, transparency, trust, courage and fun.

A key aspect of this is helping organisations unlearn last centuries management practices.

Ivy league business schools and the big management consulting firms pushed these practices for decades. “Good management” was based on planning, hierarchy and control. The mindset was that the top layers of the organisation would come up with the right strategy, and then the troops would execute. The focus was on coming up with the best strategy (which of course you would need help with) and on execution excellence, namely conformance to plan (i.e. control).

However, with business increasingly operating in a world of unknown unknowns, this approach increases risk, reduces responsiveness and ultimately results in the organisation becoming fragile. To adapt, we have to acknowledge the approach we have used for the last 30 years doesn’t work in all contexts, and then explore alternative approaches.

Instead, at Radically we help leaders focus on establishing a clear, compelling vision and then re-thinking how their organisations deliver on this, largely through the exact same characteristics as my Ruptured Duck team. It isn’t about Agile. It is about the mindset, the environment and the culture required for high performance.

Autonomous Teams

Autonomous teams are self-managing. Self-management requires two critical ingredients:

An absence of traditional management.
A light set of constraints. Constraints help balance autonomy with accountability. Constraints might be an iteration, a Sprint Review, a social contract or a facilitated meeting.

An absence of management is important as people cannot self-manage when they have a manager telling them what to do.

For many managers, creating an absence of management is truly frightening. How can you be accountable when the teams manage themselves? How does a manager approach this situation? Do they just let go of everything and hope for the best? We are seeing a lot of people struggle with this.

The art of it is choosing how much space to leave by actively stepping out, in order to allow others space to step in. You can’t just walk away, leaving a gaping hole, and expect everyone to magically self-manage. Yet if you don’t leave enough space, you will prevent them from self-managing.

We ask leaders to move their focus away from telling others how to do the work, to the following three areas (leveraging David Marquet’s experiences captaining a nuclear submarine with no knowledge of how it worked):

  1. Clarity – what do you seek? What difference does it make and to who? Why is this important? What does success look like?
  2. Competence – does the team/individual have the competence to deal with this situation (or at least the growth mind-set to learn what is required). Does the structure support them in their level of competence? What help might they need?
  3. Control – delegate control to the people doing the work, once the platform of Clarity and Competence is in place.

This is precisely what I unwittingly established all those years ago as a chef at The Ruptured Duck!

Leadership and Culture

I believe one of the most critical factors for a high performing culture is leadership. The agile community has pushed servant leadership as the answer, but I don’t believe this is correct. I believe situation-appropriate leadership is the right answer.

To help organisations discover what this means, we prefer a discovery-based approach.

We use the Cynefin framework to first establish context. Collectively, we work through what it feels like to work in each of the four domains, what is different about each, and which approaches might work best for each domain. We then work through what sort of culture and leadership style would be required to support this way of working in each domain. Then, we review how we all currently think and lead compared to this.

The results can be quite profound.

These are some of my experiences helping create high-performing teams. What are yours? Have you ever worked in a high-performing team? What was it like? How did it compare to my pizzeria team? What was the predominant leadership style?

Many organisations are embracing agile ways of working in an attempt to build faster, more customer-focused and resilient organisations. They are redesigning themselves to create a culture where decision making is transitioned away from middle management towards those working with customers at the coal face. Ultimately, they seek engagement in order to create a culture where staff are empowered to truly delight customers. Autonomy is the critical ingredient; however, autonomy is often misunderstood. Many organisations think they just need to increase autonomy, however they forget to include the counter-balance of accountability, often with disastrous results.

 

Too Much Autonomy too Quickly

Recently, many senior leaders have shared with us a worrying concern. It is happening so much that it is becoming a pattern. They are telling us, often with hushed voices, that they feel they cannot ask important business questions such as “when do you think this will be done?” or “how is cost tracking?” or “will we hit our launch date?”. When they do ask these questions, they get proudly shunned and told that that these questions “aren’t agile”.

Perplexed, they feel stuck. Do they go back to their old ways and demand answers (which they know will be fabricated anyway)? Do they dare mess with the new agile culture and risk being seen as “a manager”, the evil conspirator who is secretly trying to stop agile and control everyone? Or do they try to manage the business without the vital information required to make decisions? The end result is managers on tip toes.

The problem is that they have increased autonomy without increasing accountability.

Empowerment

One firm wanted to increase autonomy by empowering their people to put forward initiatives that would be funded based on their ability to help deliver the strategy. The “how” (the execution of initiatives) would be entirely up to the proposer, giving the teams freedom and flexibility to focus on delivering the best outcome as the work progressed.

All sounds awesome right? Unfortunately, it wasn’t, as year after year they encountered the same problem: 9 months into the year they would run out of money and the entire organisation would then go into a capital freeze for the remainder of the financial year, causing significant disruption.

Why?

Firstly, those leading the initiatives were not being held accountable for actually delivering something of value. They were given a chuck of money at the beginning, based on forecast delivery of a business outcome. The intent was to give the teams autonomy, however without the counter-balance of accountability for how the investment was being spent, the teams failed to deliver.

The root cause was that they were still running a traditional governance model that didn’t understand agile. The teams weren’t being held to account to deliver “done” increments of value every iteration. This resulted in the illusion of progress (“we are doing iterations therefore we are be doing agile!”), however nothing could be shipped to the customer. The catch-up stabilisation and integration required a lot more budget.

The lesson – they decentralised decision making and control to provide autonomy but failed to establish the corresponding accountability. They went from centralised accountability, to no accountability at all.

Another firm wanted to embrace agile in order to build highly autonomous teams and attract the best talent in the market. They rapidly “delayered”, removing most middle-management positions and set the teams forth on a journey of self-organisation. Teams were taught new ways of communicating, sharing and collaborating. Each team had a facilitator – a servant leader who would help them teams as required.

Again – seems awesome doesn’t it? However, when the CEO asked how many more iterations would be required to deliver the release, she was shocked to find the teams had no idea. Nobody knew whether this was on track nor did they know cost to date and forecast completion cost. Again, they went from a small group of managers being accountable, to nobody being accountable in the new approach.

Cupcake Agile 

Sadly, we often encounter this and the frustrating thing is that this is not (in our opinion) professional agile at all. One senior leader we talked to called it “Kindergarten Agile”, another “Cupcake Agile” and yet another “Jazz-hands Agile”. It is often the result of well-meaning people who simply lack the business acumen to understand the implications of changes they are suggesting. They recommend autonomous squads, that team have lots of fun and we will measure success by team happiness.

Agile for autonomy

Balancing Autonomy with Accountability

Agile is based on transparency. When we have transparency, we can see what is going on change course accordingly. Accountability is very specific – in Scrum the Product Owner is accountable for value, the Team is accountable for delivering done increments and the Scrum Master accountable for the process.

Governance remains vitally important. It doesn’t disappear, it just changes, typically from a classical model where the focus is on schedule, scope, budget, quality and risk, towards a modern model that focuses on value, risk, learnings, and then the next optimal move.

Management remains important too. It doesn’t disappear. It just changes from a role that allocates work to people and then manages their progress, to a role that focuses on growing people, providing honest feedback and coaching them.

Business questions such as “when do you think this will be done?” or “how is cost tracking?” or “will we hit our launch date?” are completely fair and valid. The difference is that we are moving from a world where we pretended to be able to know all of this upfront and would lock it down in a plan and then govern to that plan regardless, to one where we accept we don’t know it all up front and instead forecast these factors and continually update the forecast as we progress, enabling regular changes in direction based on the information at hand.

Don’t accept Cupcake Agile. Yes, autonomy plays a critical role in reshaping our workplaces, but don’t forget to balance autonomy with accountability.