Agile projects: why Scrum?

The implementation of agile methodologies makes it easier not to lose focus of the project and to obtain results that provide value quickly. Here is why we have chosen Scrum.

By Isaac Gómez, Project Manager at Beonprice

Haz clic aquí para leer el artículo original en español.

The day-to-day work in a startup is both exciting and intense: many open fronts to which you have to respond quickly, speed of delivery is a priority, challenges arise daily, you communicate with many people from different areas throughout the day… All this means that at the end of the day, you feel as if you’ve just stepped out of a cocktail shaker! I think all of us who work in a similar environment can identify with this situation and I personally love being there, in the centre of the hurricane.

In the early years of a technology company, the number of people is generally small and you will probably work day-to-day with a team of no more than three people. So far the “chaotic” organisation works, and it’s fun! However, as time goes by, the sophistication of the product and, above all, the growth of the team, suddenly this chaos has completely absorbed your day-to-day work. At that very moment you will encounter, among others, two tremendously important problems:

The first, used mainly in economics but which I have experienced first-hand, is the problem of bounded rationality:

1) the available information: you will not have it organised, nor will it arrive in a structured way, you will depend absolutely on your mind, and here you will come face to face with the following problem.

2) the cognitive limitation of the individual mind: although at some point you may think you have everything under control, you will be surprised how easy it is for the human brain to forget things.

3) the time available to make the decision: if you add to all of the above that neither the customer nor the market will wait indefinitely for your response, you are at risk of making wrong decisions.

The second problem you will encounter is a loss of focus. There really will be so much daily work that it will prevent you from having a global vision. If you are also responsible for a team, you will again be at risk of drifting the project.

If I am telling you this, it is because I have experienced it first hand. I remember that Emilio Galán, our current CTO, insisted to me when I took on the role of department leader that the first thing I had to do was to implement an agile work culture, but until then my response was: “it’s not the right time, if I dedicate myself to implementing a methodology now we won’t get the job done, we’ll drown in bureaucracy”.

Well, persistence paid off. The time came to shape our framework. My first perception when assessing methodological alternatives was that it was all fads, that it wasn’t really going to solve a problem, that we could just say we were on the cutting edge and say we used Scrum, but I decided to apply the advice.

Among the different candidates (Kanban, Scrum, XP, Waterfall…) we decided to use Scrum, why?

• Agility: the fact that we can deliver the product and shape it in each cycle is something very valuable in fast-growing companies.
• Scrum Ceremonies: being aligned all team members (Scrum Master, Product Owner, Dev Team and Stakeholders) and communication flow is essential in such a changing environment.
• Role differentiation: make clear what the responsibility of each member of the Scrum Team should be, eliminating duplicities and uncertainties.
• Cycles: performing a review in short periods of time, in our case two weeks, avoids deviations between the expected and developed product. In addition, the retrospective allows for a culture of continuous improvement.
• Limiting the work: it allows us to have a clear focus and to move in the same direction, pursuing a common goal. It also allows the amount of work to be adapted to the performance of the development team according to its maturity.
• Kanban panel: although it is not strictly speaking native to scrum, the reality is that it is very common to use it as it is very visual and intuitive. In addition to the panel itself, having limited parallel tasks is a highly recommended practice in terms of efficiency.

This set of potential benefits not only solves the aforementioned problems but also brings extra benefits.

Implementing a new methodology in an organisation that is already up and running is no easy task, from finding the perfect management tool, phasing the implementation stages, preaching change to the technical team, explaining the implications to stakeholders… I could go into all these aspects in detail, but each of them could be the subject of a separate article.

Several years into this process, I would love to say that we have a definitive framework, that there are no problems and everything is running smoothly, but I would be lying. It is a process of continuous improvement that we have implemented step by step, trying to avoid the bureaucracy I mentioned at the beginning and to obtain results from day one. This is precisely one of the most representative characteristics of Agile and specifically of Scrum, to deliver frequently and quickly, seeking to provide value as soon as possible.

Looking back, I have no doubt that the improvement in all senses has been enormous: we work keeping the focus, the objectives are agreed every start of the sprint by all the roles of the organisation, we can assign the work fairly attending to the team, we are able to measure productivity, the work comes out with quality, each role can focus on its speciality… besides, if things go wrong they will come to light in the retrospective and start all over again!

Finally, I would like to give a brief piece of advice if any reader is in a similar situation: don’t try to apply the most sophisticated, novel or complex methodology, look for the one that best suits your way of working and apply it without fear of making mistakes, only then will you soon realise that it really works or that you should change.