Becoming a Customer-Centric Organisation

Intro

Twenty years since the Agile manifesto was created, there is no shortage of Agile frameworks, methods and practices. There are also plenty of Agile organisational experiments to learn from. First with tech firms and now transforming enterprises across industries. Statistics show that between 85 (Gartner report) and 95% (State of Agile survey) of organisations use some Agile practices.

A company is genuinely Agile when it is organised to respond rapidly to customers' changing needs. For an enterprise, Agile transformation means potentially redesigning all aspects of the organisation:

• structure and processes,
• technology,
• culture and mindset.

The challenge with agility is, by its nature, there are no plug-and-play formulae. All the Agile practices in the world won’t make a successful Agile transformation. Real Agile transformation requires an emergent approach that results in a unique organisation, relying on feedback and lessons learnt on the way.

This case study will share the transformation of the country division of a globally known insurance company, which Meirik coaches and consultants supported. One year into their digital and Agile transformation, they have reshaped half of their organisation into an Agile structure. They used a principle-based approach, aligning first on what they wanted to achieve in their transformation. From there, they experimented with a range of approaches and practices. Here we’ll explore the principles and practises the organisation found useful as well as problems they faced in the first year of their transformation.

Why enterprise agility?

The company’s division under transformation is one of the top three insurance companies in the country. As a leading insurance company, they understood they would need to take advantage of the digital age to stay ahead. The goals of their transformation are:

• transform into a customer-centric business,
• build a business based on long-lasting relationships with customers, and
• remain a step ahead of the market by recognising customer needs early.

Digital transformation is now the core of their strategy, and it is an ambitious transformation programme that will continue as they keep up with constant digital advancement.

The Agile transformation is part of the digital transformation efforts. The leadership team recognised that the organisation must become Agile to implement and benefit from the digital transformation successfully. The digital and Agile transformation began and covered 400 of their 800 employees within the first year. Main organisational changes done this year include:

• Eight new departments established - mini-enterprises built around value streams, organised by product and supported by Agile teams. The term “Value Stream” will be used in the text to refer to the organisational unit from now.
• Around 30 Agile teams formed, all using either a Scrum or Kanban Method.
• Supporting functions (e.g. security, legal, or compliance team) close to Agile teams but outside of Value Streams.
• A new portfolio management and governance model driving alignment, focus and transparency on the strategic level.
• Product owners recruited from business and empowered to prioritise their products and services for their Value Stream.
• Explicitly defined and managed cross-organisation initiatives of strategic importance (e.g. regulatory projects).
• Designed and started comprehensive Agile competence development programmes for key roles, including Scrum Masters, Product Owners, managerial and leadership positions and all Agile team members.

Principle-based transformation

Many companies who undertake an Agile transformation get stuck in the design phase. They spend months trying to plan out the transformation. They hold workshops to find the best Agile approach for their company and often find themselves in unresolved debates on where to start.

In the case of our customers, they have found a better way to get started – first, the leadership aligned on the principles. From there, they had clear parameters to test out Agile approaches and adapt them over time.

These are the five principles used to transform 50% of their organisation to work in an Agile structure with Agile practices in 12 months.

1. Concentrate on customers and value

Like most established enterprises, the previous organisation structure mirrored the process of creating products and services rather than the products and services themselves. With the transformation, the customer was put in the centre, and the organisation was designed to deliver value.

As a result of this principle, silos were broken down, favouring close collaboration of all involved in delivering value to the same customer segment. However, more than internally, collaboration is needed with customers and acting on the feedback. A rigorous focus on the customer was built into the product development processes, and customer feedback is used as a core part of decision-making and prioritisation on all organisational levels.

2. Build a culture of entrepreneurship

When teams are organised around customer value, they should operate like entrepreneurs, and everyone in the organisation is empowered to think strategically about maximising value delivered in their Value Streams.

Teams can act autonomously when they see potential sources of value. All employees are encouraged to act like entrepreneurs instead of waiting on instructions through a hierarchy.

3. Single-company strategy

