We use agile development model where business case and existing product functionality are combined to reach maximum business value for each euro spent on a project. In our model, the project team gets to work with an actual product starting from day one instead of just using wireframes and layouts. Using a real prototype makes it much easier to understand the design, estimate the amount of work and especially communicate ideas. We call this model prototype driven development. This model also enables us to do very cost-efficient development where customer has excellent control of where and how to spend their money on the development. Entire development process becomes transparent to the customer and educated decisions can be made on how much time (money) should be spent on each detail.

Prototype driven development

Our projects always start with business concept planning. At this phase it's important to concentrate on why not how. It is imperative that every member of the project team has a clear understanding of why this project is being done and what the primary business goals are. This also helps us to make educated suggestions instead of making the customer always define every single detail of a project.

Right after the business concept planning, we spend a few days throwing together a quick prototype. We are using an existing software platform after all and prototyping is very quick. We review the prototype together with the customer and create a list of things to do, known as a product backlog. Armed with the business concept, prototype and product backlog we do a more detailed project plan so that we can set deadlines for external integrations, reserve people and other resources when needed and so on. This is still a very initial plan that will change during the project, but it helps us get an idea what to expect at a particular stage of the project.

Iterations

Every sprint begins with planning, where we pick stories from the backlog to be implemented based on their priority. We also update project plans, product backlog and sometimes even the business concept in sprint planning. After planning, the selected team starts to work on a project. We use slightly modified Scrum framework in our projects. In most projects managed by Mearra, Drupal is used as a high-productivity development platform. This means small teams with 3-6 members and short two-week iterations. Development with Drupal is up to 90% choosing the right components, configuring and working with the user interface and very little actual programming.

In our projects we have weekly peer reviews, where typically two of our project teams from different projects sit down for an hour and review all aspects of their projects. By peer reviews we can maintain high quality implementation and get instant feedback on design while it's still easy to make changes. We usually also include additional quality assurance (QA) step to each sprint where automated integration tests and/or manual testing takes place. In projects in which we are publishing a new version of a live site, continuous integration testing is especially important.

Each sprint ends in a sprint review where we take a look at all the tasks completed in the project. Review also tells us if the initial work estimates made by the team were accurate and let's us get even better in the art of task estimation. Together with the review we always have sprint retrospective as well. Retrospective is an important step to improve our ways of working together with the customer, process model, tools and everything related to the project work. Together the review and the retrospective provide us with an up-to-date view of the project and create continuous improvement of the project team and the model.

Working on a task

Our workflow on a task is also slightly different from what many organizations are used to.

Again, because we are dealing with an existing product, a quick prototype starts the work. Based on the prototype all stakeholders have a good idea on how a particular functionality would work out-of-the-box. This makes planning easier for the product owner, user experience designer and developer as well. By combining business goals and user experience with the product we can make educated decisions on the details of a project. Sometimes we end up rewriting much of the existing functionality to meet business or user experience goals and some times we can leverage from the existing prototype. With this way of working, different options and their costs become transparent to everybody and decisions that may have a big impact on the total project costs are no longer done in isolation.

Primary benefit of our prototype driven process model is concentrating on maximizing business value instead of working on sometimes trivial details. When working with more traditional layouts and wireframes first -methodology it’s much easier to get stuck in visual details instead of concentrating on what’s important on a conceptual level. The prototype driven process model makes it transparent for the product owner to pick the implementation path which to follow, helps the developers to understand the drivers behind business needs and enables the user experience designers to work more closely together with the final product. In most cases our process model means we can implement larger scope or more refined details where they really matter while not adding to the costs. The process model is also much easier for everybody involved with less assumptions and initial guess-based plans making the final product much higher quality.