One of Agile’s most fundamental and defining aspects as a process model is its focus on iterative workflow. Following this approach, complex projects are subdivided into small, actionable work-items, which are completed, reviewed, and, if necessary, reiterated, toward realization of the ideal outcome. These work cycles are often called sprints — a concept we will explore later in greater detail.
“Research has repeatedly demonstrated that short-duration projects are more likely to be successful than prolonged endeavors. Oftentimes business transformation projects involve a mix of complex development efforts, such as business process reengineering, legacy IT system replacement, and the creation of new, innovative business practices that rely heavily on technology. To increase the probability of project success, structure your project into multiple deployments of small solution components rather than taking the ‘big bang’ implementation approach. As you develop and deliver the solution in increments, incorporate lessons learned from each increment into the next iteration and constantly test for alignment with business objectives.”
— Kathleen B. Hass, Principal Consultant at Kathleen Hass & Associates, Inc.
Sprint. A sprint is a time-boxed period to complete a set amount of work. In other words, it is the basic unit of iterative workflow — a single pass through a task intended for reiteration. A sprint is one of the building blocks of the entire Agile approach. Sprints work particularly well in software programming, where small parcels of code can be quickly written, executed, debugged, and refined until they reach an optimally functioning end state. Each iterative cycle ends with a potentially shippable product that can be delivered to the customer for feedback. Sprints help to reveal problems early in the coding process, while maintaining creative momentum, and most significantly, allows for greater flexibility in response to changing project goals or parameters. The same concept can be applied to work items in the M&A process.
See Plays —> Fast Learning Cycles
The iterative approach is flexible in its scalability. Iterations can be applied to extremely detailed, low-level items like individual diligence requests, as well as to more high-level, abstract goals, such as integrating HR or aligning value drivers between PMs. Critical to this approach is understanding that any given Agile technique is highly modular. An iterative approach can be used as part of a detailed process model or employed on its own to meet a unique need. Following this line of thinking, we consider the steps outlined in this chapter as “plays,” and conceive our overarching process model as a “game plan.” We understand that, within the world of Agile, “plays” can sometimes refer to broad strategic moves (i.e., to the types of acquisitions, like acquihires and so on), but, in the context of this book, “plays” describe a collection of techniques for approaching acquisition. Plays, taken together as a set, comprise a game plan.
The use of the term “game plan,” over the more common “playbook,” originates with the integration team at the software company Atlassian. After experimenting with traditional playbook-driven approaches to organizing workflow, Atlassian ultimately rejected the playbook, as this model lends itself to the impression that deals and pertinent factors can be templatized. Working experience demonstrated to the Atlassian team that this is a misleading and potentially dangerous impression — and that ultimately no rigid, pre-existing strategy can anticipate the complex needs of an integration project. Atlassian still uses trusted techniques, called "plays," when appropriate, but frame their collection of plays a “game plan” to encourage team members to think beyond the traditional playbook paradigm.
In this chapter, we offer a “process model” which, at the strategic level, enables for the completion of any M&A deal with maximum value-capture. The model consists of two basic game plans: the first covers the front end of the deal — finding a target, completing due diligence, and closing — and the second addresses post-close integration. Taken together, the game plans form a basic framework for approaching any deal confidently and efficiently.
“Where I have an issue with playbooks is that it becomes this sort of fail-safe that everyone starts to use for any deal going forward. The reality is that each deal — even if it’s in the same sector, same geography, same scale — each deal is going to be fundamentally different. And so to expect a playbook to work in a different environment, it almost removes the thinking power and expects some sort of autonomous process to work. I think that’s a mistake.”
— M&A Science Interview with Ben de Haldevang, Founding Partner of Agile Gorilla
“You really need to think about development as you go along, and that really is how we approach integration. It’s what we found works because in a pre-deal environment you have limited time, very limited information and access to people, and you need to accept that once you get post-deal a lot of the things you assumed are going to be wrong. That ability and that willingness to learn and evolve as you go through integration is that core factor to success.”
— M&A Science Interview with David Boyd, Founding Partner of Agile Gorilla
We encourage practitioners, however, not to treat this model as a rigid, linear blueprint for success, but rather as a collection of techniques operating holistically to allow teams to execute deals as effectively as possible. So, teams can follow the process model as a whole, or they can take any of the techniques outlined below to run as plays, fielding plays when appropriate circumstances arise and tailoring the approach to fit operational conditions.
After outlining the process model and its plays, we will discuss a broad range of accessory plays which can be employed to address specific needs or challenges or to increase the efficiency of the game plan as a whole.
Expert Opinions, on Eliminating Static Playbooks:
“I’m trying to get people to focus not on playbooks but more on frameworks. What is our stance going to be from the integration point of view? Then, for any given acquisition we will have an OKR [Objectives and Key Results] and OKRs shift pretty regularly and are cross-functional in nature. The actions associated with each of the OKRs go down to pretty impressive depths around all the different areas that need to be touched in order to drive whatever that goal might be.”
— Chris Hecht, Head of Corporate Development at Atlassian
The game plan approach aligns well with the rugby metaphors used in the Scrum methodology — and, all things considered, an M&A deal is remarkably like a game of football or rugby. The goal remains the same in each iteration: to win, i.e., to successfully and profitably integrate the target asset. The route to victory is always different, however, as every game unfolds from the same starting point along radically different and unpredictable lines. Only by relying on proven techniques — the plays — and remaining flexible in their application can a team respond to evolving conditions effectively, and achieve victory.
The steps outlined in the next chapter are just that: proven techniques that have helped teams complete complex projects like M&A deals quickly and intelligently.