While teams can act independently, they have the support and direction of a single strategy for the entire organisation. This allows autonomy for the teams with uncompromised organisational alignment in the same strategic direction. Furthermore, information on the progress toward this strategy is transparent across the organisation. This gives teams access to the information they need to make the best decisions for the company as a whole.

Equally, any issues that are blocking progress towards the strategy are transparent. The intention here is to resolve these issues as quickly as possible and allow the benefits to be felt across the organisation.

4. Consistent Agile model

For the organisation to gain the benefits of an Agile structure, the Agile model shouldn’t inhibit self-organisation. Remembering this, the organisation decided to build a single consistent Agile model to be used across the company to create a common language in all parts of the organisation and to minimise friction and conflicts between ways of working in different areas of the company.

5. The incremental rollout of organisational change

While the goal is to become an Agile company in its entirety, the initial change is incremental, and this is aligned with the Agile philosophy of inspecting and adapting.

With any change, there is a period of learning. An incremental rollout minimised the impact on current business results and gave teams time to become effective without excessively disrupting the organisation. In addition, this incremental approach supports the continuous and never-ending nature of Agile transformation.

Agile organisational model

With clear principles in place, the next step was to select an Agile approach that would be the basis of the organisational design. Despite 20 years of Agile experience, there is no one size fits all approach. In fact, any transformation that is not emergent or empirical is missing out on the benefits of an Agile approach.

There is an abundance of lessons and insights to be drawn from available Agile frameworks and the experience of others. The two big names when talking about Agile transformations (according to the State of Agile 2020 report) are:

• Scaled Agile Framework (SAFe): 35% of scaled transformations use this approach, more than any other scaling method
• Scrum: 76% of Agile organisations use the Scrum framework or a hybrid that includes Scrum

Another helpful influence was the Spotify Model. This well-documented organisation model also influenced the ING Agile transformation, which experiences were particularly relevant for our transformation as there were certain similarities to ING’s organisational context.

Methods and frameworks outside the Agile umbrella were also considered when they supported the principles and organisation’s strategic goals.

From these sources of inspiration, a unique own Agile organisational design has been developed. The model builds on the synergies between the well-known and proven methods and aims to remove their drawbacks and conflicts.

The following elements were taken from these frameworks and models. They were selected according to the outlined principles.

1. Scaled Agile Framework (SAFe)

SAFe is increasingly popular for enterprise Agile transformations because it addresses the complexity of these organisations. For our transformation, in addition to the complexity of any large organisation, they had a goal to launch a large number of Agile teams over 12 months - taking inspiration from a proven capable method that can support that many teams were simply the practical solution to start with. Over time, the company’s model is emerging, often far from the solutions proposed by SAFe.

SAFe provided a comprehensive organisation-wide approach and was used to draw from as a library of practices. Critics of SAFe share concern that the approach removes autonomy and the ability to adapt, compromising agility. For this transformation, drawing from the SAFe framework gave clear steps forward for their Agile transformation, which outweighed the risks of using this approach. The key was to carefully evaluate any SAFe practices’ relevance and applicability to the unique context and remember that SAFe is not a silver bullet. The drawbacks of SAFe were also addressed using a blended approach to the adoption.

While transitioning from a functional (siloed) organisation to a value-based organisation structure, the newly launched Agile teams needed to be fully autonomous from their start. SAFe provides practices to coordinate collaboration between dependent teams. The following elements of SAFe have been used and adapted. More practices may be adopted over time, whilst others might be discarded as they are no longer needed. Here are some examples of such adaptations:

• Program Increment (PI) planning was used as a starting point for designing a quarterly cross-team planning mechanism, internally referred to as Big Room Planning and evolving towards smaller, more frequent planning events.
• Program Boards to visualise the work across numerous interdependent teams.
• Visualisation of backlogs on multiple levels and connecting to company-wide objectives

At the same time, they were committed to removing organisational impediments that prevented these Agile teams from being truly autonomous. Many SAFe agilists are paying insufficient attention to this aspect of dealing with dependencies, believing too much in the dependency management practices built into SAFe, which only boil down to cross-team coordination and, as such, are not solving the systemic problems that cause the dependencies. Part of our transformation was eliminating the root causes of team dependencies, which often meant a profound restructuring of the roles and organisational structures.

