Basic laws for creating development teams
Engineers who want to add employees to the team often turn to EDISON . I want to "quickly rivet the puzzle," taking advantage of a dozen additional developers. Does this approach work? Unfortunately, not always. In programming, as in physics, there are laws.
To assemble an intelligent team is real art.
No discussion of development teams takes place without a mention of this principle:
Countless development teams have confirmed the postulate. The laws of Brooks and Conway form the basis.
')
By attaching a new person, the team spends efforts on introducing a course of action, on explaining the tricks and devices used. Participants spend time on informing and synchronizing with the recruit, on learning teamwork and transferring knowledge. Work slows down.
Fresh staff needs help not only in the first week. Part of the authors (for example, Koplien and Harrison) suggest a one-year interval before production from the novice. It is not necessary to attach undue importance to the statement because of the influence of various factors. It is reasonable to assume that some of the employees will do without help in the first three months.
A team can slow down work long before the appearance of a new person. The employee does not arise just like that. Sometimes HR managers act in private interests, requesting more resources. Job descriptions need to write, check, publish, redirect to the personnel department, send to recruitment agencies. It will take time to approve the processes.
Resume should be considered and write either a waiver or a call for an interview. If the candidate approves, a contract is drawn up and a proposal for admission to the team is sent.
Procedures take place before a person receives the right to write a line of code. Even if the personnel department manages most of the processes, team leaders and ordinary members will be distracted. Time for real work and development will be reduced.
Brooks's law does not mean a complete refusal to expand teams. But union growth rarely happens quickly. If the team decided to expand, a part of the performance will be used to increase capacity.
Richard Sheridan made a bold statement:
In the book, the author presents a software development environment different from the real one for most developers and managers. Menlo Corporation does not stint on the issues of building, participating and strengthening its own culture and community. As long as companies do not try the approach in practice, there will not be enough examples to study, it’s hard to say whether Sheridan’s samples should be copied.
The methods described by the author are credible. Well, if Brooks’s law is broken.
People and their organization play a significant role in determining the architecture of software adopted by developers.
Imagine the government creating a new social security system. Required database, interfaces, business logic. It will take developers and testers, costly management, installation requirements, and more.
As a result, the result takes on a visible shape: the roles of users, workflow, data forms, reports are defined. At this point, you see, the creation of a smaller or fundamentally different system is no longer possible.
Take a look at the system after 10 years of operation. Observed Conway's reverse law:
Conway's law reports possible copying of enterprise problems in the interface: in layers, or in APL, or in modules, or somewhere else.
Conway's law must be considered when organizing teams and software systems. Attempts to break the principle consciously or out of ignorance will create a counter-project force. It looks like the desire to split the wood across the fibers. It is more reasonable to respect and use the law of Conway.
A frequent question from the development teams: “How big should the team be?” The work of anthropologist Robin Dunbar gives interesting ideas when trying to answer a question.
The author provides a compelling argument that 150 is the upper limit for organizing people. Dunbar noticed the indicated number in military formations from the times of Ancient Rome, in Neolithic settlements, in Amish communities and in modern research groups.
Communities of more than 150 members are less cohesive, requiring increased control of behavior and hierarchy. Research and analysis highlights the main points in group formation. The parameter is more intelligent to call "Dunbar Numbers". Characteristics are applicable to the various groups that make up the large formations. Smaller teams are stronger and are supposed to rely on numbers with a multiplier of 3.
Following the thesis, most people have a circle of close friends from 3 to 5 people. The next level of buddies is from 10 people to 13–15 (with some effort). The next group contains from 30 to 50 - a typical combat platoon. The population of 150 represents the minimum independent bloc in a military company and the point of creation at enterprises of separate groups.
Dunbar assumes the existence of a formation of 500 and 1500. The author supports Plato in determining the ideal size for democracy of 5300 units. You can draw interesting parallels between the size of military units.
The list is not final. Do not forget about the differences between countries. Even about the features of the flanks of one military organization. But in a broad sense, block sizes follow the conclusions of Dunbar.
It is considered a wise choice the size of a team of 7 people (± 2). There is no practical meaning in the statement. There is no evidence for a thesis about the optimal number of team members of 5–9 people.
Proponents of size appeal to Miller's famous 1956 article "The Magic Number Seven Plus or Minus Two: Some Limitations to Our Information Processing Ability." In practice, most of those who cited the work did not read.
In the article, Miller argues that 7 is the most important number for describing the power of the processing capabilities of the human brain. The selected number determines the maximum number of “pieces” of information for simultaneous processing by the thinking center. The author comes to the conclusion that the interpretation of the frequent repetition of the number 7 is ambiguous:
The significance of the magic number 7 is questionable.
In conclusion, the author says: "I feel that my story here should stop, because it has already become quite interesting." More than 50 years have passed since Miller’s article was published. By all accounts, the range of a team of 5–9 people is satisfactory for managing change. Bottom of the interval justified the need for tests and meeting the requirements for a team of specialists. At the upper end of the range, it is difficult to fully control the system. Therefore, the number of employees from 5 to 9 people makes sense.
The number described does not negate the existence of larger teams, depending on the circumstances.
How can Miller's article on the amount of information processing by the human brain be applied to determining the size of the software development team? Let us turn to the Scrum methodology. The textbook says: “A team in Scrum should be seven plus or minus two people” (Dimer et al., 2008). At the same time, the 2011 Scrum manual states: “Teams of more than nine members cause too many coordination problems. Large development teams significantly complicate the whole process ”(Sutherland and Schwaber, 2013).
The manual says:
In parallel, the introduction of the team leader Scrum assumes that the owner of the product is outside the team.
Other sources give various recommendations on the definition of group members and "just involved."
Teams in the range of 4–8 people are visible everywhere. Miller's article rationally justifies the choice of the size of groups of 7 ± 2. Experience confirms the optimal number limit. The amount may be more than stated in the sources for Scrum.
Let's try to answer the question: “Do you remember studying at a university? At what point were the tasks realized? ”Most readers did the work a few days before the deadline. Part of the project involved in the night before the surrender.
And the vast majority fit in time.
Scientists confirm: people do not do well with the estimated period required to complete the work, but succeed in solving the problem by a clearly agreed date (for example, Buehler, Griffin and Peetz, 2010).
With an excess of time on the project, there is an excessive expansion of the scope of work by the contractor.
Software development is affected by the laws of Parkinson and Hofstadter. Choosing a deadline date will inevitably lead to an underestimation of the required time. As a result, the timing and scope of work will increase. The study (Buhler, Griffin and Pets, 2010) shows: optimism about the date of the task gives an opportunity to carry out the work earlier than with a pessimistic estimate of the time. But the overall project execution time will be optimistic longer than a pessimist. The deadline may be more important than the estimated project completion time (Ariely and Wertenbroch, 2002).
The law echoes the words of David Parnassus:
"As a rule, software systems do not work well until they have been used, and more than once, in" combat "conditions."
The authors emphasize various aspects of a single phenomenon, called "organic growth" by Christopher Alexander.
When creating software using a technique called a walking skeleton, it is recommended to make a simple, basic working piece of code. "Skeleton", although with a certain risk, but pushes the system forward. Creating a base, the team adds "flesh" - a layer of functionality.
The principle can be applied to groups, to software:
“An effective complex team invariably arises from a simple, productive counterpart. A complex team, assembled from scratch, cannot function effectively. And no changes will make it work. It’s worth starting a business with a team that has already worked together. ”
You can draw a parallel between a complex and a large team. The law hints at the way of creating large groups, at a flexible methodology for scaling associations.
The connection with Conway's law is obvious: the construction of the “walking skeleton” is based on the backbone of the team. An equivalent skeleton skeleton is used to create a large and complex formation.
When building an initially large-scale structure, Conway's Law predicts a large and complex architecture. Golla's law says about the appearance of a non-working system and advises the team to start with a smaller one in order to meet the deadlines.
It should add a couple of useful postulates from the author of the article.
Overly large-scale team to justify their own size will give a greater amount of labor, cumbersome solutions and tricky architecture. Easier to add than to remove against the will of the group member.
Keeping the team size small at least initially, there is a chance of finding a simple and concise solution. Starting with a large team will guarantee a cumbersome implementation.
Dunbar numbers determine the effective team size limit. Based on the law of Conway, we can talk about the potential limit of the system. The only way to get around the axiom is to divide a large system into compact groups. Teams are not born fully formed and effective. Conway's law works in conjunction with Goll's thesis. Groups should grow gradually. Brookes postulate implies that teams cannot expand too quickly. Parkinson's law means the employment of too large teams maintaining their own existence.
The second postulate of Kelly suggests a solution: avoid big, focus on small.
It is better not to resist the laws, but to find an approach and work with the provisions. Attempts to find a way to deal with laws can be commercially viable, if you use them at least to substantiate the decisions made to higher managers.
The article is an excerpt from Allan Kelly’s new book, Xanpan Book 2: Means of Production. Will be available at the end of 2015.
To assemble an intelligent team is real art.
Brooks Act
No discussion of development teams takes place without a mention of this principle:
“By adding human resources, we are delaying the end of a software project” (Brooks, 1975).
Countless development teams have confirmed the postulate. The laws of Brooks and Conway form the basis.
')
By attaching a new person, the team spends efforts on introducing a course of action, on explaining the tricks and devices used. Participants spend time on informing and synchronizing with the recruit, on learning teamwork and transferring knowledge. Work slows down.
Fresh staff needs help not only in the first week. Part of the authors (for example, Koplien and Harrison) suggest a one-year interval before production from the novice. It is not necessary to attach undue importance to the statement because of the influence of various factors. It is reasonable to assume that some of the employees will do without help in the first three months.
A team can slow down work long before the appearance of a new person. The employee does not arise just like that. Sometimes HR managers act in private interests, requesting more resources. Job descriptions need to write, check, publish, redirect to the personnel department, send to recruitment agencies. It will take time to approve the processes.
Resume should be considered and write either a waiver or a call for an interview. If the candidate approves, a contract is drawn up and a proposal for admission to the team is sent.
Procedures take place before a person receives the right to write a line of code. Even if the personnel department manages most of the processes, team leaders and ordinary members will be distracted. Time for real work and development will be reduced.
Brooks's law does not mean a complete refusal to expand teams. But union growth rarely happens quickly. If the team decided to expand, a part of the performance will be used to increase capacity.
Richard Sheridan made a bold statement:
I am pleased to report that the Brooks Act may be violated. All our activities are focused on breaking the statement. Dividing people into pairs, moving between pairs, testing automation, code management, hiring not based on heroes, constant negotiations, an open work environment and visible artifacts are all to refute Brooks’s assertion (Sheridan, 2013).
In the book, the author presents a software development environment different from the real one for most developers and managers. Menlo Corporation does not stint on the issues of building, participating and strengthening its own culture and community. As long as companies do not try the approach in practice, there will not be enough examples to study, it’s hard to say whether Sheridan’s samples should be copied.
The methods described by the author are credible. Well, if Brooks’s law is broken.
Conway's Law
Organizations that design systems ... produce them by copying the communication structures that have developed in these organizations,
- Conway, 1968
People and their organization play a significant role in determining the architecture of software adopted by developers.
Imagine the government creating a new social security system. Required database, interfaces, business logic. It will take developers and testers, costly management, installation requirements, and more.
As a result, the result takes on a visible shape: the roles of users, workflow, data forms, reports are defined. At this point, you see, the creation of a smaller or fundamentally different system is no longer possible.
Take a look at the system after 10 years of operation. Observed Conway's reverse law:
Enterprises using software systems ... are limited to communication structures that replicate this system.
Conway's law reports possible copying of enterprise problems in the interface: in layers, or in APL, or in modules, or somewhere else.
Conway's law must be considered when organizing teams and software systems. Attempts to break the principle consciously or out of ignorance will create a counter-project force. It looks like the desire to split the wood across the fibers. It is more reasonable to respect and use the law of Conway.
Dunbar number. Natural landmarks
“Extrapolating people's relations among monkeys gives an idea of ​​the size of social groups. About 150 individuals - the limit of human social relations. The number has been honored with the name "Dunbar Number",
- Dunbar, 2010
A frequent question from the development teams: “How big should the team be?” The work of anthropologist Robin Dunbar gives interesting ideas when trying to answer a question.
The author provides a compelling argument that 150 is the upper limit for organizing people. Dunbar noticed the indicated number in military formations from the times of Ancient Rome, in Neolithic settlements, in Amish communities and in modern research groups.
Communities of more than 150 members are less cohesive, requiring increased control of behavior and hierarchy. Research and analysis highlights the main points in group formation. The parameter is more intelligent to call "Dunbar Numbers". Characteristics are applicable to the various groups that make up the large formations. Smaller teams are stronger and are supposed to rely on numbers with a multiplier of 3.
Following the thesis, most people have a circle of close friends from 3 to 5 people. The next level of buddies is from 10 people to 13–15 (with some effort). The next group contains from 30 to 50 - a typical combat platoon. The population of 150 represents the minimum independent bloc in a military company and the point of creation at enterprises of separate groups.
Dunbar assumes the existence of a formation of 500 and 1500. The author supports Plato in determining the ideal size for democracy of 5300 units. You can draw interesting parallels between the size of military units.
| Organization | The size |
| Fire brigade | 4 or less people |
| Section / Detachment | 8–12 participants (several fire brigades) |
| Platoon | 15–30 employees (2 squad) |
| Company | 80–250 soldiers (several platoons) |
| Battalion | 300–800 fighters |
The list is not final. Do not forget about the differences between countries. Even about the features of the flanks of one military organization. But in a broad sense, block sizes follow the conclusions of Dunbar.
Miller's Magic Seven (Miller's Wallet)
It is considered a wise choice the size of a team of 7 people (± 2). There is no practical meaning in the statement. There is no evidence for a thesis about the optimal number of team members of 5–9 people.
Proponents of size appeal to Miller's famous 1956 article "The Magic Number Seven Plus or Minus Two: Some Limitations to Our Information Processing Ability." In practice, most of those who cited the work did not read.
In the article, Miller argues that 7 is the most important number for describing the power of the processing capabilities of the human brain. The selected number determines the maximum number of “pieces” of information for simultaneous processing by the thinking center. The author comes to the conclusion that the interpretation of the frequent repetition of the number 7 is ambiguous:
“At the moment, I urge to refrain from unequivocal judgments. Perhaps in the depths of these sevens there is something important that needs to be discovered. But I suspect that everything can be just a pernicious Pythagorean coincidence. ”
The significance of the magic number 7 is questionable.
In conclusion, the author says: "I feel that my story here should stop, because it has already become quite interesting." More than 50 years have passed since Miller’s article was published. By all accounts, the range of a team of 5–9 people is satisfactory for managing change. Bottom of the interval justified the need for tests and meeting the requirements for a team of specialists. At the upper end of the range, it is difficult to fully control the system. Therefore, the number of employees from 5 to 9 people makes sense.
The number described does not negate the existence of larger teams, depending on the circumstances.
Team size in Scrum methodology
How can Miller's article on the amount of information processing by the human brain be applied to determining the size of the software development team? Let us turn to the Scrum methodology. The textbook says: “A team in Scrum should be seven plus or minus two people” (Dimer et al., 2008). At the same time, the 2011 Scrum manual states: “Teams of more than nine members cause too many coordination problems. Large development teams significantly complicate the whole process ”(Sutherland and Schwaber, 2013).
The manual says:
The roles of the product owner and head of the Scrum team are not included in the calculation, unless they are included in the work to reduce the backlog in the next sprint,
- Sutherland and Schweber, 2013
In parallel, the introduction of the team leader Scrum assumes that the owner of the product is outside the team.
Other sources give various recommendations on the definition of group members and "just involved."
Teams in the range of 4–8 people are visible everywhere. Miller's article rationally justifies the choice of the size of groups of 7 ± 2. Experience confirms the optimal number limit. The amount may be more than stated in the sources for Scrum.
Parkinson's Law and Hofstadter's Law
Work fills all the time allotted for its execution,
- Parkinson's law
It will always take longer than you expect, even if you know the Hofstadter law,
- Hofstadter's law, 1980
Let's try to answer the question: “Do you remember studying at a university? At what point were the tasks realized? ”Most readers did the work a few days before the deadline. Part of the project involved in the night before the surrender.
And the vast majority fit in time.
Scientists confirm: people do not do well with the estimated period required to complete the work, but succeed in solving the problem by a clearly agreed date (for example, Buehler, Griffin and Peetz, 2010).
With an excess of time on the project, there is an excessive expansion of the scope of work by the contractor.
Software development is affected by the laws of Parkinson and Hofstadter. Choosing a deadline date will inevitably lead to an underestimation of the required time. As a result, the timing and scope of work will increase. The study (Buhler, Griffin and Pets, 2010) shows: optimism about the date of the task gives an opportunity to carry out the work earlier than with a pessimistic estimate of the time. But the overall project execution time will be optimistic longer than a pessimist. The deadline may be more important than the estimated project completion time (Ariely and Wertenbroch, 2002).
Golla's law. Parnas and Alexander
A complex working system is invariably obtained from a simple working system. A complex system designed from scratch never works. And no improvements will make it work. Start with a simple working system.
- Goll law, 1986
The law echoes the words of David Parnassus:
"As a rule, software systems do not work well until they have been used, and more than once, in" combat "conditions."
The authors emphasize various aspects of a single phenomenon, called "organic growth" by Christopher Alexander.
When creating software using a technique called a walking skeleton, it is recommended to make a simple, basic working piece of code. "Skeleton", although with a certain risk, but pushes the system forward. Creating a base, the team adds "flesh" - a layer of functionality.
The principle can be applied to groups, to software:
“An effective complex team invariably arises from a simple, productive counterpart. A complex team, assembled from scratch, cannot function effectively. And no changes will make it work. It’s worth starting a business with a team that has already worked together. ”
You can draw a parallel between a complex and a large team. The law hints at the way of creating large groups, at a flexible methodology for scaling associations.
The connection with Conway's law is obvious: the construction of the “walking skeleton” is based on the backbone of the team. An equivalent skeleton skeleton is used to create a large and complex formation.
When building an initially large-scale structure, Conway's Law predicts a large and complex architecture. Golla's law says about the appearance of a non-working system and advises the team to start with a smaller one in order to meet the deadlines.
Kelly's laws
It should add a couple of useful postulates from the author of the article.
The scale of the software will always increase in proportion to the resources available
- Kelly's first law
Within each large development project there is a small side project outside the main task.
- Kelly's second law
Overly large-scale team to justify their own size will give a greater amount of labor, cumbersome solutions and tricky architecture. Easier to add than to remove against the will of the group member.
Keeping the team size small at least initially, there is a chance of finding a simple and concise solution. Starting with a large team will guarantee a cumbersome implementation.
Conclusion
Dunbar numbers determine the effective team size limit. Based on the law of Conway, we can talk about the potential limit of the system. The only way to get around the axiom is to divide a large system into compact groups. Teams are not born fully formed and effective. Conway's law works in conjunction with Goll's thesis. Groups should grow gradually. Brookes postulate implies that teams cannot expand too quickly. Parkinson's law means the employment of too large teams maintaining their own existence.
The second postulate of Kelly suggests a solution: avoid big, focus on small.
It is better not to resist the laws, but to find an approach and work with the provisions. Attempts to find a way to deal with laws can be commercially viable, if you use them at least to substantiate the decisions made to higher managers.
The article is an excerpt from Allan Kelly’s new book, Xanpan Book 2: Means of Production. Will be available at the end of 2015.
Source: https://habr.com/ru/post/272483/
All Articles