Applying CAO Guidelines at a Big German Insurance Company 

By Wolfgang Steffens – Certified Creating Agile Organizations Trainer.

This experience report describes in hindsight the beginning of the Agile journey of the IT department Terra. This IT department was part of a large traditional German insurance company.

This report is divided into the following parts:

• • Formulating desired organizational capabilities

• • Understanding the organization and its current organizational capabilities

• • Wishful thinking and the management-induced copy/paste Scrum

• • Creating an Agile organization by applying the CAO Guidelines

• • Ideas for further improvement

For the reader: Creating Agile Organizations (CAO) definitions and concepts are highlighted in a text box.

Disclaimer

This experience report is written based on my best knowledge of the company, yet it might be that due to its huge size, I misinterpreted some of the circumstances, events, or relations.

Formulating desired organizational capabilities

The department had been working in a functional setup for a couple of years. Many issues arose and the department wanted to use an Agile setup to achieve the following organizational capabilities:

• • Reliability in Agile product increment delivery

• • Delivery of small product increments with high product quality

• • Technical capability to deploy after each Sprint

• • Transparency in the status of product development

• • Flexibility in handling changes in requirements

• • Faster prototyping

• • Improved collaboration with stakeholder organization

• • Increased test automation

Before we go into the adoption, let’s have a look at the current setup to attempt to understand the complexity of the organizational design, the existing organization capabilities, and the resulting gap regarding those capabilities.

Understanding the organization and its current organizational capabilities

Overview

Terra developed two customer-centric products (Alpha and Bravo) and it was responsible for its operations including fiscal reporting to the headquarter’s Finance & Control department.

When I asked Terra’s managers “What is your product”, there was no customer-centric view. Instead, my question was answered with “It’s very very complex” complemented by technical gibberish trying to explain the main architectural building blocks.

Product Products represent the goods and services that an organization offers to its external customers.

Structures within and outside Terra

The organizational structure followed a typical functional organization design. The main groups of the IT development were:

• • Business – doing design work as well as customizing the SAP system for their needs. This unit also contained a financials group taking care of accounting and work involving financial aspects.

• • Technical – implementing code (mostly based on Java and PL2)

• • Testing – the testing was organized in the form of an outsourced “testing factory” located in India, mainly doing manual regression tests. There was a so-called testing bridgehead which was responsible for communication between the test factory and the teams

The structure of the Product Development functions consisted of a Project Manager (Head of the department), Business Leads (BL), and Team Leads (TL) each heading one team.

Organization Chart of the department Terra

Furthermore, there were several other functions in the IT department:

• • Architecture Group – looking after the architecture and sometimes helping with programming, bug fixes, etc.

• • Test tool Development – developing automated test tools for user acceptance tests

• • Release Management – Planning of releases, status reporting, Ticket tool management and support

• • The production group consisted of two teams:

    • • Operational support group – focusing on keeping the Server system operational
    • • Incident Management  – focusing on collecting the discovered bugs from the test factory, and other incidents reported by users, as well as prioritizing those incidents for all the teams to solve.

• • Customer Documentation group – focusing on collecting topics and steering the external technical writers.

• • IT Product Management  – keeping in direct touch with selected customers for selected topics on the main product. Product Management with ROI responsibility for product Bravo.

Department Terra and its interfaces to other departments, customers, and users.

Besides all these groups, the following other departments in the company are important to mention as they were outside of Terra:

• • Business Operation (BO) – This department was responsible for high-level release planning, steering, and first-level business analysis of the product Alpha.

• • The common platform development group. This group focused on the development of the Host system of the entire insurance company.

• • The department Terra used some 3rd party components in their development e.g. SAP

Describing the existing way of working

The organization suffered from dependencies which were seen in unnecessary waiting, hand-off, knowledge scatter, and long lead times, leading to frustrated and unhappy employees. The usage of a Design Structure Matrix helps to visualize the task interdependencies between the different functions.

