Churn is a natural and healthy part of the development process and varies from project to project.
However, Unusually High Churn is often an early indicator that a team or a person may be struggling with an assignment.
Unusually high churn levels aren’t a problem in themselves.
More likely, there are outside factors causing the problem.
―𝐏𝐞𝐫𝐟𝐞𝐜𝐭𝐢𝐨𝐧𝐢𝐬𝐦: When an engineers’ standards of “good enough” are not aligned with the company’s standard of “good enough”.
Engineers keep going back into the code to rewrite it
because they think it can and should be better but may not add much to the actual functionality of the code.
―𝐓𝐡𝐞𝐲’𝐫𝐞 𝐬𝐭𝐫𝐮𝐠𝐠𝐥𝐢𝐧𝐠 𝐰𝐢𝐭𝐡 𝐭𝐡𝐞 𝐩𝐫𝐨𝐛𝐥𝐞𝐦 𝐚𝐭 𝐡𝐚𝐧𝐝.
―Or, most commonly, 𝐢𝐬𝐬𝐮𝐞𝐬 𝐜𝐨𝐧𝐜𝐞𝐫𝐧𝐢𝐧𝐠 𝐞𝐱𝐭𝐞𝐫𝐧𝐚𝐥 𝐬𝐭𝐚𝐤𝐞𝐡𝐨𝐥𝐝𝐞𝐫𝐬.
We see this with unclear or ambiguous specs, late arriving requirements, or mid-sprint updates to the deliverables.
WHAT TO DO
Determine whether an 𝐞𝐱𝐭𝐞𝐫𝐧𝐚𝐥 𝐬𝐭𝐚𝐤𝐞𝐡𝐨𝐥𝐝𝐞𝐫 𝐢𝐬 𝐝𝐫𝐢𝐯𝐢𝐧𝐠 𝐭𝐡𝐞 𝐬𝐢𝐭𝐮𝐚𝐭𝐢𝐨𝐧.
If so then:
1. 𝐒𝐡𝐨𝐰 𝐭𝐡𝐞 𝐝𝐚𝐭𝐚.
Show how late arriving specs or last-minute changes are throwing the project off.
2. Pull the ticket from the sprint,
or decide on an MVP and split off the additions into a refinement sprint.
𝐈𝐟 𝐚𝐧 𝐞𝐱𝐭𝐞𝐫𝐧𝐚𝐥 𝐬𝐭𝐚𝐤𝐞𝐡𝐨𝐥𝐝𝐞𝐫 𝐢𝐬 𝐧𝐨𝐭 𝐝𝐫𝐢𝐯𝐢𝐧𝐠 𝐭𝐡𝐞 𝐔𝐧𝐮𝐬𝐮𝐚𝐥𝐥𝐲 𝐇𝐢𝐠𝐡 𝐂𝐡𝐮𝐫𝐧, call in the cavalry!
It is usually preferable to be coached by a fellow engineer or team lead instead of a manager.
1. Ask for a pre-submit code review or a rubber duck.
2. Ask to split the work. The act of dividing the work often reveals the root issue.
3. Ask a more senior engineer to assess what “good enough” is in the context of the project.
4. If the problem is difficult, or if the domain is unfamiliar, bring in another engineer to pair program.