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

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

I’ll tell you how we solved them.

As I said, we had 2 troubles:

1. Sprint could linger due to the fault of one task . QA and Dev worked on the same sprint, task scopes were fixed at the beginning of the work, and the whole team heroically rushed to implement it. Sometimes urgent bugs arrived that went to the "master" hotfixes. Sprint tasks 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. Standups were time consuming and of dubious utility . The team grew, stand-ups were carried out on Skype, and in the beginning nothing boded of trouble. We began to suspect 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 tried to fight.

• They reduced stand-ups through the introduction of regulations on humans.
• They reduced the number of those present - only team leader went to stand-ups.
• Tried weekly sprints.
• Reduced the number of tasks in the sprint.

These attempts did not give the expected result. An understanding has come that radical changes cannot be dispensed with.

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

We are a SaaS solution available 24/7. In addition to the part visible to users - 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 updating of the service is ongoing, without stopping.

Going to Kanban

The first large-scale revolution happened when we realized: "Scrum is not suitable for us."
We decided to switch to Kanban. Of course, we were not Toyota and did not begin to implement the full implementation. Therefore, "our kanban" will be different from "your kanban."

Sprints and team work

In a nutshell about our version:

• We considered sprint (a completed piece of functionality) as the unit of work.
• A team for the task was collected depending on the load and the necessary skills. One team usually had 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, tasks were carried out through the addition to Jira.

In this case, the team had to do a sprint from start to finish. This also applied to the testing phase: the same people who worked on the sprint corrected the errors.

Result.

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

Standups

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

Result.

• Standups became like standups and we again began to fit into the standard 10-15 minutes.

Thus, we were able to solve critical problems.

But ... the whole iceberg began to emerge from behind the island!

After switching to Kanban, we got 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 the team had to retell information.
• One QA could have 2-3 parallel sprints with different teams. I had to switch: remember the features of the sprint and constantly re-deploy the code on test environments.
• QA were not fully involved in the process of working on sprints. Often the task reached them at the end of the sprint and the requirements were studied after the development was completed.
• Teams gathered for the project and their composition often changed. A team of two developers could work on 3 sprints simultaneously: 2 sprints on the 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 struggled with new challenges. We tried different approaches and filled a lot of cones.

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

Division into teams, new stand-ups, introduction of Fireteam

We analyzed the processes from the inception of the idea to the deployment of the finished implementation in prod. We looked at how agile methodologies work in other companies. We realized that our approaches to the development process were not so bad.

No need to break a working system, you need to fix 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 a “near two-week” scope of work for the team.

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

What can be improved. Often we miss the mark and sprints are a little delayed. The time to work on some sprints is initially difficult to evaluate (for example, a lot of refactoring). We have to solve this problem.

Division into teams

We split one large 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 rosters or add the required expertise to the team. BA participates in the team, but at the same time can lead 2-3 projects.


Although we still rest with one team)

At the same time, the whole team works on one project from the beginning to its completion. One project can consist of several sprints.

What is the plus.

• Teams are in the same room. Before that, everyone was sitting in departments.
• The team is included in the work on the project from beginning to end, which reduces the bus-factor.
• Team members are present at all events: retro, stand-ups, plenings. All employees are up to date with current tasks.
• The team no longer works on other people's sprints. Now everything is native.

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

Team work

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

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

What can be improved. Ideally, a team should have only one sprint in work. But for now, an ideal world is not our world.

Fireteam

Each team is elected for one week. This command responds to all external irritants: calls from other departments, abnormal behavior of the service, hotfixes. We call this team “Fireteam”.

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

• Refactor.
• Complete the sprint task.
• Write documentation.
• Carry out a knowledge transfer with other teams.

Disadvantage. In the fireteam week, the life of the team is very eventful. All departments love and know these people in person, especially technical support. You have to constantly switch between different tasks: debiting, reading logs, sawing urgent tasks and putting out all the fires. All this must be done simultaneously.

Standups

We introduced 2 types of stand-ups:

1. Team They involved a team that works on the project.
2. Are common. They are held once a week, leads from each team participate in them.

What is the plus.

• The team is informed about the state of sprint.
• Employees are aware of what other teams are doing.
• Stand-ups do not turn into "boring activities for reading from a piece of paper some sets of numbers." All present understand what is at stake. It has become easier to detect problem areas at work.
• Standups take 5-10 minutes.

Disadvantage. The team still carries information to the team.

Total

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

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

Well, we are working on.