How to rebuild project processes and make development more efficient

One of the golden rules of product development was formulated by Jeff Bezos: “You can feed an effective team with two pizzas.” Which means that it consists of 7-8 people. The size of the team directly affects the effectiveness of each participant and the project as a whole. When a team grows out of 10 people, you need to create a separate group with separate management.

Over the past year or two, the team of one of our major projects has been constantly growing. As a result, in some processes the costs began to grow while the work results were not so great.

What exactly went wrong

With the growth of people, the volume of communications within the team grew. On the one hand, it is logical – a bigger team means people need to communicate more. But when we estimated the time spent on communications, the numbers were several times higher than planned.

True Engineering has an unspoken metric: at least 85% of the time employees work on some productive result, 15% can be devoted to something passing (planning, rallies, retrospectives, synchronization calls). As long as project management and other supporting processes fit into 15% of the working time, everything is in order. As soon as this figure starts to grow, questions arise.

The problem arose especially acutely when we saw that the quality of team interaction at least did not change. On the contrary, important details began to fall out of focus, and priorities had to be clarified. We were in a vicious circle - a lot of time was being spent on hyper-management, less and less resources was being left for high-quality work which in turn leads to additional communications.

This was the final point for the decision to change. Moreover, we decided to completely redo the processes within the project. We relied on the experience of other teams, where we managed to build the right system from scratch. First, assess where the bulk of time goes.

Step #1: Focus on Priorities

The number of tasks that a team of 10 people can have in a sprint and one of a 30-people team are two completely different figures. An indivisible team sprint contained up to 1.5 hundred tasks. At the same time, the tasks belonged to different development streams with their own grade of priorities. Managing such a backlog "visually" is very difficult which causes losing control.

Solution: we divided the team in TFS into 3 areas with their own two-week backlogs each containing 20-50 tasks per stream. Every “micro-team” has its local priorities, development dynamics. At the same time, the planning and release management processes remained indivisible.

Step #2: Communication in the team - remove unnecessary

At the start of the project daily meetings took about 15 minutes a day. A couple of years later, the team tracked up to 30 working hours a day.

The most annoying thing is that most of the time each of the team members read out a report on the work and plans for the day. I.e., for 30 man-hours a day, everyone listens to each other, even if this has nothing to do with their immediate tasks. And if a problem sparks a discussion, every minute of such a meeting becomes too expensive for the project as a whole.

Solution: One day, the dailies were turned into written reports for each team member. We formalized the structure of reports so that they contain key information. Every morning, the PM starts by going through these materials, identifying problem areas and bottlenecks, and dealing with them in a separate manner. Discussion of problems goes to local chats only with direct participants.

And the discussion of some topics on the project was transferred to MS Teams chats - more on that later.

Step #3: communication channels - we leave only the necessary ones

Over the years of project development, the team has built several parallel communication channels: Slack, Skype, our Teams, the customer's Teams, email. Information rained down on the manager and the team from every direction, and it became more and more difficult to separate important issues from secondary ones.

In addition, notifications constantly distracted people who participated in chats out of necessity. This brought chaos to communications and created a constant information noise for the participants.

Solution: reduced internal communications to two Teams and mail, plus the customer's Teams in the background.

We formalized the rules for working with these channels. This allows each team member to understand which topic belongs to which channel and how to respond to it. At the same time, we are negotiating with the customer to bring communications in his Teams to the same format: chats should be specific, solve a concise problem and contain only the right participants.

The main idea of ​​change is that any communication, external or internal, must be managed.

Step #4: general project information - accessible and uniform for everyone

Analysts and managers spent too much time to find information on the project in several disparate sources. To understand what is happening in the project (what the agreed estimate was, which status a task has, what the deadlines are, which features go into the release, etc.), one had to search a handful of sources, or ask those who own the information. The majority followed the second path, so that calls on the same issues became more and more frequent, and knowledge holders were distracted more and more often.

This led to another problem - different specialists owned different information, so a single unchanging picture did not work. This created disorientation and could lead to conflicts.

Solution: created a unified coordinate system based on the TFS tracker. It now holds all (!) information on the project, team capacity, vacations and days off, assessments and statuses, the project knowledge base, sprints, releases, and so on. It is strictly forbidden to use XSL-files and other third-party documents.

Now any project participant can log into TFS and see the status of tasks and priorities. Information is in one place, and it is read linearly, remains relevant and can always be trusted.

What do we end up with

1. Incomparably less time is spent on group calls, chats and other interactions. And labor efficiency has increased - on average, people have freed up two hours a day, which they now also devote to productive activities.

2. Finding the right information has become easier, and it is guaranteed to be reliable. To do this, we use both standard TFS views and a variety of process monitoring charts. No need to make appointments for holders of valuable knowledge. If you need to update something, you have to update only one resource. The customer can also see the current status of the project at any time.

3. The team is not distracted by dozens of notifications on all possible topics, it is easier for people to concentrate, everyone works exclusively with the tracker and does not think where to write to deal with this or that issue.

Of course, in these processes, sometimes you have to call and clarify something. But these are one-time cases, and they are not of such a mass character. We plan to close the lack of personal communication by introducing regular one-to-one meetings and team retrospectives.