One of the tasks in agile methodologies is to agree on what the Minimal Viable Product (MVP) for each sprint is. This allows the team to get software in the hands of users sooner before investing a ton of time and money into it. The sooner people get to visualize the software and test the usability, the faster we get real requirements. As we all know from years of waterfall development, writing down all of the requirements on paper and then building software to those specs is a long process that often ends with a product that lacks real user feedback. The best user feedback is from users using the software, not from users looking at a blank sheet of paper trying to visualize how a system should work.
Challenges of the MVP approach
One of the biggest challenges I have experienced in agile is the MVP approach often leads to a lack of architecture. When building products from scratch, teams are in such a hurry to get product out the door they tend to focus too much on metrics like velocity and story points at the expense of sound architectural principles. I have also seen teams lead with a series of sprints focusing entirely on architecture (we call it plumbing). This approach can be overdone and create months of design and development with nothing tangible to show to an end user, which defeats the purpose of agile. What we need is a balance of speed to market and architecture. What we need is a Minimal Viable Architecture (MVA).
Making money vs making software
I stumbled across this article the other day called Your code may be elegant and it really hit home. For those of us who have had experience in a startup, we know that there is nothing more important than getting a product to market quickly to start generating revenue and ease the burn rate. Somehow the concept of making money tends to get lost within the cubicles in corporate IT. IT often is in search of building the perfect system. But how good is a perfect system that takes several months to get to market when competitors are delivering not so perfect systems and grabbing market share and generating revenue? The best system does not always win.
Getting to MVA
So how do we go about defining what our MVA is? I recommend asking your product owners questions like this:
- How many users will be on the system in the initial launch? Within the first 6 months? Within a year?
- Will the users at launch be internal users, external users, or both?
- How many transactions per second do we expect at launch? Within the first 6 months? Within a year?
- At launch, is the expectation that the product will be an alpha, beta, or production ready?
- How will users be added to the system at launch?
- What level of security and auditability is required at launch? Within 6 months? Within a year?
I could go on and on with many more questions, but you get the point. These questions help the architects define what the minimal amount of plumbing is in order to get to market. This is very different from skipping good architecture to hit a date. It is more focused on defining how much of an investment is required to launch and then defining a roadmap for future sprints to make the system scale as usage goes up. What we don’t want to do is to invest heavily upfront and risk overspending in case the system never exceeds our usage expectations. Don’t build a space shuttle that can go to the moon if you are only traveling from NY to LA.
One of the other goals for building products quickly is to get a functional demo into your product and sales teams’ hands. The demo can simply be an html site that flows from point A to point B using dummy data and no real backend. This allows people to visualize the product and provide much better feedback (requirements) early in the life of the product. I have seen teams take months building caching, APIs, redundant databases, and all kinds of great IT plumbing, while the sales team is left with nothing more than wire frames or screen shots to sell with. It would be much better if they had a functioning demo or prototype as early in the life cycle as possible.
Over-engineering prior to launch
Building the perfect system is rarely the correct approach. Let’s say that the product owner’s answer to my questions above are the following:
- There will be only five internal users setting up programs on behalf of our customers for the first three months. Six months from now our first two pilot customers will be using the systems in self-service mode. A year from now we are launching the system to all customers.
- At launch there will be a trivial amount of transactions. Six months from now the traffic will be moderate. Next year the traffic will be extreme.
- We are launching an Alpha first to learn. Six months from now we will pilot a production product with two customers. We will be in full-blown production in one year.
- IT will add the users manually for the Alpha, operations will add the users through a UI for the beta, customers will have self-service ID management a year from now.
- We only need the bare minimum security for the alpha. We want full-fledged security and auditabiity for the pilot.
Based on these answers, there is a ton of plumbing work that can be deferred until after the alpha product is released to the market. Why spend time on caching strategy now when we don’t see a need for up to a year? We can put off a lot of the ID management tasks for later on as well. The problem I often see is IT thinks about the end game and makes the business wait months and months to get a product out the door. This is why the MVA is so important.
But there is a catch
The approach to delaying some of the plumbing work until later can come back and haunt you if the product team shifts priorities later on and you never get to work on those stories. This approach takes trust and discipline between product and IT to ensure that both teams get their desirable outcomes: Business gets product out the door and a quicker path to revenue; IT gets to build a well architected system with little IT debt.
A better way to measure
I often see a heavy focus on metrics in order to judge if the IT team is truly agile. Management tends to focus on number of story points, velocity, bugs, and many other metrics so they can jump in and help when certain metrics are trending the wrong way. In my opinion, these metrics are only good for comparing a team against itself to see if they are getting more throughput than in previous sprints. These metrics by no means tell the story if the product is good and if customers are happy. These metrics are like blood pressure. You want your blood pressure to stay at a healthy range at all times. But just because your blood pressure is good does not mean you are healthy and just because your blood pressure is too high or too low does not mean you are sick. A better way to measure progress is to show the team’s output regularly. I like to do the following for web based apps:
Publish two URLs prior to launching a new web product. The first URL is the development URL (ex: dev.yourproduct.yourdomain.com). This URL is only for the IT team and the product owner. The second URL is the prototype or demo URL (ex: proto.yourproduct.yourdomain.com). This URL shows the work in progress that can be shared internally throughout the company and even to clients. The prototype site may have some “under construction” or “coming soon” pages as the product features are still being built. The site may also have some menu items that are unclickable or don’t link to anything yet, but show the viewer what features are coming. I recommend posting to the prototype site at least once a week to show progress. The more progress people see the less they focus on metrics which means developers can focus more time coding and less time discussing metrics. When necessary, show the dev URL to certain privileged people to show the progress of a compelling feature. Only the product owner and the IT team should have credentials to the dev URL because it may be a non stable environment since people are often working in it. Always coordinate with the developers before showing anyone this URL and only show it when absolutely necessary. The dev URL is more geared for IT and the product owner to collaborate on the feature set and usability of the product as it progresses.
Summary
Agile is an art. Some companies are very successful with agile methodologies and some are not. The trick to agile is balancing the minimal required product with the minimal required architecture. Doing this requires a lot of trust between IT and product. IT is willing to defer some of the underlying plumbing to meet the speed to market requirements as long as product agrees to circle back around later and let IT finish the job. The first time product breaks that trust, IT will likely require more up front plumbing the next time.
