Article

Scrum application errors and hits in an engineering environment - Part 2

Mining

From crushing to transport, solutions with great experience of the processes

Project Data

However great the advantages of using agile methodology, some contexts require special attention to certain details and may require some adaptations to the methodology. This is the case of engineering. And, although the bibliography on Scrum, DevOps and other methods grows every day, materials reporting eventual problems and ways to avoid them are still almost non-existent.

In my experience acting as Scrum Master in a team of engineers by ihm Stefanini, success came, but in the midst of many problems, attempts at solutions and consequent learning. In the first part of this article, which you can read here, we address the main problems faced, such as the difficulty in making estimates and the uncertainties in tasks and processes. In this second part, we will talk about the tools and resources that can help in your solution.

Planning Poker

Planning Poker is the most popular way to make estimates within agile methodologies. It can be "played" using different parameters, but the most classic way uses an adapted Fibonacci sequence: the advantage of this method comes from the fact that the difference between the numbers increases as larger values are used in the sequence (the difference between 8 and 13 is 5, greater than the difference between 1 and 2, which is 1). Commission, it is possible to better map the increase in the number of uncertainties that occurs when we estimate too large tasks.

Each team member receives a deck of cards with the values of the adapted sequence (1, 2, 3, 5, 8, 13, 20, 40, 100). During the Sprint Planning meeting, the staggered tasks are discussed individually and each team member gives an estimate using one of the cards, which must be played simultaneously so that there is no influence from each other. After this, the members who presented the highest and lowest estimate justify their options and everyone votes again, until there is consensus, so it is not just a matter of majority.

As we had already reported in the first part of this article, we began to estimate tasks by effort, which was measured in points. We took a task well known to everyone and assigned it the value of 1, precisely to serve as a comparison parameter. With this, the following tasks are estimated in a relative way to the one chosen as a basis.

Later, we modified the base values by choosing well known tasks to represent the 2 and the 5, to give a slightly more extensive comparison capability. It is easier to estimate an 8 or a 13 by comparing the 5 instead of the 1.

Using Planning Poker we are faced with several situations. The group discussion ended up bringing aspects that had not been thought of initially, and even data that had not been raised before. Everyone had an opinion about the task, even those who would not perform it, which allowed us to visit the problem from other perspectives. What happened was that often the people who brought a certain task were surprised, with its value revealing itself either above or below what had been initially estimated by them.

In cases where the task proved to be more complex than anticipated, this new assessment led to a rethinking of whether it should really be brought to this Sprint, as well as its scope and its uncertainties. In many cases the tasks were redefined, divided into two or more parts, in order to prioritize those that were better defined and therefore easier to perform.

In other cases, the presentation of a task led members to collaborate: when talking about a facility for which a survey would be necessary, for example, it was discovered that this survey had already been done for another activity, which reduced the effort initially estimated. The team thus began to exchange data, information and tips so that it would hardly happen without Planning Poker, which contributed to reduce the time and effort of some activities.

The use of Planning Poker allowed us to increase the assertiveness of the estimates made by 56% as we were able to follow ScrumWise. This was fundamental to the planning, as well as increasing the team's confidence in the sense that the members felt they would be able to execute what had been proposed for each Sprint almost in its entirety.

Adaptation of the backlog

When using Scrum, the most traditional is to put in the backlog everything that is in the requirement analysis and therefore needs to be validated. As the project develops, it is possible to change this backlog, defining new priorities and neglecting or even discarding some items. This is perfectly possible for common, small projects that start from scratch. When you have large-scale projects involving plants that are already in operation, however, things can be different.

In the beginning, we put everything that had to be done in the backlog, which generated a huge number of items, and started bringing the items to the Sprints each week. This, however, didn't work very well: the large number of items made the process confusing, the burndown (percentage of the project missing to be done) didn't seem to evolve as we expected, and we've been doing the same documents for different areas (making for example interconnection diagrams of identical drives for different areas like crushing, metallurgy and others). In view of this, we decided to change the way we did it, since we realized that we were not reusing the work already done.

We started to create only the macro items, like "interconnecting diagrams", for example, and instead of creating several sub-items for all the small diagrams and various activities that needed to be done, which would make the thing confusing, we created only the specific items for that Sprint, what was being worked on at the time and what would be voted on in Planning Poker to be worked on in the next sprint. Things started to flow better, with clearer tasks and more engagement from the team.

