Daily Scrum

Do the same as in experiment 1, but give each Team Member the same amount of time, and start counting down for every Team Member.  For example, if you have 7 people on the team, give everyone a maximum of 2 minutes each.

Create a talking token.  A talking token is passed around the team, and the only person allowed to talk is the person with the token.  This stops people from over-talking each other, but it doesn’t stop them from talking too long…

If the team has strayed from using the basic 3 questions, and the team is not satisfied with the Daily Scrum, go back to the 3 questions.  If you need a refresher…

1. What did you do yesterday to get closer to the Sprint Goal?
2. What will you do today to get closer to the Sprint Goal?
3. What is slowing you down?

Create a talking token.  A talking token is passed around the team, and the only person allowed to talk is the person with the token.  This stops people from over-talking each other, but it doesn’t stop them from talking too long…

If some Team Members are constant stragglers, try to get them to speed up a little by just starting without them.  They are on the hook for knowing everything that happened in the meeting, so maybe they’ll get the hint.  It’s passive aggressive, but sometimes works.

Pass a rule on the team, that if you show up late for the Daily Scrum, you have to go last.  It’s not a real punishment, because someone has to go last everyday, but they might see it as a slight embarrassment.

Impose a fee for being late.  There’s really no excuse to be late, so have them pay a nominal fine for it.  At the end of the Sprint/month/year go out for pizza (with the team).

The purpose behind the Daily Scrum is 3-fold – to update the Team on what you’ve done to get closer to the Sprint Goal, let the Team know what you expect to be doing next, and to get help for anything that’s keeping them from helping the Team get to the Sprint Goal.  Anything more or less than that isn’t really doing the Daily Scrum justice.

If the Daily Scrum has turned into a status meeting, your Team is missing the point.  Status meetings are detailed, long and (in many people’s opinion) BORING!  Usually, by the time something interesting is revealed, everyone has tuned out.  Don’t turn the Daily Scrum into a status meeting, it won’t serve the Team.

Bring up your concerns at the next Retrospective and see what the Team wants to do about the structure of the meeting, and then make the agreed upon adjustments.

Remove the ScrumMaster from the meeting.  The updates are for the other Team Members, so have the ScrumMaster join after the updates are over, or not at all.  This almost forces the Team to start taking on more responsibility for their actions and their needs.

When the ScrumMaster isn’t present for the Daily Scrum, the Team should proactively make a point to update the ScrumMaster on any impediments they uncovered during the meeting, and any other important facts that would make the ScrumMaster’s job easier.  If they don’t, the ScrumMaster should reactively follow up with Team at some point during the day when several Team Members can chip in on the conversation.

If the team usually forms a circle or semi-circle (both are very common), have the ScrumMaster stand behind the Team.  Even more effective, have the ScrumMaster stand behind the person currently talking.  This makes it nearly impossible for the Team to talk to the ScrumMaster.

In a clearly passive aggressive move, you could always move the Daily Scrum to another location, another time, or both.  By having the Daily Scrum without the Product Owner, you could avoid the command and control task mastering behavior.

Beware, this will undoubtedly result in some sort of retaliation if the Product Owner is not told about this ahead of time.  Even then, this must be handled very delicately be a seasoned facilitator.

Exercise the Team’s right to only invite Team Members to the Daily Scrum.  This is a planning meeting for the Team, by the Team.  The only mandatory attendees are the Development Team members.

As with Experiment 2, beware.  This requires the mediation of a good facilitator to pull off with no negative repercussions.

If you and your company believe in certifications and the value they project, then send the ScrumMaster to a certification course.  Personally I prefer the Certified Scrum Master (CSM) courses from Scrum Alliance, but Scrum.org offers Professional ScrumMaster (PSM) courses as well.  Arguably, they are both well suited to inform your ScrumMaster that they are a servant leader, not a task master or manager.

Sending the ScrumMaster to a course, rather than reading a book or watching a video, is key.  The courses are immersive and allow the ScrumMaster to not only learn from a very experienced trainer, but also hear from other students and their experiences.  This is incredibly valuable.  Books and videos are passive and not very responsive when you might have a question, or even a quizzical look on your face.

