Accelerate the process of developing complex projects. Without chaos and nerves

In practice, we often encounter the fact that the project manager wants to speed up the development process - he is not satisfied with the speed of delivery of new functionality. As a rule, such clients need complex products such as hospital management systems, trading systems, banking systems, remote banking systems.

In such cases, you can connect a new team of specialists, establish processes in an existing one, or combine both. Consider the pros and cons of each approach. Immediately make a reservation that the article discusses the development of large and complex projects (more than 10,000 hours).

Why it is impossible to immediately connect new specialists

Often the easiest and most obvious way to increase development speed is to connect new specialists or a team. It seems to the project manager that it is possible to accelerate the speed of delivery of business-value to the end users. In practice, this is not always the case, especially when the processes in the project require processing. We give one example from our practice.

It was necessary to connect two teams to an existing developing project. The project has been developed for more than 4 years and contains a large number of subsystems (more than 20) with their own common mechanisms and services. Full regression required the participation of 5-7 QA engineers and about 4-6 working days. When entering the project and when the teams reached the required level of problem solving, the following difficulties were encountered:
')

• One part of the system source code was under the control of the version control system svn, the other git. SVN was previously very popular, but is not suitable for large team projects and frequent concurrent changes. Therefore, before switching to git, part of the time was lost on the merge, editing conflicts and other operations related to branching into svn.
• For the deployment of the environment was outdated instruction, so the teams collected all sorts of pitfalls of this system, and the first tasks could be started only in 3-4 days.
• Key analysts, technical specialists were busy preparing the release, so it was impossible to quickly obtain clarifying information on new tasks. Task setting was very high level. This significantly slowed down the implementation of tasks.
• The workflow of tasks was difficult, at first the teams “stumbled” how to deal with the task during its life cycle.
• At first, the client wanted to do only with the help of his QA-engineers, but they didn’t manage to check the new functionality fully and in due time, connected development teams, due to heavy load. So I had to work with overtime.
• Code review was conducted according to the principles and criteria established on the draft. The criteria have not been documented. Therefore, extra time was spent on correcting comments.

The result of the above nuances are:

• additional time costs that could be spent on solving business problems
• slow development of the entire system
• either overtime.

Consider how to avoid this situation.

Process analysis

Before connecting new specialists, it’s worth finding out how the team’s work is organized - it is necessary to find and eliminate “narrow” places. Usually PM deals with this issue, as he is responsible for the project, and it is he who wants to spend less effort on tracking the processes.

Removing bottlenecks moves the project forward. For example, the time for entering a project of a new specialist or a team of specialists is reduced, the team’s involvement in the project increases, the cost per hour is reduced due to the correct implementation of the tasks the first time. If you remove all the bottlenecks, the project manager will get as fast growth in development speed as current practices and the context of the project allow. In general, all of this is good.

Analysis of “bottlenecks” is possible from two sides: from the top management / expert and from the team. Let us consider each option separately.



Third-party experts. In this approach, the work process is analyzed by either an external team of external experts, or a project manager together with a team leader. With the latter, it’s not a fact that it will turn out - it’s important that they can drop all the nuances of the project, otherwise the analysis will be meaningless.

An important condition is the support of the project management and readiness for changes.

Accordingly, the expert is immersed in the project and analyzes in detail the documentation, source code, database structure, production process (from analytics to release). Gradually, the work looks like this:

1. We consider the entire chain of work on the project from start to finish. The time of each process is measured.
2. Build a gantt chart. The expert looks at what processes are going on in parallel, which one after another.
3. The expert thinks how to make each process more productive and less expensive. As a rule, the expert intuitively understands in what places the greatest difficulties arise and begins to promote them for possible modernization.

Advantages of this approach:

• The work is analyzed by a person who does not participate in the project. He has a straightforward look at the processes, therefore, he can find those problems that are not visible to team members.
• The expert, as an authority, is able to convince the team to accept changes in the processes. Teams that have been working on the project for a long time do not strive for innovations. For them, this is a big stress, as they will have to relearn again. Moreover, such a reaction goes even to those changes that will help work more efficiently.
• Rapid implementation of solutions - from 2-15 days. It all depends on the global changes and bureaucracy within the organization.
• The project team adopts the experience of third-party experts. In the future, it will help to customize the processes.

