The agile nightmare of Paul M.
Paul was convinced: this time everything will be different. No rigid Gant charts, no endless Excel spreadsheets, no yesterday's waterfall logic. His PMI project - a medium-sized but politically sensitive merger - would be agile. With daily stand-ups, backlog grooming and, of course, reprioritization “on the fly”. Paul was reading Scrum for Dummies when the first topic came up.
The integration of the sales team, actually a “top priority”, was postponed - “because finance is shouting louder right now”. Two weeks later, HR postponed the onboarding process “because the target system is not yet connected”. And when Paul realized in Sprint 3 that neither team knew what the other was working on, he decided to turn the retrospective into a crisis meeting.
The only thing that moved regularly was the priority list. Instead, the timeline remained constant: late. Paul smiled bravely through the daily chaos, clinging to agile manifestos - and secretly wished for nothing more than an honest, old-fashioned project plan. With milestones, deadlines and please, please: clarity about who has to do what and when.
Agile is good. But maybe not here? Not right now? Not like this?
Agile project principles - beyond post-is and stand-ups
Agile project principles and, in particular, frameworks such as Scrum are not just tools or methods. They are thought models. Their foundations include the three pillars of continuous improvement: transparency, review and adaptation; the Agile Manifesto, the twelve agile principles and the five Scrum values: commitment, focus, openness, respect and courage.
These principles and values form a flexible framework for how (software development) projects can be implemented. Two central ideas underpin them. An iterative-incremental approach in order to be able to better absorb changes and external influences, and a focus on customer value to deliver results with the highest added value.
The agile framework includes the roles of Product Owner and Scrum Master, the artifacts Product Backlog and Sprint Backlog as well as the events Sprint, Daily Scrum, Sprint Review and Sprint Retrospective. However, the concepts that originally came from software development should not simply be adopted unchanged. They need to be translated into the context of mergers & acquisitions and post-merger integration.
Integration backlog - what really counts
What is to be achieved? In software development, this central question is usually answered in terms of customer value. But who is actually the customer in a post-merger integration?
In a project as complex as a post-merger integration, there are not only many, but also very different customer groups. To avoid confusion, it is better to speak of stakeholders. These include the usual suspects: Owners, employees of both companies (including management or board members), (regulatory) authorities such as tax offices, suppliers, financiers and, last but not least, the companies' “real” customers.
There are indeed many of them, which explains why post-merger integration is considered so complex. Different stakeholders have different needs that need to be taken into account. Accordingly, the integration backlog quickly fills up with a wide range of housekeeping objectives as well as deal-specific value creation objectives.
The integration backlog does not contain the individual action steps. Instead, it lists the objectives that are to be achieved. Goals that can be clearly derived from the needs of the stakeholders. If these needs are prioritized, the entries in the integration backlog can also be prioritized accordingly.
This prioritization is usually based on predefined milestones, such as reporting obligations, trade fair appearances or the goals from the deal story. And: this prioritization is not universally valid, but always situation- and acquisition-specific.
The integration backlog already contains a large number of “must-dos” on day one. The good news is that they do not all have to be completed immediately. In many cases, a phased approach of First 10 Days, First 30 Days, First 100 Days, Beyond 100 Days has proven effective for quick clustering and implementation focus.
The integration backlog is not a static document. This aligns with one of the basic principles of agile project work. Items can be added, removed or reprioritized during the course of the project. The original weighting can also change over time. The advantage of this thinking model for complex post-merger integration is that you can start quickly and go straight into implementation, without having to plan everything down to the smallest detail beforehand.
Integration Sprint - Or is it a marathon?
Classic post-merger integration is more like a marathon than a short-distance run. It is not uncommon for 18 months or more to pass before an integration is fully completed. Perhaps post-merger integration should even be compared to an ultramarathon, with distances of 100 kilometers and more.
The idea of achieving results and celebrating small successes at short intervals is just one of the considerations behind the integration sprint concept - but it is a particularly central one with regard to the principle of “growing together by coming together”. This is because the first fruits of the joint work become visible after a short time, rather than after many months. In this way, people and organizations grow together step by step.
An integration sprint usually lasts two to four weeks. The exact duration is determined in advance. And this is precisely where another advantage of the approach becomes apparent. This manageable period is much easier and more reliable to plan. In contrast, planning across six, nine, or even twelve months is far more time-consuming and significantly less precise . The use of available resources - especially internal resources - can also be better estimated and managed more efficiently within this short time frame.
In this way, joint activities can be implemented more quickly. The high level of short-term planning certainty means that there are fewer deviations from the plan, which in turn increases satisfaction within the integration team. And once again, the team grows closer together.
During an integration sprint, the team members can concentrate fully on the issues at hand and deliver concrete results. Requirements and priorities remain constant during this phase. And thanks to the brevity of the sprint, new prioritizations can wait until the next sprint without disrupting ongoing work.
The central elements of an integration sprint are the integration review and the integration retrospective at the end of the respective sprint as well as the integration daily, which, as the name suggests, takes place every day.
Integration review - more than just ticking boxes
Transparency and feedback are key principles of agile projects. They are systematically embedded in the integration review. At the end of each sprint, the team members report on what they have achieved. The PMI owner and the stakeholders provide feedback on the results presented.
In this way, the “customers” of the integration are regularly involved and remain informed about current issues and progress. The integration team receives valuable information on whether the integration is progressing in the right direction, whether the results achieved meet the expectations of the stakeholders and whether integration may have gone too far or not far enough.
The high frequency of the integration reviews ensures that all participants stay actively engaged in the integration process. The substantive evaluation of the results prevents pure task tracking - a typical pitfall of classic large-scale projects, where the focus is merely on completing tasks without questioning the content of the results. New or additional requirements are also identified in the integration review and added directly to the integration backlog if necessary.
Integration Retrospective - Internal Only
In addition to the “external” format of the Integration Review, the Integration Retrospective is an “internal” event. It is aimed exclusively at the integration team and also takes place at the end of each sprint. Put simply, two central questions are reflected upon. What went well in the current sprint? And what should be improved in the next one?
This is not about the work results but about collaboration within the team. The focus is on how we deal with each other, communication and cooperation within the integration team. Another important dimension of the retrospective is the interaction with stakeholders and other people outside the team. Did the integration team have sufficient opportunity to focus on the relevant topics or was it too distracted by outside influences?
This is where the Integration Master and the PMI Owner come into play. They are responsible for creating the necessary framework so that the team can work effectively.
The Integration Retrospective not only serves to improve the operational aspects of project work, it also promotes cultural understanding between the organizations involved. Open discussions about collaboration naturally bring cultural differences to the surface. By regularly discussing these differences and jointly considering how to deal with them, cultural integration emerges as a by-product.
Integration Daily - Every day!
That brings us to the central element Integration Daily. As the name suggests, it takes place every day. It is a short coordination meeting of the members of the integration team. The goal is to create transparency. Everyone knows what the others are currently working on. Dependencies are uncovered and clarified, obstacles are identified and necessary support can be requested.
Especially in the early phase of integration, in preparation for Day One and in the first few days afterwards, it is highly recommended that the Integration Daily is held daily. Unplanned or unforeseen challenges always arise in this phase, so this brief coordination brings a noticeable gain in effectiveness.
As the project progresses, the frequency of the Integration Daily can be adjusted, for example to two or three times a week or, if there is less need for coordination, to an Integration Weekly. Especially after the first 100 days, when the team members are no longer predominantly involved in the integration work, the rhythm of the daily meeting should be adapted to the respective course of the project.
PMI Owner - One for all
Every integration needs someone who understands its value and takes responsibility for its success. This is the role of the PMI Owner. Managing directors or board members with operational responsibility are often appointed to this role as project managers for post-merger integration. While this is possible, in practice, the limits of this approach quickly become apparent.
In the agile world, the product owner - in our case the PMI Owner - is the person who keeps an eye on the business perspective of the project. In the context of post-merger integration, this means aligning integration efforts with the corporate strategy and acquisition goals, and vice versa. The PMI Owner thus establishes the link between the integration activities and the overarching strategic vision of the acquisition.
Accordingly, the PMI Owner is also responsible for prioritizing the integration backlog and defining the sprint goals. These are based on strategic requirements, acquisition targets and external milestones, such as reporting obligations or regulatory deadlines.
During a sprint, the PMI Owner is available to the integration team as a sparring partner to quickly clarify open questions. This has the advantage that the team does not have to wait for feedback from steering committees or other escalation rounds. This keeps the sprint focused and efficient.
However, this requires the PMI Owner to be constantly available for the integration team. And this is precisely where a conflict of objectives arises: the managing directors with operational responsibility are always heavily involved in day-to-day business, making it unrealistic for them to be constantly available. This is why the idea of using these managers as PMI Owners often falls short in practice.
Integration Master - the real PMI experts
Alongside the PMI Owner, who maintains the link to the corporate strategy and the acquisition targets, the Integration Master(s) serve as the central experts for post-merger integration. They know exactly what it takes to ensure a successful integration and are familiar with the typical housekeeping issues that need to be addressed.
Integration Masters are facilitators, transformation agents, moderators - and sometimes also mediators. They network the various workstreams, remove blockages within the teams and ensure smooth collaboration across team boundaries. While the PMI Owner primarily focuses on the “outside world” beyond the integration team, the Integration Masters are operate within the team, acting as a driving force and providing hands-on operational support.
Last but not least, they play a central role in cultural integration. Their experience from numerous post-merger integration projects and other transformations makes them key figures when it comes to bringing different corporate cultures together.
Agile in post-merger integration?
Yes - but only if it makes sense. Not because it's currently “hip”. Agile is not a panacea. However, the sprint principle helps to maintain focus and use the available resources effectively, especially in projects of the caliber of an ultramarathon, as post-merger integration often is.
If the values of the Agile Manifesto are applied to post-merger integration, the following picture emerges.
Individuals and their interaction take precedence over processes and tools. This is precisely what encourages people from both organizations to grow together. Former boundaries are overcome - a new, joint organization begins to shape.
A functioning organization is more important than extensive process documentation. The focus is on genuine collaboration and functionality within a (new) organization, not on appearances and shadow processes.
Alignment with the corporate strategy and the acquisition targets takes precedence over merely creating project plans. Integration is not carried out as an end in itself ; it is a critical driver for achieving the acquisition goals.
Responding to changes is more important than rigidly following a plan. The ultimate goal is a resilient and sustainable new organization that not only achieves the initial targets but continues to evolve.
The formal agile elements - from clear objectives in the sprint and the Integration Daily to the Integration Review and Integration Retrospective - create a structured framework that also leaves room for focus and adaptability. PMI Owners and Integration Masters ensure that this framework is adhered to and remains effective.
