Agility in Merger & Acquisition

Introduction:

The benefits of using agile methodologies for software development and delivery are by now well documented. An obvious question then surfaces, is it possible to realize similar benefits outside of the IT realm?

The answer is a resounding YES. However, Scrum is a framework and not a methodology. As such you cannot import the processes and artefact “as is” and hope to replicate the result and benefits achieved elsewhere. That is the approach currently used on several “transformation” initiative and the dismal results speak for themselves. To illustrate, I am providing below, a real-life example and provide some conclusions that might be of use to those who are contemplating such an endeavour.

Premises:

A brokerage firm successfully negotiated the acquisition of a competitor. Said competitor has more asset under management than the acquirer and is the subsidiary of a foreign bank. Full integration of both entities must be completed in a very short window (16 weeks or less) for 2 reason.

· Failure to do so would require the generation of 2 separate annual reports. A very cumbersome and onerous exercise for publicly traded entities.

· A major initiative is scheduled to start in the new year and all top executives must be available to support it.

A further constraint relates to the fact that except for the IT department no one has any experience with the processes or tools used in traditional project management.

A quick assessment of the situation by the leadership team of the acquirer lead to the following conclusions.

· Given the severe time constraints, training the participants in traditional project management is not an option. New tool/software are not to be introduced. The learning curve cost has to be kept at a minimum.

· Finding several consultants to help would take 5 to 8 weeks and add to the workload of already overburdened department heads. Therefore, not an option either. Outsourcing was limited to 4 consultants that were known to be available immediately. 2 specialists to transfer positions to the book of record and 2 to help figure out how to pull this off. (a program manager and a PCO).

The approach:

The newly hired program manager (Yes it was me !!!) suggested using an Agile framework (Scrum). This highly atypical implementation of Scrum proceeded as follow:

1. Creation of 12 Scrum team (one for each department, HR, Finance, IT, Legal/Compliance, Marketing, Sale, Insurance, Training, Account management, Premises, New employee integration, Data conversion)

Each team was composed of the head of each department for both corporation (acquirer and acquiree) each one in turn had to nominate an assistant/backup person. The program manager assumed the role of scrum master for all teams.

Is it still Scrum ?

- Team size of 5 to 9 peoples

- 1 Scrum master for several teams

- Only 1 product owner

· In software delivery the PO optimize communication and transparency between business and IT and provide quick decision making. In M&A communication and transparency between acquirer and acquiree is what need to be optimized. Hence the 2 PO. There is no IT task and not a single line of code was delivered. A decision could not be delayed more than a week before being escalated to the 2 CEO.

· To have single and clear vision for the product. In software the solution is an emergent process that follow the vision

. In M&A taking the 2 visions (acquirer and acquiree) to make a single one that is bigger than the sum of its part is the emergent process. Hence the need for a team that has mostly business expert.

· To maximize value. In M&A, value is defined as offering more services and products to a larger audience, faster and cheaper than before due to economy of scale. Which was also accomplished.

· To validate with the marketplace the vision and value (Update and reprioritize Product Back Log). This take place after the merger is completed.

So, while we did not follow a standard configuration of the teams, we did achieve all the goal that having a single PO is supposed to reach. In other words, we did not import blindly the scrum software delivery methodology but instead created a methodology for M&A that respected the goals of the Scrum framework.

2. Sprint zero

The 12 Scrum team were told to generate a to do list that was as complete as possible and to not focus too much on providing all the detail for each of these tasks. Furthermore, they had to identify which task would be more valuable to do first. This document was to be provided in exactly one week and became the basis of the team product backlog.

Is it still Scrum ?

· Nexus (Scrum.org model for managing several scrum teams concurrently) mandate the use of a single product backlog per products. However, we considered that each department was a distinct product so we used 12 product backlog.

· The tools and medium used to create the product backlog were left to the discretion of the team. Many different tools and format were used.

3. Scrum events and artefacts

To minimize time spent in meeting it was agreed to have a single meeting per week. This, by default fixed the sprint cycle to 1 week.

The agenda for this meeting was only 6 questions that each team had to answer in turn.

· What have you fully delivered this week (sprint review and increment)?

· Was everything planned for this week fully delivered (sprint review and increment)?

· Have you added or reprioritized item in your to do list (product backlog refinement)?

· What do you intend on fully delivering next week (commitment and some sprint planning)?

Note that we did not create sprint backlog. detailed sprint planning was done at the team level and directly in the product backlog including cross dependencies work. There was no separation between business and solution development which made this approach more streamlined.

· Are you waiting for anything from another team (cross dependencies management)?

· Do you have any limiting issues that the program manager (scrum master) was not able to resolve? (escalation to CEO)

The sprint retrospective and daily scrum were left at the discretion of each team. Scrum master attended only when invited

What is atypical here:

· Most scrum events were bunched inside a single meeting with every team present

· Not a single line of code was to be delivered

· The process was very informal and only what was useful at the moment would be used.

Conclusions:

The delivery was very successful. Integration was achieved a lot faster than for other acquisition of comparable size. It was done by a much smaller group. Both of these elements resulting in an overall lower cost.

Create a methodology that make sense for your unique situation, be creative but respect the framework. Provide team with the ability to self manage and self determine and above all be courageous enough to pivot when a better option appears. The results will astound you!