I got to know Scrum very recently, in mid-2019, when, fortunately, I was invited to take a course with Jorge Abad. Since then, I have studied and learned under the guidance of Juan Andrés Ochoa, Felipe Mejía, and Jorge’s support in case of any doubt.
Last year (2020), I was certified as a Scrum Master with Scrum.org, and it didn’t take long for an opportunity to present itself to use what I learned in a real project.
The approximation
Fortunately for me, the Scrum 2020 guide begins by saying: «Scrum is based on empiricism and Lean thinking» because nothing really prepares you to face the use of Scrum in a real project. You must learn it and understand that there is no magic formula but that each case is unique. From paper to the real world, there is a giant stretch, which makes its implementation much more interesting (and sometimes frustrating). Not for nothing do they say that Scrum is easy to understand and difficult to implement.
As a good apprentice, I screw up as many times as possible. From my perspective, this is how we humans learn: repeatedly failing until we succeed.
Apply Scrum in Latin America
My encounter with reality, at least in all the initiatives in which I have participated, has been with these characteristics:
- The Developers team is not ten or fewer people or three to nine people. It is for one or two people.
- The dedication time of the Developers team is not always 100%.
- In some cases, the Developers team changes frequently, and people come and go.
- At present, it is difficult for us all to be in the same physical space, so all events have been remote.
The approach that has worked best for me so far, and here I intentionally expose myself to being told that what I do is not Scrum, is the following:
1. I suggest estimating, in each Sprint, as if it were the first. What was achieved in the previous Sprint is taken into account but not about how many points.
The inspiration, and how I want us to estimate, came from this great video by Jorge Abad (Spanish):
http://www.lecciones-aprendidas.info/2020/10/Como-Estimar-la-Capacidad-Velocidad-de-tu-Equipo-Scrum-en-el-Primer-Sprint.html
This is the way we seek to do it:
1.1) The scale 1, 2, 3, 5, 8, 13, 20, 40 and 100 is used.
1.2) Developers look for the Backlog item (s) that they consider to be the simplest and set the value 1 (pivot). The aim is to assign the pivot value to Backlog items of similar effort.
1.3) With those 1, scale values are assigned to the rest of the Backlog items of the Product Backlog.
1.4) Developers indicate the time, in hours, that they consider it takes to make a 1.
1.5) The calculation is made in days by dividing the time in hours that a 1 takes by the day’s working hours (I use 6 hours, but it works with any number). We obtain the number of person-days it takes to complete a 1.
1.6) If a 1 takes more than one person-day, the Product Owner is asked to divide the elements with an estimate greater than 3. My suggestion, for convenience, is that the maximum size is between 3 and 5 points.
1.7) Sprints of two weeks (10 business days) are used, and it is assumed that two days are spent in meetings, so we calculate about eight business days.
1.8) Developers indicate the time, in days, that they can dedicate to the Sprint. Example: 4 days (50%), 6 days (75%), etc.
1.9) The sum of days of the Developers gives us the number of person-days.
1.10) The division of the total person-days (item 1.9) by the number of person-days it takes to finish a 1 (item 1.5) indicates the approximate maximum of total points that can be achieved in the Sprint.
1.11) Based on the approximate maximum of points, the Developers select the Backlog items to place in the Sprint Backlog, the Sprint’s commitment.
1.12) Developers divide the elements of the tasks into Sprint backlog and place, in hours, the time each of them can take. My recommendation is that a task has a maximum duration of 6 hours (one day) to see each day’s progress on the board (We use Yodiz as a tool).
It is important to consider that the pivot (elements with effort value 1) of this Sprint may be very different from the previous or the next one. This is because there are additions and changes to the Product Backlog according to the Product Owner and Stakeholders’ criteria. Also, the team is becoming more and more aware and knowledgeable about the product and is increasingly improving its works.
2. During the Sprint, I maintain the interaction with the Developer’s team in a way similar to the idea that I have about being a father: To be present without being in the way. We maintain channels on Telegram and Discord for communication.
3. I have found that being teams so small and in sprints so short, the events are high-speed and, so far, they have had, on average, these durations:
3.1) Sprint Planning: 2 hours
3.2) Daily Scrum: 10 ~ 15 min
3.3) Sprint Review: 45 min
3.4) Sprint Retrospective: 30 ~ 45 min
4. In each event, and due to the remote component, we use Miro and Google Meet as work tools.
The result has been very positive, both for the clients and the teams. Clients have seen their initiative gradually become a reality, and teams are constantly appreciating the freedom they have to work.
Apply Scrum in Latin America, next steps
In Castor, constant learning and using what we have learned is our culture, a culture of experimentation. For that reason, the following steps will be:
Seek the simplification of the implementation process (applying the Lean principle of waste elimination)
Adapt the Scrum framework to each initiative according to the needs that arise so that the generation of value for the client and well-being for the team occurs incrementally.
Understand that what has worked so far may not work in the next initiative.
The cover image was taken from: Technology vector created by vectorjuice – www.freepik.com
We invite you to follow us on our social networks: LinkedIn, Twitter y Facebook.
