Software developers are a funny bunch. Not necessarily “ha ha” funny—you don’t see many developers on the stand-up comedy circuit—but they have certain peculiarities. Although they are generally amenable to learning new things, such as shopping for books, buying airline tickets, and meeting people in “chat rooms.” Witness, for example, the great struggles some development teams had when switching from procedural to object-oriented programming.
Similarly, the move from the traditional “waterfall” model of development to “agile” or one of its variants has proven difficult for some teams. Some initially compromised on an approach somewhere between waterfall and agile. The trouble with this idea, however, is that in order to reap the benefits of agile development, you have to go all the way with it. Partly agile is not agile at all.
But with several years of proven success behind it, agile has attracted enough adherents that it is now the de facto standard—it’s unusual to find a development team that doesn’t use some flavor of agile.
Agile at AndPlus: The 100-Day MVP
At AndPlus, not only have we embraced the agile methodology, we have found ways to make it better (for us, at least). One of our modifications is the concept of the 100-Day MVP cycle, in which a development team designs, builds and tests a minimum viable product (MVP) version of a software solution in—you guessed it—100 days, or 20 weeks (we do give ourselves weekends off).
The first, and most crucial, phase of the 100-Day MVP cycle is the first 10 days. This phase is a variation on Google Ventures’ five-day Design Sprint. (We didn’t steal it from Google, honest. They give it away.)
The 10-Day Design Sprint
The goal of days one through 10 is to identify all of the software requirements and come up with a user interface design, complete with wireframes and other design artifacts that the customer reviews and approves. Why do we take 10 days, when Google Ventures takes only five? We found that by giving ourselves extra time, we were better able to understand the customer’s needs and market, and could develop richer, more complete design prototypes that left nothing to the customer’s imagination. The result is a better product that more closely matches the customer’s vision.
Here is what we do in our 10-day design sprint.
- Days 1 and 2: Map. Using information already gathered from the customer regarding the business problem or product vision, end-user characteristics, revenue model and specific product requirements, we determine and agree on the end goal—that is, what set of functionality constitutes the MVP of the product. We also create user journey maps that define the high-level paths for all of the envisioned use cases.
- Days 3 and 4: Sketch. The team brainstorms possible solutions for the user interface. This is the team’s opportunity to come up with elegant, creative approaches that make the user experience streamlined, intuitive, simple and fun. These ideas are usually sketched out on paper.
- Days 5 and 6: Decide. At this point the team reviews and evaluates the ideas, with the goal of deciding on one, or a small number, of design ideas to present to the customer. There’s not enough time to build prototypes for every idea, so the team must reach consensus on the best ideas, which are those that have the best chance of fulfilling the customer’s requirements within the project cycle.
- Days 7 and 8: Prototype. The top designs are turned into prototypes that give the customer realistic models of the solution. The prototypes cover all of the important functionality that will distinguish this solution from others in the marketplace, or solve the customer’s biggest business pains.
- Days 9 and 10: Test. This is where we present the prototypes to the customer and get their feedback. By getting the customer involved at this point, we can validate that we thoroughly understand the business needs, get full support for our approach and ensure the customer understands exactly what they will (and will not) get on day 100.
At the end of day 10, we have a solid user experience (UX) design that the customer has approved. After the design sprint, we work on the back-end architecture design and start coding.
We find that this methodology maximizes customer satisfaction by providing the customer with a known end state for the MVP and a definite delivery date. It also gives us a well-defined goal that we know we can meet. It’s win-win for all stakeholders.