December 9, 2017 at 11:17Renga development team: how we reached an idyll, working without managers
7 teams and not a single manager - do you think this is possible? We built a process in which we show 1-2 features from a team on each demo, conduct retro teams, retro releases and at the same time get real pleasure from the work. Want to organize your work the same way? Then welcome to cat.
We, Renga Software , are developing software products for the design of buildings and structures in accordance with information modeling technology ( BIM) We go sprints, release releases every 3-4 months. There are more and more users of the system every week. The product is very young, so the backlog is full of important, and most importantly, interesting tasks. But how to quickly develop a product that will be used for the design of residential buildings, kindergartens, hospitals and theaters?
“Let the application fall better than the designed building”
- Architect's joke
So, our development department consists of 28 developers, 3 product analysts and 6 testers. Each team includes a product analyst, tester, and four developers. We follow all the required activities of scrum - sprints, planning, retro, demos, daily stand-ups. Moreover, we use some features from the SAFe (Scaled Agile Framework) to synchronize the work of several teams - weekly team synchronization, retro release every 3-4 months. We also have an unusual activity - we call it grooming, on which we analyze a business feature together with the entire team and analyst and get a list of understandable requirements for a feature and readiness criteria (DoDs).
In the classic Scrum, as you know, there is an activity called “Planning”, on which a product owner, a development team, testers, and other interested parties are always present. In the planning process, the goal of the sprint, the composition of features or stories (user story) for development is developed. The presence of a product owner is a prerequisite for successful planning, because only he can answer non-standard questions about a feature that come to the mind of experienced (and not only) developers when they realize the purpose of a feature and in the process of decomposing it into tasks.
Here lies the first pitfall of classical scrum - how to make possible the presence of a product on the planning of 7 teams in one day? Maybe there is the 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 sprint planning. In addition, in such a desync, it becomes unclear how to conduct a demo on which you want to show the integrated result of all the teams?
We have solved this problem. Planning is carried out only by the team. On planning, the team is engaged in the decomposition of pre-prepared and broadened features for which readiness criteria have already been formed. Thus, on planning, everyone in the team (if he / she listened carefully and actively participated in grooming) knows what exactly needs to be done in a particular feature. This saves the product owner’s time and allows you to synchronize the planning of teams and carry them out in one day.
The peculiarity of our scrum consists precisely in carrying out special activities - grooming features. They have a product owner, the entire team that will develop the feature, testers, technical writers and all interested. The grocery store tells what the feature will be about, how it should look and the main use cases. During the grooming process, anyone present can ask any questions regarding functionality, usage scenarios, and boundary conditions. As a rule, despite the preparedness of features from the product owner, 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 fundamental to analytics, developers can decide for themselves how to implement this or that functionality.
The knowledge base is formed, including from such wall recordings.
Thus, a rather expensive labor-intensive activity is obtained. But this is the only minus of grooming, the advantages of which are obvious and largely outweigh the time spent on discussion. I have already mentioned some of the pluses, let’s go through them again:
Development sprints last ten business days. Between sprints there is a day for demo and 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 telegram, which allows you to quickly discuss all issues of development, organization of activities, as well as issues of politics and religion. Conducting retro, daily stand-ups, planning, as a rule, is initiated by different developers who have time to write in the chat. Any developer who wishes can be responsible for the activity. We set the time of activity, gather as a team and discuss. As a rule, each team has an experienced team lead who also has good soft skills, which helps to keep discussions aside. Although, in each team, soft skills are well developed by most developers, which allows constructive discussion of issues and minimizes the time spent on non-constructive discussions.
Planning tasks are evaluated in abstract working hours, which we optimistically consider as many as five in the working day. That is, if the assessment task takes a day, then we evaluate it at five o’clock. We use poker planning for evaluations. If the estimates diverge, as a rule, this indicates that one of the participants knows more than others. Thus, the understanding of the context of the task is aligned and, as a consequence, the reassessment of the task.
Why do not we use parrots or story points to evaluate? Over time, we came to the conclusion that it is important for the team to correctly evaluate the development speed 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 familiarity with the code section. At the same time, story points allow you to evaluate the amount of work without reference to a specific developer. But what happens if in the next sprint, for example, a beginner takes a task at, for example, 3 story points? He will spend 3 days on it, while an experienced one will manage in 1 day. Thus, the sprint scope will no longer be tied to the time frame of the sprint. In the planning process, we align the time with the task. It happens that an experienced developer evaluates a task at two hours, and an inexperienced one at five hours. After discussion, the final rating is likely to be five hours. Thus, we potentially overestimate the assessment of the problem, but, on the other hand, are protected from default on the development of a sprint scope.
In addition to decomposed tasks, a bugpool is indicated for a feature, which is also evaluated, including by a 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%. Nevertheless, experience shows that uncertainty depends on the context of the task itself. For example, bugs in a task related to the atypical use of the GUI or an unknown part of Qt are likely to become a headache. At the same time, the feature for expanding the well-known functionality is understandable and predictable. This allows us to have a stock of hours in the sprint to fix bugs, in addition to a basic estimate of the development time.
I want to end the story on the most positive sprint activity. The presenter of the retro, as a rule, is chosen according to the rule: who has not conducted the retro for the longest time. On the retro, we make a list of positive and not so highlights. As a rule, in terms of pluses, there are records like “Showed 3 features on the demo”, “Fixed a difficult bug”, “Celebrated the team’s birthday”. In terms of cons, the opposite is found: “We did not have time to complete the feature”, “Found an irreproducible bug”, “Found an architectural problem”. For each minus, as a rule, a heated discussion takes place, which translates into constructive proposals and corresponding improvements. It is especially nice to reread the previous retro and see how with each sprint we do not return to the previous minuses.
Each retro mood is excellent, but some of the disadvantages are very serious: “Tribute is not persistent”
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 without managers. Try our BIM system - design your dream home.
Anatoly Osokin, Leading Software Engineer, Renga Software.
We, Renga Software , are developing software products for the design of buildings and structures in accordance with information modeling technology ( BIM) We go sprints, release releases every 3-4 months. There are more and more users of the system every week. The product is very young, so the backlog is full of important, and most importantly, interesting tasks. But how to quickly develop a product that will be used for the design of residential buildings, kindergartens, hospitals and theaters?
More on the Renga Product Family (Caution Marketing!)
Renga Architecture - a system for architectural design. The program was created to provide maximum assistance to the designer in solving his tasks: creating the architectural appearance of the building and the information model, and quickly arranging the drawings according to the standards of SPDS and much more.
Renga Structure - a system for designing the structural part of buildings / structures. A program for structural engineers and designers to create an information model of a building or structure and obtain drawings of the KR / KZh / KZhI / KM / AS brands.
The Renga product family is designed for BIM technology design. High system performance allows you to work with large projects without a visible decrease in the quality of work with the 3D model:
Object design
Create a 3D model of a building / structure in Renga with object design tools (wall, pillar, window, etc.).
Teamwork.
Exchange and storage of data is carried out using the BIM-Server Pilot.
Interaction with cost systems.
Integration of Renga via API with cost estimates. systems 1C-estimate and ABC-estimate for the interaction of design and estimate departments. Renga
data
exchange allows you to exchange data with other systems through various formats (.ifc, .dwg, .dxf, .obj, .dae, .stl, .3ds, .lwo and .csv)
Automation of receiving specifications and statements
Renga implements the function of receiving reports for the formation of specifications, statements and explications.
Automation of obtaining drawings
According to the 3D-model, views (facades, sections and plans) are automatically obtained and placed on the drawings at specified scales.
Renga Structure - a system for designing the structural part of buildings / structures. A program for structural engineers and designers to create an information model of a building or structure and obtain drawings of the KR / KZh / KZhI / KM / AS brands.
The Renga product family is designed for BIM technology design. High system performance allows you to work with large projects without a visible decrease in the quality of work with the 3D model:
Object design
Create a 3D model of a building / structure in Renga with object design tools (wall, pillar, window, etc.).
Teamwork.
Exchange and storage of data is carried out using the BIM-Server Pilot.
Interaction with cost systems.
Integration of Renga via API with cost estimates. systems 1C-estimate and ABC-estimate for the interaction of design and estimate departments. Renga
data
exchange allows you to exchange data with other systems through various formats (.ifc, .dwg, .dxf, .obj, .dae, .stl, .3ds, .lwo and .csv)
Automation of receiving specifications and statements
Renga implements the function of receiving reports for the formation of specifications, statements and explications.
Automation of obtaining drawings
According to the 3D-model, views (facades, sections and plans) are automatically obtained and placed on the drawings at specified scales.
“Let the application fall better than the designed building”
- Architect's joke
So, our development department consists of 28 developers, 3 product analysts and 6 testers. Each team includes a product analyst, tester, and four developers. We follow all the required activities of scrum - sprints, planning, retro, demos, daily stand-ups. Moreover, we use some features from the SAFe (Scaled Agile Framework) to synchronize the work of several teams - weekly team synchronization, retro release every 3-4 months. We also have an unusual activity - we call it grooming, on which we analyze a business feature together with the entire team and analyst and get a list of understandable requirements for a feature and readiness criteria (DoDs).
To grumble or not to grumble, that’s the question
In the classic Scrum, as you know, there is an activity called “Planning”, on which a product owner, a development team, testers, and other interested parties are always present. In the planning process, the goal of the sprint, the composition of features or stories (user story) for development is developed. The presence of a product owner is a prerequisite for successful planning, because only he can answer non-standard questions about a feature that come to the mind of experienced (and not only) developers when they realize the purpose of a feature and in the process of decomposing it into tasks.
Here lies the first pitfall of classical scrum - how to make possible the presence of a product on the planning of 7 teams in one day? Maybe there is the 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 sprint planning. In addition, in such a desync, it becomes unclear how to conduct a demo on which you want to show the integrated result of all the teams?
We have solved this problem. Planning is carried out only by the team. On planning, the team is engaged in the decomposition of pre-prepared and broadened features for which readiness criteria have already been formed. Thus, on planning, everyone in the team (if he / she listened carefully and actively participated in grooming) knows what exactly needs to be done in a particular feature. This saves the product owner’s time and allows you to synchronize the planning of teams and carry them out in one day.
The peculiarity of our scrum consists precisely in carrying out special activities - grooming features. They have a product owner, the entire team that will develop the feature, testers, technical writers and all interested. The grocery store tells what the feature will be about, how it should look and the main use cases. During the grooming process, anyone present can ask any questions regarding functionality, usage scenarios, and boundary conditions. As a rule, despite the preparedness of features from the product owner, 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 fundamental to analytics, developers can decide for themselves how to implement this or that functionality.
The knowledge base is formed, including from such wall recordings.
Thus, a rather expensive labor-intensive activity is obtained. But this is the only minus of grooming, the advantages of which are obvious and largely outweigh the time spent on discussion. I have already mentioned some of the pluses, let’s go through them again:
- There is no need for product analytics to be present at the planning of all teams, which allows synchronizing planning. Grooming is carried out on the eve of the sprint, where it is planned to work on features at a time convenient for all participants.
- The whole team is immersed in the process of discussing the functionality and subtleties of the feature. This avoids the known discrepancy between expectations and the fact of the implemented functionality. In addition, a collective discussion reveals inaccuracies and ambiguities in the originally formulated feature, identifies analytics errors due to unexpected questions from those present (and there are almost always such questions).
- The output is a complete and understandable list of requirements and usage scenarios for features. Developers will check the code for the main points of the functional, and testers will write integration tests, knowing the scenarios of system behavior.
Managers themselves
Development sprints last ten business days. Between sprints there is a day for demo and 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 telegram, which allows you to quickly discuss all issues of development, organization of activities, as well as issues of politics and religion. Conducting retro, daily stand-ups, planning, as a rule, is initiated by different developers who have time to write in the chat. Any developer who wishes can be responsible for the activity. We set the time of activity, gather as a team and discuss. As a rule, each team has an experienced team lead who also has good soft skills, which helps to keep discussions aside. Although, in each team, soft skills are well developed by most developers, which allows constructive discussion of issues and minimizes the time spent on non-constructive discussions.
Planning
Planning tasks are evaluated in abstract working hours, which we optimistically consider as many as five in the working day. That is, if the assessment task takes a day, then we evaluate it at five o’clock. We use poker planning for evaluations. If the estimates diverge, as a rule, this indicates that one of the participants knows more than others. Thus, the understanding of the context of the task is aligned and, as a consequence, the reassessment of the task.
Why do not we use parrots or story points to evaluate? Over time, we came to the conclusion that it is important for the team to correctly evaluate the development speed 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 familiarity with the code section. At the same time, story points allow you to evaluate the amount of work without reference to a specific developer. But what happens if in the next sprint, for example, a beginner takes a task at, for example, 3 story points? He will spend 3 days on it, while an experienced one will manage in 1 day. Thus, the sprint scope will no longer be tied to the time frame of the sprint. In the planning process, we align the time with the task. It happens that an experienced developer evaluates a task at two hours, and an inexperienced one at five hours. After discussion, the final rating is likely to be five hours. Thus, we potentially overestimate the assessment of the problem, but, on the other hand, are protected from default on the development of a sprint scope.
In addition to decomposed tasks, a bugpool is indicated for a feature, which is also evaluated, including by a 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%. Nevertheless, experience shows that uncertainty depends on the context of the task itself. For example, bugs in a task related to the atypical use of the GUI or an unknown part of Qt are likely to become a headache. At the same time, the feature for expanding the well-known functionality is understandable and predictable. This allows us to have a stock of hours in the sprint to fix bugs, in addition to a basic estimate of the development time.
Retro
I want to end the story on the most positive sprint activity. The presenter of the retro, as a rule, is chosen according to the rule: who has not conducted the retro for the longest time. On the retro, we make a list of positive and not so highlights. As a rule, in terms of pluses, there are records like “Showed 3 features on the demo”, “Fixed a difficult bug”, “Celebrated the team’s birthday”. In terms of cons, the opposite is found: “We did not have time to complete the feature”, “Found an irreproducible bug”, “Found an architectural problem”. For each minus, as a rule, a heated discussion takes place, which translates into constructive proposals and corresponding improvements. It is especially nice to reread the previous retro and see how with each sprint we do not return to the previous minuses.
Each retro mood is excellent, but some of the disadvantages are very serious: “Tribute is not persistent”
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 without managers. Try our BIM system - design your dream home.
Anatoly Osokin, Leading Software Engineer, Renga Software.