Agile Scrum–Part 1 The Daily Scrum
Sharing Our Expertise

Our consultants solve challenging business problems and love sharing their knowledge. Tap into our insights and put them to work for you.

Back to Blogs >>

Published by Kathy Eager, on Wednesday, August 8, 2018

If you just cringed when you saw this was about Agile, you’re doing it wrong.

I recently spoke at CollabSphere about Agile Scrum. What I realize in conversations with attendees was just how many places are doing “Agile” (some mishmash of techniques that they’re calling Agile), but not actual Agile Scrum.  They don’t include the true spirit of Agile. It’s really a shame because Agile Scrum has so many benefits and isn’t as terrible as many people think. I’m hoping to break down a few of the things I heard and explain how to do them better.

If you’re a developer, your first fear (or sadly, experience) may be that Agile Scrum sounds like micromanagement and endless meetings. If done correctly, it shouldn’t be either of these.

I’ll start with the Daily Scrum, or daily stand up, whatever you want to call it. I’ve heard nightmare scenarios where the daily scrum lasts an hour. This is flat out wrong. Per the scrum guide, the daily scrum should be time-boxed (aka last no longer than) 15 minutes. The dev team states what they did, what they’re doing, and if there are any blocks. That’s it. There should NOT be 30 minute discussions of the user story, or detailed conversations of technology, or anything beyond what they did, what they’re doing, and if there are blocks. If your scrum master keeps everyone on track, you’ll be done within the 15 minutes. (If your scrum master doesn’t keep everyone on track, then THEY are doing it wrong).

I like to say “it should be about checking in, not checking up”. If your devs feel like they’re being micromanaged during the stand up, you’re doing it wrong. The value and the benefits of the stand up are a few things:

1) If someone is blocked, the scrum master is alerted, and it’s the scrum master’s job to remove that block. Say your dev is blocked because they don’t have a login to the system. Should they waste time chasing down a login? No, the scrum master can do that, while the dev does development.

2) Sharing knowledge. I don’t mean the stand up is the time for a developer to lecture on how to do something. What I do mean, is a developer might say they’re working on a document upload feature today. Another team member might hear that and say, “hey, we’ve already done that on this page, you can probably just use that code”. Or a dev might say they’re stuck on a particular plug-in and another dev might be able to offer their assistance (at a later time, not during the scrum).

The value of the scrum is communication, not checking up on whether people are getting their work done. Feeling like you’re being micromanaged doesn’t foster efficiency or provide motivation. The core of Agile Scrum is about seeking efficiency. So make sure your daily scrums are checking in, not checking up!


Categories: Technology,Agile,Agile Scrum,PSC

Original Post: https://iamkathybrown.com/2018/08/08/agile-scrum-part-1-the-daily-scrum/

Recommended For You
PSC's Kathy Eager is now a Professional Agile Scrum Master.
View More ...
Collaboration and flexibility are key tenets of Agile. Now modern tools exist that allow teams to communicate as openly and easily as shouting ov...
View More ...
Executives don't want to be told they have to learn something new. Lead your stakeholders to Agile using concepts they already understand.
View More ...
As a consultant, selling Agile can be a tricky business. To many executives, “Agile” smells like time and materials, yet it can help deliver exac...
View More ...
When working on agile projects, PSC recommends using Azure DevOps as the management tool of choice and building, testing, and deploying SharePoin...
View More ...
Fibonacci numbers facilitate countable user stories of measurable effort that lead to project management with reliable completion dates and budge...
View More ...