Design structure matrix & interdependence A Design Structure matrix helps us to understand the task interdependencies or like in this case, the dependencies between the different functions. There exist three types of interdependencies:Pooled interdependence e.g. shared resourcesSequential interdependence e.g. asymmetrical Team Technical depends on one Team finishing the work firstReciprocal interdependence e.g. two teams (or team members) dependent on each other to finish the work package

Design Structure Matrix of Terra and Business Operation

All reciprocal interdependencies were handled as if they were sequential (“waterfall” model). This approach was working in the sense that the department got stuff done regardless of how painful it was and how much time it took. However, this way of working resulted in a lot of issues which we discuss next.

Illustration of the way of working with sequential dependencies

The department followed a classic sequential life cycle model with the following phases: Analysis, Design, Implementation, and Testing. The business analyst department was crunching the requirements from a high-level, problem statement into lower-level technical requirements. From there the Team Leads took over and did some more analysis to spoon-feed the teams with work packages. Those work packages were then given to the Business teams, and once they were finished the work was handed over to the Technical teams. Finally, the Test Factory performed the tests, and the Incident Management group closed the loop by feeding the found bugs and incidents back to the Business and Technical Teams.

One huge problem was the amount of incidents after the software went into production. The week after go-live was feared by everybody in the department. At one point in time, a temporary task force was formed to fight the symptoms by reducing the number of incidents (see graphics below). This pattern, establishing a temporary task force, repeated over time (please note the systemic dysfunction as a result of the structure), if the number of incidents grew out of hand. There were two main reasons for this huge amount of incidents: the requirements were not properly understood in the first place and the technical solution contained bugs, misfits in the interfaces, poor test coverage, low reliability in Agile product increment delivery, delivery of product increments with low product quality, etc.

Another huge problem was that the business’s need to respond to rapidly changing requirements was not met. Instead, a long-lasting, complicated, and cumbersome change management process was initiated when there was a change request.

Coupling and dependency In any system, its parts are either tightly or loosely coupled. Coupling can happen between functions such as departments, sub-departments, groups, teams (even firms), workflows, process steps, resources, product goals, PBIs themselves, and the technical implementation of PBIs. Coupling on Functions means that work by one unit negatively influences the ability of another unit to achieve its goals and thus overall performance degrades at the benefit of local performance yet they are not dependent. Dependence means the unit cannot complete its function/task. Example: A product is built using several software components. (A) Component teams can work only on a single component. A customer-centric PBI is built by enhancing and changing multiple components. Thus, there is a tight coupling between the teams from the overall product-level perspective on goals, a tight coupling from a PBI perspective, and a loose coupling from a technical perspective as each team works on its component in isolation. (B) Cross-functional, cross-component teams have all the competencies to work on several components. If the product complexity is too high, those teams might focus on a customer-centric part of the product instead of the whole. Thus, there is a tight coupling from the overall product-level perspective on goals, a loose coupling from a PBI perspective because the teams are interchangeable, and a tight coupling from a technical perspective as each team is touching simultaneously the same components as other teams.

Design Matrix between functions

The design matrix below shows both, the dependencies and the coupling between the different functions within the IT Development group, the IT Product Management, and the Business Operation function.

The detailed analysis revealed the following main dysfunctions:

• • The various functions within the IT department were tightly coupled resulting in more goal conflicts between the functions and decreased product-level adaptability.

• • To get a product developed for the customers, the IT development functions must work together. Since the structure was not designed for collaboration, it led to employee frustration, a high need for coordination, and lots of rework, resulting in decreased adaptability.

• • The BO functions could not achieve their goals as they were tightly coupled to the IT department, resulting in cumbersome change management processes and lower adaptability.

Legend:

• • R – the unit is mainly responsible for fulfilling the function,

• • r – the unit is partly responsible (contributes) to fulfilling the function

Conclusion

In this way, the current approach revealed the following major weaknesses:

• • The development of features and functionalities took a long time (it might take half a year to one year to get big features into production)