Bring in someone who can help the ScrumMaster understand that they are also part of the team.  Labeling the work of the team as a failure, is reflective on the ScrumMaster just as much as the team that produced it.  Not to be left out, it’s also a reflection on the Product Owner.

I recommend bringing in someone from outside the team to talk to the ScrumMaster, because if this is the ScrumMaster’s behavior, it’s likely (not predetermined) that they will not want to hear this sort of information from someone on the team.  People that treat other people this way tend to accept behavior-corrective information from someone they are hierarchically subordinate to, or at the same level, but from another part of the organization, or brought in as an external expert.

Convincing this type of ScrumMaster that they are an equal to other people on the Scrum Team will not be easy.  So, try to make it as painless as possible.

This is a good thing.  Read Experiment 1 again.

What will you do today to get closer to the Sprint Goal?

What is slowing you down?

I meant it the first time.  If you didn’t realize it before, that the problems won’t go away if you don’t solve them, then you are probably too reluctant to get the job done.  Find the person or people can than solve the Team’s problems.

This is a recursive algorithm.  If the Team has problems, fix them.  If you can’t find the person that can.  If they can’t, have them help you find the person that can.  Keep collecting helpers until the problems are solved.

Help facilitate the intent of the Daily Scrum, and ask if anyone has anything holding them back.

This is going to sound stupid, at first, but give it a try.  Listen more.  We tend to get caught up in the discussion about what’s going on sometimes.  If this happens, we are more likely to ignore, or just plain not hear the impediment that’s staring us in the face.  Try to keep an attitude of trying to call out impediments all the time.  If you are wrong, the rest of the team will let you know.

Encourage the entire team to write impediments on a highly visible board whenever they hear one – even if they aren’t in the Daily Scrum.  That way, you never miss one.

This can be a real problem, if it’s the ScrumMaster’s idea to not attend.  What matters is the affect it has on the team.  The ScrumMaster deciding the Daily Scrum isn’t important enough to attend, or that the team isn’t important enough…  That’s bad news.

The decision to not have the ScrumMaster in attendance should come from the team.  That doesn’t mean that the ScrumMaster can’t propose the idea.  I’ve done it a few times myself. I’ve had several teams try it without me, and one specific team just flatly say I had to stay.  Both responses I was cool with.  It showed me the security the team felt with having me there (or not).

OK, so an invitation to the Product Owner didn’t work…

Try talking to the PO.  Explain that the team would like their opinion on several things that routinely come up at the Daily Scrum.  Talk about the team’s needs, and how they are usually greater in importance than most other things the PO could be concentrating on instead of hearing the Daily Scrum’s updates.  Plus, it’s only 15 minutes out of the day.  That’s nothing!

Is this a distance thing?  Stop it!  I’ve told you before that distributed, remote, non-co-located teams don’t work very well.

I’ve been places where the only reason the Product Owners didn’t attend the Daily Scrums was because they had a 5-10 minute elevator ride to get to the floor that the team was on.  It still blows me away that they never considered it a credible improvement to move the PO closer to the team!

If you know that planting the PO close to the team is a good idea, then do it.  Have the PO move in with the team.  You’ll be a happier team for it.

If this isn’t getting in the way of the Team Members updating each other on things they are working on, allow it.  If it is, then maybe you should interrupt with something like…

“Hey, it sounds like we are about to go down a rabbit hole.  Can we delay this for just a minute, until we get through the rest of the updates?  Then we can get to the discussions.”

Hmm, let’s think about this a little.  Is this a good thing, or a bad thing?  You’ve, no doubt, been told by blog posts, Twitter tweets, and so-called Scrum experts that the team needs to keep the Daily Scrum to the same 3 questions and that’s it.  Hopefully, that short-sighted advice was followed up with something like “… and if the team needs to discuss anything, they should do so after all Team Members have had a chance to give their update.”

