~4 min read|
In a Scrum / Agile workflow, one of the most important meetings of the day is the daily Scrum / Stand Up. It’s also one that’s so easy to mess up. Our team’s been experimenting with the daily stand up in an effort to make the meeting more valuable / useful.
One experiment in particular has been particularly useful. Instead of asking each member of the team to answer
with it to see how we might get more value from it and a few months ago we started talking through the board right to left.
This was a departure from my past experiences where Stand Up meant reporting out on 1. What I worked on yesterday, 2. What I’m planning on today, and 3. Blockers impeding my progress.
I loved the new approach. It got the whole team focused on where things stood for the team. It encouraged working together to “push things to the right.” For the first time, stand up felt collaborative. As a team we could spot blockers, identify slow tickets, and devise plans to help the work continue to flow.
These benefits, it turn out aren’t actually novel. They largely mirror how Scrum describes the “Daily Scrum”:
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
At some point, we lost that thread. While we were still working right to left, we’d fallen into a cycle of really chiming in only on the work we owned and losing sight of the collective decision-making.
So, we’re learning. We’re iterating. We’re adapting.1
The realization that we’ve wandered from the path led to some really interesting discussions about the purpose of stand up. As I noted above, the meeting’s really easy to mess up because it’s so easy to fall into a status update - particularly one that reports up.
That’s not the meeting’s purpose though. Instead, a successful standup ensures that the team has a plan to make progress toward the “sprint goal”.
Focusing up / transforming into a status update is easy, particularly when the meeting is run by an authority figure, i.e., a manager (there just aren’t that many organizations that can have a dedicated Scrum Master).
What happens if you reframe the communication from up to out, from providing a status to telling your peers , teammates, and collaborates what they’re interested in knowing and working through problems? What would you need to change in what you say and how you say it to achieve that?
If you stop thinking of the stand up as an audit of your time and rather as a collective planning session, what you say will very likely be more actionable and useful information for the rest of the team. Instead of “I worked on X, today I’ll be switching to Y. No blockers here.” Maybe the following is more useful: “To solve X, which is now ready for testing, I introduced a new technology. I also noticed that testing revealed a bug over in this area of the code, so there’s refactoring I did there. Joe, you may want to take advantage of that when you pick up the ticket Z. Today, my plan is to dig into Y and have no blockers right now - though I think we would benefit from having a strategy for adopting new technologies going forward and whether we’re okay with the approach I took here.” Product knows where you are, but the engineers also know how you went about it and can come together to make a decision on something that affects everyone.
It’s also longer, sure, and definitely not a read out.
A stand up is a piece of evidence. It’s an artifact of the team’s. Don’t squander the opportunity to use them to learn, iterate, and adapt. It’s all part of the cycle.2
Hi there and thanks for reading! My name's Stephen. I live in Chicago with my wife, Kate, and dog, Finn. Want more? See about and get in touch!