Renga development team: how we reached the idyll, working without managers

7 teams and no manager - do you think this is possible? We built a process in which we show 1-2 features from the team on each demo, we carry out retro teams, retro releases and at the same time get real pleasure from work. Want to organize your work in the same way? Then welcome under cat.



We, the company Renga Software , are developing software products for designing buildings and structures in accordance with information modeling technology ( BIM ). We go sprints, release releases every 3-4 months. System users every week becomes more and more. The product is quite young, so backlog is full of important, and most importantly, interesting tasks. But how in a short time to develop a product that will be used to design homes, kindergartens, hospitals and theaters?




“Let the application fall better than the designed building”
- Joke of the architect

So, our development department consists of 28 developers, 3 product analysts and 6 testers. Each team includes product analyst, tester and four developers. We follow all mandatory scram activities - sprints, planning, retro, demo, daily stand-ups. Moreover, we use some chips from SAFe (Scaled Agile Framework) to synchronize the work of several teams - weekly command synchronization, retro release every 3-4 months. We also have an unusual activity - we call it grooming, where we parse a business feature along with the whole team and analyst and get a list of understandable requirements for the feature and readiness criteria (DoDs).

To grumble or not to grumble, that is the question

In the classic scram, as you know, there is an activity called “Planning”, on which the product owner, the development team, the testers, and other stakeholders are necessarily present. In the planning process, a sprint target, a composition of features or story (user story) for development is developed. The presence of the product owner is a prerequisite for successful planning, because only he can answer non-standard questions about the feature that come to mind experienced (and not only) developers with awareness of the purpose of the feature and in the process of decomposing it into tasks.

Here lies the first pitfall of the classic scram - how to make possible the presence of the product on the planning of 7 teams in one day? Maybe there is a possibility of desynchronization of teams and planning on different days? It turns out that the product owner will spend 7 days out of 14 allocated for the sprint on the planning. In addition, in this desynchronization it becomes incomprehensible how to conduct a demo, on which you want to show the integral result of the work of all teams?

We solved this problem. Planning is done only by the team. On planning, the team deals with decomposition of pre-prepared and loaded features, for which readiness criteria have already been formed. Thus, in planning, everyone in a team (if he / she listened attentively and actively participated in grooming) knows what needs to be done in a particular feature. This saves the time of the product owner and allows you to synchronize the planning of teams and carry them out in one day.

The peculiarity of our scram lies precisely in the conduct of special activities - grooming features. They have a product owner, the whole team that will develop the feature, testers, technical writers and all interested. The product tells what the feature will be about, how it should look and the main usage scenarios. In the process of grooming, anyone present can ask any questions regarding the functional, use cases, boundary conditions. As a rule, despite the fact that features from the product owner are prepared, there are always 2-3 key questions from those present, which can affect the analytics of the feature and affect its final version. In addition, on issues that are not critical for analytics, developers can decide for themselves how to implement this or that functionality. The duration of the activity depends on the complexity of the features and lasts from 30 minutes to 5 hours.



The knowledge base is formed, including, of such wall entries.

Thus, it turns out quite expensive activity on labor costs. But this is the only minus of the grooming, the advantages of which are obvious and largely outweigh the time spent on discussion. I have already mentioned some advantages, we will go over them again:

1. There is no need to attend to product analytics on the planning of all teams, which allows you to synchronize planning. Grooming is held on the eve of the sprint, where work is planned on the feature, at a time convenient for all participants.
2. The whole team is immersed in the process of discussing the functionality and subtleties of the features work. This avoids the well-known discrepancy between the expectations and the fact of the implemented functionality. In addition, a collective discussion reveals inaccuracies and ambiguities in the initially formulated feature, reveals analytics errors due to unexpected questions from those present (and there are almost always such questions).
3. At the output, a complete and understandable list of requirements and usage scenarios is formed. Developers will check the code for the main points of the functional, and testers will write integration tests, knowing the system behavior scenarios.

The managers themselves

Development sprints last ten working days. Between sprints there is a day for the demo and a retro and a day for planning the next sprint. As a result, sprints are not tied to the days of the week, but only to the absolute number of working days.

Each team has a team chat in telegrams, which allows you to quickly discuss all issues of development, organization of activities, as well as issues of politics and religion. Carrying out retro, daily stand-ups, planning, as a rule, is initiated by different developers, who have time to write in the chat. Responsible for conducting activity can be any developer who wishes. We assign the time of activity, we are going to the team and discuss. As a rule, each team has an experienced team leader, who also has good soft skills, which allows not to divert the discussion aside. Although, in each team, soft skills are well developed among most developers, which allows us to constructively discuss issues and minimize the time spent on non-constructive discussions. The results of most discussions are records on a marker board, the photos of which are carefully stored in the chat archives and in the cloud storage for history.

Planning

Planning tasks are estimated in abstract working hours, which we optimistically consider as many as five in a working day. That is, if the assessment task takes a day, we estimate it at five o'clock. Use for estimates poker planning. If the estimates differ, as a rule, this suggests that one of the participants knows more than others. Thus, the understanding of the context of the task is aligned and, as a result, the revaluation of the task.

Why we do not use to evaluate parrots or story points? Over time, we came to the conclusion that it is important for the team to correctly evaluate the speed of development in order to make plausible promises to develop features in the next release. The main criticism of the evaluation in hours is the dependence on the experience of the developer and the degree of his acquaintance with the code segment. At the same time, story points allow you to estimate the amount of work without reference to a specific developer. But what happens if in the next sprint the task in, for example, 3 story points is taken by a novice? He will spend 3 days on it, while the experienced will manage it in 1 day. Thus, the sprint skoup will no longer be tied to the time frame of the sprint. We are in the process of planning exactly the time for the task. It happens that an experienced developer estimates the task at two o'clock, and an inexperienced at five o'clock. After discussion, the final assessment is likely to be five hours. Thus, we potentially overestimate the assessment of the task, but are protected from non-compliance with the obligations to develop a sprint skoupa.

In addition to decomposed tasks, a feature is designated a bugpool, which is also evaluated, including by the tester. Its meaning is to indicate the degree of uncertainty for potential bugs in the feature. It seems that uncertainty can always be taken as 30-50%. However, experience shows that uncertainty depends on the context of the task itself. For example, bugs in a task related to an atypical use of a GUI or an unknown part of Qt will surely become a headache. At the same time, the feature on the expansion of a known functional is clear and predictable. This allows us to have a supply of hours in the sprint for fixing bugs, in addition to the basic estimate of development time.

Retro

I want to finish the story on the most positive activity of the sprint. The leading retro is usually chosen according to the rule: who has not led the retro for the longest. At retro, we make a list of positive and not so much moments. As a rule, in terms of benefits there are records like “3 features showed on demo”, “Fixed a complex bug”, “Celebrated the team’s birthday”. In part of the minuses there are the opposite: “We didn’t manage to finish the feature”, “Found a non-reproducible bug”, “Found an architectural problem”. For each minus, as a rule, there is a heated discussion, which translates into constructive proposals and corresponding improvements. It is especially nice to re-read previous retro and see how with each sprint we do not return to the previous minuses.



Every retro mood is great, but some cons are very serious: “Danya is not persistent enough”

On the road

The agenda did not cover the issues of team synchronization, demo, release planning, retro release. In the following articles I will definitely tell you about this and much more.

Join our development team with no managers. Try our BIM system - design your dream home.

Anatoly Osokin, Lead Software Engineer, Renga Software.