Context and Challenges

The lesson left is that I need to set up and manage the backlog so that it effectively helps and facilitates the work, which is after all the function of the tool. As much as the recommendation was to include all the items, which might seem more complete and organized, we found in practice that this did not help, since items from different sprints sometimes got mixed up and ended up confusing. For large scale projects and those where you don't have the whole scope defined at first, it may be better to go on defining the backlog as you execute the project, which even saves hours of typing to try to define all the tasks.

Refinement of the backlog

The refinement of the backlog is nothing more than a transfer of tasks between the Product Owner and each one of the Development Team members, making a follow-up to know how is the progress of the activities and above all scheduling the tasks to be brought in the next Sprint Planning meeting. This helps to give more clarity in what needs to be done and in the continuity of each activity. In addition, we observe other long-term gains.

What happened was that, as the work was being developed with Planning Poker, the adaptation and Refinement of the Backlog, the latter was no longer so necessary, as the team members themselves began to get a glimpse of the activities to be carried out in the next Sprint. Few tasks were questioned and discussed during the Planning meetings, without reducing the team members' assertiveness regarding the estimates of the tasks to be performed. In other words, the team became more and more autonomous and less dependent on Scrum Master as the Product Owner.

Solutions Used and Equipment Provided

In the long run, the team saw itself more united and approached a process of self-management, which was excellent for reducing stress and preserving human relations, since there was no need for the leader to seek out each one and remind them of their tasks day after day, which eventually led to misunderstandings, forgetfulness and failures. The fact that each one had in mind what was necessary to do allowed to execute the work in a more dynamic way, delivering more value in less time. This was undoubtedly one of the greatest gains observed by the use of Scrum.

Experts

Control Engineer and Expert in Agile Methodologies

Leonardo Pankiewicz

Awards

No items found.

Scrum application errors and hits in an engineering environment - Part 2

June 3, 2020

published by

Leonardo Pankiewicz

Control Engineer and Expert in Agile Methodologies

However great the advantages of using agile methodology, some contexts require special attention to certain details and may require some adaptations to the methodology. This is the case of engineering. And, although the bibliography on Scrum, DevOps and other methods grows every day, materials reporting eventual problems and ways to avoid them are still almost non-existent.

In my experience acting as Scrum Master in a team of engineers by ihm Stefanini, success came, but in the midst of many problems, attempts at solutions and consequent learning. In the first part of this article, which you can read here, we address the main problems faced, such as the difficulty in making estimates and the uncertainties in tasks and processes. In this second part, we will talk about the tools and resources that can help in your solution.

Planning Poker

Planning Poker is the most popular way to make estimates within agile methodologies. It can be "played" using different parameters, but the most classic way uses an adapted Fibonacci sequence: the advantage of this method comes from the fact that the difference between the numbers increases as larger values are used in the sequence (the difference between 8 and 13 is 5, greater than the difference between 1 and 2, which is 1). Commission, it is possible to better map the increase in the number of uncertainties that occurs when we estimate too large tasks.

Each team member receives a deck of cards with the values of the adapted sequence (1, 2, 3, 5, 8, 13, 20, 40, 100). During the Sprint Planning meeting, the staggered tasks are discussed individually and each team member gives an estimate using one of the cards, which must be played simultaneously so that there is no influence from each other. After this, the members who presented the highest and lowest estimate justify their options and everyone votes again, until there is consensus, so it is not just a matter of majority.

As we had already reported in the first part of this article, we began to estimate tasks by effort, which was measured in points. We took a task well known to everyone and assigned it the value of 1, precisely to serve as a comparison parameter. With this, the following tasks are estimated in a relative way to the one chosen as a basis.

Later, we modified the base values by choosing well known tasks to represent the 2 and the 5, to give a slightly more extensive comparison capability. It is easier to estimate an 8 or a 13 by comparing the 5 instead of the 1.

Using Planning Poker we are faced with several situations. The group discussion ended up bringing aspects that had not been thought of initially, and even data that had not been raised before. Everyone had an opinion about the task, even those who would not perform it, which allowed us to visit the problem from other perspectives. What happened was that often the people who brought a certain task were surprised, with its value revealing itself either above or below what had been initially estimated by them.