Minuses:

• Experts need to spend a lot of time to understand the intricacies. The team can study the history of the project for the day, while the expert needs at least a week and a half.
  What to do about it : set analysis goals with the project manager / team leader. Give the expert all the “introductory” project, do not hide the details.
  
  If the client is so loyal that he is ready to analyze the project iteratively, you need to take the opportunity and agree to such conditions. Subsequently, it will be possible to correct the direction of the analysis after each iteration, focusing only on the necessary one.
• Some team members may not agree with the decision. Subsequently, they can sabotage the project, poorly implement the agreement, and this badly affects the overall mood of the team.
  
  What to do with it : discuss each decision with the team, and not just put them before the fact.
  
  Ideal: the expert analyzes the processes independently and then discusses them with key people on the project. If there are contradictions - they discuss them. So there will be a mass of people loyal to the changes that will affect other members of the team. You can convince the most ardent skeptics.

From the team . This approach can be called a retrospective, which is an integral part of the scrum. The process looks like this:

• The whole project team is going to
• One of the participants takes on the role of facilitator (scrum-master). He ensures that the conversation goes in a constructive way.
• The team discusses their approaches to work. All aspects are considered: processes, writing code, setting tasks, etc. Then there are the pros and cons.
• On a general vote, they agree on changes: the pluses must be fixed, the minuses eliminated.
• After 3-4 weeks the process is repeated. The team looks at the results, and if everyone is happy with everything, then the work continues.

Important conditions:

1. Management support of any changes and innovations.
2. Team cohesion and focus on improvement.

If the company's culture does not encourage initiative, innovation, then a retrospective is not the best way to recycle processes. Team members will not go beyond their "swamp".

Advantages of the approach:

• Involvement of each participant in the discussion of the project.
• The ability to identify all the positive aspects of the project and, if necessary, form them into a sample (best practice).
• Team members exchange experiences with each other.
• The gradual solution of problems, ranging from those that most slow down the team and the project, ending with small improvements.

Minuses:

• There is a risk that only minor problems will be solved, and all the key ones will remain intact.
  What to do with it : PM, timblid and the facilitator should, through authority, influence their opinions on the team. Their task is to draw attention to important issues at the discussion stage.
• For major changes that require a lot of effort, additional time is required for approval with management. It is not a fact that the management will agree with the innovations.
  What to do with it : to defend one's point of view before the leadership is the only solution.
• If there is no permanent training in the team (conferences, exchange of experience, trainings), then most likely the solutions achieved will be outdated and not so effective.
  What to do with it : constantly share experiences. To participate in specialized conferences, meetings, internal trainings. If we are talking about a large company, then demo days will be a good option. At such events, teams show what results they have achieved in their work.

In most cases, you can get by adapting and improving the processes described above. Even if initially it is clear that it is really possible to complete the project on schedule by only attracting new specialists / teams, we strongly recommend that you try the steps above.

If, after eliminating the “bottlenecks”, the project manager believes that capacity has not reached the required level, then new teams can be connected.

Preparing infrastructure for new teams

At this stage, it is worth carrying out preparatory work that will reduce the duration and cost of development, will help to save the nerve cells of the developers. Consider what should be the conditions:

1. Tasks for the new team should be detailed. Each of them can be started without waiting - there is no dependence on current or future tasks. Outlines the responsibilities of each team.
   If this is not the case , then most of the new team will stand idle or engage in secondary tasks that have the least impact on the value of the product.
2. The architecture of the project is “correct”, i.e. divided into modules, subsystems, common components.
   
   If it does not , then connect the new command will not work. Developers will be running the current team leader, but a person can effectively manage no more than 7-9 people. Timlid will be torn, and some team members will be idle until they are given tasks.
   
   If there is no possibility to single out isolated sections of the project code, but we need to move forward, then we can try to get around this restriction. It is necessary to divide the project into several parts through refactoring.
   
   Another option is, after immersing two or three people in a project, to devote ever larger business functions to developing a new team. So the teams will develop the project in isolation from each other, and at the expense of the new team leader (the person who has plunged into subtleties) will reduce the burden on the main team leader.