• • The quality of the Software released into production was loaded with bugs (the week, after a release went into production, was feared by all because it was hailing hundreds of incidents from the users and stakeholders)

• • Change requests from the Business Analysis group were hard to get inserted (Typically it was a fight to add a small feature after the go-milestone of a major release was agreed, since the department was measured on how well it fulfilled the targets agreed in the milestone document. Small changes caused trouble and were disliked by the IT department).

• • The developers experienced long feedback cycles from e.g. testing function, and customer documentation, resulting in weeks or months-long delays. The coordination by the Incident management group made the cycles even longer.

• • Employees were frustrated with the current way of working and developers were well aware of better methods to develop products proclaimed in the Manifesto for Agile Software Development, and practices like Scrum, Kanban, XP, etc.

Wishful thinking and the management-induced copy/paste Scrum

Due to the successful Scrum pilots of two independent teams, managers decided to move the IT development organization to Scrum by scaling Scrum (aka copy/paste Scrum). The result was system component teams around the main architectural building blocks: Portal, Rich Client, Finances, Business Logic, and a few more. Each component team had its own “Team PO” who prioritized the “team backlog”.

New organizational structure with teams formed around system components

Other functions within the IT department did not change. The product view was still technical instead of moving towards a customer-centric product view. This means all Product Backlog Items (PBIs) were centered and expressed as parts of the major architectural components.

Illustration of the attempted way of working with management-induced copy/paste Scrum

As a result of this copy/paste approach, the IT development came almost to a stillstand and after 3 Sprints (6 weeks) only a fraction of functionality compared to the functional organization was regarded as ready. The head of the IT department pulled the plug on the organization and moved everybody into a task-force mode. Now it was possible to get some functionality done with the remaining 3 Sprints to reach at least a bare minimum of the release targets.

The key learnings from the failures were:

• • The teams’ compositions were not fit for purpose.

• • We made our lives worse than before.

• • An architectural view does not equal a customer-centric view of the product.

• • We have not been able to define our product and what it does.

• • One Product backlog with a customer-centric view brings focus to the entire group.

Creating an Agile Organization by applying the CAO guidelines

In this section, we will apply the most relevant of the CAO Guidelines in order of importance to describe the changes in the department Terra and its surroundings.

For the reader: related CAO guidelines are highlighted in a text box.

Guideline 1: Organize in Product Groups

Product Group A Product Group is defined by the purpose within the company, as well as the necessary organizational elements like cross-functional teams, separate functions, and roles to achieve the purpose. Leadership is provided by a senior manager with in-depth market understanding, and the autonomy to make budget, resources, and planning decisions. A Product Group is a semi-autonomous unit that is created to develop, enhance, and sustain a product.

In the flow of what one needs to clarify first, the definition of the product group(s) was pretty much on the top. The department Terra had two missions: satisfy the BO function needs (focus on car insurance sold at car dealerships in Germany) and expand car insurance markets internationally on their own. This led to the conclusion that there are two different products:

• • Alpha: Everything around car insurance which was sold by the car dealer to the end customer for the German market only.

• • Bravo: sell car insurance through other means internationally (especially outside Germany). Product Bravo was in full control by the IT department. The Product Management had ROI responsibility and was located with the IT department Terra. A cross-functional, cross-component, co-located, and stable development team was formed for this product.

Illustration of product Alpha

Since the product Alpha was too large to be handled by one Product Owner alone, it was further divided into three Value Areas:

• • Contract underwriting – Developing the interface to the car dealer, so that the systems are integrated and a car dealer can offer car insurance to car buyers (incl. The financials, so the car salesperson receives its commission).

• • Contract modification – Enhancing the existing system so that the insurance clerks can support customers to make changes to the contract or their user data.

• • Claims – Enhancing the existing system, so that the customer can file a claim either directly or through an insurance clerk.

Value Areas A Value Area is defined as a valuable product part that addresses the needs of a customer or user segment.

