1. Conway’s Law is paramount.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
In order to design a piece of software we need to “design” the team that is going to produce it.
2. Developer Experience is key to productivity
Developers must spend as much time in the “flow” state to maximize the joy their profession sparks. A developer in flow state can resolve any problem in front of them. Meetings and constant interruptions break them out of the “flow”, impacting their job satisfaction and productivity. Given that coordination overhead (= meetings) increases quadratically with the number of people in a team, developers works best when in teams of 4-6 people.
Optimising developer productivity is a fundamental activity of every team. Every tool and framework could impact developer productivity. Choose wisely.
3. DORA metrics, not burndown charts
Scrum and other Agile methodologies predicates the use of story points and time to assess how much work will fit in a sprint. Then, the team is benchmarked with these estimates. This incentives writing low quality software as bug fixes will be more story point to churn later on.
Continuous Deployment is the way. The best way to measure CD are DORA metrics:
- deployment frequency (DF)
- lead time for changes (LT)
- mean time to recovery (MTTR)
- change failure rate (CFR)