Having advised PE-backed companies, we see an unusual proportion of companies that have not yet embraced Agile software development and/or struggle to adopt it under a PE umbrella. While the majority of both startups and public companies we see have embraced Agile, why is it that this trend doesn’t carry over to PE-backed software companies? In this article we will examine this phenomenon and explore solutions for evolving to an Agile approach even in a PE-backed, modest growth software organization.
Fundamentally, PE firms typically leverage their investments making them less able to “pay up” for acquisitions like VCs and strategic buyers can. Thus, a software company acquired by a PE firm tends to be a modest to low grower, entrenched in a niche vertical, with a significant amount of recurring revenue (more often traditional maintenance than cloud-based SaaS). PE firms are known for robust oversight of their portfolio companies, emphasizing metrics-driven decision making, high margins, and EBITDA.
PE firms rely on robust planning processes, sometimes even at the expense of growth, because of the significant leverage (read covenants) and needed predictability. Management teams enter every year with firm plans, the results of which will determine not only their compensation but also whether a bank will be breathing down the company’s neck or not. Traditionally, waterfall development processes have served the PE community well – as a lot of time is spent in annual planning processes. It isn’t uncommon for development teams to spend months planning, designing, and estimating future product releases that are quarters away, even though many of those features will never be delivered and requirements will certainly change during the intervening months. This common, fallible practice creates waste in the ecosystem.
Agile development strives to delay major investments until they are necessary and eliminates waste in doing so. This is because many R&D activities never see the light of day. Time spent designing products and modules that never ship is eliminated and instead redirected to things that are going to matter. The fundamental tradeoff is that development teams become more accountable for short term deliverables (monthly “sprints”), but no longer have to provide fine-grained estimates for long term deliverables (that were never believable nor accurate to begin with).
A PE-centric executive team will of course have initial frustration with such a shift. Not being able to precisely predict effort and deliverables a year out is foreign to such investors, most of whom, unlike their VC cousins, are not dedicated to the software industry. Getting over the hurdle requires the following leaps of faith on the part of investors and executives: (1) the benefit of development actually owning and committing to short term deliverables will more than make up for any losses associated with less long-term, fictitious commitments, and (2) the increased visibility into short-term deliverables will result in more responsiveness and a higher velocity of development deliverables. In a SaaS environment where more frequent deliverables are standard fare, this shift is not only desirable but a necessity. In a traditional on-premises deployment model, this shift is harder to digest. However, in the companies we have worked with, SaaS or a combination of SaaS and on-premises products, most investors and executives have seen the light after one or two quarters working with the Agile model.