About 3 years ago, we started a path towards Intraway’s Scrum Implementation to use of Agile methodologies. This road was initiated by different teams with the strong support of the company, as it was the right way to improve our performance Intraway’s-Scrum-Implementation
We spent a good deal of time learning and reading books, as well as through an external company that audited and contributed to improving our operation.
In the first stage, we used Kanban as preparation for later using Scrum.
First, we started using post-its to manage our board, but this approach lasted very little. The reason? A team distributed in different countries.
Then we started using Trello, the well-known Kanban online tool, but we quickly moved to much more professional tools, like JIRA and its Scrum plugin.
Initially, we had many inconveniences in our meetings, whether they were daily meetings, reviews or retrospectives. These meetings could last for hours. I still remember the moments when the Scrum Master had to bring us to the meetings like cattle, and we all asked when we were actually going to get to work. Luckily, we have overcome those issues. At the time, we didn’t realize that the problem was not Scrum. The real problem was that we did not focus on the goals of the meetings. In fact, we were not clear about the goal of the meetings.
Want to learn more? Keep on reading Some advice on Scrum methodology.
Improving Intraway’s Scrum Implementation Development
Retrospective meetings generated a space that did not previously exist, where each team member was able to express what they thought was not working well or could be improved. It is incredible that after taking a lot of time with the methodology we are always finding something to improve in the retrospective. This is truly continuous learning.
In this time, we greatly improved estimation of user stories, as well as our commitment to performing the stories that we had planned within the sprint. At first, we tried to make more user stories than we could finally finish. I guess all the teams have been through this.
When we started, teams were divided by programming languages, as they had been previously. There was a PHP team, a Java team, and a C++ team. We quickly realized this was counterproductive: To perform a new feature, the Product Owner had to speak with three different teams, and some level of coordination was required between all of the teams. We learned from this experience and integrated the three teams, avoiding team synchronization overhead and enabling the delivery of a feature in only one sprint.
One of the points that I want to highlight is the much-talked resistance to Scrum implementation. In our case, it was almost none. I imagine that this can happen due to the tendency of software development companies to apply some kind of Agile methodology.
One of the main obstacles in this learning process was the high turnover of team members. This generates an inconvenience at the metrics level (the team velocity) and at teamwork level. However, I understand that this is all a part of being in the IT field.
Another issue has to do with the measurement of team velocity and the predictability of the user stories that can be made during the sprint. It seems like a simple task. According to any Scrum book, we should calculate the average story points made in the last N sprints and no more. Simple, right? But the problem is that we have a team of members that are too specialized in the tasks they perform. Many user stories focused on developments that only required testing and one developer group. This makes the number of user stories included in the sprint to be carefully selected, verifying who should participate in each user story. Another point is that this super specialization generates greater coordination and selection of team members.
I would like to mention a very good book for anyone who is working with Scrum, or starting to work with Scrum, entitled “Succeeding With Agile: Software Development Using Scrum” by Mike Cohn.
You can also browse for more information on Agile Methodologies in this very site.