In cases where the task proved to be more complex than anticipated, this new assessment led to a rethinking of whether it should really be brought to this Sprint, as well as its scope and its uncertainties. In many cases the tasks were redefined, divided into two or more parts, in order to prioritize those that were better defined and therefore easier to perform.

In other cases, the presentation of a task led members to collaborate: when talking about a facility for which a survey would be necessary, for example, it was discovered that this survey had already been done for another activity, which reduced the effort initially estimated. The team thus began to exchange data, information and tips so that it would hardly happen without Planning Poker, which contributed to reduce the time and effort of some activities.

The use of Planning Poker allowed us to increase the assertiveness of the estimates made by 56% as we were able to follow ScrumWise. This was fundamental to the planning, as well as increasing the team's confidence in the sense that the members felt they would be able to execute what had been proposed for each Sprint almost in its entirety.

Adaptation of the backlog

When using Scrum, the most traditional is to put in the backlog everything that is in the requirement analysis and therefore needs to be validated. As the project develops, it is possible to change this backlog, defining new priorities and neglecting or even discarding some items. This is perfectly possible for common, small projects that start from scratch. When you have large-scale projects involving plants that are already in operation, however, things can be different.

In the beginning, we put everything that had to be done in the backlog, which generated a huge number of items, and started bringing the items to the Sprints each week. This, however, didn't work very well: the large number of items made the process confusing, the burndown (percentage of the project missing to be done) didn't seem to evolve as we expected, and we've been doing the same documents for different areas (making for example interconnection diagrams of identical drives for different areas like crushing, metallurgy and others). In view of this, we decided to change the way we did it, since we realized that we were not reusing the work already done.

We started to create only the macro items, like "interconnecting diagrams", for example, and instead of creating several sub-items for all the small diagrams and various activities that needed to be done, which would make the thing confusing, we created only the specific items for that Sprint, what was being worked on at the time and what would be voted on in Planning Poker to be worked on in the next sprint. Things started to flow better, with clearer tasks and more engagement from the team.

The lesson left is that I need to set up and manage the backlog so that it effectively helps and facilitates the work, which is after all the function of the tool. As much as the recommendation was to include all the items, which might seem more complete and organized, we found in practice that this did not help, since items from different sprints sometimes got mixed up and ended up confusing. For large scale projects and those where you don't have the whole scope defined at first, it may be better to go on defining the backlog as you execute the project, which even saves hours of typing to try to define all the tasks.

Refinement of the backlog

The refinement of the backlog is nothing more than a transfer of tasks between the Product Owner and each one of the Development Team members, making a follow-up to know how is the progress of the activities and above all scheduling the tasks to be brought in the next Sprint Planning meeting. This helps to give more clarity in what needs to be done and in the continuity of each activity. In addition, we observe other long-term gains.

What happened was that, as the work was being developed with Planning Poker, the adaptation and Refinement of the Backlog, the latter was no longer so necessary, as the team members themselves began to get a glimpse of the activities to be carried out in the next Sprint. Few tasks were questioned and discussed during the Planning meetings, without reducing the team members' assertiveness regarding the estimates of the tasks to be performed. In other words, the team became more and more autonomous and less dependent on Scrum Master as the Product Owner.

Cases and Similar Articles

Experts from all areas are available for you!

We know how difficult it is to find efficient tools and appropriate solutions to your problems. Our team is available to help you choose the best solution, based on our experience in the most diverse areas of the industry.

Connect with our team of experts in various areas of industry.
Finding experts
MATRIZ
Av. Cristovam Chiaradia -
670, Buritis Belo Horizonte, Brazil
30.575-815
OUR FACTORY
Rua Gracyra Resse de Gouveia -
120, Betim, Minas Gerais - Brazil
32,689-372
CONTACT
Phone: +55 31 2129 7799
FAX: +55 31 2129 7700
E-mail: comercial@ihm.com.br

© 2019 HMI, All rights reserved
Designed by Dinius
analytics.identify(' {{user.id}} ', { name: '{{user.fullname}}', email: '{{user.email}}' });