Article

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

Mining

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

Project Data

The use of agile methodologies became the "ball of the turn". Scrum, DevOps, Extreme Programming and other methods have gained captive sections in bookstores with thousands of books released and have been the subject of numerous courses and lectures. This scenario led several companies to want to use these methodologies in their processes, but the application of the concepts may not be so simple, requiring adaptations according to the context and type of service.

At IHM Stefanini, I worked as a Scrum Master in a Scrum team formed by engineers, in a project of adaptation of an industrial plant to NR-12 (machine safety standard), for one year. Although we were successful in using the methodology, we also went through problems and challenges that provided a lot of learning, making us rethink how to apply Scrum and the factors to be considered. In this article, I seek to share a little of this knowledge, reporting practical challenges of applying agile methodology to an environment not always conducive. In this first part we will talk about the problems, and in a second part, about tools that can help in their solution, always taking into account that there is no single recipe and that each project has its own difficulties.

The size of teams

Initially, the team was formed in a traditional way, considering factors such as the size of the project, the productivity of each one and the deadline, and we reached the number of 16 people. The tasks were divided in such a way that the same people were responsible for one type of service in all sectors of the work. This made it practically impossible to divide the team in two or perform the same task in two sectors at the same time.

We realised, however, that this was not working very well. The large number of people made the meetings long and sometimes tiring, and it also caused people to be dispersed. A lot of things were not said because of the fear of exposure, and the process became less agile than it could be.

Taking stock of our retrospectives, we came to the conclusion that division into different teams would be necessary. We had to change the way we divided the tasks, to then assemble two teams of eight people, within the recommended by Scrum. The difference in performance was noticed not only in Scrum events and work meetings, but also in the performance of the people themselves. From that change everything started to flow better.

Scrum advocates that the team be as transparent as possible, with all members sharing as much information and opinions as possible. This happens more naturally when the team gets to know each other and the members develop a relationship of trust between them. In addition, small teams hold more dynamic meetings and communicate in a more assertive way, which allows for faster results and contributes to a better climate among the team. The size of teams, as it has become clear to us, cannot be easily increased.

Lack of faith in agile methodology

Scrum is a methodology and not a technique. Therefore, the execution of an engineering project tends to be basically the same from a technical point of view: what changes is not so much what is done, but how the activities are prioritized and how the deliveries are made. However, even if there is no difference from a technical point of view, Scrum requires a paradigm shift.

The human being is already resistant to change by nature. In the engineering environment, this resistance is even greater, since professionals have been accustomed to performing activities in a certain way for many years. And it is necessary to be aware of this, since many times the reluctance is not a matter of ignorance or lack of training, but only the will of the professional to maintain the status quo.

The point is that Scrum requires a very strong sense of teamwork and this is only possible when the members have the feeling that they are all in the same boat. As a tough professional doesn't identify with Scrum's values, he ends up not applying the method in the right way, which can hurt the team a lot. The other members of the team end up mirroring themselves in those who don't want to change the way they work, and start not caring about using Scrum.

When we started the project, we could see that there were some employees who were really resistant to the methodology. When, for some reason, the results did not come out as expected, these people blamed Scrum and exposed their disbelief on him, sometimes contaminating the whole group, since there were many who, although not exactly resistant, were still in the process of adaptation. It became evident that although success depended on a great commitment from everyone, a small negative effort from someone who disbelieved could bring everything down.

As the project progressed, the amount of work decreased and it was necessary to deallocate professionals from the project. They were reallocated to other projects (which did not necessarily use agile methodology) and, as a result, the number of people little engaged with Scrum decreased. The teams' communication started to flow better and, while the results became more evident, even the members who were not totally convinced got excited and began to have faith in the methodology, which greatly facilitated the process.

Number of Product Owners per team

Scrum is a methodology that works a lot with the notion of product: even a software is seen as a product in function of its functionalities and one works to improve it in this sense. The Product Owner, also called P.O., is the collaborator whose function is to have the vision of the product and organize the tasks to be performed by the team seeking to produce all the necessary functionalities.

