Digital transformation projects carry an unresolved tension between speed of delivery and control. Arguably, the best environment for productivity requires a healthy balance of both. But such a balance is often hard to strike.
While some argue that the era of ‘move fast and break things’ is over, well-established companies are still under pressure to adapt to an ever-faster changing market. On top of this, they still need to crack the Innovator’s Dilemma by balancing sustaining innovation and disruptive innovation. The first deals with exploitation of the current business or product, the latter with exploration of new ideas and expanding to new markets. Incremental versus radical changes. Faster horses versus cars. Evolution versus revolution.
It is much easier to associate the terms ‘revolution’ and ‘disruptive’ with college dropout startup founders in hoodies rather than well-established multi-million-dollar companies. The lean startup culture of the early 2000s that gave birth to unicorns provides powerful tools to deal with speed of delivery, but the perception is that it had to sacrifice control dear to the corporate environment in order to do so. This leads to a climate of mistrust between these two worlds. So, are they incompatible? Is there a way to resolve the tension?
One way to release this tension is by adopting a useful technique from lean startups, the Minimum Viable Product (MVP). This is an approach that satisfies the need for speed without losing control. Let’s start by looking at what an MVP actually is.
Minimum Viable Product
The term MVP was coined and defined in 2001 by Frank Robinson, and then popularised by Eric Ries, author of The Lean Startup, amongst others. Fundamentally, an MVP is a learning tool, an artifact built with the purpose of testing an idea. Often it is a working piece of software, an unrefined prototype with just enough features. But in some notable cases it can be a video or even just a document or a landing page on a website. It is, however, a product. It is aimed at solving a problem for people who are willing to pay for using it.
Given this, you need to consider some questions up front, such as: Who are your clients? What problems are you solving for them? How do you measure success?
The most common misalignment between lean and enterprise culture is around what to expect from an MVP. If there’s only one message to take away from this article, it is the following: The most valuable output of an MVP is not the artefact itself, but the knowledge it generates.
Uncertainty is the fuel of risk and risk leads to fear of change. Knowledge is the antidote and the MVP is its vehicle. This result seems intangible, but has a deep and measurable impact on the business.
Despite the bombastic title of this article, the truth is that challenging head-first an enterprise culture that has been built over decades will have only one likely result: failure. We must be more tactical and realistic. The lean MVP is not enough to describe the complexity of enterprise environments. As a Cloud Native consultant, you need to be perceptive of these complexities and, with humility, integrate with the culture of the company you're working for.
Your role, our role, is to find ways to contribute to a company’s culture by lowering the perceived risk, bypassing complexity, and achieving results. Companies rely on us to infect their culture with Cloud Native ideas and make change achievable. The MVP is one of those ideas.
The questions raised above (clients, problems, success criteria) are fundamental components of an MVP. Without them, learning cannot really happen. When answering these questions keep the context in mind. The best answers are those that keep the whole system in mind.
Minimum Viable Push
So, how do you run an MVP in an enterprise environment without it being rejected by the ‘corporate antibodies’? Now for the bad news: you cannot drop a lean concept into crystallised, well-established companies and expect it to work.
Research suggests that ideal transformation journeys need to mobilise the entire company. A transformation effort will certainly fizzle out if you don’t generate enough initial momentum. There needs to be a minimum viable push from all levels: from engineers to middle managers, to top executives. In short, involvement of the whole business is crucial.
Not everyone needs to be on board, but just like a functional MVP you will need a critical mass of people from all levels in order to overcome inertia and minimise the resistance to change. There are always a few people within an organisation who see the future better than others.
A typical first step is then identifying the transformation champions among them. The challenge is to recognise and empower these people rather than banishing them into ‘business as usual’. Executive commitment is the support necessary for this to happen. The immediate next step is to form a multidisciplinary core team of five to eight people.
When transformation objectives are clear at each level of the company, roadblocks can be removed or avoided much more quickly. This vertical team will be able to run a series of experiments to uncover the best transformation path and increase the chances of success.
Minimum Viable Principles and Practices
The previous section made clear that a transformational effort needs to involve the whole company. This is not only true at the organsational level but also at the strategic level.
The initial impulse mentioned above is typically a strategic business goal: expanding to a new geographical market, targeting a new segment, or simply being more responsive to clients’ feature requests. Business goals are deeply interconnected with a company’s mission, identity, and culture. These are complex concepts, well beyond the scope of this article.
Let’s limit our context by saying that an MVP in an enterprise environment cannot deviate too much from the core principles of the company. This is another source of tension: it might not be easy to reconcile radically new practices with well established company principles.
A lean way to link business goals to architectural practices is suggested by Sam Newman’s principled approach in his Building Microservices book.
At Container Solutions we agree on these principles and practices early on, typically during the initial kick-off of a project: an event full of workshops. The vertical team described in the previous section is the cornerstone of this process. The key is to ensure that information about strategic goals, technical and operational knowledge is present in the same room.
This event is often a rare occasion of mutual understanding for a company. Each part is finally able to grasp the motivations and limitations of the other. The codified principles and practices represent a distilled artifact of this understanding that will guide the path to an MVP.
Minimum Viable Planning
Probably the most difficult puzzle to solve when introducing an MVP in an enterprise environment is planning. Planning is of course the process of deciding in detail how to do something before you actually start doing it. Perfect planning requires perfect knowledge. Since the MVP is the source of that very knowledge, planning becomes a bootstrapping problem: a seemingly unsolvable, self-referencing riddle.
Companies have an almost religious obsession with requirements gathering. This behaviour is reinforced by the classic enterprise architecture school, which preaches a step-by-step, mechanistic approach to planning. The promised reward of months of careful requirement gathering and blueprinting is perfect knowledge of what the ideal product will look like. The rest is merely execution.
What actually happens is that requirements turn into infinite lists of use cases. Each one is of ‘high’ priority. They are almost always unappealable and completely unusable by the people who should actually implement them. Additionally, those use cases are the ones the stakeholders believe will have a positive impact on the business. Unfortunately, believing is not knowing.
A minimum viable planning approach prescribes iterative methods to solve the puzzle instead. Managers in enterprises typically look at iterative methodologies with suspicion. The fear is that delegating control and decision making from the all-knowing Enterprise Architects to the lower levels will plunge the company into anarchy and chaos.
On the contrary, iterative software development methods can be disciplined (regular backlog grooming, retrospectives, stakeholder’s demos) and rigorous (definition of done, quality and performance metrics). But the real advantage of blueprinting is flexibility. By trading belief with experimentation, new knowledge is continuously gathered and incorporated in the original plan.
Admittedly, waiting for the big picture to emerge requires a leap of faith. But so does expecting to come up with a perfect design the first time around. While uncertainty in complex projects cannot be entirely eliminated, an iterative approach seems like a much less risky bet.
How much time should a team spend on design, then? This is very much dependent on the context the company is in and the principles established in the previous sections. For an MVP with the goal to deliver value quickly, the bias should be towards action. This entails, for example, delaying decisions until they are absolutely necessary, in order to reduce the time spent in design but also preserve the manoeuvrability of the system. Similar useful principles of “continuous architecture” are:
- Architect products, not projects
- Focus on quality attributes (measures), not just functional requirements
- Architect for build, test, and deploy
Minimum Viable Platform
One of the most exciting steps for many companies on the journey to Cloud Native is building a Cloud Native Platform. This step often happens after a few more or less successful attempts at designing proof of concepts (PoC). While these attempts are extremely valuable, one of the reasons they often fail is because they suffer from the second-system syndrome: trying to devise a new system that solves every problem at once.
In fact, this is the perfect occasion to apply the MVP idea. When building an MVP Platform, your clients are your developers (sometimes even your own team!). The problem you are solving is streamlining their software-delivery practices.
In general, companies have a large estate of applications of varying complexity. It is important to identify one or more candidate applications that will be onboarded first on the MVP Platform. A smart way to do this is selecting the best one according to specific ranking criteria. Here are a few examples:
- Is the application containerised?
- Is the application stateless?
- Is the application build process automated?
- Is the application tightly coupled to other applications?
- Is the application’s team available to apply changes?
- Is the application ‘business critical’?
This is a two-way process with communication at its core: The features of the platform MVP need to be minimal but just enough for the application to run successfully. Equally, depending on its ‘Cloud Native readiness’, the application might need some adaptations.
Minimum Viable Progress
What about the measuring part of your Platform MVP? How do you know when you are on the path to success? My favourite metrics are the four DORA key metrics of DevOps performance:
- Deployment Frequency: How often an organisation releases to production
- Lead Time for Changes: The amount of time it takes a commit to get into production
- Change Failure Rate:The percentage of deployments causing a failure in production
- Time to Restore Service:- How long it takes an organisation to recover from a failure in production
Don’t aim at measuring all four from the beginning;, just start with deployment frequency. Even on its own, this metric requires a considerable level of sophistication and control of your CI/CD pipeline. The immediate effect of having this measure is the ability to communicate progress.
Effective progress communication has two important consequences. On one hand, enterprises love progress. Prompt communication of progress helps keep momentum and involves the rest of the organisation. On the other hand, since ‘what's measured gets improved’, this process will uncover those areas that can contribute to improving this measure. Often these are: testing time, artifact build time, dependencies, efficient deployment strategies, and more.
As mentioned earlier, the system-level context is key: higher deployment frequency means reducing the time it takes from idea to production. And by extension, adapting faster to customer needs and meeting business strategic goals.
Minimum Viable Process
The tension of building a Platform MVP in an enterprise context has consequences, implications and opportunities for the company’s processes as well. This emerges in two main ways.
On one hand, established companies exhibit processes that might appear highly baroque and bureaucratic to outsiders. While some of these processes may very well be the result of stratification over the years, some of them are instead dictated by strict regulatory requirements. This is the case for PCI compliance in organisations that handle payments or the even more strict ISO 13485 for medical software systems.
On the other hand, the MVP is the perfect occasion to review what the minimum viable process that respects these regulatory requirements is. Finding a compromise between getting things done without too much frustration and still following the processes is a delicate but not impossible task. Agile methodologies can be evolved quickly and without zealous adherence to one particular scrum school of thought or another. A company can converge towards what works best in that particular context.
There are two further concepts that we can borrow in order to keep flexibility and speed of delivery in our Cloud Native Platform MVP: automated testing and bounded contexts, the latter an idea originating from Eric Evans’ Domain Driven Design. Automation helps reduce the manual labour required for testing and validating a release. Bounded contexts reduce the scope of the releases themselves: If payments-related data flows only through a limited set of microservices instead of the entire system, then the validation effort will be greatly reduced.
Minimum Viable… Conclusions
There you go! An attempt to reconcile the Minimum Viable Product way of working with the intricacies of well-established enterprise companies. Was this a definitive, convincing one? I am afraid it is for you to decide.
In the meanwhile, the Cloud Native space changes at an exhausting pace. We don’t have the luxury of well-established best practices and certain outcomes. While technologies and methods are still evolving, we are left to make decisions without enough rigorous data or case studies.
The Innovator’s Dilemma hinges on the tension between enterprises unable to risk their existing business and demanding certainty before making a move, while startups with nothing to lose are willing to gamble. An MVP is not a fast track to your next big enterprise system, but a tool to reduce this tension. It is a stratagem, a sleight of hand, a card established companies can play in order to make uncertainty bearable and lower the risk of difficult transformation journeys.
Previous article
