How can Organizations adopt an agile organisational structure?

Faster time to market to gain market advantage before your competitors, the ability to learn and adapt as you go, reduce risk and pivot when a better solution is presented, these are just a few reasons why 61% (and counting!) companies are implementing agile structures and capabilities to drive their digital transformation.

Hold up! Before you race to kickstart your agile transformation, there are some key risks that most organizations encounter. Due to its everchanging nature, the actual cost of development tends to exceed cost estimations in the early stages. Companies need to also understand that for agile to work, deadlines need to be flexible, and long-term predictions may be hard to achieve.

In this exclusive blog featuring inputs from Niels Mærkedahl, Independent Director, and Abhijit Dey, Vice President – Product Head – API Banking, WhatsApp and Chatbot at Axis Bank, we’re giving you an extension on their highlight panel "Questioning the Leaders: Remaining competitive and relevant in today's fast-changing digital landscape”!

.

What's more necessary to successfully deliver an agile system? Top-down, or bottom-up?

The question for any transformation, top-down or bottom-up, and is one really better than the other?

Niels agrees that implementing a more agile business operating model is a cultural change, so a sizeable amount of change management needed, not just a top-down strategy. This is when you use a hybrid model consisting of both approaches, where participating contributors to leadership need to be aligned.

He suggests starting with a group of 100 - 150 people, where's it's small enough to control the outcome of the pilot phase, yet big enough to gain learnings from it. It's important to think about agile transformation across a number key pillars: strategy, structure, processes, people, and technology. These are all critical and important aspects to drive the change in the organization. Most importantly is to take some time up front to think about the business value that you want to achieve with agile instead of just jumping into it.

Abhijit agrees that a top-down approach alone isn’t enough, especially when you work in a federated culture. You need to onboard all relevant stakeholders and manage them proactively.

There will be skepticism for a long time, and to counter the resistance, management needs to continuously push and learn from the roll-out and have the courage to make changes along the way. The best way to drive an agile transformation is by making the transformation agile itself. This will ultimately secure a broader buy-in and excitement in the organization.

Niels highlights that one must think of an agile transformation as a cultural transformation. This is not about becoming less rigor on your execution and letting deadlines slip. Quite the opposite, with an agile approach you should measure your progress and outcomes on a sprint by sprint basis, which means you on 2-3 week basis take full stock of what you are achieving, the challenges you are facing and the road blocks that management need to resolve.

Should you isolate a line of business (as full stack as possible) to demonstrate the benefit of agile vs waterfall?

This is a key question to address in the early stage of your agile transformation – because it defines your structure, your pilot area as well as the ultimate outcome you want. Do you want tech, ops and business to work together holistically to drive outcomes? Including how risk officers and compliance teams operate – or do you want to create a ‘digital’ unit that is doing agile more in ‘isolation’.

Niels mentions that it’s for sure easier to find a part of the business where technology and business managers can come together and from there start the design of the agile operating model. You will need to map out the work and the dependencies – and then try to minimize the need for external inputs to drive an outcome.

In most organizations it’s impossible to get something done with no dependencies to other teams. Therefore, you should think about how you secure the capacity of those teams in a smooth way. This could be setting up a dedicated CoE capacity that operates as its own squad – fully available for a given Tribe (typical grouping of squads with a total volume of 100-150 members), or it could be a few people that act as liaison downstream to make sure things are managed well. In many cases, this is where agile and waterfall meet each other – as you have not yet moved the entire organization over to an agile operating model.

Niels highlights that a key success criteria is to platformatise your tech solutions, so you can build connectivity between systems via APIs instead of relying on people to support interactions. This should be a KPI for the individual platform owners along with operability, security, and deployment capabilities. People often forget these aspects in an agile transformation.

Where should Product Managers fit within the organisation chart?

For Niels, the role of product managers can sit within several departments of an organisation. Spearheading the project in a development team, providing content for campaigns in the marketing team, aiding as sales support engineers in the sales department. However, the most important thing is that product managers and product owners sit as close as possible to the P&L ownership to drive decisions effectively.

Don't create a 'digital' team in between the real business and technology as this will only add unnecessary costs and layers. Also it’s important that you distinguish between product SMEs and actual Product Managers. Very often, people with expertise related to the product is not necessary the right people to lead the product roadmap and outcomes as a Product Manager.

Abhijit highlights that product managers are the translators among the stakeholders, translating the requirements from business to technology, and back. They are the ones you reach out to if there's a problem with the delivery, operations, finance, etc. associated with that product. In agile, most product managers hold the pen, tracking the progress, making prioritization, managing escalations, and getting relevant benchmarks on almost a weekly basis.

How will an agile transformation impact the workforce?

As you embark on your agile transformation, there is no doubt that you face a lot of challenges along the way as a lot of uncertainty will need to be dealt with.

Niels says that as you think about the People part of the strategy, you really need to think about a number of things. These include the career path for people going forward, the performance management process and ultimately the metrics and KPIs that people will be measured on. How do you ensure you reward the right behaviour and get a proper 360 degree input for each individual going forward?

To get the full value of an agile transformation, the HR processes and overall systems likely need to change. You will need to enable people to belong to a chapter, work in squad and take part in relevant guilds of their interest. This shifts the paradigm of a reporting-line centric performance management model to a model with wider range of inputs, focus on craftmanship, and empowerment to the individual to drive their career. Niels highlights that some organizations split the personal part and the team part in the performance management aspect – so your year-end appraisal is 50/50 depending on how you do as an individual and how your team has performed on the outcomes they committed to.

The bottleneck in most organizations, when scaling agile is the processes in HR as well as in Finance. Therefore it’s important to look at this upfront and work on these changes early on as they normally take a lot of time to change.

                      Niels Mærkedahl                           Abhijit Dey, Axis Bank