Minimum viable product considered harmful without architecture

SUMMARY:

Agile says build a minimum viable product (MVP) and continuously improve it with DevOps. Just don’t neglect architecture, advises New Relic’s Lee Atchison

crossing-the-gapAgile development and DevOps processes are in vogue now. It seems that most well-run development organizations either have these processes ingrained in their culture, or are trying to build them into their culture.

No matter which agile development process you use, they all have one guiding principle – incremental software development. In its simplest form, agile methodologies teach to only build the minimum viable product that will solve your business’s needs. Then, based on feedback and experience, you incrementally and iteratively add new features and/or capabilities, sometimes throwing out code and rebuilding it, to grow the product into what you need it to be. The intent is to make sure that the product you build is the right product with the least investment, which can only be determined through trial, error, and experience.

In the meantime, DevOps methodologies encourage the quick and easy integration of new features and products into a release-ready state. These new capabilities can be deployed for a customer’s use very quickly using continuous integration and continuous deployment methods.

Used together, agile development and DevOps processes can give you an incredibly quick feedback cycle between making changes to your software and getting customer feedback on those changes. This allows you to tune and adjust your application as needed to meet customer  needs.

This approach has improved the quality of customer experiences available in products, while revolutionizing the ability of a company to adjust and pivot quickly to dynamic market demands.

Architecture gets lost

There is, however, a problem with this approach. Often, solid product architecture gets lost when you ‘incrementally build’ your product. The minimum viable product is thrown together as quickly as possible, and improvements are only made as needed to add the incremental capabilities you need.

What is lost is a solid systemic architecture. A solid systemic architecture helps guide your product development and makes sure that core and fundamental issues are considered, such as resiliency and scalability. Without a solid systemic architecture, every change you make increases your technical debt, and makes your system harder to support, harder to expand, and less capable as your needs grow.

While building a minimum viable product is an important strategy in making the right product, and incremental development/deployment is critical to getting customer’s feedback quickly into the development process, just using agile and DevOps processes to build your product can very quickly create a large backlog of technical debt. You may get short term benefits, but the long term costs can be astronomical.

It is therefore important to always have a focus on an overall architecture strategy for your product, even if you are building your product incrementally. It is important to understand how the decisions you make now impact that strategy. It is possible and reasonable to make shortcuts in the name of expediency, but you must have the knowledge and understanding to know what the real cost of those shortcuts are, when the cost must be paid, and how you will pay the cost as you move forward. You can only do that if you have a strong architectural focus from the beginning and consider and understand the long term architectural impact of your decisions as you go.

Maintain a long-term vision

How can you accomplish this? The easiest way is to make sure you have someone whose job it is to ‘own’ the overall systemic architectural vision of the product, even when you are building only a minimum viable product. This person is outside of the agile process. They must create and maintain a long-term vision of what you want to build. While the rest of the team quickly adapts and adjusts the product itself, this person must think longer term and make sure the short term decisions the development team makes doesn’t create unacceptably large long term costs.

This vision can and should adjust as time goes on to the changing business needs of the company, but this adjustment in general should be substantially slower than the quick and agile process used by the rest of your development team.

Only by having someone focus on the overall architectural vision for the product can you be assured that what your development team is building doesn’t have an unacceptably high amount of technical debt.

Image credit - Drawing A Bridge © freshidea - Fotolia.com

    Comments are closed.

    1. Mario Peshev says:

      Just stumbled upon this one earlier today – https://medium.com/@rikhigham/the-mvp-is-dead-long-live-the-rat-233d5d16ab02#.7w71m2qfc . MVPs are getting questioned lately, or at least their standard interpretation by development agencies who tend to apply different meaning to what the Lean Startup methodology implied a while ago.

    2. Ariel David says:

      Frankly, I’ve seen thia happen time and time again. But tgis has nothing to do with agile but about people that use agile. This is what sets apart good CTOs from bad CTOs. A good CTO will have an architectural roadmap, a vision of the future architecture, and in an agile fashion, work toward that grand vision.
      Agile methodologies like any other methodology is just a means to an end. No matter the methodology it requires smart people to look at the bigger picture and drive it

    3. Gabor Torok says:

      Maybe good solution architecture is of secondary in importance when we’re delivering an MVP? An MVP must prove its viability first and then when it did we must make it sustainable. I’m an SA, I would probably never think like this, yet this thought might not be from the devil.

    4. Hello,
      A helpful perspective!
      The real key is what are the consequences of “high technical debit”. CEOs, CIOs, CTOs often don’t know. They do know that developers think it is bad. But why is it bad?

      High technical debit cripples business agility. It significantly extends time-to-market and significantly increases total-cost-of-ownership. As such, it makes a business much less competitive. CxOs need to understand this dynamic, especially with the advent of the cloud era and the fact that many systems are now distributed systems which are much more difficult than monolithic software systems of the past.
      hth
      George

      May I have permission to use a link to this article in an up comming blog article I am writing in my own blog?