You want to know how it’s possible to deliver working software in 15 days?

Start with a working piece of software on day one.

This may sound crazy, in a world where software development can take months and years. However, we firmly believe in delivering a first working product in two weeks. We achieve this goal through with two key decisions.

First, we carefully prioritize what is most important to the product. We obviously can not deliver all functionality in two weeks, so we work with you to understand your customers and how you’re trying to help them. Then together we come up with the simplest design which will allow you to test your objectives. In the industry, we call this an MVP, or Minimum Viable Product. We prioritize the elements to reach this initial design, so we know what to work on first, and more importantly what not to work on first.

Second, our development team is a real team that works together, on one project at a time. We schedule an entire team into two full-week sprints on your project, Monday to Friday, Monday to Friday. We use a very popular rapid software development style called AGILE, using a process called SCRUM. In this development style, there are no fixed schedules or scopes, features are prioritized based on importance and implementation difficulty. Most importantly, the process is built around starting with a simple runnable scaffold application, and incrementally adding and testing working features, in live running software.

By starting with a working scaffold application on day one, and adding working features day after day, we can assure the software is always running, we have enough experience with this process to be a good judge of how many features we can fit into a two week MVP. Will there be bugs? Probably. Will it be the final version of your product? Doubtful. However, it will meet an agreed set of functionality targets, and it will be working right away, on your own Android and iOS smartphones, after only two weeks. How many development shops can say that?

We feel the most important way to accelerate software development is to understand not only where you are going, but why you are going there. Before the Sprint, we build a relationship with you, understanding who your customers are, and figure out how you’re trying to help them. Some customers may be familiar with fast MVPs and validation. If you’re not, don’t worry, we’ll mentor you through how it works, and figure out to create a plan that will best help you.

Sometimes this process uncovers questions you don’t yet have answers to, and that’s okay. However, you’ll need to answer them before we schedule a sprint, because if we can’t understand the problem we’re trying to solve, we can’t build software to solve it. Other consulting companies might start the project and start billing you to make mistakes. We don’t think this is fair. We know the right and wrong ways to build software, and that is the wrong way. Take your time, figure out your customers, and when we all know what we’re building, we can line everyone up on the starting line, tell them where they are going, and get to the finish line fast.

Out of the planning process comes a list of user stories which describe what your users will do with the product, prioritized in the order of importance to your business and your customers. In the Agile process, this is referred to as the Backlog.

When the sprint starts, the user stories are presented to the team, and the team turns the user-stories into software development tasks. These tasks are divided up, and performed in the order of value and how they will give the software the ability to enable the user-stories as efficiently as possible. These tasks are designed to rapidly move through to do, doing, and tested/done status. Every day of the sprint, the team hosts a daily meeting to maintain a good understanding of progress.

We love this process, not only because it is a better way to achieve your objectives, but also because it’s more engaging and more fun for our developers. Trust me, no software developer enjoys working on software that doesn’t do anything useful for months or years. With our process they get to stay focused on what they do best, which is rapidly assembling software components to deliver running software that quickly achieves customer objectives.

A single two-week Sprint is not a guarantee that everything that was requested will be performed on that Sprint.  User stories and features sometimes present unforeseen challenges. However, this is the best process available in the industry for rapidly developing working new applications. And because we structure every project around the same process and the same techniques, we have the experience to judge what we can usually produce in a bounded timeframe.

For example, we’ve learned the first work on a project needs to be two-weeks, because a single week sprint is normally not enough time to get an MVP off the ground. After this initial MVP, sprints can be scheduled based on the enhancements required, in one-week sprints. Normally we recommend only a single one-week sprint per month, to give you time to test new features with real users.

In fact, once we handoff a product to you, we watch your usage data, and encourage you to put your software in front of real users, even if they are test users. Because this is the best way for us all to figure out where your product should go.