In Evoluzione, we not only defend this methodology a lot but we also try to use it as much as possible where we are allowed.
To understand why we are big Agile fans, let’s first step back and go to the origins of this movement: we are in 2001 and 17 “sacred monsters” of computer science including Kent Beck, Robert C. Martin (or Uncle Bob) and Martin Fowler publish the “Manifesto for Agile Software Development”, also called the “Agile Manifesto”.
The 4 Principles of the Agile Manifesto as agency Best Practice
Within this document, a new software development method is outlined, which aims not to fulfil a contract but to ensure full customer satisfaction (it seems trivial, but the two do not always coincide!). The Agile Manifesto is made up of 12 specific points that can be grouped according to four principles that, over time, we have tried to integrate within our Best Practices in the agency:
1. People and interactions are more important than processes and tools: you need to communicate! In Evoluzione, we firmly believe that communication between all the protagonists of a project is the key to its success! All team members must be aware of what is happening, not just the developers: we always try to create cross-functional work teams and we like that all members are always aware of everything that is happening, although some operations may only concern a part of it.
2. It is more important to have working software than documentation: let’s be clear, we don’t write undocumented code, but that is certainly not the priority. For us, the code must be simple, readable and self-explaining… so we try to keep the comments for the essential. We believe it is more important to always release new versions of the working code and to do so frequently. Only through frequent releases and a technically advanced code is it possible to release true value to the project and, therefore, also to the customer.
3. Collaboration with customers is fundamental, we must not “only” respect the contract: as in life, even in the development of a project, collaboration can guarantee fundamental results, going beyond the “cold” conditions contractual. We believe that sincere dialogue and total collaboration with our customers is the key to constantly releasing value, achieving successful projects. We like to integrate the customer within our Agile team, giving him the role of Product Owner where possible: we have seen that in this way we have a motivated interlocutor in front of us and aware of having a goal to achieve together with the team: the resulting final is that we work with our client, not for our client!
4. Be ready for change as well as adhere to planning: things do not always go as we imagined them in the early stages and, many times, it is necessary to correct the course. It is very important for us to be reactive and to know that we can “change course” if there is a need to do so. This requires good flexibility but, above all, an interlocutor aware that a “deviation” from the path initially traced can be the key to guaranteeing the success of the project.
Well, we have seen what the Agile Manifesto is based on but, in practice, what is done in everyday life to respect all this?
Scrum, the Agile methodology chosen by Evoluzione
Currently, there are various Agile methodologies that each team can follow for the management of their works: we in Evoluzione, after various research and experiments, have chosen to follow Scrum.
Scrum creators Ken Schwaber and Jeff Sutherland borrowed this term from the game of rugby. It indicates the scrum package, which is the game situation in which all players have to push compactly in the same direction to reach the common goal: this is what Scrum does! The whole team must go in the same direction to achieve a single goal. Scrum is based on the theory of empirical process controls. This theory states that knowledge comes from experience and decisions are made based on what is known. There are three pillars at its base:
1. Transparency: the significant aspects of the process must be visible to those responsible for the work. These aspects must be defined through common standards so that they can be understood by all. We try to have a language that is as codified and standard as possible for everyone, avoiding ambiguity and misunderstanding. We try to include self-explanatory descriptions in our activities, which facilitate the task of those who read them.
2.Inspection: it is necessary to often inspect the artefacts produced (we will see shortly what is meant by artefacts) to understand which activities have been completed and, instead, what may be the impediments to achieving certain objectives.
3. Adaptation: If some aspects of the process are not going as planned or, even worse, cannot be completed, action must be taken as soon as possible to reduce the gap as little as possible.
We release value through artefacts
We talked about artefacts, but what are they? Scrum artefacts represent work and value in several ways that are useful for providing transparency and opportunities for inspection and adaptation. There are three types of artefacts:
1.Product Backlog: The product backlog is the list of all the activities necessary to make a product. Each activity is called Item and, within it, contains the user story. The list of items is prioritized in such a way that, at each sprint, it is decided to carry out the activities with higher priority. Furthermore, at the beginning of each sprint, it is possible to review the list of priorities. Since we try to apply agile methodologies also for our activities, we have also created an agency backlog. All the backlogs of our projects converge in it and we use it as a driver to plan our sprints (a sprint is nothing more than the work cycle, we have decided to regulate our company life on 2-week sprints).
2. Sprint Backlog: it is represented by all those Items that during the Sprint Planning are “promoted” to be included in the sprint. Each Item is then assigned to a team member who will be responsible for its completion.
3. Increment: an increase is represented by everything that meets the definition of FACT established by the team. In some cases, the list of increases, at the end of the sprint, is the same as the sprint backlog: this happens in the case of high performing teams. In all honesty, this situation does not always happen to us; several times our Increment is not like our sprint backlog but it is precisely here that, in my opinion, we see the true strength of Agile: it is the impediments and situations to be solved through adaptation that show the true power of this methodology.
How do Sprints work in Evoluzione?
The Agile, however, does not represent a rigid and harnessed doctrine but leaves room for some interpretations depending on the needs that may arise. Consequently, in Evoluzione we have put our idea of Scrum into play, regulating our sprints through these two types of events:
- The Daily Standup: a daily meeting with a fixed timebox of maximum 15 minutes, in which each team member updates the others on what has been done, what will be done before the next standup, but above all what are any impediments that could hinder the achievement of the target. Standup is always done at the usual time and… standing up. In this way, we try not to allow the members of the meeting to get distracted. Now the situation has changed slightly and, for remote team members, the “stand up” rule is not necessary.
- Sprint Review e lo Sprint Planning (to optimize times, if there are no particular criticalities, we combine these two activities in the same meeting): The sprint review represents for us a possibility of comparison, growth and being able to learn from mistakes made in the previous sprint. We raise any problems that have emerged in the past two weeks and try to understand how to prevent them from happening again. Sprint Planning, on the other hand, is the basis for correct and honest planning: we are aware that there are unexpected events (for which there is no solution) but over time we have understood that the more a sprint is planned with accuracy, the more the possibility of making a quality product is high.
All the work is driven by the sprint Board but unlike the classic Scrum flow, in which the board foresees that the columns exist
- ToDo, activities to be carried out
- In Progress, an activity that is currently taking place
- Done, activity concluded, validated and published
we have added two more:
- Testing, we include all those completed activities that must be validated before release into production.
- Wating/Blocked, in this column we “park” all those activities for which an impediment has arisen at that moment or we are waiting for external intervention to be able to complete them. We prefer to put them in a separate column so that, at each iteration (whether Daily or during the retrospective), it is very clear what the critical activities of the Sprint were and why they could not be completed.
None of us in the agency were born “doing Agile” so for the first year we were followed by a facilitator. In this way, we were able to learn the key concepts of agile and the Scrum philosophy, make them our own and be able to use them to the fullest.
After this initial training period, given that the desire to do and get involved was high, we decided that each member of the agency in turn is responsible for the good output of the Sprint Review and Sprint planning. In this particular historical situation, not being able to all be physically present in the office, we rely on Miro’s virtual boards that serve to guide our meetings. We hope we can all be together soon and be able to use that fantastic blackboard we have set up for meetings like these!
Here we have come to the conclusion of this mini-presentation of agile methodologies but, above all, of how we use them to improve our production processes. In the next articles, I will talk about how we started to concretely apply the agile methodologies to our customers, what the initial risks and difficulties were and what concrete advantages we were able to obtain.
Do you want to know more about how to be able to increase the effectiveness of your efforts thanks to the Agile method? Contact us!