Red Flags Spotted in the First 5 Seconds of a Stand-Up Meeting
You are new to the organization, coming to the first daily stand-up and, instantly, something doesn’t feel right. Let’s review the immediate signs pointing to the wrongly-implemented agile processes and, of course, the corrections worth making.
Symptoms
- It looks like a zombie parade: everyone starts from what he/she was doing yesterday, followed by the recent plans for today.
- People solely report to the facilitator: scrum master, product or project manager.
- The facilitator just says “ok” when a member finishes his update and moves on to the next member.
- The facilitator is the only one who asks questions.
- Participants just wait for their turn to talk and don’t listen to what others are saying.
- The kanban/sprint board is not presented during the meeting or each one just looks only at his tasks.
- The board is not updated or participants update it as they speak or, even worse, the board is maintained by the facilitator.
- Members often tell they have nothing to do for today.
- Some prioritized tasks are stuck “In Progress” or not picked up for too long.
- The number of tasks which are “In Progress” is considerably higher than the team headcount.
- Team leaders have much more tasks than juniors and mids.
- Tasks are being moved to “Done”, but nothing is released to production.
- Tasks titles refer solely to technical activities (e.g. “Rename database column A to B and deploy”).
- Some people have bandwidth but say they cannot take any of the tasks left in “To Do”.
What’s wrong and how to fix it?
The company goal is to create self-organizing teams, able to deliver their sprints together as a single operational unit. The symptoms above tell the story of an un- or mis-orchestrated team where everyone is on his own (or out of focus) and there is neither an understanding about the company milestones nor which steps should be taken to deliver them.
- Make the communications delivery-centric: talk about hands-offs, announce heads-ups and share time estimations. e.g. instead of Alice saying “I was working on feature X yesterday and will continue tomorrow, you’d rather prefer to hear her saying “I plan to pass feature X to QA to Bob by today and switch to feature Y”. Watch Bob turning his head to Alice and keep smiling.
- Explain that failure isn’t when something goes slower than expected or even when it’s stuck. A team failure is rather when people are not helping each other to deliver the designated scope, e.g. updates like “I need help reproducing the bug X from Carol” or questions of the sort “David, do you need help with the task you took 2 days ago?” are good signs that things start working as they should. Encourage the team to ask these questions without waiting for your sign.
- At the end of each meeting ask the team to look at the board and burndown chart to examine the sprint condition, e.g. the closer we are to the end of the sprint, the fewer tasks should remain in “To Do” or “In Progress”.
- Review sprint goals when starting or ending the meeting, and ask the team whether we are still on track. When red flags are raised, outbound communication regarding delivery timelines, tasks’ reprioritisation and sprint scope reduction are natural to happen.
- Help the members to overcome ambiguities in announcing that something is “done”: for the devs’ perception, the task is not done till QA validated it in production. This terminology is misleading as the team’s goal is to deliver the task to production. Use the actual task status such as “moved to QA” or “waiting for code review” etc.
- This one is a bit tricky but still might work for small teams from time to time: ask team members to update on someone else’s tasks. That would help to understand that everyone (and not only the scrum master or product manager follows what happens).
- Some team leaders tend to cover the ass of their teams, by actually executing their tasks instead of coaching their subordinates (or firing them if no way to align worked). Encourage the leaders to spot the potential roadblocks, and to focus on helping the team to grow professionally by teaching the subordinates to solve these roadblocks, even when it takes time at the initial stages.
- 95% of the tasks’ titles should be in product language. Help the team understand what exactly they deliver to the users, in users’ terms. The tech details stay in the description. Exceptions to the rule are mostly technical debt as “Upgrade library X to version Y” but even then when the library provides new capabilities it’s better to say what the upgrade will mean for the users such as “Improve performance when loading images”.
- When some tasks are left in “To Do” and no one from those who don’t have any tasks “In Progress” cannot pick these tasks up it usually means that either capacity calculations should be improved or the members’ qualifications are too specific. Encourage broadening of professional horizons by knowledge sharing sessions among the team members and some tasks given outside of one’s comfort zone.
Conclusion
Spotting problems in 5 seconds is easy, fixing them even in 5 months is not. Yet, when I started as PO in Agoda (a part of Booking Holdings), it took just a few sprints when applying the techniques above led to 33% velocity increase of the booking engine dev team!
Use the well-known agile meetings to help your teams to grow professionally, e.g. small hints on dailies, longer discussions on retrospectives with proper followups, specific agenda for dedicated knowledge-sharing sessions so that the things planned to start doing won’t be forgotten.
The last but not least, when managing remote teams ask people to switch the cameras on to improve the personal touch. Some wouldn’t like to expose the interior of their houses, this is where computational backgrounds would come to the rescue. There is nothing like seeing everyone on the screen smiling when the sprint delivery is accomplished.
Thanks to Alexandra Shelenkova for the great artwork illustrations.