In truth, ultimately it needs to be up to the team to decide the format of the Daily Scrum.  This isn’t to say that the team shouldn’t start out with some guidelines for a Daily Scrum format, and then modify the meeting as the team matures.  In fact, if the team is doing that, then they are properly Scrumming the Daily Scrum 🙂

Think about it.  Scrum essentially boils down to doing what’s right for the team, to do what’s right for the customer.  You want know what’s right for the team, or what’s right for the customer until you’ve experimented a bit.  Scrum is ALL ABOUT experimentation.

So, all that being said, the team should decide what works for them.  If technical discussions are needed, and the team isn’t impeded by them, then I would lean toward allowing it.  If the discussions are holding the team back, then I would lean toward sticking to the originally agreed upon format.

Kinda.

The 2017 Scrum Guide says the team will come up with their own way of formatting the Daily Scrum.  The focus still remains on communicating and planning progress toward the Sprint Goal.  If the team chooses to do this by using questions, fine.  If the team chooses to do this by discussion, fine.  The questions provided in the Scrum Guide are merely examples to help you.

Why are you holding the Daily Scrum on the phone???  Why don’t you stand up, move to a common location in the office, and talk directly to each other?

I’m being purposefully obtuse.  Distributed teams are discouraged.  Many dysfunctions occur simply because you are not co-located.  If you accept being distributed geographically as an acceptable way to work, you inherently accept all the dysfunction that comes with it.

A phrase comes to mind…  “You get what you pay for.”

Carry a buzzer, or have a buzzer in the team room.  Every time someone interrupts during the updates, hit the buzzer.

Create a talking token.  A talking token is passed around the team, and the only person allowed to talk is the person with the token.  This stops people from over-talking each other, but it doesn’t stop them from talking too long…

Have a private conversation with the ScrumMaster about the role of the ScrumMaster in the Daily Scrum.  Really, the only thing a ScrumMaster should be doing during the Daily Scrum is listening and facilitating.  More often than not, this just means making sure the Daily Scrum happens, and recording impediments to follow up on.

If the team is ok with it, they might want to talk about this as a team in the next Retrospective.

Yup, this is another one of those Team Working Agreement answers.  Hey, if you made a rule that demands people to stand during the Daily Scrum, then it’s up to you to enforce that rule.

If you don’t have an ‘or else’ clause in the Team Working Agreement, then maybe you should.

Why are you standing anyway?  Don’t try to answer me (I’m not going to turn on the comments section).  Maybe ask that to the entire team.  If you don’t know why you are standing in the first place, maybe standing shouldn’t be a rule?

Most teams stand, because it helps them go faster.  It gets oxygen to the brain (supposedly – it’s not like I’ve seen the actual medical research data), and people don’t want to be standing around forever.  So, they learn quickly to make their updates short and their discussions concise.

Talk to the ScrumMaster and tell her why you’re fed up with this.  Odds are, she’s either got some ‘splainin’ to do, or she’s being pressured to give non-Agile or anti-Agile statuses (WASTE!) to someone else in the organization.  Either way, have the conversation and get down to why this is a poor practice.

Remember, the ScrumMaster is ultimately an optional invitee to the event!

Did the role/responsibilities of the ScrumMaster change over time, and now the team doesn’t appreciate this behavior anymore?  Don’t discount this as BS.  It’s absolutely possible that the ScrumMaster has been conditioned to behaving this way and just keeps doing it out of habit.

As an Agile organization matures, the behaviors should mature too.  If they aren’t, Retrospect on those behaviors and change as needed.

That’s the whole point of the Daily Scrum.  If you’re not talking about what’s going on, then you’re probably not really having a Daily Scrum.  It’s probably something less dynamic.  Take a look at what the Scrum Guide says about the Daily Scrum, and make sure you are at least trying to do a Daily Scrum right.  Then, ask the team why it seems no one know’s what’s going on.

If you are dedicated to using Scrum, you should be able to change your process so you are talking about up-coming work everyday.

Trade your current ScrumMaster with another.

Rinse and repeat until you find one you like.

(This is really bad advice, by the way)