Additionally, SAFe’s portfolio view helped the leadership to understand how it might be possible to lead the fully Agile organisation of the future.

Why was SAFe not adopted precisely as it is in its entirety? Several reasons were discouraging SAFe purism:

• the complexity of the framework,
• the frequency of specific decision-making was too slow to adapt as quickly as the organisation needed,
• it may limit the autonomy of teams and prevent the benefits of empowered decisions on the team level (going against the principle of building a culture of entrepreneurship).

The following elements of SAFe were cautiously not adopted.

• Agile Release Trains are central to the SAFe framework, designed to deliver value. However, there was no need to introduce them as the construct of Value Streams as organisational units emerged earlier and, in it, the Agile teams are taking the concept of organising around delivering value to customers to the extreme. However, some Release Train guidance from SAFe was applied to Value Streams, for example, around the number of people allowed.
• Program Increment (PI) Planning in SAFe is organised around Agile Release Trains. The already-mentioned Big Room Planning replaced PI Planning and was held for the entire organisation (around 30 Agile teams) at once. This helped align the teams around the vision and organisation goals and tackle one of the main challenges - dependencies, which cross the organisational borders.
• SAFe roles were not used. In SAFe, there are Product Managers, Agile Release Train Engineers and System Architect roles. There was no need for these roles as the organisation arrived at the roles of Value Stream Leader, Tech Leader and Agile Coach, and the differences with SAFe roles were far deeper than just the names. Where the same terminology was used for SAFe roles, especially Product Owner and Scrum Master, the SAFe definition was not used. These roles were more closely aligned to the Scrum Guide and its interpretation by Scrum.org, enabling more vital empowerment and autonomy (more about it in the next chapter).

The evolution of SAFe practices and their combination with other approaches means that the organisation cannot be called a SAFe implementation and is barely recognisable as SAFe now.

2. Scrum

There are vast benefits of implementing Scrum well as it facilitates the bottom-up discovery of products that would be optimal from a customer value perspective and helps build healthy team dynamics around self-organisation.

Nevertheless, Scrum is not a complete and ubiquitous process that is implemented everywhere in the same way. Although this is a single framework, there are a variety of approaches to Scrum, which may lead to misunderstandings between different parts of the organisation on how to practise this framework. The company chose to align with the Scrum.org approach to Scrum closely. The teams (teams) who use Scrum align to the Scrum Guide rigorously and rely on explanations from Scrum.org to ensure consistency of interpretation.

Another challenge with Scrum is the lack of guidance around scaling or adoption. Since the shared perspective is that of a single team, the Scrum Guide doesn’t account for common large-scale organisational challenges, and it may be seen as an idealised and narrow view on an organisation.

Therefore, its application wasn’t always easy, especially where there were conflicts between SAFe and the Scrum Guide or Scrum.org. These were most largely felt in the role of the Product Owner and the creation of a backlog.

SAFe outlines the roles of a Product Manager and Product Owner. The Product Manager most closely resembles a mature Product Owner in scaled Scrum. During the transformation, the company decided to build its organisation on firm Product Owners, who can be empowered to take full accountability for the business success of solutions developed by the Agile teams.

The separate role of a Product Manager was not introduced. The additional layer of hierarchy in the SAFe structure between the Product Manager and Product Owner role creates a risk of reducing the Product Owners autonomy. It was essential to have empowered Product Owners to achieve the principle of an entrepreneurial mindset. This also supported the principle of concentrating on customer and value as these Product Owners originated from the business and had a solid customer-centric perspective from day one in the new role. Finally, it helped align to a consistent Agile operating model with a simpler organisation structure.

SAFe introduces up to several backlogs creating a 4-tier structure, whilst Scrum Guide and Scrum.org are adamant that there is one and just one Product Backlog. To minimise complexity and maximise consistency, a two-tier approach to Product Backlog was implemented whilst upholding the principle of a single Product Backlog and single Product Owner role for any product. The intention was for a single backlog to achieve a concrete strategic objective, regardless of how many teams work from that product backlog. At the same time, all strategic objectives in the entire company are tracked on the portfolio level in a single artefact, clearly visualising the company’s roadmap and enabling effective strategic decision-making. The roadmap presents strategic initiatives, which may map into a single existing team, multiple teams from the same Value Stream, multiple Value Streams, or even require setting up new teams or a Value Stream. Thanks to the portfolio level, the Value Streams and teams within them gain the company’s internal perspective on why they exist.

