Agile: the key for digital transformation and company’s growth

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

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.

The 4 values of the Agile Manifesto

1.Individuals and interactions over processes and tools

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.

2.Working software over comprehensive documentation

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.

3.Customer collaboration over contract negotiation

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.

4.Responding to change over following a plan

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:

• “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
• “Simplicity – the art of maximizing the amount of work not done – is essential.”
• The best architectures, requirements, and design emerge from self-organizing teams.

Benefits of Agile approaches

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:

• Lack of requirements’ change management
• Ineffective communication
• Inadequate skills within the Team
• Undefined requirement
• Inaccurate estimates
• Lack of a risk management plan
• Low alignment on the definition of “Finished”
• Not enough time devoted to project management
• Low knowledge of how to manage a project

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:

• Cost reduction: being able to continuously check the evolution of the project allows you to implement the necessary changes when you are still running and avoid having to make large, and expensive, changes only once the project has been completed
• Greater collaboration: this methodology encourages continuous dialogue both within the team and between team and customer;
• Greater trust: the possibility of carrying out continuous tests and being able to actively and consciously participate in all the steps of the project, allows all the people involved to have greater confidence in the work of their colleagues or, in the case of the customer, in the work of their supplier;
• Greater flexibility: the goal of the agile methodology is not to give a definitive answer on the management of a project, but to give precise rules on how to act in contexts of continuous change, to derive value from them.

Scrum: the most widespread Agile framework

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:

• Roles. The Product Owner is the person who is responsible for the implementation and evolution of the product in a given project and who interfaces with the customer; the development team; the Scrum Master is the process manager, who could belong also to the development team, and who knows how to best apply the Scrum methodology.
• Artifacts. The Product Backlog is the list of team activities which are necessary for the realization of the product. This list of activities is then recalled from time to time in the Sprint Backlog, which collects the activities to be carried out in a given period.
• Events. These are the moments of the Scrum such as Sprint Planning, when the team plans the activities of the next period – the sprint – which can last one or several weeks. At the beginning of the day, there is the Stand-up, a 15-minutes meeting in which people participate to promote follow-up conversation as well as to identify issues before they become problems. The retrospective is a moment of in-depth discussion on how a particular project went or how the team is generally doing.

Agile culture as an engine of internal and external digital transformation

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).

Continuous improvement

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.

Mob Programming

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:

• Review something that has already been developed
• Improve a piece of code that has already been written
• Study something new
• Solve a problem together that has arisen

Kata

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 for Scrum Masters

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.

Continuous improvement for Product Owners

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.

The continuous improvement of the product

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

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:

• Set the stage: it is the starting phase and it is very delicate, because it is in these first minutes that it is essential that everyone feels involved so that they bring value for the entire duration of the retrospective. One of the techniques used in this phase is to describe the project with a word;
• Gather data: in this phase you get to the heart of the project, and you go to collect everyone’s opinions. There are various ways to do this, one is the “start, continue, stop”: participants can express their ideas which will be placed in one of the three options available.
• Generate insight: this is the moment in which you can deepen the information gathered in the previous phase. One technique for doing this is with “the five whys”.
• Decide what to do: once the comparison and study phase is over, it is time to decide what to do with all the observations that emerged. In this phase, therefore, a plan of actions, and its assignees, is created to be started immediately.
• Close the retrospective: in conclusion, there is a short passage, similar to the one we started with, where we wonder if the retrospective was useful or not. This will allow us to organize ourselves even better for the next one.

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.

Unconference

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:

1. Whoever participates is the right person
2. When it starts it’s the right time
3. Whatever happens is what had to happen
4. When it’s over, it’s over

And finally the law of two feet: if you are not learning, nor contributing, then it is good to move elsewhere. 

Working remotely: the ultimate guide

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:

• Time management and logistics: even remotely, it is very important to have rules in time management. This is to avoid the risk of scattering energies, nor working beyond what is necessary. Starting a morning routine as if you were leaving home to go to the office, taking breaks to get up and exercising, reducing distractions from notifications, and drinking a lot of water are some of the essential tips.
• Communication: this is one of the most complex points of remote working. Sometimes you risk being in endless chats or email rounds when it would be easier to start a video call and share your screen to quickly solve doubts or find common solutions. It is also very important, in remote meetings as well as in presence, to stay focused and avoid doing anything else: in this way, we reduce the time of meetings and avoid spending hours on the phone without finishing anything.
• Tools: to support us in this way, many tools come to our aid. Therefore, it is important to understand which ones to use and on which occasions to make the most of their potential. For example, we use Google Chat for both 1:1 and team conversations. Google Chat is a very simple tool also to start video calls directly on Meet when we see that the conversation is lasting longer than it should. We then use all the other tools of the Google Suite to work in sharing mode (Drive) and make appointments (Calendar). Jira and Confluence help us for all the work organization and documentation part.
• Team Rules: it is important that the rules are shared among the team and that the planning is done on time. For example, if we work in a mixed remote and presence mode, knowing the days of office presence of the other team members in advance allows us to better organize ourselves for all those activities that would be better to carry out in co-presence.
• When it is mandatory to work in co-presence: for some activities, remote working is not very effective. Some examples are the more complex scrum events: Sprint Planning, Retrospectives, Sprint Review, etc; the activities of co-design or co-creation of content; the onboarding phase of a new entry into the team; the kick-off phase of a project. 

Onboarding

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:

Administration

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.

People & Culture

This is the moment of culture and values: the manifesto, corporate social responsibility activities, training moments, events, and career paths.

The team that will welcome the new person

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.

Conclusions

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.