A large company is most often characterized by well-established and complex processes, lack of freedom of choice to one degree or another, and a strict corporate culture. Given these conditions, how can you maintain interest among developers, if a team is accustomed to working in its own way? Before we started, no one had digitalized production processes on such a scale, and now we can choose the best ways to solve these tasks.

The team's collaboration has great significance for the product. They don't develop a product separately — one person working on a bit of interface and another on the backend, and so on — but all together, with a clear understanding of their own roles and strengths. Our developers take regular work trips to the factory to see who uses our product and how, to interview the users and experience their daily work first-hand.

This is not a conveyor. Now, it is very important for people to understand the meaning of what they are doing. And the task of the product owner is to constantly inform the team about what is being done and why, how we know what is needed, what we investigated and how, and also what feedback was collected from users. It's great when the team's maturity reaches a certain level, and employees start asking their own questions: Are you sure that it is really necessary? How do we measure it? Let's look at the statistics. Is it really used?

I cannot say that everything for us is now divided into "before" and "after" Agile. It seems to me that at first the world was quite reasonable, and everyone understood why they were doing what they were doing. And then projects started getting bigger and more cumbersome, and people began to be responsible for separate tasks.

As a result, everyone tried to fulfill their part of a large task as quickly as possible, and at the same time it did not matter to them what role this part played in the final product, or what would happen next. The overall meaning became increasingly blurred. There is something wrong if your work, which occupies most of your life, does not make sense.

However, any area that becomes completely familiar starts to bore you. We must understand that a huge source of energy can be derived from interest. For example, I witnessed the following situation: we once chose the week before New Year (when, frankly, work efficiency tends to zero) and organized a hackaweek. As a result, the development teams implemented projects that they themselves have long wanted, but that were not a priority in their backlogs: voice recognition and biometrics.

That is something that is cool, but does not always make money in the short term. This approach perfectly motivates and inspires and also helps to find a lot of interesting ideas that are hidden behind the routine work. As for production, in particular, now our teams have no trivial tasks at all. Our work is intense.

The reliability of the equipment ensures the continuity of production. Its operation must be constantly monitored: walkrounds and inspections, maintenance and repair. To solve these problems, we are creating a system of several web applications and one mobile application. This system will track and manage mobile rounds and repairs (or mobile MRO). We provide employees with smartphones. They connect to the Bluetooth beacons that are located on the plant's territory: people pass by, and the sensor registers their presence in this place. Then the information is displayed on a map through the interface for the shift supervisor. The employee receives tasks, records defects, consults with colleagues — all this takes place in the mobile application.

And what will it look like on this particular phone? And what should be done to prevent the phone from discharging during the Siberian cold? How to ensure its connection with the sensor? How to make it comfortable to use at sub-zero temperatures? There are a lot of questions.

Today, the largest (12+ employees) team of my function is engaged in developing this product: a product owner, a scrum master, a development team, a designer and a project manager who have joined us recently. Also, representatives from the production site, at least the owner of the process, actively cooperate with us. It is difficult to succeed without an interdisciplinary team. This is Agile in work at a plant.

Communication is aligned horizontally.

As concerns the scrum, then I would say that seven employees in a team is the upper limit. For example, a one-hour meeting with 10+ participants is usually a terrible waste of time. But motivated people do not like to waste time. Therefore, one team is divided into two or three parts. Our target is to work on any product in such a way that small teams can simultaneously develop a product without interfering with each other.

Another example is the system for issuing electronic work permits. This product is also being developed by a cross-functional team with identical roles. There are a number of high-risk jobs at any production facility, including hot work, gas hazardous work, work at heights, etc. Before starting them, you need to get a work permit which indicates the list of team members, types of work, as well as all approvals. This is usually a 4–5 sheet paper document.

We have created a convenient web application for issuing an electronic work permit with the possibility of obtaining all the approvals online. This significantly speeds up all processes, both for engineering and technical personnel, and for members of the working teams.

In addition, while simplifying the process, we eliminated the need to issue a paper work permit for repairs. For this, servicing schedules for the safe execution of such work have been developed and approved. This is a good example of a digital lean approach: together with the process participants, we broke it down into stages and eliminated unnecessary procedures before digitalization.

During the interaction, changes occur within the Agile team. Before launching a project, we always strive to analyze the current situation and understand why we need a digital product.

Initially, end users (the employees for whom we develop our products) did not readily answer our questions about “how” and “why,” but  confidently told us which functionality they thought was necessary. But their vision was not always right. Now we are working together: we reveal the weak points of the processes, test the applications, and get what brings real benefits.

Some scientists claim that our brain functions with maximum efficiency for only two hours a day. Developers can write code for a maximum of six hours. And there are various approaches that help strengthen the development team. For example, pair programming. Two developers sit at the same computer and write the same code, while discussing and improving it.

At first glance, this model may seem inefficient in terms of employee costs. However, by working together they improve their knowledge and teach each other. As a result, we can get real full stack engineers. We don't work like that at the moment. For now.

Scrum masters constantly use various techniques. Take, for example, the retrospective after a sprint. If it is boring and tedious, the team loses interest in such a meeting. A good scrum master first analyzes the sprint, and then tries to design a retrospective for it and how best to conduct it. There may be associations and metaphors, as well as fictional situations that reflect what is happening in the team.

There are many psychological aspects in the work of scrum teams: the performance of the team is constantly changing, and all internal interactions influence the process greatly. There are all sorts of good scrum masters. But all the bad ones say: your stand up will take place at ten, and the retrospective will be held on Fridays at four o'clock. See you.

Of course, the formal "setting" of rituals is also part of their work, but if they do only that, then they will have free time and will be assigned to additional project work to the detriment of their main role. And it is very difficult for scrum masters to prove their usefulness, especially in traditional organizational models.

People and interactions are more important than processes and tools. What do you think is more important: always complete all the fields in Jira or discuss and clarify the task to solve it correctly? We and our teams do not take any unnecessary steps, such as preparing technical requirements six months before the start of work, instead we immediately discuss with the users what they need.

Of course, it is important to document all requirements, but the focus is shifted: we first communicate and try to understand each other, and then we create a product and prepare documentation for it. By the way, in the updated Agile manifest, this recommendation now sounds like this: teamwork and responsibility are more important than processes and tools.

There is a performance indicator called velocity. We can use it to analyze the changes in team performance, and the team itself can accurately assess when it finishes a task. So, it is also a planning tool.

This is an effective indicator, but it is not as simple as it seems. To make it really work, teams must be able to properly decompose tasks and use story points. In addition, the team itself must remain stable in its composition. For the most part, this task relates to the activities of scrum masters.
 

• Team motivation is one of the ways to improve performance. I am sure that for our teams the key to motivation lies in creating interest: field research and interaction with users, search for something new and non-standard use cases. And if the current tasks do not provide this, it is always important for us to find a way to inspire and encourage the team.
• Working climate. Scrum implies the presence of a scrum master, who not only ensures communication, but also creates a special microclimate and regularly improves the team's activities through proper "rituals" with a deep understanding of group dynamics. Simple activities such as, for example, a daily stand-up, can have a huge impact on the success of the whole team or its failure.

Aren't you convinced? Then just remember how many times your team performed the wrong task or solved the wrong problem. And then they had to re-engineer everything. If you have not spoken to the team throughout the day, you may not even know about it. In such situations, 10 minutes of proper communication will help you save a lot of time in the future.