It is essential to mention that one strategic objective (for one backlog) as products is broader than a single insurance product or a single IT system. They can require numerous insurance products to be released to the market, likely involving deliverables from a wide range of company functions. Each deliverable may need a different nature of work, and as many functions required as possible would be reflected in permanent members of the appropriate Agile team(s). The essential common aspect of this diverse work and deliverables is that they are associated with business KPIs - the ultimate product of the Agile teams is to deliver a change in the company’s business, which is measured predominantly from the customer perspective.

There are some exceptions to this concept of teams and backlogs, and more could occur as the transformation continues to scale to the remaining parts of the organisation. In particular, many exceptions are for shared services teams, which maintain separate backlogs.

3. Kanban

Whilst Scrum was the starting point for the initial Agile teams set up in the new structure, it quickly turned out once again that one size does not fill all. Certain teams were finding Kanban more natural in their context, and Kanban started spreading in the organisation, where the teams offering services within the organisation were taking the lead. To ensure consistency in the approach, a decision was made to adhere to Kanban University definition and guidance on the Kanban Method, which included using the STATIK method for starting any new Kanban system.

The application of the Kanban method is not limited to Kanban teams. Even some Scrum teams found Kanban helpful, mainly the Upstream Kanban quickly gained popularity, where the product discovery was not a straightforward process but involved numerous steps and the necessity of coordinating with a larger number of stakeholders. Furthermore, Kanban was applied to ensure the flow of larger strategic initiatives across the organisation - the Portfolio Kanban is also known in SAFe.

Kanban adoption is growing fast and together with maturing of the method implementation, the organisation is expected soon to become a well-functioning network of interconnected entities much reassembling higher levels of the Kanban Maturity Model.

4. Spotify Model

The illustration of the so-called “Spotify Model” is well known by all who were part of any Agile transformation. Yet, as popular as it is, it is discouraged from copying this model. During the transformation, this model was treated as a source of inspiration similar to SAFe - the terms Squad and Guild were adopted as they eased everyday communications. A squad is understood as an Agile team, which uses either Scrum or Kanban and operates within a single Value Stream.

A guild in the Spotify model is an organic community of shared interest, but in the case of this transformation, a guild is more an explicitly established community of practice. It is created for people with similar competencies and development needs, e.g. Tech Leads, Product Owner, and Scrum Masters. The intention behind forming a guild is to share learnings across the organisation, beyond the reporting lines. As a result, they establish good practices in the particular area of speciality and drive improvement across the company in their fields.

Tribes, another construct known in the Spotify model, were not needed because of the Value Streams structure already in place. Chapters are currently not used, although the organisation may evolve towards introducing them over time.

5. Lean

The Lean management philosophy inspired the use of Value Streams, but it doesn’t carry exactly the same meaning in the case of our transformation. The Agile Teams are built around value streams (known from Lean) to such an extent that the term “Value Stream” is used to call organisational unit made of Agile teams that have been established to change or build the value stream (Lean) aiming at an increase in value delivered to the customer. So if, for example, you will mention Individual Value Stream or Group Value Stream, all will understand that the conversation is about the group of Agile Teams deliberately set up and optimised to discover and deliver more value to Individual or Group customers, respectively.

Another idea inspired by lean was consistency in improving the Agile organisation.

6. Design Thinking

To understand the customer’s point of view, workshops inspired by design thinking were run. CX (customer experience) and UX (user experience) philosophies were drawn on to create the customer-centric organisation design. CX and UX practices are also being absorbed by Agile teams operating in that structure.

7. DevOps

Google and a DevOps approach heavily inspire the broader digital transformation. One of the goals is to increase automation, as well as SRE (Site Reliability Engineering) initiatives were undertaken.