As in the traditional organization of the company there are technical leaders for each discipline, the team was assembled with two Product Owners. The idea was to divide the tasks so that one of them would be on the electric part and the other on the automation part. We found in practice that this does not work. Scrum works with multidisciplinary teams, and the P.O. must have an overall view of the product within all disciplines. Hosting two P.O.'s in the same team, even for different areas, can lead the product in different directions, to conflicts and conflicting decisions.

Context and Challenges

Estimates of activities

Making estimates is one of the most difficult activities there is. In addition to the estimated values often proving to be faulty and erroneous, they are usually based on units of time (hours, days, months, etc.), which are absolute values. The lack of relative comparison with something really known ends up generating huge disproportions, since the execution time of an activity can vary a lot depending on the task and the employee's experience. In this scenario, an interesting solution may be to estimate the tasks by the effort involved, measuring this effort in points.

In our case, we use planning poker. We take that task that we consider the simplest and best known and assign it the value of one point. From then on, every new task is estimated in a relative way, as multiples of the one-point task. With this the team dramatically increased the ability to select the tasks for each Sprint, improving performance by approximately 57%.

The uncertainties in tasks and processes

When a project is developed from scratch, information related to the plant is more abundant and easier to access. Therefore, the level of blurriness of tasks is relatively small. When dealing with a plant in operation, as it was in our case, with the suitability of the industrial plant to NR-12 standard, things can be much more complicated.

Solutions Used and Equipment Provided

In our process, we had difficulty in accessing various equipment and information. Some of them were used almost constantly and could not have their operation interrupted for us to do the activities, since they would stop the production. Even scheduled stops and combined with the team were relocated according to the need to produce, which made the planning of sprints difficult and delayed development. And the worst: there is no simple solution to these uncertainties.

Something that may help, however, is to consider the blurriness when making the sprint backlog. Tasks that have many uncertainties should not be brought into the sprint. If it is not possible to define it more clearly, it may be worth trying to separate it into parts that are well defined. This has helped us a lot to move forward, although this possibility only occurred to us during the execution of the project. Having this possibility in mind from the beginning can be of great value.

Experts

Control Engineer and Expert in Agile Methodologies

Leonardo Pankiewicz

Awards

No items found.

Whitepapers

No items found.
Connect with our team of experts in various areas of industry.
Finding experts

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

January 25, 2021

published by

Control Engineer and Expert in Agile Methodologies

Leonardo Pankiewicz

The use of agile methodologies became the "ball of the turn". Scrum, DevOps, Extreme Programming and other methods have gained captive sections in bookstores with thousands of books released and have been the subject of numerous courses and lectures. This scenario led several companies to want to use these methodologies in their processes, but the application of the concepts may not be so simple, requiring adaptations according to the context and type of service.

At IHM Stefanini, I worked as a Scrum Master in a Scrum team formed by engineers, in a project of adaptation of an industrial plant to NR-12 (machine safety standard), for one year. Although we were successful in using the methodology, we also went through problems and challenges that provided a lot of learning, making us rethink how to apply Scrum and the factors to be considered. In this article, I seek to share a little of this knowledge, reporting practical challenges of applying agile methodology to an environment not always conducive. In this first part we will talk about the problems, and in a second part, about tools that can help in their solution, always taking into account that there is no single recipe and that each project has its own difficulties.

The size of teams

Initially, the team was formed in a traditional way, considering factors such as the size of the project, the productivity of each one and the deadline, and we reached the number of 16 people. The tasks were divided in such a way that the same people were responsible for one type of service in all sectors of the work. This made it practically impossible to divide the team in two or perform the same task in two sectors at the same time.

We realised, however, that this was not working very well. The large number of people made the meetings long and sometimes tiring, and it also caused people to be dispersed. A lot of things were not said because of the fear of exposure, and the process became less agile than it could be.

