As we reached idyll, working without managers. Part 2. Secret Room

Hello to you, dear reader! In the previous article, I talked about how 28 developers were able to build a workflow in which there is no manager role. We continue to work with pleasure and release complex features one by one. Soon we will have sleepless nights before the release of the release. And then the most enjoyable stage is the technical sprint and the retro release, as well as the planning activities for the next release.

Today I will talk about activities that provide maximum transparency of the workflow and allow developers not to fall out of the events occurring in the whole company and in other teams in particular. Want to build quality processes and work with pleasure? Welcome under the cut!



Before continuing to share the experience of organizing the development process, I want to clarify a couple of questions regarding the specifics of the company. The business structure of the company implies the development of an in-house product and the subsequent sale of the solution to customers. The company has a marketing department, a sales department and other divisions besides the development department. This largely determines the possibility of interaction directly with the product analyst, who is the supplier of the basic requirements for the product. In the usual sense, we do not have a client-customer from outside. We ourselves develop the requirements, we develop and sell ourselves. Traditional grocery company.
')
Nevertheless, I insist that the experience of organizing processes between development teams and developers within teams can be used as an example for building processes in your company, be it a developer of outsourced solutions or a product company. Experience shows that the classic “book by book” scraps are not applicable to the realities of the development of real products, and that is why the specificity of the product determines the specifics of the processes.

Let me remind you that 28 developers are currently working in our company. What is applicable for 7 teams (four developers per team) may become inappropriate when working with 15 teams and vice versa. At the same time, the development of a high-quality architecture of the code base, and the building of high-quality processes implies the freedom to scale without high costs. In addition, in most companies, the development department of a single product line consists of just 5-7 teams (20-30 people). Such a department, as a rule, has the freedom to make independent architectural decisions, the freedom to organize internal interactions and the building of processes.


So, 5-7 teams, developing your own product. How to build a process without a manager? In the first part of the article I already talked about such activities as grooming, planning and retro teams. Next, we will focus on activities that allow you to synchronize the work of several teams and move in one direction.


Sample project in Renga Structure

Command synchronization

Our sprint length is ten working days. There are two days between sprints for demo, retro and planning. If there are two days between sprints for retro, demo and planning, this does not mean that no code is written on these two days. This means that these days of activity go with a higher priority than writing code. These two days are a good buffer for depreciating underestimations / overestimates of the sprint. Team synchronization - activity not tied to the sprint schedule. This synchronization is held every Friday at the same time after lunch. All developers, testers and product analysts are present on the synchronization. In a general sense, command synchronization is a stand-up, where one developer comes from each team and tells what team was done, which areas of the code were affected and how it might affect other teams.

Often in companies synchronization is carried out in the form of a team of team leaders. This approach has a minus, which I discussed in detail in a previous article: one person can forget, not pay attention to many details that are important to others. Thus, synchronization of timblids saves team time, but significantly inferior to the quality of communications. It is understood that after such a meeting, the team leader will tell everyone to his team about the progress of the other teams, which, again, will spend the time of each team. Here there is a minus "deaf phone" when transferring knowledge from the team leader. Thus, the team remains, as it were, “aside” from the work of other teams, communicating only through the team lead. As a result, interest decreases, the gap in understanding of the overall development movement of the entire department increases. Saving team time can not cover the disadvantages of detachment from the general direction of development and communication between developers.

After each performance, teams are usually asked clarifying questions from any of those present. If someone understands that the answer to a question develops into a long and distant discussion, he / she can interrupt the dialogue and offer to transfer it to another time. Thus, the synchronization of seven teams lasts no more than forty minutes and allows all developers to remain in the flow of product development by other teams.