In my experience, most ScrumMasters that try to manage the Scrum events, instead of facilitating them, are reformed Project Managers.  I have no problem calling them reformed Project Managers, because they are not in a PM role anymore, and they are on their way to becoming something else.  But calling them ScrumMasters is a stretch.

They haven’t learned the very first Value in the Manifesto for Agile Software Development.  People & interactions over processes & tools.  The process becomes less important over time, because people’s needs change like the weather.  Sometimes violently. Sometimes fluidly. Sometimes cyclicly.  ScrumMasters understand this are the best people at adapting to the needs of the system and the people.

So, if your ScrumMaster is in a reformation effort, try to help them through it, instead of beating them over the head with the ScrumGuide.

It’s disrespectful to be messing around with anything, phones, books, laptops, papers, your watch – anything – while others are talking.  Stop it. Set everything else aside for 15 minutes everyday and focus on what your fellow Team Members are saying.  They are talking to you by the way.

Scrum values discussed in this post: Respect, and Focus.

Keep that timebox!  At the end of 15 minutes, cut off all updates and go back to work.  If the ScrumMaster asks where everyone is going, tell them that the Daily Scrum is a maximum 15 minute event that the team uses to update the Team Members on the current state of the Sprint. Tell them that nowhere in that description does it say that the ScrumMaster needs to assert any kind of process authority or control.

That’ll teach ’em!

Let’s talk about the ‘letter of the law’ and the ‘spirit of the law’ a little.

Letter of the law: The Scrum Guide says “The Daily Scrum is a 15-minute time-boxed event…” and “…is held every day of the Sprint.” and continues with “…is held at the same time and place each day…”

Spirit of the law: If you talk candidly (and sometimes openly) with the most experienced Scrum industry leaders, you’ll find there’s a widely shared opinion that much of what the Scrum Guide says, is for new Scrum Teams.  We understand that teams evolve over time.  So, let’s explore one scenario. If a team is in constant communication, and they sit together throughout the day, there are going to be situations where that team won’t need a Daily Scrum.  Because, they’ve been talking all day long about what’s being completed, and what’s getting picked up. A Daily Scrum, for them, might be a waste of their time.  But, the ScrumMaster should still hold a block of time aside so the team can check in.  If they need it, someone speaks up and says so.  All agree to meet for the Daily Scrum, in that scenario.

The spirit of the law is that we need Scrum Teams to be as informed as possible at all times.  They need to know what’s done, what’s next, and who needs help.  They need to know what’s going on in the organization.  They need to know what’s coming in the future.  People need reminders about things they might have forgotten about.  And, if the team looks at a chart that expresses progress daily, they might be motivated a little.  These are good things that the Daily Scrum promotes.

No. Don’t do that.  Did you read the Principles Behind the Agile Manifesto?  Here, I’ll quote one for you…

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

That doesn’t mean face-to-face is the only way to communicate.  It’s just stating that it’s the most effective.  On the other end of the communication spectrum is smoke signals. Email is closer to the smoke signals end.

Don’t start emailing updates from anyone.  Ever.  You’re going to think ‘this is so much easier than going to the Daily Scrum’ and you’ll start finding excuses to not hold the event.  Very important ideas and solutions will never be fully formed, people won’t bring up impediments, and the list of anti-patterns will start unrolling before you like Santa’s list.

Just, don’t start down this road.  Only bad stuff will follow, and it’s so hard to recover.

OK, what’s the problem with breaking PBI’s down into simple daily tasks, then counting the number of done tasks, creating a percentage, and reporting on that?

The problem is that it is totally possible that you didn’t think about some tasks in the beginning of the Sprint, and that percentage was wrong when it was created.  Let’s say the team creates 100 tasks and each done task is 1% done. On day three of the Sprint, the team is 23% done and you realize that 3 steps were missed in 4 of the PBI’s.  So you add 12 tasks and you’re now at 20% done.  You’re going backwards.  And, let’s say that this happens every Sprint for the first few Sprint that a team is working together.

