Agility

50% of operating model changes1 today are focussed on adoption of Agile and DevOps delivery models. While prototypes and proof of concepts have demonstrated value, scaling Agile hasn’t always been successful – here’s why. 

Many organisations start their Agile journey by running a few projects using Agile2 methodologies and DevOps practices and unlock varying degrees of benefit. This shift from traditional to Agile typically begins in digital as a grassroots effort and, often results in uncoordinated or inconsistent ways of delivering Agile projects across the organisation.

The question that is usually posed to CIOs, and business and technology leaders is “how and when do we scale these new ways of working, in a consistent yet flexible manner, across the technology and business functions?” While these are pertinent questions, they are often not the right starting points for scaling Agile3 across the organisation. Successfully scaling Agile ways of working at the organisation or portfolio levels involves a structural shift across people, processes, technology and culture. These transformations are too often led from within technology. This is a key issue in our eyes, the change needs to be co-owned by the business and technology in order to fully realise the benefits of Agile.

Given these apparent failures across organisations to scale agility, we recommend that, instead of starting with the “how and when”, start by aligning with the business on “why do we want to adopt these new ways of working and where should we scale?”

Why start on a transformational journey?

Change is difficult without a clear idea of “why the change is needed?” The premise for the change needs to be agreed to by both the business and technology and then communicated to all parts of the organisation impacted. In our experience, to drive the right outcomes, leaders need to consider not just external macro drivers in the industry but also their expected influence on the business vision to decide if the transformation is necessary.

Organisations need to look at the following external market dynamics to understand if the Business needs to re-think its strategies and adopt Agile ways of working:

  1. Pace of innovation – is the innovation cycle accelerating due to new entrants or products and are competitors using the acceleration as a competitive advantage?
  2. Product or service personalisation – do customers expect product and service personalisation and are customer preferences frequently changing?
  3. Technology disruption – are technology disruptions leading to better products or services, faster business decisions and reduction in costs (e.g. digital business models, automation through robotics, better services using AI and XaaS through cloud solutions)?

External market dynamics

Alongside these market dynamics, it is important to consider the business benefits associated with delivering using Agile and DevOps. These include: increased speed to market, reduced costs through productivity gains, greater customer advocacy, improved employee engagement, faster reaction time and, an innovation led collaborative culture4. Utilising historical Agile project results or learnings from pilots, estimate the benefits and gain alignment with Business / Leadership on the expected outcomes. Ensuring alignment and buy-in is critical to sustain the Agile and DevOps transformation benefits. In our next blog we explore how you can secure organisation wide cultural alignment alongside leadership alignment.

Where is the change most effective – should this be an “all or nothing” approach?

After having secured the buy-in for “why” to transform, you need to turn your attention to “where” the new ways of working should be applied and scaled. Most organisations attempt to scale across all technology and business functions without considering the specific need in each area. Instead of being thought of as bi-model i.e. traditional vs. Agile, the needs of different parts of the organisation to vary in speed should be considered. A ’multi-speed’ or ‘right-speed’5 approach is often the more appropriate answer. For example, the front office (e.g. digital), middle office and back office applications have different needs in terms of the pace of change required. It is not necessary that all parts of the organisation operate at highest speeds possible. If the customer is not able to realise value from the delivery speed, then it could result in waste and unnecessary cost increase. In addition to customer expectations, it is vital to understand the constraints within your environment. You need to review your overall architecture (e.g. front, middle and back office) to target the right speed of Agile based on your customer aspirations, business vision and operational constraints. 

Agile based Approach

Agile can be applied to a diverse set of scenarios. Consider a regulatory project where all requirements are known upfront and a high degree of change is not anticipated. You might still use Agile practices to mitigate risks by incrementally building your solution. In another scenario, you may have a project where there may be a number of unknowns in customer requirements. You may use Agile practices in this context to deliver smaller value increments and adjust next iterations based on learnings or customer feedback. In this instance, you may also combine DevOps’ continuous integration and continuous delivery with an Agile delivery approach to accelerate the value delivered and time to market. There isn’t a “one size fits all” approach for adoption.

These new ways of working are most effective in areas where there is a high degree of uncertainty or lack of clarity on the influencing parameters. This uncertainty can be associated with business or customer requirements, risk or, value realisation potential. We will explore how you manage these parameters as part of next set of blogs in this series.

In a nutshell

Organisations have a real opportunity to get Agile right by simply establishing the foundations in terms of the “why” and “where” before expanding into “how and when” to scale. To find out more about creating the “why” and the “where” for your organisation, contact one of the authors.

__________________________________________________________________________________________

End Notes:
1 Estimation based on our extensive network of clients and their request of consulting services in 2017
2http://Agilemanifesto.org/
3http://www.scaledAgileframework.com/
4Experiment Hungry Culture – http://blog.deloitte.com.au/enabling-agility-experiment-hungry-culture
5Right speed IT – https://dupress.deloitte.com/dup-us-en/focus/tech-trends/2016/devops-it-optimization-speed.html – Deloitte Tech Trends 2016

 

Aarti Balakrishnan - Technology Strategy and Transformation Leader, Deloitte

Aarti Balakrishnan is a Senior Manager in our Technology Strategy Practice. She works with Global Financial Services organisations articulating their Technology Strategy and helping them on their transformation journey. Her recent transformation focus has been in helping organisations adopt Agile and DevOps through Infrastructure transformation.

Email | LinkedIn

Ali Raza


Ali Raza - Agile and DevOps Transformation Leader , Deloitte

Ali Raza is a Manager in our Technology Strategy Practice. He is an Agile and DevOps operating model expert. He also works across Global Financial Services organisations advising them on how to scale their Agile and DevOps practices.

Email | LinkedIn

Comments

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.