For the past two and half years, I have been heavily involved in an enormous transformation initiative in one of the biggest companies in Australia. The goal of the initiative is to bring in the Agile mindsets and culture as a completely new way of working for the entire enterprise. Agile as we all know, is not something astonishly new. To save everyone’s time, I am not going to recap the entire history of Agile here. Anyone interested in reading out what Agile is and when it was originated can read them here. What is really new about Agile, especially in coporate Australia, is that it has been recognised by large companies to be a tranformational approach for the entire ways of working across the whole organisation. This has been a strong contrast to when Agile was first arised that it was deemed to be another type of project management methodologies purely for software developments. The company I am invovled in, certainly sees this as a brand new idea to start the enterprise transformation initiative

The company

I intended to maintain annoymality of the actual organsiation, so it will be only a brief background to serve as the context. This organisation is one of the biggest companies in Australia and one of the biggest players in the information and communication technologies industry. Facing strong competitions and heavy government regulations in recent years, it’s financial bottom line has taken a major hit. It has become imperative that the company needs to change the way it operates to stay competitive and profitable. In 2018, the company established an enterprise wide transformation initiative with a target end date in 2022. One of the key pillars in the initiatve is to introduce an “New Ways of Working” by embracing Agile mindset and culture. This is the part I was heavily invovled in.

Why Agile?

I have no intention to “sell” the Agile benefits here but rather, to simply explain some of the key drivers why the organisation chose Agile as the mean for its transformation. Looking back at the situation at the time, there are several key drivers for Agile to be chosen:
  1. Agile has manage to reinvent itself to be more than just a software development methodology. The likes of successful modern tech-compnaies such as Sportify, Atlasian etc, who have embraced Agile principles and Agile ways of working as core organisation culture, has painted a glory picture of what success Agile could bring to an orgnisation.
  2. Agile is always recognised as the nemesis of traditional waterfall-type project managements organisations. The company has a long history of running enterprise wide management and processes based on traditional waterfall project management methodology. This means Agile is the perfect change agent to break out from the old world.
  3. A few other big companies in Australia have already gone done the Agile path at the time. There is a sense of “you are Agile or you are out” existed in the corporate envrionment.

The Agile transformation

The tranformation initiative was massive. As always, corporate transformation results in huge number of lay-offs. In this case, one third of the employees, close to 10,000 were shown the door. Many employees in the process argued that the so-called “Agile transformation” was merely the excuse used to execute large-scale redundancy program. As the transformation is still progressing, I am not intended to make a judgement on how successful it is now. I am also not going to go through the detail tranformation processes that the orgnisation has undertaken as it is not the focus of this article. The details of the entire transformation journey, including success, mistakes and lessons learnt will be the focus of another article. In this article, my main focus will be the use of metrics in Agile transformation.

The need for measuring

Even at the early days of the Agile journey, one of the key questions managements and stakeholders would like to answer is:

How do we measure success?

As any other initiatives in a corporate envrionment, you were bound to provide measurable KPIs and outcomes for a given period of time. At first, it doesn’t seem to be a big deal as one of the 12 Agile principles states the importance of early and continuous delivery of values to customers. However, digging deeper, it becomes evident that while there are numerous metrics related to team cadence and operation, there is no proven or widely accepted framework or model to measure the success of Agile transformation which would satisfiy the corporate stakeholders and the requirement for endless regular reporting. The best advices I have recceived from most of the external Agile professionals all attempting to paint a long term picture: A transformation program as big as this one, we will have to wait for a couple years at the minimum to see any tangible outcomes. I don’t want to dispute the fact that Agile transformation in a large corporation, very often is about culture change more than anything. To change the culture of a long running organisation takes a long time. However, intrigued by the Agile principle of early and continuous delivery of values to customers as well as responding to change, I decided to have a measurement framework in place such that values can be realised early, any wins can be celebrated and communicated, as well as being able to pivote when changes are introduced.

The Metrics

When designing this Agile transformation measurement framework, it is important to understand how it is in sync with the overall transformation roadmap. For instance, when I first thinking of putting in the measurement framework, the organisation was in the middle of spinning up “Agile teams” in different part of the business areas. This means there is a strong need to understand how “Agile” these teams and how do we make them more “Agile”. This translates into a requirement for measuring the “Maturity Level” of the Agile teams.

Agile Maturity Model

In order to measure maturity levels, we will need a maturity model. Again, at that time, there was no well-accepted agile matruity model that I can leverage directly. Therefore, I will have to create a brand new model for this purposes. The final model is here: There are 3 main dimensions of the model:
  • Team Dynamics
  • Team Environment
  • Agile Practices
For technical teams such as software engineering teams or network engineering teams, there will be additional dimension designed specifically for them. Under each dimensions are individual assessment questions that team members will respond by choosing a ranked responses (from 1 – 5) that is most accurate description for their team. The result is then aggregated into team level with a single score representing current maturity level for the team.

<To be continued>