Iterative Approach to Software Development

Iterations are short time frames of planning and functionality; the shorter the frame is, the faster the prepared functionality will be delivered to the users of our software.

We believe that publishing apps frequently is a good choice: it builds trust in the team creating an app, reduces the costs of publishing, and facilitates the introduction of changes concerning the business assumptions of the project. Due to short iterations, less can go wrong, and we lose less work time if the assumptions change. Also, it forces us to optimize the actual releasing process.

Netguru tries to release at least once a week. This assumption requires from us a particular approach to planning and communication.

How do we do it?

We talk with the Client about the project at least once a week to plan the following week. During the meeting (via Google Hangout) we try to gather all the parties interested in app development. Therefore, the Client (the Product Owner), web developers engaged in the project, and our Project Manager are usually all present during the meeting.

The agenda of the meetings is very simple: we briefly discuss what was done in the previous week (3–5 minutes), then we plan the following week (25 minutes).

Planning involves the Client stating what should be done in the next couple of days. The Client also identifies priorities.

We use JIRA as the project management system, so the whole planning process takes place there. The Client posts Stories in the correct order.

Later on we discuss each Story to make sure that everybody understands it correctly. If something is unclear, we try to explain it as accurately as possible. We sometimes rework parts of the Story or divide it into smaller units to complete it in one or two days.

It is crucial for us to plan the following week well in order to avoid wasting time on more meetings and discussions. It is not always possible, but that’s the ideal.

During the meeting, we consider the possibility of achieving a given business goal by simpler means. It is important for us to use ready-made solutions wherever possible, according to the rule, “don’t repeat yourself”.

We also try to avoid planning too far ahead – a week is enough, in the case of unexpected turns of events. The rule is that we want to know the vision of the product in the long run, but we also realise that this is a general idea. We prefer to plan in detail only one week in advance, because we feel that a different kind of planning is a waste of time – plans tend to fail.

While working on functionalities using JIRA software, specialists tend to commit, and all the changes introduced are immediately visible on the staging server. It allows the Client to figure out if the software specialist has correctly understood the assumptions of the Story.

Such fast working on the product fits well with our technical solutions – the Client is aware of the new staging version, because they get HipChat notifications.

A fast iteration also appears in the coding process. Our review process assumes that each and every change introduced by the software specialist will be verified by another specialist within two days.

I think that this method allows us to build apps of different size. Even if the business element requires the publication of an app as a finished project, iterations allows us to better control app development. It also helps us to test functionalities faster and change their shape if business assumptions change.

It is crucial to avoid getting too attached to the code created. If assumptions change after a particular iteration, code may not even be used. However, it means losing only a single week of work maximum.

It is also possible that code review reveals that the other software specialist’s approach is better. A small part of the code might then need to be improved.

We feel that working with iterations is the fastest software development approach available online. It helps to achieve results, control changes better, and reduce the cost of publishing an app.