The DevOps approach is valuable in addressing the challenge of technical debt. Like all well-established financial and insurance companies, legacy IT systems are integral to providing customer service, offering insurance products and organisational operations. Fortunately, the company under transformation treats technical debt very seriously and addressing it is considered one of its strategic programmes. As progress is made, the company is moving closer to the DevOps model.

8.OKR

As part of the portfolio view of the organisation and to create transparency and alignment, the leadership team created OKR (Objectives and Key Results). The process of creating them highlighted a challenge for leadership to align the priorities across them strategically. Eventually, six objectives were agreed on at the whole company level, which is a significant improvement in driving focus across the entire organisation on what matters the most. These OKR marked the beginning of the broader adoption of OKR within the organisation, where every Value Stream and every team is engaged in crafting the objectives and regularly inspecting their progress towards them. The OKR are also the starting point for any larger planning and collaboration events like the Big Room Planning.

Challenges

If no challenges emerge in an Agile transformation, it’s not done correctly. One of the benefits of agility is making transparent difficulties so you can resolve them.

The principle-based approach helped overcome the most common challenges of adopting and scaling Agile. Challenges such as organisation resistance, insufficient leadership participation or inconsistent application across teams are visibly less problematic than in many other companies undergoing Agile transformation.

This does not mean that there were no challenges in the transformation! In addition to their principled approach, the leadership team is committed to transparency in the organisation’s challenges. This commitment to transparency reminds the organisation of the value of solving challenges and increasing overall organisational agility. The subsections below present the seven major challenges faced in the transformation so far.

1. Inconsistencies while defining an Agile organisation model

While the blended Agile model chosen through principles gave a head start in the transformation, it also brought inconsistencies between the approaches, roles and methods. By all means, overcoming those inconsistencies was and still is not a straightforward process. The logistics of consultations and finding solutions by the organisation contributed to the difficulties – the company embraced participatory decision-making, which sometimes led to lengthy discussions of very large groups. The more people affected by the discussed issue, the higher risk of controversies, but it gives back in the quality of the decisions. Facilitating such discussions by the Transformation Team was crucial in reaching satisfactory results.

2. Ownership of IT systems

Shifting from traditional and separate IT and business departments to organising around customer value created a question of ownership over IT systems. Value Streams and teams are empowered to do all necessary to deliver value to their customers. This means that various teams or Value Streams may modify the same IT systems to achieve their business objectives. Questions on who is responsible for the IT infrastructure and its elements posed a risk to business operations. The following issues were discussed:

• How are standards maintained while changing systems, and who sets these standards?
• Risk of destabilising critical systems by uncoordinated changes to the system
• Lack of clear ownership regarding who should solve maintenance issues.

These risks and uncertainties led to resistance to breaking the old structures. In effect, all the IT systems were mapped to organisational units, which, together with the responsibility for the system, also received a maintenance budget.

3. Regulatory work

Insurance is a highly regulated industry, and regulatory work needs to be effectively managed. Unfortunately, it usually comes about quickly, with little time to make the changes and a hefty penalty for failing to comply or missing the deadlines provided by regulatory bodies.

The challenge with regulatory work is that it often goes across Value Streams, and this makes it hard to coordinate, prioritise and allocate across multiple backlogs. The solutions to these challenges so far include tracking regulatory initiatives in the strategic portfolio and the help of the Portfolio Management Office in coordinating those efforts. The most important piece of the solution was the organisation-wide mechanism for managing dependencies between the teams, which was discussed earlier.

4. Autonomy vs. standardisation

In an ideal Agile organisation, teams would be fully independent and autonomous. This ideal must be matched with the company context in every Agile transformation.

In the early stages of the transformation, the organisation was highly interdependent. This meant some level of standardisation and centralisation supported the necessary collaboration across teams. However, as these dependencies decrease, this level of centralisation and standardisation will likely be too heavy and limit the benefits of self-organisation. The teams might outgrow the standardisation required at the start. So, the challenge is finding the point of balance between the two conflicting needs of the organisation, which keeps changing over time.

OKR partially address the need for standardisation by giving common objectives and measures. However, there were still questions to be answered, such as:

