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’s 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 log in to the system. Should they waste time chasing down a log in? 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 an 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 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!
[…] recently wrote about Agile Scrum – Part 1 The Daily Scrum, in an attempt to dispel some myths and hopefully give tips on how to better use the Agile Scrum […]
This is a great postt thanks