The tools and processes are ready and we are ready to get to work.

In Siesta we manage projects either in a sequential way, which is called waterfall, or in an incremental way, called agile. You can read about their difference here.

However, it should also be said here that nearly 90% of our projects are developed in an agile way and it is also our preference.

How the development goes

1. Introduction

If your project is also agile, you may find it useful to know a few terms that have made their way into the international IT world.

Agile projects usually have requirements written in the form of functionalities from the user’s point of view. These are called user stories. The template for expressing the user story looks like this:

As a <role> I want <capability> to <action benefit>.

For example: as a user, I want to assign a client to his case so that I can inform the client about the progress of his case.

In agile, everything happens in 2 week periods called sprints.

2. Planning

We always meet before the start of a new sprint that we plan together. Backlog consists of epics, user stories and individual tasks. We estimate all the tasks at the beginning in terms of their time complexity. At the meeting, we then select the user stories we will work on in the next sprint together in accordance with your priorities. Depending on the degree to which you envisage the final product, we roughly plan the development process at the beginning of the project and then only adjust or confirm the plan at regular meetings. Or always plan anew.

3. Demo session

At the joint meeting, which always takes place at the end of one sprint and before the start of a new one, we also show you what we have developed in the last sprint. This is why these meetings are sometimes called demo sessions or steering committee meetings. Steering Committee members tend to be senior management representatives on the client’s side and the project manager and possibly the lead developers on the contractor’s side. The main goal of the steering committee meeting is to determine the direction of product development.

4. Your part of the collaboration

You probably already understand that a key aspect of agile development is regular collaboration on your part. It’s critical that you plan for the investment of your time during development and that you are genuinely and actively involved in the project. This is the only way to build software that will meet your expectations and benefit your business. 

Regular testing of the software is part of your involvement. We naturally test the software internally. For this we use manual testing and automated tests. However, it is absolutely essential that you test the software yourself on an ongoing basis and communicate feedback back to us (you will be given access to the reporting system to do this; more on this in the Support and Maintenance article). Because it’s most often during user testing that you’ll find out what you’ve forgotten in your original requirements, or which functionality or design needs to be modified.

Agile development takes your change requests into account and we are able to incorporate them into the development. This is not quite possible with sequential waterfall development. With each change, we discuss its complexity and impact on the original time and financial estimates.

The primary purpose of testing is to find and fix the bugs that happen during the development of any software. Our estimates account for the time required for bug fixing or debugging.

The goal of agile

The goal of agile projects is typically MVP, minimum viable product. That is a product that has a chance to attract first users on the market. They will verify the potential of the idea and the product in its early stages. Before you hone your software to perfection, only to find out later that users want something else and you’ve spent a lot of money for nothing. MVP is therefore one way to validate your business idea at a reasonable cost. Of course, validating a business idea is also possible before you even start development. We can help you with that too.

Reporting

In the interest of transparency, we should also tell you that at the beginning of each new month we will send you

• a report summarising what we worked on the previous month, what we have completed and what is in progress
• an invoice for the hours worked multiplied by the hourly rate stated in the contract. Our invoices are due within 14 days.

Did you have any questions while reading? Something we didn’t explain properly? Please let us know – we will be happy to answer you, discuss any uncertainties and comments and improve the article for future readers.