How not to go crazy with Scrum? Experience a growing project

Nadezhda Metker, Senior QA, DataArt

I will tell you how to increase the efficiency of the team in a complex project through a flexible approach to development, with which our team has been safely living for the third year. Actually, the real project from the field of health will be an example for me. I think it’s relatively easy to talk about the Scrum and Agile theory, some of the solutions we used may even seem obvious. But I am sure that personal experience and the methods tested in a responsible project can be useful to many.
')
The first thing I’ll talk about is the Feature Demo - the process during which we demonstrate the new functionality of the application within our own team. We are considering exactly how it was made, what worked out particularly well, and where it was possible to do better. After a general review and final approval, the functional can go into production.

Team grows

The project began quite a small team, but in two years it has grown greatly. Appeared Product Owner, which ensures that all requirements are clearly defined by us and meet the desires of the customer, estimates how long it will take to perform new tasks. Two business analysts work directly with him, there is a designer and a webmaster, a backend and front-end teams of four people with their own leads, three testers with me as QA Lead.

As you can see, the team is big, so at first we did not avoid problems with communications. Any general phoning was long-lasting: everyone wanted to speak, someone didn’t like something, or, on the contrary, liked it - they took a lot of time. We understood that we needed to call up, because the whole team should be involved in the development process and know what we are trying to create together. Therefore, they identified people (mostly leads) who are involved in planning and solving global problems of the project, for which this group regularly calls up with the Product Owner.

Project Features

I gently call our project “combed Excel”. Because the system itself consists of a set of Excel files embedded in one application. With it, we consider budgets for researching new drugs.

The project is divided into two parts, one - the Budget Tool (BT) - more dynamic and is 2/3 of our application. Here we enter the parameters and participants of the experiment, in the same place are all the requirements of customers who want to test the drug. The specification is actively filled out, after which the budget is displayed - a specific amount: how much research will cost under certain conditions.

The second part of the project is the Budget Tracking Tool, which mostly contains static information and in fact represents a report on the execution of the plan drawn up by BT.

The peculiarity of the system is the number of internal dependencies. Different parameters refer to each other, their interaction is determined by very long formulas (the fields here allow us to enter up to 5000 characters, although the real formulas are somewhat shorter), and getting lost in such a stream is quite easy. In the first dynamic part it was simpler, the situation with statistics was more complicated. If some feature turns out to be unfinished in BT, information simply does not come to BTT. And while the backend team is looking for what was missed, the QA team has to sit and wait for the news. Then she can repeat the test and re-discover the bug - this happened, the process could even be fascinating, but it took time. We understood that it was necessary to work faster, but we could not get rid of these dependencies.

Planning and timing

It turned out that the initial plans for each release were constantly shifting. We release every three months, immediately after one we plan the next. But due to constant delays, we could not test everything in time.

The customer had a huge number of requirements: they consider budgets - this is money, and a lot depends on each figure. We always treated this with understanding, made concessions and listened to comments. The client, in turn, responded to any of our clarifications very responsibly, carefully checking every change we made.

But due to the large number of requirements and careful consideration of each refinement, we began to be significantly late even at the stage of approval of the specification: the backend team could not deal with the code until it was approved. Then the front-end developers figured out that they missed something in the backend (for example, something that was not mentioned in the specification). At the end of the functional came to us for testing on the eve of the planned release. Thus, we accumulated technical debt, which introduced uncertainty at the stage of preparing a stable version.

Workflow Feature Demo

To begin with, we decided to admit that everyone cannot be equally involved in everything that a team does. But we can divide it into parts with our own tasks. Such a task can be, including the development of a separate feature.

We began to plan the work trying to identify those responsible at the stage of harmonization of requirements. For example, at the start of each sprint, we single out an element of the functional that we will develop. Leads are assigned backend and front-end developers and QA to the team responsible for it, and a separate chat is created for them where leads are added if necessary.

There also come a business analyst who records requirements, and a Product Owner.
As soon as the business analyst wrote the requirements, he sends the specification to this chat, and the other members of this particular team immediately begin to develop. A QA engineer can immediately start writing test cases and making comments at the stage of studying the specification. The process is very active, phoned can be daily.