Another important aspect that is discussed on synchronization is the actualization of development dates. As a rule, once every two weeks, teams publicly evaluate their chances of “getting there in time for release”. During the discussion, it becomes clear which team is not in time, and which team performs tasks on time. In addition, due to the presence of product analysts, development priorities can be changed. For example, one team does not have time to release the functionality to the release. The other team is also not in time, but the analyst understands that the business value of the first team is higher, so the second team postpones the functionality planned for release and helps the first team finish the work on time. It is important that each member of the team hears the arguments and arguments that led to such a decision. I am sure that in most companies where such a decision would be made to synchronize timblids, teams would have a clear misunderstanding of why someone's features are more important, and someone else's not. Here you can ask all the questions and there are no obscure moments left.

The result of such synchronization is the awareness and acceptance by each participant of the development process of the actual deadlines and development priorities. Also, each participant understands the current changes in different parts of the application code, thus avoiding misunderstandings when merzhah, version conflicts and other unexpected changes during the operation of the application.


Sample project in Renga Architecture

Demo

Another activity that allows you to stay abreast of changes in the product is no longer at the code level, but at the user level - a demo. The demo is held the day after the sprint is completed. The demo is organized by product analysts for all product stakeholders - investors, the marketing department, company executives and internal development departments. Leading demo analytics teams, each of which represents the product functionality developed, tested and merged into the main development branch. Each demo script is checked on the eve of the show for compliance with the requirements (Definition of done). It is important to understand that unfinished features or scripts are never shown on the demo. It is understood that any scenario shown in the demo can be very likely used by the end user of the product without any errors.

In the process of showing the script, as a rule, the main motivation to develop this feature is explained, the main user scenarios of the work are shown. After completion of the script, all present can ask questions. As a rule, the stakeholders clarify the subtleties of the work of the features, the marketing department - the applicability of the features for the client and some features of implementation, express suggestions for improvement. More than once in the process of showing, from the marketing department there were requests for the refinement of features, which were added to the development plan for the next sprints.

The result of the demo is the publication of the next increment of product functionality for all interested parties. Due to the presence of developers, testers, and marketing staff on the demo, a lot of things become clear, there is an exchange of up-to-date information on product product scenarios. Such transparency of product knowledge minimizes differences in expectations from a particular functionality and allows you to quickly respond to any suggestions.

Retro release

One of the longest and labor-intensive activities is the retro release. This activity lasts about 5 hours with a lunch break. Anyone can become a leading retro, but, as a rule, they are led by evangelicals. Retro release is divided into several semantic blocks-tasks performed by each team. As a result of each task, a certain artifact appears, for example, a success map, a disappointment map, a map of useful and disturbing moments during the release. Each such artifact is presented, as a rule, by different team members. According to the result of the retro, each team takes into the work positive practices of the work of other teams and tries to find a solution to the negative aspects in the working methods of other teams. Each retro release is designed to increase the transparency of the practices used within each team, and to help teams discuss different approaches to solving problems arising during the development process.

Perhaps the retro release is the most interesting and useful event of all the activities used in the company. In the short term, all teams exchange positive and negative experiences, help each other to find solutions to the tasks of organizing the workflow, assessing tasks, and composing descriptions for features.

Chamber of Secrets

The secret room is our demo room in which all the activities described are carried out. It has everything you need - flip charts, tables by the number of teams, boards and a projector. There are a lot of constructive references to Harry Potter in our development department. We have Sirius, Ravenclaw, and even the Order of Phoenix, but more on that in the following articles.


There are a lot of references to Harry Potter in our development department.

Instead of conclusion

In the comments to the previous article, the idea was expressed that in such a process “without managers” the meetings take too much time for developers. I allowed myself to appreciate the distractions on activity.

In pure time, it’s about 0.4 hours for stand-ups, 5 hours for planning, 2 hours for retro, 2 hours for demo. 28 * 0.4 * 10 + 5 * 28 + 2 * 28 + 2 * 28 = 364 man-hours per 12 days for 28 people or 1 hour per day for one person . I did not take into account activities like code-review, architectural discussions, because I consider them to be an inseparable part of the development process.

Share how much time you have (or your teams) integrally spent on activity other than development? In my opinion, 1 hour a day “to talk” is a very small fee for spreading knowledge, team reflection and increasing transparency.

Anatoly Osokin, Lead Software Engineer, Renga Software.