3. Work processes in the project are described in detail. For example, there is a workflow task, the task execution in the version control system is shown (practice shows that not all have standard GitFlow), the interaction between project participants is described.
   If this is not , then chaos will be created on the project. In this case, the project manager will be engaged only in “manual”, emergency management.
4. Common components and modules have up-to-date, understandable documentation. There are unit and integration tests of the main parts. There is a clear description of the architecture of the whole project, general mechanisms, as well as instructions on how to use them. If the above does not exist yet, then it is necessary to add such tasks to the technical debt pool to correct the situation.
   
   If this is not the case , then the risk of doing double work increases. Poor quality or duplicate source code will be written. In the future, this will lead to more costly project support. As a rule, the connection of a new command implies the possible connection of several more commands. Accordingly, the time spent will be scaled by a multiple of the number of teams.
5. The rules of writing code are fixed - convention code, scripts for updating the database structure - migration, general principles of mandatory code review. Despite the strong similarity, surely each project has its own characteristics.
   If this is not the case , then the complexity and cost of further supporting the project will multiply.

The above conditions allow you to connect new teams most effectively. The time it takes the team to enter the project is noticeably reduced. The same thing happens with the effort to support and develop the project.

How we connected an extra team to the project

We had a case when the project had to urgently speed up the development process. Until the next major version is put into commercial operation, it remains 2-3 months. The project itself was a complex system that was developed by one team for 3-4 years.
First of all, we plunged into the context of the project itself. The result was the following picture of the bottlenecks of the project:

1. There is no single exact information on how features should be implemented. The list of tasks, bugs, improvements is outdated.
2. There is no continuous Integration, and development is conducted in two branches.
3. The product testing process is not debugged. For example, QA-engineers can find bugs that have already been fixed, which leads to additional labor costs.
4. The base of test cases was in its infancy. Individual QA engineers began writing case studies for themselves. Because of this, no one could give a definite assessment of the quality of the product and the possible risks with the release of the new version.
5. The process of work, from setting to approval by the customer, is not documented. It was impossible to predict the exact composition of the functions of the release, as well as other less significant points.

After analysis, we created a plan to eliminate the points described above. Of course, the team did not immediately agree with the changes, but with the support of management and the development of clear deadlines, we were able to persuade each team member.

We coordinated our actions with the key persons of the project: PM, team leader, lead analyst. Together, these three people represent a single command center on the customer’s side. They further promote solutions and control their implementation in practice. Without such a management team, it is impossible to coordinate the actions of more than three teams.

As a result, the following processes were implemented / optimized:

1. They built communications between all members of the product team - developers, analysts, and testing specialists.
2. They documented critical and complex functions for more transparent testing, elimination of defects, resolution of disputable situations, and subsequent work planning.
3. Optimized development processes. Adopted WorkFlow and GitFlow project. They helped set up Continuous Integration and run AutoTests automatically.
4. Increased the speed of assembly of test stands twice.
5. Organized the process of proper testing. Implemented regression testing at the end of each iteration.
6. Implemented an iteration planning process.
7. Conducted load testing.

According to the results of the first iteration, we have prepared the infrastructure for connecting a new team. In parallel with this, two of our developers connected to the current team to dive into the code base. Then one of them became the team leader of the new team. At the second iteration, two teams achieved the following results:

• Putting into commercial operation after 3 months.
• 70% of bugs fixed
• Four serious features are implemented.
• Optimized and increased by 8 times the download speed of some pages
• Accurate information about the quality of the entire product has been obtained.
• Built roadmap iterations

I believe that one of the most important achievements of this project is the joy of the client. He transparently represented the state of the project at any time, and the obligations to the business were fulfilled in full and on time.

Conclusion

There are two main ways to increase the speed of project development: eliminate bottlenecks and increase production capacity. In the first case, you can get 30-40% increase in the speed of development, in the second 70-80%. Additional teams do not give double performance gains, since more time is spent on interaction between several teams.

Key success factors for the expansion of development teams are:

• preparatory work,
• streamlined processes
• the leader or member of the project team who would promote and control the activities of the teams,
• single command control center.

The project, which we described earlier, is currently working on 3 teams (one old and two new). The number of tasks performed increased by 1.9 times .