Having finished the feature, the developer reports that he is ready to show a demo. Then everyone who participated in the development of the feature is going to call. It recalls the specification and shows how it fulfilled the requirements. There is also a mini-testing on some of the most common cases, if everything works, the functionality is sent to full-fledged tests.

Assigned to a small group of QA starts to work morally prepared. He is familiar with the requirements, he knows how the application works, what the developers have done. When the tester is finished, the business analyst shows the result of the work to the customer.

With such small teams, we are developing from start to finish, with one person can participate in several such groups at once. This allows him not to lose sight of the other parts of the big task set before us all. Of course, we also practice daily general calls, but limited their duration to 30 minutes. Only PM can extend a general call if an important conversation has not been completed.

Use Feature Demo

The new approach has allowed us to significantly reduce technical debt and better close new features. In addition, it makes the process of developing each individual functionality transparent to all involved. As for the QA group lead, it is especially valuable for me that testers know well what inaccuracies were made in the specification (if the requirements were formulated suboptimally), where the developers had to redo something. Also during the demonstration of the functional, we come up with a lot of non-standard scenarios for using the program. Given the complexity of our system, this allows us to raise the quality of testing to a new level.

Support Activity

The tight development schedule created a problem to support the application. At the same time, the support of what is already working was crucial for us: the client is very sensitive to the speed of our reaction, as it is necessary to respond to requests from pharmaceutical companies as quickly as possible.

It was very important for the customer to add comments to any cell of our system. The fact is that several people often work with one budget on the client side, and the ability to exchange comments allows people who are responsible for different parts of the budget, which are connected with each other by complex dependencies, to avoid conflict. In fact, they can use the comment system as an internal chat, adjusting formulas and coefficients.

In the same internal comments we asked to write any comments and suggestions regarding our work. According to the comment to the specific cell “The parameters are considered wrong here,” we can easily get to the bottom of the problem.

But, of course, such comments appeared constantly. It was obvious that you need to deal with them urgently, faster than with the new functionality. So there was a need for intermediate releases: it would be strange to respond to comments that we will fix everything in just three months.

First damn lump

First, we asked the business analyst who was responsible for the formulas for internal dependencies to transfer customer comments to Excel. We are well acquainted with him, it was easy to handle the requirements, and at BA it took quite a bit of time. But as the system evolved, comments began to arrive to us in the hundreds, and we simply lost the business analyst - he should be solely involved in sorting and posting comments.

The first stage of automation involved the automatic export of comments to all the same Excel. But for this it was necessary to constantly erase what we have worked. Otherwise, the comments were multiplied so that it would be impossible to understand them. At the same time there was always the danger of erasing something important.

We have screwed a big beautiful blue Report an Error button on each page. When you click on it, our team left a letter. But users still had to wait for the reaction, sometimes an hour, sometimes two, and sometimes even longer. What to do if there are 50 or 100 such letters at once? We didn’t have any individuals who were engaged in supporting the system.

We added an additional function to the button: it not only sent the letter, but also created a priority task for our team in Jira, and the user was notified that the task was taken into account by his comment. However, the problem remained: switching to the support task, we lost in active development.
Then we created a separate support team, allocating half of the backend developer, one front-end developer, and one QA for these tasks. Of course, this is not about concrete people, but about man-hours. That is, the conditional attendant immediately begins to find out what the problem is, whether a bug is actually detected and begins to deal with it. Such a reform allowed us to fix 10–15 problems a week and immediately accumulate them as part of the interim releases as they accumulate.

This provided us with complete control of the customer's comments, allowed us to instantly respond to any request without losing a single letter. At the same time, we constantly keep the customer informed what exactly they are doing. In the end, a happy customer is a guarantee of happiness for our (or your) team.

***
At the level of theory, many things seem simple. But, I think, in your projects you have repeatedly come across the fact that it may take weeks or even months to implement a solution that looks after the fact after the fact. Therefore, I hope that the local experience of our team can be useful, save some of you time and help in planning the next sprint or even the whole project. After all, they sometimes grow seriously, especially if you are doing everything right, and the customer is pleased with you.