Getting started
Start to learn the main concepts of Mia-Platform and how to use to develop your services
Start to learn the main concepts of Mia-Platform and how to use to develop your services
Discover more
Discover all the benefits of becoming a Mia-Platform's partner entering the program.
Discover more
We hear more and more often about Agile, an approach born in the world of software that is gradually establishing itself in other contexts as well. Thanks to this approach, companies and people acquire the best suited rules and tools to face changes. Let’s see in this article what are the origins of this approach and some practical examples.
The Agile Manifesto was born in 2001 from the collaboration of 17 software professionals, whose goal was to define the values and principles underlying software development in an ever-changing environment. The manifesto stands in contrast to the classical methods that had not always proved effective and aims to propose a new vision for work processes organization. The agile methodology is mainly applied to software development contexts and, more precisely, to the processes of development teams. In addition, it has also proved effective in other areas where it has been possible to draw inspiration from the values expressed in the Agile Manifesto.
Processes emerge from people’s interactions during daily work, while tools simplify and facilitate these interactions. Therefore, we should not introduce Agile starting from processes or tools, but from the constant analysis and continuous improvement of how people work with each other. Agility is a matter of continuous cultural improvement.
The true measure of the progress of a project is the value generated and it can only be measured with a working software. Feedbacks are collected better and are more truthful if you see the software that works compared to a powerpoint or a gantt. The documentation supports the development of the working software and must be as concise as possible in order to be updated with the minimum effort. The first documentation is the code and must be inspired by the Clean Code Principles.
Customers and suppliers succeed if they generate value for each other. This is the reason why it is important to work closely and in a clear and well-regulated context. The contract should not be a bond but a transcript of the working rules that have been given.
Responding to change does not always imply saying “yes” to change, but saying yes to the changes that bring value to end-users. We’re talking about continuous planning. The further the planning is, the more we know it will be inaccurate. The more the planning is done in the short term, the more stable it should be. With each increment released, you learn something new and adjust your schedule.
In addition to the four values, there are also 12 principles, which you can deepen more about at this link.
In addition, we want to underline the ones we consider most relevant to our way of working, which we will discuss in the following paragraphs:
Agile, as previously mentioned, is an approach to software development born as opposed to traditional methods. One of the best known is the Waterfall method, according to which the software development takes place sequentially to achieve the fulfillment of the requirements that were defined at the beginning of the process.
The waterfall method, therefore, requires the development team to receive all the specifications at the beginning of the project and deliver the finished product in the next step, without a review during the steps and without taking into account possible changes or variables that may be introduced during the path.
This method has several limitations. The main one is that it is very difficult to provide the development team with all the necessary specifications before the start of the project and then be sure that they will be respected until the end. What usually happens is that many aspects that contribute to the success of the project and the optimal release of a product emerge only in the subsequent phases and following tests and comparisons both within the team and between the team and the customer.
But this is not the only limit of the waterfall approach. There are several problems that arise during the management of a project that this type of approach hardly takes into consideration. We can name a few:
As you can see, through the values and principles of the Manifesto, the Agile methodology therefore aims to solve, or at least manage, this type of problems that can potentially emerge in any project.
The Agile methodology has its roots in the concept of continuous improvement: the ability to review at different times both the initial specifications and the variations that emerged during the development.In fact, Agile is based on the Deming Cycle: a series of steps that allow us to remodel, correct, test what we are working on.
The Deming Cycle consists of four moments: plan, do, check, act, which allow for the development of an incremental product that takes into account continuous tests also with the end customer.
This image is AgileReloaded’s.
This image illustrates the differences of the two approaches mentioned above: the Waterfall model on the top, and the incremental one in the lower part.
Given the above and the strong diffusion and effectiveness that the Agile methodology can now boast, we can define some benefits deriving from the adoption of this approach:
Scrum, according to the official guide, is a framework for developing and sustaining complex products.
It is, in fact, a framework, which makes it more flexible than other methodologies, and therefore more easily applicable to many contexts. It is for this reason that Scrum is the most widespread framework among the Agile methodologies.
Scrum, literally, is the scrum of Rugby. It is therefore from the world of sports that this term has been borrowed. The term identifies that game situation in which players compact to push in the same direction.
There are several aspects that characterize Scrum, we can list some of them:
We have seen so far the values and principles of Agile and how these have stood in opposition to more traditional methods such as the waterfall one.
At Mia-Platform we have adopted the values and principles of Agile, and used the Scrum framework, right from the company’s first steps. We started doing retrospectives in a company of only 5 or 6 people, up to having more than 60 people organized in different teams.
We will therefore tell you some examples of how we apply this approach internally and how this has supported us in a very rapid growth (context of great change) and rich in complexity (risk factors).
We have already talked about how the Agile approach is based precisely on continuous adaptation and continuous improvement both individually and at team level.
Continuous improvement is a concept that has its roots in the distant past. It comes from Japanese Kaizen: the commitment to make small and continuous changes to all aspects of a business organization. These small changes allow us to bring about profound innovation in all areas of the company.
There are various ways to carry out moments of training and discussion within the team and cross team. Let’s see some of them.
It is a moment, typically a few hours, in which a group of people work simultaneously using a single computer. Mob programming can be carried out within the team or cross-team.
There are no fixed rules for mob programming but, usually, you can:
This is also an activity for developers, that boosts their skills and competencies with programming exercises. Kata can also be done in pair programming sessions.
Continuous improvement activities can also be carried out cross-team, and an example are activities aimed at scrum masters. In this case, meetings are organized, each on a specific topic linked to a moment of the Scrum. An example can be the retrospective: in this case the scrum masters meet and share their experiences on the retrospectives conducted within the various teams; on this occasion, they can learn good practices and guidelines to share with everyone.
This activity is similar to the previous one. Also in this case, the meetings among POs are structured as to cover a specific theme each time, in order to find common guidelines between teams. The goal is that these guidelines can then be declined in each working group, which will take into account the different internal needs, and which can vary in number, type of project and much more. Some of the topics to be covered include: improving user story writing, how to make meetings more effective, new management models and frameworks, and much more.
Meeting among different roles is very effective; especially when we have to evolve not only practices and processes, but also products. A useful moment to pursue product improvement is the meeting between the tech leaders of the various teams and the R&D team. Thanks to this meeting, the R&D team can collect requests and needs from the teams and update them in detail about the development plans.
The retrospective is a key moment of the Agile methodology. It is an opportunity for the t team to reflect and analyze their general processes or the progress of a specific project. Retrospectives enable change: they highlight virtuous behaviors as well as practices that would be better to stop.
The Agile Manifesto dedicates an entire principle to the retrospective, the twelfth: “At regular intervals the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”
There are several ways to conduct a retrospective. Below we propose 5 steps to manage the team retrospective:
For more information on the retrospective and how it can be managed and carried out even remotely, you can read the article at this link.
The unconference is one of the moments of Agile that is carried out less frequently than others. But it is not less important for this.It is a particular type of conference, based on Open Space Technology.In this unconventional conference the agenda is built by the participants themselves at the beginning of the day. Therefore, everyone can propose contents, there is no call for paper, and the environment that hosts the event is chosen precisely to facilitate free exchange dynamics.
Contents can be presented in different forms: talks or face-to-face meetings, round tables or workshops, and even requests for further information on specific topics.
The marketplace is perhaps the most important moment of the day: it is the moment in which the agenda is created, everyone can propose their own content and at what time it will be presented and in which conference room.
Once everyone has presented their content, exchanges can take place between slots to make the agenda more usable, with little overlap and trying to facilitate everyone in participating in the interventions that interest them the most.
The unconference, apparently without rules, is however guided by 4 principles – and one law – that are very important for managing the sessions:
And finally the law of two feet: if you are not learning, nor contributing, then it is good to move elsewhere.
We know that the Agile manifesto says that: “a face-to-face conversation is the most efficient and most effective way to communicate with the team”. We firmly believe in this principle. Despite this, remote work is sometimes necessary, or at least occasionally provided for, within our work routine.
Knowing how to manage at best, through defined tools and rules, can help compensate for the shortcomings that arise from all situations in which the team, or part of it, does not work in presence.
To structure the remote work we must take into account some aspects:
Onboarding is a very delicate phase of entering the company. It starts long before the date defined by the calendar and involves many roles within the company.
For us it is also an important moment to share our culture and how we work: we explain it in the guide that you can read at this link.
There are mainly 3 areas involved to which an onboarding phase is dedicated to:
In this first phase, the person in charge would give an overview of all the useful tools that are used in the company, from the more informal ones to those related to scrum events, documentation, and the wiki.
This is the moment of culture and values: the manifesto, corporate social responsibility activities, training moments, events, and career paths.
At this moment, the newcomer would meet the colleagues, familiarize with the project, and join the teammates: the Product Owner, the Scrum Master, and the whole development team. The new person would start getting to know the moments of the Scrum: each team has its own Sprint opening and closing calendar, stand-up time, and retrospective calendar.
As we have seen from the beginning, the Agile approach aims to provide rules and tools that can help manage complex situations and continuous change.
We saw how this approach is applied in our context, with some concrete examples of Scrum activities and moments.
Each reality, within its own context, can find its path of applying the Agile approach and the Scrum framework in the most appropriate way. Only by experimenting and testing, and continuing to change and improve, you can find the optimal way to manage the team and its growth.