Taking stock of our retrospectives, we came to the conclusion that division into different teams would be necessary. We had to change the way we divided the tasks, to then assemble two teams of eight people, within the recommended by Scrum. The difference in performance was noticed not only in Scrum events and work meetings, but also in the performance of the people themselves. From that change everything started to flow better.

Scrum advocates that the team be as transparent as possible, with all members sharing as much information and opinions as possible. This happens more naturally when the team gets to know each other and the members develop a relationship of trust between them. In addition, small teams hold more dynamic meetings and communicate in a more assertive way, which allows for faster results and contributes to a better climate among the team. The size of teams, as it has become clear to us, cannot be easily increased.

Lack of faith in agile methodology

Scrum is a methodology and not a technique. Therefore, the execution of an engineering project tends to be basically the same from a technical point of view: what changes is not so much what is done, but how the activities are prioritized and how the deliveries are made. However, even if there is no difference from a technical point of view, Scrum requires a paradigm shift.

The human being is already resistant to change by nature. In the engineering environment, this resistance is even greater, since professionals have been accustomed to performing activities in a certain way for many years. And it is necessary to be aware of this, since many times the reluctance is not a matter of ignorance or lack of training, but only the will of the professional to maintain the status quo.

The point is that Scrum requires a very strong sense of teamwork and this is only possible when the members have the feeling that they are all in the same boat. As a tough professional doesn't identify with Scrum's values, he ends up not applying the method in the right way, which can hurt the team a lot. The other members of the team end up mirroring themselves in those who don't want to change the way they work, and start not caring about using Scrum.

When we started the project, we could see that there were some employees who were really resistant to the methodology. When, for some reason, the results did not come out as expected, these people blamed Scrum and exposed their disbelief on him, sometimes contaminating the whole group, since there were many who, although not exactly resistant, were still in the process of adaptation. It became evident that although success depended on a great commitment from everyone, a small negative effort from someone who disbelieved could bring everything down.

As the project progressed, the amount of work decreased and it was necessary to deallocate professionals from the project. They were reallocated to other projects (which did not necessarily use agile methodology) and, as a result, the number of people little engaged with Scrum decreased. The teams' communication started to flow better and, while the results became more evident, even the members who were not totally convinced got excited and began to have faith in the methodology, which greatly facilitated the process.

Number of Product Owners per team

Scrum is a methodology that works a lot with the notion of product: even a software is seen as a product in function of its functionalities and one works to improve it in this sense. The Product Owner, also called P.O., is the collaborator whose function is to have the vision of the product and organize the tasks to be performed by the team seeking to produce all the necessary functionalities.

As in the traditional organization of the company there are technical leaders for each discipline, the team was assembled with two Product Owners. The idea was to divide the tasks so that one of them would be on the electric part and the other on the automation part. We found in practice that this does not work. Scrum works with multidisciplinary teams, and the P.O. must have an overall view of the product within all disciplines. Hosting two P.O.'s in the same team, even for different areas, can lead the product in different directions, to conflicts and conflicting decisions.

Estimates of activities

Making estimates is one of the most difficult activities there is. In addition to the estimated values often proving to be faulty and erroneous, they are usually based on units of time (hours, days, months, etc.), which are absolute values. The lack of relative comparison with something really known ends up generating huge disproportions, since the execution time of an activity can vary a lot depending on the task and the employee's experience. In this scenario, an interesting solution may be to estimate the tasks by the effort involved, measuring this effort in points.

In our case, we use planning poker. We take that task that we consider the simplest and best known and assign it the value of one point. From then on, every new task is estimated in a relative way, as multiples of the one-point task. With this the team dramatically increased the ability to select the tasks for each Sprint, improving performance by approximately 57%.

The uncertainties in tasks and processes

When a project is developed from scratch, information related to the plant is more abundant and easier to access. Therefore, the level of blurriness of tasks is relatively small. When dealing with a plant in operation, as it was in our case, with the suitability of the industrial plant to NR-12 standard, things can be much more complicated.

Cases and Similar Articles

Connect with our team of experts in various areas of industry.
Finding experts