Our product development process

At the Drupal Camp Cis I delivered a speech about our way of product building at Drucode and how we managed to move from the fixed price model to the agile one. At the end of my report I got a lot of questions and had been answering them for about 20 minutes. It seemed to me, the topic was interesting for the auditory, so I decided to write a post about our way of developing web and mobile products.

This article will be about the process. How we start working on a product, prioritise, the stages we usually go through, the way of delivering a product to the end users.

1. Meet client and product.

At the very beginning we invite our client to visit our office in Lviv (Ukraine) or we fly to client by ourselves. Goal is to get acquainted with our team and tell about the project. At this stage we ask a lot of questions and literally draw on from the client as much information about the future project as possible. It helps us not only understand what we are going to deal with, but also throws the light on those features of the product, which the product owner himself had not the clearest idea of.

When everything about the product is clear, we usually make a break and then start working on the project features arrangement. We present it as a general list of functional capacities. It looks like that:

2. Prioritisation.

In oder to implement the functional capacities we have to understand the priorities. For that purpose we use MoSCoW prioritisation method. The name of this method sounds like the megalopolis in Russia, but actually it comes from four English words: Must, Should, Could and Won't. I used to come across the explanation of the way this method works with a help of a sandwich. It's plain and simple:

To live a day a piece of bread is enough.
To make tasty you need some sausages.
And it would be cool to have some butter.
But onions are not the stuff you want in your sandwich.

We work with our products the same way:
Must - is what the product can't exist without. The most essential things. The basis.
For example, if you are developing a plain news website that will most likely be a possibility of adding and editing articles, comments and user's dashboard.
Should - is what would be nice to have in your product and what will bring you an additional value.
For the plain news site it may be a possibility of sharing the content via social networks, dividing the articles into categories and logging in the site via popular services.
Could - is what would be great to have. The idealised view of the product.
For our news site it could be the detailed statistics in the industry the project functions, fast loading speed, additional functions for a more convenient back-office and the mobile application.
Won't - is what we decide not to do.
For example, there will be no mobile version (adaptive design) for our news site.

3. Roadmap composing.

Certainly, we want to understand what stages our product is to go through to become successful. We try to settle those stages in a simple line, which is sometimes called a roadmap. It looks like that:

You can say, it's a simple map of releases. We understand where we are at the moment and in what order we will do the releases for our product.

4. Agile development.

For the most of the projects we use Scrum framework as the main methodology of software development. There's no need to talk about the roles and standart development processes in agile. If you're not familiar with it, you can find lots of information about that on the Internet. You should search for "product owner", "scrum master", "agile software development". Also, I want to recommend you this short book.

This is the way we see the development:

Sprint planning It's a meeting, where we decide what will be included into the current iteration. The meeting is held at the beginning of every sprint (once per 2-3 weeks) and takes the whole day. Initial 2-4 hours we decide on what we are going to do during the current iteration and each developer gives preliminary time estimates of his part of work. The following 2-3 hours the developers spend studying their task deeper in the technical aspect. And then about an hour more we confirm those estimates. Usually the iteration planning is held on-line (via skype / google hangouts).

Prioritisation
We also use MoSCoW for the prioritisation of each iteration. The same way we prioritise the whole contents of the project.
But here we say, that in current iteration each developer spends 60% of time for his Must-tasks, 20% for the Should and 20% for the Could-tasks.
That percentage is taken from the overall development time.
For example, an engineer has 100 working hours in this sprint. Therefore he has 60 hours for the Must, 20 hours for the Should and 20 hours for the Could. In such a way we also consider the risks. The 20% of the Could is assigned for that. We try not to count on the Could-tasks being accomplished. But it often happens with the efficient team work.

Still we say that the sprint is successful, if our Musts and Shoulds are accomplished. And that it is greatly successful, if we were in time to do the Coulds. If the team accomplishes only the Musts, there are efficiency or planning problems in it. They must be solved as soon as possible. Everyday meetings, demo and retrospective.
During the iteration we have several other meetings:
- The development team and the product owner meet every day for 15-20 minutes in order to understand which task everyone is engaged with.
- At the end of each sprint we hold a demo and a retrospective meetings. In short, we discuss what we did and didn't succeed to do during the sprint. And the way we could move faster and better.

Project releases
We think, that with each release the product has to get new features that bring it additional value. It may be directly or indirectly reflected in the growth of the project's cash flow. Or, for example, it might make it more popular. It's something that will help product to become better.

I guess, in a few words that's all. I hope, the information about our working approaches was useful for you and you'll be able to use some part of it.
Thanks for reading!

UPDATE: We decided to expand this post to this separated presentation.