More often than not, when a team reports red/yellow/green, or percentages, they’re reporting UP.  So, if the team is routinely going backwards, and that keeps getting reported up the chain, what’s going to happen?  I’ll tell you what I’ve seen – control.  The team will lose a certain amount of autonomy, and self-organization, because it’s leadership will tighten control.  You don’t want that.

My suggestion: Show continual progress using burndown charts.

Live with it.  It’s obviously not worth wasting your energy to bring up anymore, because it’s not being addressed.  It’s either too boring, or to costly to fix.  So, forget it.  All is lost and you should stop complaining.  No one is listening anyway.

Nothing is forever.  There’s nothing that you come in contact with every day that hasn’t evolved in some way over time.  And, that adage about the squeaky wheel getting the grease is mostly true.

Expedite your impediments by finding the RIGHT person to help you.  If no one is helping, they are the wrong people.  Find the right one, and get them to help.

Have you considered that you are the impediment?

I know, it’s hard to accept, but no one is perfect.  There are several ways that you could be your own impediment.

• Explain the impediment to several people as best you can, and get them to reiterate it back to you.  If they explain it well, you’re good.  If not, you might need to work on how to explain the problem.
• Are you the wrong person to bring up the impediment? It’s possible that your title or role is your enemy. Maybe you need to let someone else bring it up.  Sometimes that makes all the difference. (right or wrong, the world works this way)
• Maybe this impediment is all about your own technical skills.  If so, the impediment that you bring up should not be a deficit of skills, it should be availability of training.  Try solving for that problem.

What?! Why would anyone schedule a mandatory meeting during the same time as a team’s most important meeting of the day? The ScrumMaster needs to put their foot down and demand that this time is for the team, and the team only.

You don’t have to record the meeting minutes.  But, maybe someone could fill the ScrumMaster in on anything they missed.

Look at it this way, the Daily Scrum is for the Team Members, not for the ScrumMaster.  So, let the ScrumMaster go to their regularly scheduled meeting, it shouldn’t bother the team. Plus, odds are the team will have more fun at the Daily Scrum, than the ScrumMaster has at their status meeting.

Don’t reschedule the meeting, just go ahead without the ScrumMaster.

No. This is a Members Only event.

Try it out.  If you spend too much time saying stuff like “I’ll check with Sumitro and get back to you guys around lunchtime.” then maybe you should try inviting Sumitro to the Daily Scrum once in a while.  Eventually, if Sumitro ends up being vital to the team, you might be welcoming a new Team Member.

If it’s a once a month type thing, you may want to just consult with Sumitro and update the team later.  If you have Sumitro there everyday, and it’s a waste of his time.  Well, it’s a waste of his time!  That’s a bad thing.

Be sure to set some expectations, though, if you invite a non-team member to the Daily Scrum.  Let the team weigh in on whether this new person gives an update, is there to listen only, is there to answer questions only, etc.  But, decide as a team, and let Sumitro know what’s been decided.  Otherwise, you may confuse people and/or be setting yourself up for disappointment.

Maybe your ScrumMaster doesn’t really know what a ScrumMaster’s responsibilities are.  They definitely are not to tell the team HOW to accomplish anything,  The only HOW that the ScrumMaster might have jurisdiction over would be Scrum itself.  That’s the ScrumMaster’s domain (it’s right there in the role’s name).

Get that ScrumMaster to some training!  There are many ScrumMaster certification and non-certification classes out there in the wild.  Many organizations also have internal training for ScrumMasters.  The role is only 25 years old now, and we’re still figuring it out, but there are plenty of good training offerings available.

Now, if your organization hired a technical person to be a ScrumMaster, then told this person to use their technical skills to influence the team’s solutions…  Refer to Experiment #1.

Once again, address this with your Team Working Agreement.  Get the team to agree on something addressing how you will announce late-comers on the phone.  As an example, some teams have made all late-comers wait until everyone, who made it on-time, has given their updates, then someone will call for late-comers.  Come up with something the team agrees on, and is less annoying than having half of a collaborative team unable to collaborate because they are generally late to a conversation that is spanning the entire planet.