Have you ever participated in a daily scrum where the only takeaway was that someone was working on something already listed on the board? You left without knowing how that task would impact others. While the notion of having a daily standup is noble, it provides little value if the team isn’t fully engaged and actively listening to the details. I’m willing to bet that if you’ve encountered the scenarios above, half the team isn’t listening. Why? Because they cannot draw a straight line between what they are doing and how their accomplishments are aligned with Sprint Goals.

Daily Scrums are meant for the whole team to collaborate and adjust if things start to veer off course, in order to meet the sprint goals. But if the meeting devolves into a mere checklist of statuses, it defeats the entire purpose. In many ways, I believe this meeting to be the heartbeat of a team, requiring diligence to keep the heart beating. This is where the expertise of a technical leader comes in!

As a Technical Leader, especially of a feature team, part of your responsibility is to ensure that your technical team is on track to accomplish the goals you have committed to for the sprint. If not on track, you must be able to efficiently pivot without sacrificing quality. While there is no silver bullet, one of the most effective ways to achieve this is to simply take advantage of the Daily Standups/Scrums and not let them turn into routine status meetings. This requires you to understand your technical team and architecture well enough to pick up on certain cues that could indicate risk or reward.

Key Indicators to Watch For

1. Tasks Taking Longer Than Expected
   Tasks involving the implementation of a known pattern that are taking longer than expected could indicate that the architectural pattern is not the right fit for the problem, or there is simply a misunderstanding of the pattern.
   
2. New Architectural Patterns
   The introduction of new architectural patterns may cause confusion, perhaps due to not fully understanding the pattern or why it is being used. Ensure the team is using it correctly and for the right purpose.
   
3. More Bugs
   An increase in bugs found by the collective team (i.e. QA) could indicate a lack of unit tests, misunderstandings of requirements, poor quality code, etc.. These could indicate deeper issues and must be addressed promptly.
   
4. Blocks on Other Features/Teams
   Blocks could indicate a tight coupling that violates architecture and should be avoided. It might also mean that priorities need to be adjusted to complete a dependency, or that teams aren’t communicating effectively.
   
5. Tasks not on the Sprint Being Worked On
   This could indicate that discoveries are happening often, which might indicate that the team did not plan thoroughly during sprint planning or there is a misunderstanding in the business requirements. The whole team needs to be aware of these types of discoveries and adjust as this may impact the sprint goals.

This is not an easy task, especially as your team grows and the complexity of your features increase. It becomes increasingly important for the technical leader to be aware of all the activities surrounding their team. The technical leader must know how things are progressing throughout each sprint to ensure things are on track. But more importantly, if things are not on track, it’s crucial to make adjustments. This is not trivial by any means. However, if done right, the daily scrum can be a great tool and a window into the health of your team to catch any challenges early.

Once very simple approach that I have used in the past that changed the dynamics of the daily scrum was a simple verbiage change, taking the focus away from just statuses. Instead of the standard questions “What did you do yesterday?” and “What do you plan to do today?”. Use the following: “What did you accomplish yesterday?” and “What do you plan on accomplishing today?”. The term “accomplish” implies a focus on productivity and effectiveness towards the end goal versus simply a status of activities without specific concerns for the end goal.