Status Hero FTW
I am not a fan of daily “standups” or scrums, a fundamental component of Agile with Scrum project management, and I recently came across a cool service called Status Hero which cleanly implements a much better solution.
A typical standup is a short, in-person meeting where team members gather, often in a conference room, and verbally give the status of their current work. A standup gets its name from team members physically standing during the meeting with the intent that no one wants to stand very long and so, meetings short are automatically kept short.
Each team member gives their status in the form of answering 3 questions:
- What did you do yesterday?
- What are you working on today?
- What blockers have you run into?
If a team member has questions or needs to discuss something further, a “parking lot” session sometimes occurs after the standup has concluded. Interested parties stick around for the parking lot discussion while others can leave and get on with their work.
Standups Are An Antipattern
An important goal of daily standups is to identify blockers as soon as possible, bringing them to the attention of the team, so that they can be dealt with quickly. Ideally, if someone on the team is blocked, someone else on the team, perhaps a more senior resource, can help remove the blocker or at least assist in the effort.
Consider a team with a daily standup at 10am. A junior developer reports everything is going well and will deliver a new feature by the next standup. After the standup, the developer continues working and runs into a major issue. He works all afternoon trying to figure out a solution. At the next standup, the developer reports that the feature is not complete and is blocked. The project manager is upset because she sent a status email to management at 6pm the previous evening that the feature was on track and QA could start testing in the morning. Now she has to backtrack that news, QA can’t start testing, and she looks, generally speaking, like an idiot. Another developer hears about the blocker and says “Oh, I know how to fix that. I ran into the same thing last month. It will take a few hours but you just need to do this and that and it should work.”
Using the standup to communicate blockers is an antipattern. Blockers should be communicated as soon as they are discovered. If the developer had made the team aware of the challenges when discovered, the feature might have been delivered on time.
Common Problems with Standups
There are a number of problems I encounter during standups that I particularly dislike:
- Overly detailed. An ideal scrum is less than 15 minutes long and each team member should speak for only 60–90 seconds. However, most teams are not particularly disciplined in answering those 3 questions concisely and often give far more detail about what it took to do their work or digress into unrelated matters. Especially with remote team members, that urgency to be succinct is lost as everyone is sitting comfortably at home, feet up, caffeinated beverage in hand, waxing eloquently about how they solved a problem yesterday or droning on about the unexpected complexities of their current assignment. I’m as guilty as anyone on this even though I know that no one is really interested in hearing the details of my elegant new terraform template.
- Synchronous. A standup requires all team members to be in the same place, or on the same call, at the same time every day. Inevitably, someone will be unable to attend due to a conflict, their internet is down or sketchy, there is a last minute emergency, or they simply forgot or missed a reminder to attend. This happens fairly often, understandably, and so the status of one or more team members often goes missed.
- No single time works for all. Team are now often composed of remote workers. This became especially true during the pandemic when offices were closed. Individuals working from home, working in different time zones, or even working in different countries, are all collaborating on the same projects. It is unreasonable to expect such diverse teams to personally be available every day at the same time.
- Cross-functional noise. In many standups, people on the same team are working on unrelated projects. While interesting to project managers, hearing some team member’s status on a random project completely unrelated to you, is frustrating and a giant waste of time.
- Disruptive. It’s disruptive to your flow. Every engineer, developer, artist, designer, or other professional that needs to create, knows what “flow” is: that feeling of energetic productivity where solutions come quickly and everything is coming together perfectly. Stopping what you’re doing to go off to a scrum for 30 minutes disrupts that flow. After the scrum is over, that flow is often wrecked and can take hours to get back into, if it comes back at all.
- Too many people. As companies grow, teams grow, and the number of people in a standup increases. The official Scrum Guide recommends a maximum of 9 people in a standup. Even if all 9 people stay on a strict time limit of 90 seconds per team member, that’s almost over the 15-minute time limit already.
- Ephemeral. The biggest issue is also the one that Status Hero solves best: the content of the standup is ephemeral. Unless someone is taking diligent notes about every team member’s status, there is no record of anything discussed. As a project manager, this would concern me as there is no way to trace back through someone’s work, no evidence of someone bringing up a problem, and so on. I think a standup would be much more effective if there was an artifact from it, documenting the progress, issues, and blockers.
Slack Standup!
From time-to-time, when enough people are unable to attend the scrum, the project manager might suggest doing “Slack standup”. This is where every team member is expected to write a set of bullet points in Slack (or whatever team chat app is being used) itemizing what they worked on yesterday, what they are planning to work on today, and what blockers they have encountered.
Although not everyone is necessarily reading Slack at that moment so they might not see the announcement or they may see it later. This results in a scattering of status updates in the channel throughout the day. A dedicated Slack channel for standups fixes this but it’s still a very informal way to capture status. For example, I’ve never seen a project manager actually follow up with someone who neglected to post their status in Slack. A manager would need to tediously scroll back through all the messages, looking for each team member’s status, and remembering to follow up with the negligent ones.
Status Hero to the Rescue
Status Hero makes the daily scrum a trackable, asynchronous event. Its feature list is pretty impressive but the ones that stand out for me are:
Asynchronous updates. No more standup meetings. Developers simply check in and leave an update. Updates are clear, readable, and meaningful:
Collaborative status threads. Team members can easily react to and comment on individual status updates. If someone is blocked, team members can leave thoughts, advice, and solutions in a thread directly associated with the blocker.
Blocker alerts! When a team member enters an update that indicates something is blocked, the entire team is notified in real-time. No need to wait for the next scrum and no need to bring everyone together on a call to announce the blocker. Everyone is made aware and, hopefully, can start a thread and leave help.
Integrations and activity streaming. Status Hero integrates with other apps and services like Jira and Github so updates can be made from one place. A ticket can be automatically moved to Done in the same status update that announces the work is complete. Pushes to Github can be announced in the activity stream. The stream then becomes a living record of all meaningful work committed by the team.
Multiple team support. This makes Status Hero easily usable in a larger organization where a scrum master manages multiple teams.
Daily goals. Has a team member ever said “and this story should be done tomorrow” and the next day the update is “and that story I said would be done today will be done tomorrow”? Status Hero allows a small goal to be entered and checked off at the next update: “Charles said the RDS database would be available tomorrow.”
Easily searchable. How helpful would it be to search for feature and find every status ever entered, by any team member, related to that feature? The status updates become a narrative describing the progress of a feature over time. Or search for Bob and read all of his status updates in one place. Perhaps searching for 502 error might reveal messages where others encountered and solved similar issues.
Observer mode. Leadership might want to have visibility into a team’s daily workflow but does not want to have to leave a status or take a role on those teams. Observer mode was made for them.
Vacation and holiday tracking. You know what sucks? Someone sending an Outlook calendar invite to their whole team for their Out of the Office event. That’s what I want to see fogging up my calendar: everyone’s days off. But, of course, if I decline the invitation, the event disappears and I have no way of knowing if someone is not working. And when is that information most relevant? During standup! Instead of wondering why Bob isn’t present on the call — is he in another meeting? did he forget to dial in? is he on vacation? — a team member can flag that they are out and everyone knows. Problem solved.
Status Hero is enterprise-ready with SSO and robust security. Prices are $7 per user per month at the Corporate level, which should suffice for most organizations that use SSO. This is one of the few services I can recommend paying for because the time savings and efficiencies. There is a Savings Calculator and the savings are significant. The more team members, the greater the savings. The more time saved in standups, the greater the savings. This one is a no-brainer.