Each Value Area was independent of other Value Areas and addressed different user segments. The development in each of the areas (including testing) could happen in parallel with work in other areas. However, the product was released as a whole including features and functionalities from all three Value Areas. There existed a logical order though e.g. it was not possible to modify a contract or file a claim for a contract which does not exist yet. This sequential dependency can be managed through planning.

Each Value Area had one Area Product Owner (APO), and one Area Backlog. All teams across all areas followed the same cadence. The Product Backlog Refinement, Sprint Events, and coordination happened mainly within the area. Discussions on architecture, testing, and testing tools were discussed across all areas.

The Value Areas were not defined by using the Value Area Heat Map but we followed a similar idea by investigating which components need to be touched when creating functionalities with either the car dealership, the insurance clerks, or the end customer directly. Interestingly, we noted in hindsight that the BO department was already structured into those three areas before this change started.

Guideline 3: Merge Units with Essential Interdependencies

Let’s have a brief look at those and how the guidelines Merge Units with Essential Interdependencies and Group by Common Customer contributed to defining the product groups. 

Guideline 3: Merge Units with Essential Interdependencies This guideline is a way to reduce the coupling between unit functions by either merging them and/or assigning them to a larger unit. The key focus shall be put on resolving unit functions with essential interdependencies since the coordination effort here is mani-fold compared to a sequential or pooled interdependency.

The functions of Business, Technical, Testing, Customer documentation, and Finances had essential interdependencies. Those functions were merged into one unit function (i.e. the IT development function in Terra), and at the same time split by the common users into three Value Areas. Those Value Areas were tightly coupled on both product goals (i.e. working in the same Value Area) and on the technical aspects (i.e. each team was cross-functional and cross-component). On the PBI dimension, the teams within a Value Area were loosely coupled since any of the teams in each area could work on any of its PBIs. This means that the teams within a Value Area were exchangeable. Other non-essential functions were not included in this merge.

After this merge, it instantly became clear that there existed three Value Areas that did not have essential interdependencies. The desire to have the authority as low as possible to enable e.g. faster decision-making, was one of the drivers to create the three Value Areas. However, there was a sequential interdependency between the Value Areas which did not cause any harm and was managed through planning (i.e., you cannot create a claim for an insurance policy that does not exist yet).

Furthermore, since the BO organization was already organized in these three Value Areas with dedicated contact persons and related experts, the collaboration between e.g. the BO subgroup contract underwriting and the IT dev Value Area contract underwriting was boosted to a new level. These two functions were tightly coupled to each other but loosely coupled to e.g. the BO – claims subgroup, or the IT dev claims Value Area.

Guideline 6: Group by Common Customer It is not enough for the front-end units to identify customer needs and then hand them over to the back-end units.The Agile organization considers two options to globally optimize for adaptabilityCreating shared customers and shared performance indicators for the different units’ managers.Merging (part of) market units with product units into a larger unit, the product group, that builds the complex product, brings it to the market, and leverages feedback.

When we started to investigate the customers of Terra’s product development, it became obvious that we had two loosely coupled customer segments. The main focus was on product Alpha. An established approach of selling car insurance through car dealerships in Germany to the people buying cars at their shops. At the same time, a typical consumer has different needs over time resulting in the three Value Areas: contract underwriting, contract modifications, and claims.

The second product (Bravo) was a vaguer and broadly defined customer segment with the goal of selling car insurance through e.g. third-party agents. This supported the firm’s plan to expand selected markets globally. This endeavor was very much in the beginning.

In the end, this setup made the work of the Product Owners much easier. Now there were clear interfaces with responsible counterparts, easier and faster decision-making, easier and faster feature prioritization and dealing with changing requirements in general, better understanding of the smaller work packages and what customer/user problems need to be solved.

Guideline 2: Decouple Unit Functions

Guideline 2: Decouple Unit Functions When unit functions are coupled, this leads to unnecessary coordination, goal conflicts, and poor agility. Therefore, decouple unit functions so that each unit can fulfill its function by making decisions and performing its tasks to reach its goals, without negatively affecting the ability of other units to fulfill their functions and attain their own particular goals.

