< Back to articles

Ackee Agile: Our Approach to App Development

More than years have passed since the publication of the agile development manifesto. Just a quick reminder: The top game of the year was GTA III, Mac OS X and Windows XP were released. Twenty years is a very long time in IT. So how does agile development remain relevant, even though Windows XP has been long (ehm) dead? And why do I write about agile development when everything that was to be written was written over the years? The main reason is that we still do not use agile development as often as we would like.

If you have never heard about agile development, start with the principles behind the agile manifesto. These are the principles upon which the individual methodologies were built. Among the most known are Scrum or Kanban.

Agile software development: How does it work?

How does agile development work in real life? In Ackee, we basically use the Scrum methodology that we modified to fit the agency development model:

In the beginning, the project is split into shorter time periods called sprint or iteration. The work is only planned for a couple of weeks ahead (typically two or three).

Before the beginning of each sprint, the development team meets with the customer (sprint planning) and together, they negotiate what will be its content. This content should not be changed during the sprint. All possible changes and new functionalities that cannot be incorporated into the sprint are put into the backlog, a list of future tasks.

Within each sprint, a short technical analysis takes place, as well as UX/UI design, development and testing. The output is a functional version of the application that can be presented. That is what makes agile different from the classical waterfall model, where all work is connected linearly (just like a waterfall). In the beginning, the technical analysis of the whole application takes place, after that UX/UI design of the whole application and so on.

It is necessary to realize that a sprint is not a commitment but a recommendation. The amount of work may be too big, and it is impossible to make it in the given time. It can also happen that the amount of planned work is too small, and some tasks from the backlog can be added. These planning mistakes are to be learnt from for the next sprint.

The base of agile development is close cooperation with the customer and regular communication. The customer is included in the whole development process and receives a product they cooperate on. In Ackee, we are trying to do most new projects in an agile way. Thanks to that, we can deliver great apps in a very short time and save time and money.

All hail to Agile

When we look at all the advantages of agile, is there even a reason to use another methodology? Yes!

The first principle of agile development is “...accommodate the client with timely and continuous delivery of valuable software.” However, that is not always a satisfactory way. For agile to work, the customer must be interested and have time to cooperate with the development team. The product owner (the person responsible for product decisions) must be able to communicate daily with the team and collaborate on the development through the decisions on a daily basis, take part in sprint planning and have some overview of the development.

Based on another principle of agile development, changes in requirements are welcome. That is obviously a good thing – the world is evolving quickly, and the product has to as well. But here, the product owner plays a key role and has to be able to decide which functionality is important and what is just a small enhancement. Wrong prioritization can cause there to be sprint after sprint, and in the end, there is no product or money. It is, therefore, clear that in agile development, the role of the product owner representing the customer's interests is absolutely key to success.

A little legal talk

In Ackee, we use two types of contracts for software development: Fixed Time Fixed Price (FTFP) and Time & Material (T&M). 

In the first case, the contract defines the result that should be created and it is to be delivered for a given amount of money and in a strict time frame. From the legal point of view it is a Contract to Create Work where the: “contractor commits to, on their expense and risk, perform work for the ordering party and the ordering party commits to take over the work and pay the agreed price.” (§ 2586 par. 1 New Civil Code)

On the other hand, Time&Material requires a Framework Contract about Service Provision. Such a contract does not define any result, but only services that will be provided by the contractor to the customer (for example design, programming, testing etc.). Individual services are provided based on partial orders, typically taking place after sprint planning.

An attentive reader can already see that Time&Material and agile development go together.

When to choose agile and when not to?

Agile methodologies are great for the fast development of software that changes over time. However, agile metodology not universally applicable to all projects and to all customers. The success depends on the product owner’s role, whose absence or indecisiveness can paralyze the whole development team.

When should you choose agile, and when should you not? The classical answer goes: if the customer does not know exactly what they want, go agile. If you are a customer, choose an IT agency that has experience and can advise you on the best development method for your project. The most important, however, is the approach: agile projects require time, commitment and endurance. If you don't have those at your disposal, create the project together: analyse requirements, design a solution and test it. You can go on with the waterfall as soon as this assignment is ready. It is no mistake, even over 20 years after publishing the Agile Manifesto.

This blog was written using the principles of the agile methodology SCRUM.

Marek Elznic
Marek Elznic
QA Team Lead

Are you interested in working together? Let’s discuss it in person!