Every day, the team gets together for a quick synchronization point: a short, informal chance to make everyone aware of what’s been learned, what’s been fixed, who’s doing what today, if we’re on track, what problems we may be facing, and what business value tasks we’re completing. This is expressly not a status meeting or report to management.
This is a simple exercise in shared communication. The whole point is to have each team member quickly share what they’ve accomplished, what they plan on contributing today, and what problems may crop up.
Airing this information helps reduce risk and increase collaboration, and increases transparency to executives and other areas of the organization.
Team lead/manager actively notes and works on clearing blocking issues (+5pts)
❑ Critical ✓ Helpful ❑ Experimental
Steps to first adopt this practice:
You might think this practice looks familiar to you as the “Daily Standup” from Scrum. However, the TeamSync is not the same thing as a Scrum Daily Standup. So to avoid confusion, we’re using a different name to clarify and to emphasize its purpose: this is a sync point for the team.
It needs to helpful to the team. It’s not a status report for management or stakeholders. The actual questions don’t need to be set in stone. It does need to be quick and helpful.
The first item is critical: what did you discover yesterday? What did you learn, or conversely, what did you share and teach to others? Everyone should probably have an answer for that at least several times a week, if not every day. If weeks go by without anyone learning or discovering anything new, then you have an obvious problem.
The second item is a more pointed version of “what did you work on yesterday.” The actual question being asked here is “what value did you create today,” but that’s too abstract for daily use.
So instead we ask “what did you ship?” In this case, ship does not necessarily mean “deployed to all end users,” but asks what was actually completed: finished to a shippable state. Or, what did you fix, in terms of process, broken tooling, environment, infrastructure, etc. It’s important to report on what’s finished, not just what you’re working on. The idea is to break tasks down to a small enough granularity that there’s a sense of accomplishment every day: something is finished and ready to go, ready to deliver value.
Third is a variant on what will you work on today. Can you confirm that it’s the most important thing you could be doing? Is that still true? Has anything changed?
Finally, the good old impediments question, with a twist: not only is there something blocking you, but are you planning on breaking anything today? Is there a risk there we should know about?
Remember this is not a status report to your manager or team lead. This is a peer-to-peer activity to help keep everyone aware and “in the loop.” The manager’s role is not to evaluate status, per se, but rather to note the obstacles that are slowing or blocking developers, and start to clear those obstacles away.
In fact, any sort of “status report” is a side effect at best. The TeamSync is by and for the team. Other interested or managerial parties may watch if curious, but may not speak or actively participate.
In a frequent/continuous delivery environment, observers should not be getting their status from this meeting, but instead should be getting a sense of progress from actual delivery, and also from any Big Visible Charts in the team area.
While this practice is laid out here for one team, of course you can extend it to a hierarchy by sending a representative from each team to for a higher-level, multi-team sync. However, that is a more advanced stage, and we do not recommend attempting that until all the teams are already highly functional at the “Working” stage or better.