Agile in a functional project. Organization of work on IT rails

When you talk about projects in the Agile methodology, you most often represent an IT team of creative, open-to-change specialists who are engaged in the development of the software part of some large functionality.

Omitting the many BUTs, in general, the Agile philosophy (and there is no other way to say the language) has shown quite good results from the point of view of organizing teams in other, near IT directions.

And the question arose, whether it is possible to put this approach on a clear, consistent and obvious project in the field of labor protection. It would seem, why? And then, in addition to the clear and obvious part, there is completely unpredictable and multifaceted work with the Customer, users and experts.

It is here that complications arise that create problems in the understandable mechanical part. By the way, the clear part is implemented by pure Waterfall and there is no need to change it. It is only a question of strengthening the second part with the most suitable instruments.

Since the human brain of product users is capable of generating a huge number of unique ideas and turning them into endless reasons “Why we failed”, it was decided to take this part of the project a separate approach. Agile immediately suggested this.

The task is quite simple:

1. Assess the current level of Agile maturity in the team (and it is there, because even unintentionally, the team follows some principles in one way or another).

2. Determine the target state (and this is not necessarily 100% compliance with frameworks).

3. Formulate measures to move from the current state to the target state.

The absolute Agile maturity of the team was chosen – full understanding and observance of 12 Agile principles. And how to understand that the team understands and follows them – you need some indicators, evaluation metrics, to which everyone can clearly answer either Yes or No.

There are several companies in Russia that have already developed their maturity assessment metrics. And I have these metrics. But it was decided to come up with them on our own solely for research reasons, taking into account the specifics of the Occupational Safety and Health projects (and especially there are, so the idea of ​​using universal metrics seemed wrong).

Evaluation was conducted through supervision of standard team meetings + interviews. At the same time, great focus was paid not only to the observance of ritual algorithms, but also to indirect signs: non-verbal signs, intonations, postures that contradicted what the Customer, the team and users said. Because there are correct and honest answers.

After rolling up their sleeves and enlisting the help of generative AI, 5 metrics were created for each of the 12 Agile principles, each of which complemented the previous ones and demonstrated a higher level of maturity.

After polishing the metrics with a file together with the experts of the Labor Protection, an evaluation matrix appeared, which, from a practical point of view, described the current state of the team quite well. Of course, there were many unsatisfied questions from their side, but these questions should be attributed more to the reluctance to admit that the team is “not up to the mark” (although it shouldn’t be). To be fair, a couple of metrics were reformulated to be more practical.

Three-color gamut: green — the metric is fulfilled; blue – the metric is not implemented, but is quickly implemented; red – the metric is not met and it takes more than 2 weeks to use.

The current rating was 2 points out of 5. The potential for rapid growth is up to 3.7 points.

Here it is worth noting that it is not necessary to strive for 5. The target limit is set by the team. And it does not have a goal to become the most true-agile team in the world, so that everyone else is jealous of it.

If we talk about quick measures, they are all organizational and implemented instantly. You just take and do.

Long-term measures are another matter. They are also organizational, but, as always, there is a nuance — in this case, it is not enough to introduce measures, they need to be nurtured within the team.

In summary, the first thing that stuck was that teams tried to do Scrum rituals, but regardless of the name, all the rituals always turned into planning. This is not critical, but it is a fact, and it is necessary to work with it.

It will take time, because the subconscious desire to always plan is strongly ingrained in those who have known only one approach to project management throughout their professional activities. Just as a diesel locomotive cannot be stopped with the command “Stop, once, two”, so the usual approaches change over months, or even years. How – due to the curve of changes, and the details have already been described many times on the Internet – will not be repeated.

The second is that no matter how cool it is, without the support of the principles from the management, you will get nowhere. This is spelled out in every second article about Agile. Simple, understandable, but not everyone follows this rule. And then no one understands why the culture in the company has not taken root.

Third, if the team does not share and publicly support the Agile culture, all the fancy frameworks are worthless. All work turns into repeating the right actions without understanding the benefit, so the team does not know what brings them added value, and what does not.

The fourth. Certain elements of Agile help to build the process well (for example, focus on the Customer and users through interviews and demos accelerate work on the project), but there is a nuance here.

There should be a tangible result of these process changes. You need to either see the benefit in the indicators or feel it in the form of some results. That is, if you came to a new workshop with the replication of Labor Safety approaches and all that you achieved – you changed the line manager’s way of thinking and this is not reflected in the results – then you have not achieved anything. Because his way of thinking changed most likely only in words.

And, finally, the fifth. In the described case, this was followed, but to warn everyone who is interested – Agile is good in projects with a high percentage of uncertainty. There is no need to try to make clear and consistent tasks flexible, because it is fashionable, stylish, youthful. This will only add to the chaos.

But it’s not bad to single out murky tasks for Agile, and turn the whole project into a hybrid, if you understand what you’re doing. Because if there is demand and creativity, any approach can be improved. And even in the most proven and reliable methodologies, it is worth periodically asking the question: “How can it be done differently?”.