Agile Business Design Agile Delivery Improvement & Scale Case Studies

Integrating two legacy organisations – a new context for Agile

Read the article below – or download the report for later.

Integrating two legacy organisations – A new context for Agile – Report

Imagine a client conversation going something like this:

Client: “Now we’ve seen the impact on our large programmes of work, we’d like to see where else we can use agile.”

Consultant: “Sure, what do you have in mind?”

Client: “How about integrating an acquired business? Or consolidating our legal entities for efficiency? We need the transparency and autonomy brought about by agile in both cases.”

Arguably it was only a matter of time before the agile wave picked up post-merger integrations in its executional experience toolkit, because as you will see, it is a great fit.

The client, a major energy company, wanted to integrate the acquisition’s capabilities and systems as priority, so needed further analysis and proposals across both organisations at a detailed level, and quickly. There was a tight deadline – six weeks – and the work had already started not ‘in agile’.

Understanding the need to integrate a newly acquired company and introduce agile processes made for a challenge. When asked the why of introducing a new process to an already-complex initiative, the client stated simply that the transparency and autonomy brought about by an agile process was worth the risk, especially given the complexity of the initiative.

So how did it work?

Set expectations

• Prioritise – Of the integration work, what needed to be done first, what had to be done by the deadline?

Agreed that ‘agile’ wasn’t going to be a silver bullet, and they would have to be flexible with how the toolkit was applied. To use only as much as was absolutely necessary.

Don’t stop to then start again – It was decided that stopping the already-started work to run through training on agile would be confusing and disruptive, and that concepts could gradually be introduced as things progressed, meaning work could continue and benefits could be gained from agility as we went along.

Broke it down

The integration was broken down into components, and then goals created for them, ensuring they aligned to the bigger picture and deadline. This analysis gave clarity and helped the team see where dependency and duplication existed.


The work was visualised – within the working team, scope was exposed in a granular way. This created discussion immediately, flushing out queries and opportunities to avoid waste.

Did only what was necessary for process and project

Gradually, the lightest of agile framework was introduced to help communication flow.

  • A half hour meeting three mornings per week, outlining the plans and progress of each component
  • An hour-long review weekly with a wider stakeholder group
  • A short planning session to set expectations for the following week

The team did not wed themselves to specific roles either. They didn’t have a clear product owner or sponsor, and the general manager for the proposed new organisation – who would ordinarily be the sponsor – led from the front by getting right into the detail. The only rule they had was that the scrum master role should not also define what value meant (effectively saying the PO and SM shouldn’t be the same person).

Challenged reservations with data

Initially, the team showed some reservation around introducing a new process given that they’d already started work. However, in the first meeting that came as part of the agile package, these reservations were challenged as a few of the team members began to share their initial thoughts on subjects like org structures, and these thoughts created discussion that wouldn’t have happened until much later. This meant they could keep to the tight schedule required by the project.

How did it go?

Given the initial complexity and ambiguity:
– that the team had not tried ‘agile’ in the context of a post-acquisition merger,
– that agile was introduced post-commencement,
– that the project had a very tight deadline,

the project was a significant success.

It was demonstrated that the principles underlying agile could be deployed to another context successfully – the tight deadline was met, had no re-work, and had a clear plan moving forward.

What does this all mean?

An agile mindset – being flexible around deploying agile, especially the various frameworks – is beneficial in contexts well beyond technology products. From large-scale capital projects now to initial work in post-acquisition integrations, the possibilities and benefits are racking up.

Sign up to be informed of future ADAPTOVATE webinars, and original content on all things Agile. We promise we wont spam you!

We keep your data private and share your data only with third parties that make this service possible. Read our full Privacy Policy.