Each day, loads of companies around the world blindly participate in a ritual that returns almost zero value: The Daily Stand-up.
Developers standing in a circle, mindlessly stating what they did yesterday and what they're going to do today. Each participant pretending to listen as they desperately try to think of something to say.
In fact, I would bet good money that, if put on the spot, most participants wouldn't actually be able to tell you what the person before them had just said.
In toxic companies, the person leading the stand-up may even be recording what each developer has said, comparing against what was said yesterday in a utterly futile attempt to try catch them out. As an aside, if you work for one of these companies and you aren't able to influence the way things are done, it's most probably time to get a new job.
We've got into this mess after a decade of blindly implementing "Agile" techniques to the point where they have become lore; ubiquitous and unquestionable as to their effectiveness. We've made Agile about processes and tools (JIRA anyone?) rather than individuals and interactions. We've quite literally reversed the first rule from the Agile Manifesto, all under the guise of becoming Agile.
We've lost our way and desperately need to reset, to go back to the drawing board. To make Agile about people and interactions again rather than dogmatic process. A good place to start is with the daily stand-up. Start questioning it's effectiveness. Does it deliver value each time you get together or has it become a routine that feels comfortable even though you're getting very little benefit? A routine you're blindly following?
To get you started, listed below are 5 ideas that will help re-invigorate your stand-up:
Keep it Relevant
Ensure that each member is engaged and interested in what the other members have to say. The easiest way to make this a reality is the ensure that the right people are in the stand-up, no more and no less. This may sound obvious but all too often stand-ups consist of people from a business function (e.g. all of the developers) rather than a cross functional team delivering a project. There's little value to a developer working on project A getting an update on project B (or quite often also C, D and E) when it doesn't have anything to do with them.
Keep the Group Small
Multiple stand-ups limited to people working on the same problem is much more effective than one large stand-up. These stand-ups should happen at the same time, in parallel, to keep them predictable.
Vary the Frequency
There's no rule that says they need to be held daily, use whatever frequency makes sense for your team. For example, when you're starting the build of a new platform and there's a lot of ambiguity, twice a week may suffice. When you're migrating a live system onto your newly developed platform, you might need to move to twice a day. Stay flexible.
It's About the Team, Not the Manager
The stand-up is not a status update for the benefit of the manager; they're primarily for the benefit of the entire team. Question if there's any benefit regurgitating the prescribed format of "yesterday I did x, today I'm doing y". If people are engaged, listening and care what is being talked about, simply stating what you’re currently doing and when you think it will be complete is all that's needed.
Respect the Maker's Schedule
I'm a big fan of the essay by Paul Graham, Maker's Schedule, Manager's Schedule. Stand-ups should be held before the maker starts to concentrate on what needs to be made. If you schedule the stand-up for 10am, the time between when a developer arrives and when the stand-up starts can't be used for deep work and is effectively lost. Over a week, that lost time can really stack up and could be costing you up to a day a week in lost productivity. To reclaim the time, schedule your stand-ups just after people arrive for the day or just after lunch. Mid morning or mid afternoon should definitely be avoided.
Hopefully that's given you food for thought and sparked a few ideas about how to start getting the most from your stand-up. On a final note, introducing change can be hard. People are resistant to change (yes, even developers) and too much change at once can cause people to get defensive and reject ideas that may actually be to their advantage. My advice is to take it slowly. Introduce ideas one at a time and give them a chance to bed in before moving on to the next. Evaluate at each step and adjust accordingly. Keep it human, keep it, err, agile.