We can use the Design Matrix to visualize the coupling between unit functions after the change.

Design Matrix around product group for products Alpha and Bravo

Now, the three BO subgroups had a clear point of contact with the Area Product Owner of the corresponding Value Area. There was much less need for coordination, the goals were not in conflict any longer within product Alpha, and neither was there a conflict between product Alpha and Bravo. The organizational Agility was improved significantly.

Guideline 5: Contain Reciprocal Task Interdependencies

Guideline 5: Contain Reciprocal Task Interdependencies We should design work based on the intensity of interdependence and then introduce specific coordination techniques for each.

The three main development functions Business, Technical, and Testing were re-organized into a total of ten customer-oriented development teams divided among the three Value Areas. Contract Underwriting had five teams, Contract Modifications three, and Claims two teams.

Each team was now capable of converting a customer-centric PBI into a Potentially Shippable Product Increment. The coupling shifted towards a tight coupling at the Value Area goal level, a loose one at a PBI level, and again a tight one at the technical side.

Over time this setup supported cross learning and Guideline 12: Multi-skill Development.

Guideline 12: Multi-skill DevelopmentThe team skills required are always changing. For example, a top technology today will likely not be so highly regarded in a couple of years. Teams frequently need to master new expertise. The question then becomes how to find the right balance of experts, generalists, and the skills they need to develop.Therefore, create a system of human operations that:Values employees by a combination of personal and team accomplishments.Values people who become multi-skilled specialists.Maintains a balance between deep specialists and generalists in the teams.

Guideline 10: Design Shared Services for Support

Guideline 10: Design Shared Services for Support The product group structure creates semi-independent units with separate leadership, finances, resources, and people.On the other hand, independent product groups duplicate roles and functions; organizations can lose the benefits of centralized units such as economies of scale.Therefore, considerThe cost of development delay when the unit is a shared serviceThe criticality and uncertainty of the dependency between the product group and the unit

The common platform development (the host) was loosely coupled to the department Terra. The task interdependency remained sequential as before since there was a well-working API in between.

Architecture and other functions within the IT department were mostly pooled dependencies. After the change, the Incident Management Group did not have much work to do, so some people left, some took other jobs, and only a few supported the POs in handling the remaining few incidents.

The release management group focused on Product Backlog support for the Area POs and team members working with the Product Backlog. Further, they created reports for the Head of the department. Several people left the organization and spread their knowledge to other parts of the organization.

Guideline 8: Create Conditions for Emergent Coordination

Guideline 8: Create Conditions for Emergent Coordination Because the people who do the work understand best what needs to be coordinated and how to perform coordination work.Therefore, create the conditions so that people know about what, with whom, and when they need to coordinate?”Communities: To attend to cross-unit concerns, including alignment on functional and other skills, standards, shared tools, and processes.Facilitation Processes: Multi-team meetings to discover opportunities for coordination

The collaboration between the three BO areas and each of the Value Areas was intensified by inviting the people from the BO organization to the Product Backlog Refinement events.

This improved collaboration resulted in significantly fewer Incidents when a release went to production. The previously feared spike in bugs did not occur anymore, as behaviors and expectations were clarified before they were developed ( see also the ideas in Specification by Example and Behavior Driven Development).

The BO organization participated in the relevant Product Backlog Refinement sessions and joined the relevant Sprint Review sessions. In principle, the BO organization and the IT development functions should have been merged as well resulting in a design where the Product Owners would have come from the BO organization (see ideas for further improvement). However, that decision would have to be made several hierarchical levels above the department heads and was regarded as Utopia.

Guideline 11: Separate Product Management from Line Management

