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

When talking about projects in the Agile methodology, you most often imagine an IT team of creative, open-to-change specialists who are developing the software part of some major functionality.

Leaving aside many BUTs, in general, the Agile philosophy (and I can’t bring myself to say it any other way) has shown quite good results in terms of organizing teams in other, IT-related areas.

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

This is where the difficulties arise that create problems in the understandable mechanical part. By the way, the understandable part is implemented using pure Waterfall and there is no need to change it. The only question is in strengthening the second part with more suitable tools.

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 didn't succeed”, it was decided to take this part of the project into a separate approach. Agile immediately suggested itself.

The task is quite simple:

1. Assess the current level of Agile maturity in the team (and it exists, because even unintentionally the team somehow adheres to some principles).

2. Define the target state (and this does not necessarily mean 100% adherence to frameworks).

3. Formulate measures for moving from the current state to the target one.

For the absolute Agile maturity of the team, we chose — full understanding and following the 12 Agile principles. And how to understand that the team understands and follows them — we 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 own maturity assessment metrics. And I even have these metrics. But purely for research reasons, it was decided to come up with them myself, taking into account the specifics of Occupational Health and Safety projects (and there are specifics, so the idea of using universal metrics seemed wrong).

The assessment was conducted through observation of standard team meetings + interviews. Great focus was given not only to compliance with ritual algorithms, but also to indirect signs: non-verbal signs, intonations, poses, which often contradicted what the Customer, team and users said. Because there are correct answers, and there are honest ones.

With our sleeves rolled up and generative AI at our side, we created 5 metrics for each of the 12 Agile principles, each one building on the previous ones and demonstrating a higher level of maturity.

After polishing the metrics with a file together with the Occupational Safety experts, an assessment matrix emerged that described the current state of the team quite well from a practical point of view. Of course, there were many dissatisfied questions on their part, but these questions should be attributed more to the unwillingness to admit that the team is “not up to par” (although it shouldn’t). In fairness, a couple of metrics were still reformulated to be more practical.

The color scheme is three-color: green – the metric is met; blue – the metric is not met, but is being quickly implemented; red – the metric is not met and implementation will take more than 2 weeks.

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

It's worth noting here that there's no need to aim for 5. The target boundary is set by the team. And it doesn't have a goal of becoming the most true agile team in the world, so that everyone else will envy it.

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

Long-term events are another matter. They are also organizational, but, as usual, there is a nuance – in this case, it is not enough to implement events, they need to be value-growth within the team.

To sum it up, the first thing that caught my attention was that the teams tried to conduct Scrum rituals, but regardless of the name, all rituals always turned into planning. This is not critical, but it is a fact, and we need to work with it.

This will take time, because the subconscious desire to always plan is deeply rooted in those who have known only one approach to project management throughout their entire professional career. Just as a diesel locomotive cannot be stopped by the command “Stop, one, two”, so habitual approaches change over months, and even years. How – through the curve of changes, and the details have already been described many times on the Internet – I will not repeat myself.

Second, no matter how you look at it, you can't do anything without support from management for the principles. This is written in every other article about Agile. Simple, clear, but not everyone follows this rule. And then no one understands why the culture hasn't taken root in the company.

Third, if the team does not share and publicly support the Agile culture, all the memorized frameworks are worthless. All work turns into repetition of correct actions without understanding the benefit, which means the team does not know what brings them added value and what does not.

Fourth. Individual elements of Agile help to build the process well (for example, focusing on the Customer and users through interviews and demos speeds up work on the project), but there is a nuance here.

There must be a tangible result of these process changes. The benefit must either be seen in the indicators or touched in the form of some results. That is, if you came to a new workshop with the replication of Occupational Safety approaches and all you have achieved is changed the line manager's way of thinking and this is not reflected in the results, then you have achieved nothing. Because his way of thinking has most likely changed only in words.

And finally, the fifth. In the described case, this was observed, but in order to warn all the curious – Agile is good in projects with a high degree 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 chaos.

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