The daily stand-up meeting (also known as a "daily scrum", a "daily huddle", a "morning roll-call", etc.) is simple to describe: the whole team meets every day for a quick status update. We stand up to keep the meeting short. That's it. But this short definition does not really tell you the subtle details that distinguish a good stand-up from a bad one.

Given the apparent simplicity of stand-ups, I was quite surprised the first time I saw one that wasn't working. It was immediately obvious to me what was wrong but I realised that it was not obvious to the team. I realised that my team was not aware of the underlying principles and details that would allowed them to diagnose and solve problems with stand-ups.

People who have experienced good stand-ups will generally know what can be done when things aren't working well. For novice stand-up attendees, when things go wrong, it is much less likely that they'll figure out what to do. One way to approach this issue is to claim that it's all a matter of tacit knowledge and novices just need to attend more well-run stand-ups. I believe, however, that it's much more likely that given no assistance, novices will simply abandon the practice of daily stand-ups. This would be unfortunate since well-run stand-ups add significant value to projects.

This is my attempt to communicate some of the previously tacit knowledge on the benefits and consequences of common practices for daily stand-ups. These patterns of daily stand-up meetings are intended to help new practitioners as well as remind experienced practitioners of what they might already know in their gut.

In the Java community there's been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of "Inversion of Control". In this article I dig into how this pattern works, under the more specific name of "Dependency Injection", and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.