How we broke the development into teams (and forgot about endless sprints and useless stand-ups)

I am PM in the UniSender mailing service . 6 years ago I came as a programmer, and now I am responsible for the interaction between product teams. Previously, our development consisted of one distributed team and we had 2 troubles. But not fools and roads, but sprint delays and boring stand-ups for half an hour.



I'll tell you how we solved them.



As I said, we had 2 troubles:

')

1. Sprint could be delayed by the fault of one task . QA and Dev worked on one sprint, the tasks skoup was fixed at the beginning of the work, and the whole team rushed to implement it heroically. Sometimes urgent bugs arrived that went to the “master” with hotfixes. The tasks in the sprint could be quite voluminous. When some tasks were ready for release, others were still in development. As a result, the team could delay the sprint due to one task.
2. Stand-ups took a lot of time and had dubious usefulness . The team grew, stand-ups were carried out via Skype, and in the beginning nothing foreshadowed trouble. We began to suspect that something was wrong when the stand-ups began to stretch for 20-30 minutes. Those present did not always understand what other team members were doing.

For some time we lived with these problems, then we tried to fight.

• Reduced stand-ups through the introduction of regulations per person.
• They reduced the number of attendees - only timlid walked to stand-ups.
• Tried weekly sprints.
• Reduced the number of tasks in the sprint.

These attempts did not give the expected result. It is understood that radical changes cannot be done.



Here it is necessary to say a few words about the product.



We are a SaaS solution available 24/7. In addition to the visible part of the user - the GUI - we also have a large layer of system logic that works regardless of the time of day or the political situation in the country. That is, the development and update of the service is continuous, without stopping.

Go to Kanban

The first large-scale revolution happened when we realized: “Scrum does not suit us.”

We decided to switch to Kanban. Of course, we are not Toyota and did not implement the full implementation. Therefore, “our kanban” will be different from “your kanban”.

Sprints and team work

Briefly about our version:

• We considered the unit of work to be a sprint (a completed piece of functionality).
• The team for the task was collected depending on the load and the necessary skills. In one team, there were usually up to 3 developers and 1 QA. There were no permanent teams.
• The number of simultaneous sprints has become more than one.
• There was no physical board and other attributes of Kanban, the tasks were led through additions to Jira.

In this case, the team had to do the sprint from beginning to end. This also applied to the testing phase: errors were corrected by the same people who worked on the sprint.



Result.

• With the delay of large tasks did not suffer the rest, the development of which is completed.
• The number of problems during deployments has decreased - in one sprint there are fewer mixed tasks.

Stand-ups

Stand-ups were transformed - they were visited by one representative from each team that worked on a separate sprint.



Result.

• The stand-ups became similar to the stand-ups and we again began to keep within the reference 10-15 minutes.

Thus, we were able to solve critical problems.

But ... because of the island, the whole iceberg began to swim!

After the transition to Kanban, we had a dedicated frontend team, and there were more employees in the backend and product team. The interaction between the departments became more complicated - several teams could work on one project.



We solved some problems, but new ones came to the fore:

• Not everyone participated in stand-ups - often they had to retell information to the team.
• One QA could have 2-3 parallel sprints with different teams. I had to switch: remember the features of the sprint and constantly redeploy code on test environments.
• QA were not fully involved in the sprint process. Often the task reached them at the end of the sprint and the requirements were studied after the development was completed.
• The teams gathered under the project and their composition often changed. A team of two developers could work on 3 sprints at the same time: 2 sprints per test plus 1 current sprint.
• It was difficult to estimate development time. It is not clear how long the previous unfinished sprint will eat.

For some time we lived by the new rules and fought new challenges. We tried different approaches and filled many cones.



In the end, we again began to suspect that something was going wrong. New revolution to be.

Team division, new stand-ups, Fireteam introduction

We analyzed the processes from the inception of ideas to the deployment of ready-made implementation in prod. We looked at how the agile methodology works in other companies. We realized that our approaches to the development process were not so bad.

You do not need to break a working system, you need to correct the moments that cause pain.

This is what we changed during the development process.

Sprints

We still operated on the concept of "sprint". Sprint is an “about two week” scooter for the team.



What is the plus. The code does not "rotten" and gets on the prod without significant delays. If the team is going to do a sprint in 2 weeks - you need to try to tighten it up to a month.



What can be improved. Often “miss the mark” with the assessment and the sprints are a bit slow. Time to work on some sprints is initially difficult to estimate (for example, a large refactoring). This problem we have to solve.

Division into teams

We broke one big team into several smaller teams. Each of them includes 2-3 developers and one dedicated QA. Now the teams are stable and do not change from project to project. Sometimes people switch between teams to optimize the line-ups or add the required expertise to the team. BA participates in the work of the team, but at the same time can lead 2-3 projects.





Although the rest is still one team)



In this case, the whole team is working on one project from the beginning to its completion. One project may consist of several sprints.



What is the plus.

• The teams are in the same room. Before that, everyone sat in the departments.
• The team is involved in the project from the beginning to the end, which reduces the bus-factor.
• Team members are present at all events: retro, stand-ups, plenings. All employees are aware of current tasks.
• The team is no longer working on other people's sprints. Now everything is your own.

What can be improved. I would like to fully introduce BA in the team. This is problematic because the VA usually starts working before the rest of the team.

Team work

A team in work may have no more than two sprints: “the one that is still on the test” and “the new one that we will be nagging”. As a rule, after the end of development, all as they are released, they start work on a new sprint.



What is the plus. The work of the team has become more predictable, everyone is familiar with the code and can support the sprint during testing. Participants began to switch between tasks less frequently, and the switching process itself is now faster.



What can be improved. Ideally, the team should have only one sprint at work. But while the ideal world is not our world.

Fireteam

Each team for one week becomes elected. This command responds to all external stimuli: appeals from other departments, abnormal service behavior, hot fixes. We call this team "Fireteam".



What is the plus. Fireteam week does not count the team in the sprint time. In the intervals between extinguishing fires, employees can focus on their tasks:

• Refactorize.
• Finish the sprint task.
• Write documentation.
• Conduct knowledge transfer with other teams.

Disadvantage. In fireteam-week, the life of the team is very eventful. All departments, especially tech support, love and know these people by sight. You have to constantly switch between different tasks: debug, read logs, cut urgent tasks and extinguish all fires. Do all this at the same time.

Stand-ups

We introduced 2 types of stand-ups:

1. Team They are involved in a team that works on the project.
2. Are common. They take place once a week, with leads from each team.

What is the plus.

• The team is informed about the status of the sprint.
• Employees are aware of what other teams are doing.
• Stand-ups do not turn into “boring reading events with pieces of numbers”. All present understand what is at stake. It became easier to detect problem areas in the work.
• Stand-ups take 5-10 minutes.

Disadvantage. Information to the team still brings timlid.

Total

Thus, gradually changing the process, we solved most of the current problems:

• We have assembled stable teams of 2-3 developers and QA. Each team in the work now no more than 2 sprints, the participants do not work on foreign projects.
• There was a command that processes messages from other departments, responds to the anomalous behavior of the service and hotfixes. Other commands to these tasks are not distracted.
• Now the company has 2 types of stand-ups: command and general. All employees are informed about the status of the sprint, and stand-up takes a reference 5-10 minutes.

Well, we work on.