• Should there be a standard for managing product backlogs to aid dependency management?
• Is Big Room Planning really necessary? How frequently should it be organised, and who should be taking part in it?
• What quality standards should be used to address inconsistencies in the deliverables of different teams?
• How to maintain IT infrastructure stability when the IT systems are interconnected?

5. Cross-functional teams

In the context of the discussed transformation, cross-functional teams mean more than cross-functional software product teams. It meant engineers working multiple systems and business roles that used to be far from development teams but are vital to delivering customer value, working together as a single customer-centric team.

This shift from teams arranged by function and IT system (or components of IT systems) to customer-centric teams were integral to experiencing the benefits of a truly Agile organisation. However, it presented several challenges:

• The scarcity of specialists in certain areas meant that more teams wished to have an individual of specific competencies than people available.
• IT and business people had never worked closely together and struggled to align behind a common goal or deliver real value in short iterations.
• Some team members had to retain responsibilities outside their team backlog, especially business people who couldn’t be pulled out of operations entirely.

• It was unclear how to prioritise the operational running of systems and, in some cases, technical debt since it was work-related only to some team members and typically not directly coming out of the business goal of the entire team.
• In several cases, the teams would significantly exceed any reasonable team size if all the needed competencies were included in the team. At the same time, narrow specialisations of individuals were raising concerns about whether they would be well utilised when allocated to a cross-functional team.

Certain compromises had to be made. Some teams are closer to the ideal cross-functional team, while others still need time. In all cases, significant steps were made towards the desired state, and the efforts will continue since the fewer required competencies in teams, the more they suffer from dependencies.

6. Dependencies

The new organisation was built on the concept of autonomous teams within autonomous Value Streams. However, it would be naive to think that dependencies will disappear overnight with the introduction of the new structure, and there were still many dependencies across teams.

There were business dependencies between the Value Stream. This meant that one Value Stream had to do some work for another Value Stream to deliver something important for the receiving side but not necessarily equally important from the perspective of business objectives of both Value Streams. This may be due not only to technical or competence dependencies but also to a business change that should be coherent across the entire company.

Occasionally there would be dependencies on the competencies of individual team members. In these cases, it did not make sense to acquire a specialist or build that competence in the team permanently (for example, if team size would grow unmanageable, or the skills were not needed frequently, or it was not a good use of the specialist skills or budget).

The illustration below presents a snapshot of dependencies identified by various teams before a quarterly planning event. A single arch illustrates the presence of one or more items in a product backlog dependent on the team indicated by the head of the arrow. Blue boxes represent parts of the organisation that didn’t transition to the Agile organisation (although many were experimenting with Agile methods), whilst the yellow boxes stand for Agile teams and Value Streams.

Leaving those dependencies unmanaged would bring the organisation to a halt. There were simply too many of them, spanning wide across the entire organisation. So, methods of helping the teams and Value Streams to collaborate were introduced to prevent a choke of the organisation whilst parallel efforts to reduce the number of dependencies are taking place.

7. Remote work

The challenge of remote work wasn’t unique to that particular company since the transformation began days before the global Covid-19 pandemic was announced. This meant all the employees were now switching to remote work on top of the organisational changes. In the post-pandemic realities, remote work or a hybrid approach will likely continue to be part of the operating model.

It is well accepted that face-to-face communication is best for teams to collaborate and build trust, which is especially strongly emphasised in Agile. Now the new teams had to build relationships and alignment while all were working from home, i.e. an extra layer of complexity was added to every single thing that was happening in the Agile transformation.

Summary and conclusions

In one year, the company has successfully transformed 50% of their organisation into an Agile structure with Agile practices. They started their transformation with clear principles, now reaping the benefits. They are better connected to their customers and deliver valuable services and products that match their customers’ needs. Employees are empowered and encouraged to use an entrepreneurial mindset. The company strategy is transparent, and challenges are highlighted and resolved quickly.

With these clear principles, a consistent, Agile model has been created based on lessons from other Agile organisations, drawing on what works from popular and proven frameworks and approaches.

While the challenges the organisation faces in switching to this new Agile structure and practices still need to be fully resolved, the company already feels the benefits of the change.

‍