Ackee Agile: Our Approach to App Development
18 years have passed since the publication of the agile development manifesto, which is a really long time in IT. However, we still do not use it as often as we would like. Agile methodologies are not universally applicable to all. For which projects and customers is therefore agile suitable and how can it really look like in the real-life of agency development?
In case you have never heard about agile development, start with principles behind the agile manifesto. These are the principles upon which the individual methodologies were built. Among the most known are Scrum or Kanban.
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:
At the beginning, the project is split into shorter time periods called sprint or iteration. The work is only planned for a couple 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, which is 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 in a linear manner (just like a waterfall). At 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 realise that a sprint is not a commitment, but a recommendation. It can happen that the amount of work is 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 that they cooperate on throughout. In Ackee, we are trying to do most new projects in the agile way. Thanks to that, we are able to deliver great apps in a very short time.
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. In order for agile to work, the customer must be interested and most of all have time to cooperate with the development team. Product owner (the person responsible for product decisions) must be able to communicate daily with the team and cooperate on the development through the decisions on a daily basis, take part in sprint plannings 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 prioritisation can cause that there is sprint after sprint and at the end there is no product or money. It is therefore clear that in agile development, the role of product owner representing the interests of the customer is absolutely key to the 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 fast development of software that changes over time. Agile is however not universally applicable on all projects and for all customers. The success is very dependent on the product owner role, whose absence or indecisiveness can paralyse the whole development team.
When to choose agile and when not to? The classical answer goes: in case the customer does not know exactly what they want, go with agile. The most important, however, is the approach: agile projects require time, commitment and endurance. In case you don’t have those at your disposal, create the project together: analyse requirements, design a solution and test it. As soon as you have this assignment ready, you can go on with waterfall. It is no mistake even in 2019.
This blog was written using the principles of the agile methodology SCRUM.
Originally published at https://www.ackee.cz on August 29, 2019.
