Daily Standup Meetings
Half the Pain, Twice the Value, No Joke!

Fast and Ambitious OKRs for Software Engineering Managers and Teams

August 2, 2021 No Comments

What should be your goals as a software engineering manager? What are the goals for your team? And how do they align with your company’s goals, vision, and mission? More than just goals or kpis, the best way to answer these questions is with Objectives and Key Results.

To Rewrite or Refactor? Shakespeare for Software Engineers (sorta)

July 27, 2021 No Comments

What is the difference between refactoring and rewriting? What are the reasons to refactor or rewrite code? What is the good time to refactor or rewrite? Learn all about it and discover Gitential’s metrics for refactoring and rewriting.

By Gitential Team

A Jedi Master, an engineering manager, and five software developers enter a bar and… Oh, wait, you meant to ask about how to make daily standup meetings more useful, valuable, and engaging? Oh, c’mon – just tryin’ to be funny. Fine, fine.

To be clear, standups are important, and most developers like them. If they are set properly. But, having sat through many bad standups over the years, I know some of you share the pain. This is why this article tries to help you to enhance the experience for your team.

What Is a Standup and What Are Its Objectives?

In a nutshell: standups are short 15-minute, daily all-hands meetings for sharing information to help your team stay informed, focused, and efficient with their current tasks. It’s advisable for standups to be held at the same time every day just so everyone can plan them into their day, every day.

While standups are not required by Agile, they provide an opportunity for your entire team to interact face-to-face or via video chat. These are the most effective modes of communicating for co-located and distributed office environments. There are two primary formats for conducting startups – the “Yesterday, Today, and Blockers” format and the “Walking the Board” format.

The Yesterday, Today, Blockers Model

This is a typical format for a standup meeting. It’s is run by a Scrum Master asking each team member the same three questions every single day:

What did you accomplish yesterday?
What are they working on today?
Are any obstacles hindering your progress?

This format depends upon self-reporting where answers may reflect more on the individual than the task. It’s also likely that team members are thinking more about what they should say than listening to what others are sharing. Not everyone is brave enough to volunteer that they need assistance with a task. This standup routine can be painfully monotonous. If you’re using this format, and you can see engagement could be better, you might just need to mix up the format.

The Walk the Board Model

This format accomplishes all of a standup’s objectives in a more direct, faster, and visible manner focusing on task status instead of the individual. Tasks in your project management software are likely defined by four main states. In this model, we read them from right to left. They correlate to Release, Test, Develop, and Backlog. A quick mockup is provided below, and it’s illustrated further down in the YouTube video by Development That Pays.

BACKLOG

Task
Task
Task
Task
Task

DEVELOP

Task - Luke
Task - Lea
Task - Hans
BLOCKED
Task - Darth

TEST

Task - R2D2
Task - C3PO

RELEASE

Task - Obi
Task - Yoda
Task - Yoda

The individual running the startup doesn’t need to be the Scrum Master. Any team member can be the meeting’s facilitator and it’s strongly encouraged to rotate the baton to promote team ownership of the process. Rotations can be daily, weekly, by Sprint, whatever works best for your team. Here’s how it works:

The facilitator identifies one task at a time, starting on the right and moving left.
The developer assigned the task shares its current progress or if they need assistance.
If a task is complete, the facilitator or developer can move the card to the next column.
If the developer is challenged, those able to assist can chime in to talk after the meeting.
After reviewing all assigned tasks – check to see if anyone is ready for more, whether to help others finish their tasks, or start on new tasks from the backlog.
The facilitator finishes by asking if anyone has anything else to bring up. This is an opportunity to get some extra value from the meeting.

This inherently focuses more attention on the board and what others are saying than planning what to say. It also gives each team member some recognition and a little bit of a rush in being able to move the project forward. You can still get some more value from your standup, though.

Using Data to Make Your Standups More Effective

Scrum masters, software engineering managers, and development teams can and should have a part in making standups more useful, valuable, and engaging. Just as iterating can improve software, it can improve processes. So, feel free to experiment. In this regard, there’s a load of data that you can use to improve your standups.

Tips of the Day (or Week)

Best kept as a quick (15 second) mention and pinning on your Whiteboard, unless you find it too disruptive. This is a quick and easy way to share something useful, whether an inspirational quote, a short coding tip, reinforce a coding standard, company news, recognize birthdays, anniversary dates, graduations or certifications, links to short articles or videos related to the project, announcing pizza day or discounts on products of interested to your team.

Though this doesn’t serve the specific objectives of the standup meeting, it can be a small boost to team morale and reinforce a pleasant work environment.

Commit and Pull Request Metrics

Trust, but verify is a good practice. It’s easy to spot pull requests that are taking longer than they probably should. Most would also agree that a developer may be encountering difficulties if they’ve not made a recent commit. A standup is a good place to simply ask the individual about any complications they may be encountering with specific tasks so other team members can offer assistance directly.

Specific metrics can be gamed, but not in front of everyone and not for long when an engineering manager has access to an automated and comprehensive range of development metrics. Likewise, single metrics, especially outside norms can indicate that there may be a problem and prompt additional research (examining additional metrics). Even with automated performance metrics, this can take time to do for an entire team and will eventually lead to verifying any challenges with each team member.

Retrospectives

Our “Step 4” in How To Use Data To Make Retrospectives More Effective, advocated identifying 3-4 issues or metrics to improve each Sprint. After all of the tasks have been discussed, it’s worthwhile to spend a minute or two to reinforce this effort to focus on one of those metrics. You can ask the team if they’ve discovered any tips they’d like to share. On the same score, you might share metrics or ask about how they feel about progress made on items identified for improvement in previous retrospectives.

Sprint, Epic, and Release Burndowns

These can be good visuals to pull up for your standups to get a sense of whether your team’s on track. As it’s likely that you prioritize your tasks, task status plus the Sprint burndown can help guide decisions. If one developer finishes their work faster than expected, should they help another member finish their task or start a new task from the backlog? Most of the time, it’s sensible to focus on finishing tasks, but that’s not always going to be possible.

About Gitential

Gitential helps you to improve the performance of your software development team based on their Git activities with actionable insights. Our advanced software development analytics provides developers with automated performance tracking of key metrics and easy to understand graphics. Given the importance of cycle time in software development, these metrics can help you to boost your team’s productivity, efficiency, quality and collaboration. If you have any questions, please let us know at gitential@gitential.com. We welcome you to sign up for a free trial, no credit card is needed!

Fast and Ambitious OKRs for Software Engineering Managers and Teams

August 2, 2021 No Comments

To Rewrite or Refactor? Shakespeare for Software Engineers (sorta)

July 27, 2021 No Comments

Software Code Quality Metrics Simplified!

July 20, 2021 No Comments

What are the metrics for software code quality? How do you actually measure code quality? What are some best practices your team can use?

Spread the word

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Daily Standup Meetings
Half the Pain, Twice the Value, No Joke!