The standup meeting is a tool, not a ritual. It’s optional and doesn’t need be scheduled every day. Do what makes sense for your team. Keep it timeboxed. 10 minutes should be enough. Even for large teams. Traditionally, the format has been to use a simple formula: Each builder answers three questions: What did I do since the last meeting? What will I do until the next meeting? What is in my way? No discussion, no posturing, no deep explanations. ...
A breaking continuous build system is a Stop-the-Presses event. We pause our work and gather around to fix the failing build together. I’ve frequently seen teams silence the alarms by turning on the “ignore” flag on the failing tests, or deleting the tests all together. Just to stop the “nuisance” notification emails. But that only hides problems, and can lead to broken software being deployed. Instead, it’s important for the team to be encouraged and given the ability to prioritize fixing the tests, rather than being pressured to quickly meet some other completion deadline. ...
Many teams accept it as normal, and “usual”, for the build to break now and again. Instead, foster a team culture where it’s considered an “unusual” thing. Before checking in code, the builder needs to run the unit tests and acceptance tests. If the build breaks, something unusual has happened, and we switch focus to fix it immediately. A simple visual trick that can help accelerate the discipline of keeping the build in good health: Create a visual calendar year grid diagram for the build, and mark a green dot for each day with no build failures and a red dot for each day with at least one build failure. ...
The code and artifacts belongs to the team, not any individual. Collective ownership means any builder can check out and improve any module at anytime. The key is to allow and encourage people to specialize, while at the same time balance that with having generalized knowledge. Team members should split their work between their specialty and other areas so they can help across the codebase. When ownership is shared, knowledge spreads, and the team can make better decisions together. ...
Working unscheduled overtime doesn’t prove dedication. A team member that routinely burns extra hours is a signal of poor planning, agreeing to risky deadlines, or over-promising - not professionalism. It makes them a manipulable laborer, not a trusted partner. Having said that, not all overtime is wrong. Genuine emergencies do happen where extra effort is needed, but those cases should be rare and an “work overtime” solution be something that is chosen deliberately from all the options available. ...