Team Process

team_process.md

The Process

Key principles

• Integrate the code as fast as possible, the code that is not ready should be disabled by feature flags.
• Deliver frequently, deploy frequency improves quality, decreases rework.
• Enable fast flow from development to production by reducing variability and batch sizes (slice big tasks, deliver often).
• Visualize team goals and targets, actively monitor and visualize performance to goals/targets. Visualize and minimize WIP.
• Eliminate unnecessary controls (code review, QA, manager's approval), automate quality, invest in team capabilities and autonomy.
• High cooperation, knowledge sharing, novelty and innovations are highly welcomed.

Books to Read

1. Accelerate (Amazon.de). Must read.

   Key ideas:

   • deploy frequency increases quality, decreases time to recovery and failure rate
   • lean management and continuous delivery are key ingredients of performant team culture
   • Continuous Delivery decreases Rework, Burnout and Deployment Pain
   • Components of Lean Management: Work in Small Batches, Make Flow of Work Visible, Gather and Implement Feedback, Team Experimentation
   • CD and LM improves Job Satisfaction
   • Helpful practices to create high-performant generative culture (Westrum organizational culture):
     • High cooperation.
     • Messengers are trained.
     • Risks are shared.
     • Bridging is encouraged.
     • Failure leads to inquiry.
     • Novelty is implemented.

To understand the concept of innovation I’d recommend to google the definition and read a few examples.
There is also an easy book explaining what is innovation and how it works https://www.amazon.de/-/en/Matt-Ridley/dp/0062916599
Warning! It is not about processes in software industry. The book is mostly focused on examples of innovation. I like how it shows the importance of trying different approaches often (experiment, iterate) to keep innovating.

Forgot to mention one important thing:

• trunk based development. There is one version of code and changes appearing in the main brunch as soon as possible. It minimizes need of rework (rebased, merge conflicts, outdated integrations in long-living brunches).

Nice! I like this and I think it would be cool to add a couple of concrete examples of problems / decisions we have done in the team to make it really tangible and easy to copy for others...

Like maybe another paragraph that adds some meat to the statements. Like this:

Deliver frequently, deploy frequency improves quality, decreases rework.
Because the search team optimized for quick turnaround, we are able to deliver 10-15 times per week. We found that this cadence and the improves quality instead of causing many defects in production (0.123% of commits are reverted). For instance the teams development processes bake quality & code review directly into the start and not as a later process step. Also, because of early integration, unnecessary rework, such as endless rebasing & merge conflict resolution, have not been a problem.

What is lean? https://en.m.wikipedia.org/wiki/Lean_startup
https://kanbanize.com/lean-management/what-is-lean-management