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 engagementthe 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.

long term investment view

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!

I recently attended a zoom meeting with my Toastmasters club — yup, online speeches and all — which was pretty fantastic. Some of us were sitting in their kitchen, some of us in their bedroom, someone outside with an amazing view in the background. While I was busy giving my first ever online speech, I had a realisation: all these backgrounds give a much more intimate view into a person’s life than I would have had a chance to get otherwise. Has this crisis made the workplace more human? Continue reading “Why I believe this crisis has made the workplace more human”

I love travelling and visiting different countries. Being born in Singapore, I am always fascinated when I travel back to visit family and friends at how much the country has changed and evolved in just a short period of time.

Continue reading “Beyond the Pursuit of Agile”

Forward thinking firms are realising that in order to thrive in a world of uncertainty they need to fundamentally rethink themselves beyond the tactical “doing” mindset (processes, frameworks and methodologies), to an adaptive mindset, based on a culture of collaboration and a team-centered approach to problem solving.

Culture, HR, intrinsic motivation & emotional EQ are converging with agile, servant leadership, the growth mindset & customer empathy to fundamentally reshape what it means to be a modern organisation.

The winners in the current climate are not just embracing modern technology; they are fundamentally redeveloping their core DNA in order to detect new opportunities. And this change is increasingly being led as a culture-first initiative.

Much of the work we are currently doing is less about responding to a particular crisis, rather it is more focused on creating new capabilities to enable our clients to continually adapt and respond to almost any situation. We call this agility. In practical terms, what does this involve?

From years of working at the coal face of adopting agile ways of working, we have learned that a holistic approach radically increases your chances of success. We therefore approach it as two interrelated pieces – Business Design and Transformation, with the overlap, validation, playing a vital role in road-testing the change.

Business Design

Business Design is about designing the business to help it best achieve its strategy. It is vital, yet in our experience many organisations skip this and leap straight into “implementing agile”. The result is a transformation with no real substance, no compelling call to action, no North Star. And firms wonder why so many transformations fail!

At Radically we take a very pragmatic view:

  • First, understand the core strategy. What space does the firm play in? What unique combination of drivers enable it to win in this space?
  • Design an Operating Model that will enable this strategy, empowering and aligning all the key business functions towards the same outcome.
  • Get explicitly clear on the target culture required to achieve this. What does it look and feel like? What will leaders do to role model this? How do we reward and recognise people demonstrating the desired behaviours?
  • Review and align the Organisational Structure to support the above. If our Operating Model is strongly agile based, then a different org structure is often required. What does this look like and what changes are required to get there?
  • Ways of Working – clearly design how we will approach our work. What work should be approached with an agile model? What work should be delivered by a traditional model? How will these interact? Who will do what? How will we measure success of this?
  • Funding & Governance – an agile enterprise tends to adopt an experimental mindset, delivering quick iterations of value that can be quickly tested with customers, resulting in continual course correction. Traditional funding and governance models tends to focus on adherence to a fixed plan. So how should a more modern funding and governance model work?
  • Leadership – given the above, what should our approach to leadership look like? How will we live the values as behaviours each and every day?

Sadly, most agile transformations we have seen in New Zealand completely fail to consider these fundamental building blocks. Instead, they tend to take an “agile practitioner” approach, focusing on frameworks, methodologies and processes. In our experience, these firms are unlikely to achieve their desired business outcomes.

Transformation

Transformation is the art of moving the business to the new model.

This is when the ‘people aspect’ of change truly kicks in. If you think about what we are actually transforming, it is people and people are the trickiest part to change; processes and models are relatively easy. The human shift must be designed with a human-centred approach. We find that by taking a leadership and mentoring approach, our job is to guide all levels through the change and build the capability and mindset within the staff to be self-sustaining into the future.

Validation

In our experience, no design is perfect. There is low value in trying to design a perfect design as no such thing exists, and secondly it will change as you implement it through transformation. Transformation validates design, yet transformation without design is folly.

In summary, we urge you to take a strategic focus when embracing agility. Are all the pieces of the firm aligned to the same vision, model and approach? Are we all completely clear why we are doing this and what outcomes we want to achieve? If you can’t answer yes to these foundational questions then it is time to re-think what you are doing.

Don’t “go agile”. Instead, design your business for agility, break the cycle of failed transformation and realise the true benefits from your investment.

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.

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.

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.

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 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.