Mel Conway published a paper in 1968 that is still relevant today, stating the direction that companies should move in. For a long time, we focused on defining rules for everything, such as the following:
- What time you should arrive at the office
- The minimum hours that people should work
- How many days per week are used for working
- What type of clothing is appropriate to wear during working hours
These rules apply to any type of company, and, in many cases, they are still relevant today. Within the IT world (and particularly the software industry), we created another set of rules to guide our teams (feel free to avoid reading these rules if you don't want to get bored):
- Business analysts should create use cases with a well-defined structure, allowing the developer to ignore the business details and focus on the technical part of the process.
- Developers should follow the standard document created by the software architect of the product that was written many years ago.
- The lines of code written per day should indicate how productive a developer is.
- When you create a new database object, you have to update the existing trustable database dictionary.
- As soon as your code is ready to be pushed, use an email template to ask for revision by the QA team. After their approval, repeat this process with the design team and later again with the architecture team.
- Any change to the pushed code will force you to repeat the process that was explained in the preceding rule.
- Don't forget UML diagrams when you finish coding your assigned use case. Not all of them are required—only the most important ones, such as those listed here:
- Class diagram
- Object diagram
- Package diagram
- Component diagram
- Sequence diagram
- Deployment diagram
The preceding list of diagrams will be larger in some cases. Fortunately, things have changed nowadays, and crazy processes that force us to write huge documents and create different diagrams that pay no attention are no longer used. With these premises in mind, Mel Conway wrote the following as part of his paper:
Conway's thesis is still relevant and has been affecting the way we structure our teams to create successful projects and avoid wasting resources ever since.
People comprise teams, and the question of how these people should be arranged in order to create successful teams has been answered in many ways in the last few years. All of these answers have suggested building small and multidisciplinary teams that should be small enough to be fed using one pizza and multidisciplinary enough to avoid creating silos during the SDLC.
In this way, companies are promoting a culture of sharing and continuous learning within teams. Teams are continually learning from their successes and failures. They are interacting with each other directly instead of using intermediaries or other protocols of communication.
Business boundaries are defined by teams that allow them to communicate using well-defined interfaces, and since the communication is directly managed by themselves, rapid feedback will enable them to fix issues and take corrective actions when necessary.
