09 Oct Benefits of SCRUM methodology in software development
For several years, in Grup de Serveis Triangle we have adopted the development management methodology known as Scrum. For those who are not familiar with this term, this methodology proposes a series of good practices in software development procedures, based on incremental updates of the product (instead of a single delivery onche the product is finished), also known as Sprints; and a set of self-managed teams, with their respective agreements and events, focused on improving performance and production. To know more in detail all the roles, procedures or specific characteristics of this methodology, you can find all the information on the Internet, specialized books, courses, etc. But in this blog post I want to focus on the improvements our company has suffered since we started the experience of working with Scrum methodology.
As I mentioned at the beginning of this post, we are only beginning to implement this method, since the change in roles, structure or organization is not something that is easy or quick to implement, but needs a long adaptation time (and more if you take into consideration our company type: a company that had been operating for more than 30 years under other work methodologies). Even so, with the experience so far, we can already detect a series of benefits that we share below.
Big projects
The first benefit, and the clearest and most obvious we have experienced is in the longer projects such as upgrades, startups, integrations with external applications, start-up of new modules and, in short, any project whose duration exceeds 1 month. In this type of project, the different sprints that will make up the project are defined and, depending on the sprint accrual, small incremental parts of the product are delivered based on a previously performed prioritization (Product Backlog).
Periodic deliveries allow that, from a first phase of development, the client can already familiarize himself with the result, which offers him another point of view and the possibility of making small changes or different approaches from the initial one, that if they had to carry out once the product is completed would be more expensive and inefficient. In addition, it also allows you to prioritize depending on the budget assigned to the project if the functionality to be developed is very extensive.
Team Management
Another important benefit is found in the self-management of the different teams, mainly in the development team (or what we like to call DevTeam). As it is the team itself that decides the work load that can enter into each Sprint, the stress is lower and, therefore, increases the productivity of the team. Highlight that as the DevTeam assumes a role in the process (and not a role each person that forms the team), all paddles to achieve a common goal so that many dynamics are improved within the team and creates a good rapport and harmony between all the members.
Product Owner: relationship with the customer
On the other hand, the direct contact with the client is centralized by the figure of the Product Owner, who is the one who performs a filter and reduces the direct interaction of the developers with the client so that they focus on the main part of their work: to develop. In addition, another benefit for the client is that his Product Owner centralizes all the knowledge related to its implementation and, therefore, is his technical reference person in terms of new projects and possible new functionality to be implemented.
To conclude, I would like to reiterate that the implementation of all the procedures involved in this methodology can be complex. For Triangle, the current challenge lies in finding a perfect coexistence between Sprints and small projects (modifications of one or two days), and fine-tuning some meetings such as the Review and the Sprint Retrospective. But perhaps if you are thinking about adapting this methodology to your company, you should be a bit flexible and adapt some aspect to the requirements and needs of your company’s case, because even though the Scrum is specific for software production, not all the software companies are the same, nor are the software products we develop.