Guideline 11: Separate Product Management from Line Management Dual reporting lines and hierarchical competence managers lead to:Less team focus on the product group’s prioritiesEncourages people to prioritize the goals of the hierarchical manager over the PO (side steering)Encourages people to grow in narrow, single-skill career paths, optimizing the performance of individuals, not team performance.Therefore, design the product group so that line management decisions are separated from product management decisions and the teams only receive work and priorities from a single source.

The Head of the department recognized the need to get a dedicated Resource Manager for all department members. It shall be noted that the department did not have any (own) resources. All members were external, so they had their own line management, and the rest of the people were borrowed long-term from a resource pool (or other parts) of the large insurance company. Thus the real line management happened outside the department and the resource manager focused on resource planning, dealing with changes in personnel, contractual issues with the suppliers, etc.

Summary and results

What were the results of the Agile adoption and to which extent the organization developed its desired capabilities?

Successful user-centric problem-solving

The organization was now able to solve the user’s problem which is the essence of Scrum. Further, it had a clear focus on user’s needs and was able to achieve all release goals which were required by the users.

The creation of cross-functional, cross-component development teams by using a self-designing team workshop boosted the motivation of the team members to such a high level that people still talked about this great event months later.

Enhance collaboration and reduced number of incidents

There was a significantly improved collaboration between the teams themselves, as well as the teams and the Business Operation organization, especially between the Value Area contract underwriting and the car dealer’s IT, which was the most challenging interface compared to the others.

The spike in incidents once the software went into production was gone. This was mostly a result of the improved collaboration between BO and the teams (understanding the requirements), as well as the cross-functional, cross-component team structure which allowed teams to find and correct faults before they went into production.

The organizational structure was now much simpler and the complexity was reduced.

When reflecting on the desired organizational capabilities, we can conclude:

• • Reliability in Agile product increment delivery

Through the strong involvement of the teams in understanding the users’ problems, the continuous Inspect & Adapt, and the new team structure the department continued to deliver several releases reliably.

• • Delivery of small product increments with high product quality

The product quality improved significantly and remained consistently high. The days of the horror week after a release went into production were over.

• • Technical capability to deploy after each Sprint

There was a clear improvement in this direction, however, there was also room for improvement. This was partly caused by the company’s decision to change suppliers for testing resources during the Agile adoption.

• • Transparency in the status of product development

There was a clear improvement compared to earlier. Now the APOs could provide the first release forecast after the 2nd Sprint. The usage of Jira as a Product Backlog, and the manual conversation from and to a high-level spreadsheet for other analysis was tedious, cumbersome, and error-prone. However, management did not want to give up the usage of Jira and go with a spreadsheet alone.

• • Flexibility in handling changes in requirements

Small features could now be developed in 1-2 Sprints after Product Backlog refinement without the heavy change management process.

• • Faster prototyping

The new team structure enabled the teams to swiftly create prototypes that were inspected by the users and stakeholders. That was especially crucial in the Value Area Contract underwriting which had to integrate the firm’s own system with the one of a car dealer.

• • Improved collaboration with stakeholder organization

The previously existing goal conflicts that resulted in working against each other disappeared. Now, there was a much higher degree of collaboration noticeable. The BO organization participated actively in the Product Backlog Refinements and the sprint Reviews. Also, the collaboration between the department managers improved a lot, yet higher-level management did not show much interest in this transformation. Their focus was solely on the financial numbers.

• • Increased test automation

For the first time, the organization developed a testing strategy with a clear focus on improving test automation at multiple levels. This was somewhat slowed down by the change of testing supplier as well as the fact that the testing supplier was initially paid by time spent on testing thus decreasing further the move towards automated testing.

Ideas for further improvement

• • The Area POs should have been located in the BO organization instead of the IT Department.

• • The architecture group wanted to move closer to the actual teams potentially even dissolving the group completely, working directly in the teams (or at least becoming a member of the Value Areas), and with the support of the architecture community handle cross-area issues.

• • More focus on automated testing as well as TDD and ATDD.

• • More focus on Technical Excellence.

• • Eliminate the need for Operations Support during deployment by aiming for a Continuous Delivery model.