Daily Scrum

Problem

Try This

Daily Scrum meeting goes too long

Experiment 1 - Countdown 1

Add a visible ‘countdown’ clock to the environment.  Bring a tablet, or phone, to the room where you do your Daily Scrum.  Put 15 minutes on the clock and set it to countdown.  Tell the team that you are trying to get them back on track by really timeboxing the meetings.  When the first Scrummer starts giving an update, start the countdown.  If the team is still talking when the timer runs out, walk away.

Experiment 2 - Countdown 2

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.

Experiment 3 - Talking Token

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…

Daily Scrum meeting is too short

Experiment 1 - Embrace the simplicity

Most coaches will tell you that there’s no such thing as a Daily Scrum that is too short.  The only Daily Scrum that is too short is one where everyone says “No update”, turns around and leaves.  If no information is being shared, yeah, it’s too short.  If everyone is sharing regularly, then it’s probably not really too short.  The meeting is supposed to be a maximum of 15 mins, not a minimum.

Experiment 2 - Stick to the 3 Questions!

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?
Experiment 3 - Talking Token

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…

Daily Scrum never starts on time

Experiment 1 - Saved By the Bell

Try ringing a bell in the team area when it’s time to start the Daily Scrum.  Sometimes ringing bells are a little disruptive to other people working in the area.  If so, try something else.  Blowing on the open mouth of a glass bottle isn’t too disruptive … usually.

Experiment 2 - Just Do It

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.

Experiment 3 - I Got Picked Last

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.

Experiment 4 - I Want My $2!

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).

Team members give a complete status of what they did and what they will do

Experiment 1 - C'Est La Vie

If that’s what the team wants to do, why interfere?  IE: If the team feels like that’s important, to give excruciating detail about what they’ve done the day before, and what they plan to do for the following day, then let them.

Experiment 2 - Let's get something straight here

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.

Experiment 3 - Talk it out

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.

Team members report to the ScrumMaster during the Daily Scrum

Experiment 1 - Nothing wrong with that, right?

If the Team feels the need to have an appointed leader, the ScrumMaster, then they are there to fill that need as a servant leader.  No harm in that right?  WRONG!

The ScrumMaster is available to the Team as a servant leader, that’s true.  The false assumption is that it’s OK for the Team to rely on the ScrumMaster as their leader.  This gets misunderstood all too often.  The Team is supposed to be self-managing and self-organizing.  Part of that responsibility is for the Team to look for support from within first, and then turn to the ScrumMaster when that support is insufficient.  The Team should never assume that the support the ScrumMaster gives in these circumstances translates to all circumstances.

What happens if the ScrumMaster is not available?  The Team would be left helpless because they’ve never learned to become self-organizing.  Reporting to the ScrumMaster during the Daily Scrum is a slippery slope.  Don’t start, or continue, down this path.  Talk to each other during the Daily Scrum.  The Team Members are the intended recipients of the information during the Daily Scrum.  Keep it that way.

Experiment 2 - The ScrumMaster has left the building

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.

Experiment 3 - Look! Behind you!

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.

Product Owner assigns tasks to Team Members during the Daily Scrum

Experiment 1 - Say it ain't so, Joe!

Please tell me this isn’t really happening!

Really?! Well, then just stop it.  This is ridiculous and doesn’t jive with any true implementation of Scrum.  Just, stop it!

The Development Team decides what they will work on during the Sprint, how they will complete the work, and whether there are better ways of delivering the Sprint Goal.  The Product Owner has absolutely no authority to assign work during the Sprint.  If you’re doing that, then you are not doing Scrum.

Experiment 2 - Take it on the road

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.

Experiment 3 - You're out!!!

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.

ScrumMaster uses the Daily Scrum to tell the team what they did wrong since the last Daily Scrum

Experiment 1 - The good news is, you're fired

Fire the ScrumMaster.

It is not the ScrumMaster’s job to admonish the team for work done poorly, wrong, or at all.  Your ScrumMaster is assuming power, authority and responsibility that they do not have, under Scrum.

Because the Team is self-managing and self-organizing, fire the ScrumMaster and hire one that serves the team well.

Experiment 2 - You are certifiable!

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.

Experiment 3 - You are either with us, or against us

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.

Team members spend a lot of time talking about impediments

Experiment 1 - Remove the barriers to success

People will generally talk more about what is really bothering them, or not talk about those things at all.  If your team is talking about those things a lot, your battle should be an easy one.  If the team was not talking about impediments, you would have very little chance to remove those impediments.

Luckily, your team is bringing those impediments to light. So, get rid of the impediments.  If you don’t have the power to rid of them, find the person or people that do.

Yes, it’s that simple.

No, don’t make it more complicated than that.

Experiment 2 - Good

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?

Experiment 3 - Listen to my words

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.

Team members never talk about impediments

Experiment 1 - You keep using that word. I don't not think it means what you think it means

Does the team know they are are supposed to talk about what’s holding them back?

Experiment 2 - Huh?

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

Experiment 3 - Open your @!#% ears!

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.

Experiment 4 - Put it on the booooooard!!!

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.

The ScrumMaster is never present for the Daily Scrum

Experiment 1 - Nothing to see here

OK, so what’s the problem?

Honestly, that’s not a huge problem, unless the team is suffering / in trouble.  If the team is functioning well, then don’t bother them with forcing the ScrumMaster into attendance.

That being said, if the team wants the ScrumMaster to attend, or if the team is having trouble of ANY kind, you might want to have the ScrumMaster start attending the Daily Scrum.

Check it out.  The ScrumMaster isn’t REQUIRED to be at the Daily Scrum.  Does it make sense to have them attend?  Yes.  But they’re not required to be there.  Honestly, I’ve only seen a few teams that were less than a year ‘old’ (less than a year since they started using Scrum) and did NOT have their ScrumMaster attend every (or almost every) Daily Scrum.  The ScrumMaster is really just there to help, why not have them there?

Experiment 2 - Don't you like us?

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).

The Product Owner is never present for the Daily Scrum

Experiment 1 - Invitations are like love letters

OK, maybe that title goes a little too far…  But the sentiment is still there.  Some Product Owners are really waiting to be invited.  Send them an invitation and see what happens.  It’s always nice to be invited to things that you have no intention of attending.

Give them the option to say no.  Because that leads us to more experiments 🙂

Experiment 2 - Come over here

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!

Experiment 3 - Long distance relationships never last

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.

The team breaks into technical discussions during the Daily Scrum

Experiment 1 - Stay the course

Keep the team on track by telling them that you are there to update each other on the what each other is working, and try to help help with problems.  Tell the team that protracted discussions are outside the scope of the Daily Scrum.

Experiment 2 - Breaking away

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.”

Experiment 3 - Good? Bad? Who's to say?

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.

Experiment 4 - Scrum Guide 2017 says it's ok?

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.

 

 

Some team members refuse to call into the Daily Scrum on time

Experiment 1 - Stick to the script!

What does the Team Working Agreement say?  Do you have something in there about attending meetings on time?  If not, why not?  If so, do you have an ‘or else’ clause?

An ‘or else’ clause is what will happen every time a Team Member breaks the Team Working Agreement.  Common clauses describe bringing in treats for the team, performing a public Failure Bow, or putting money into a teams slush fund.

Experiment 2 - Get off the phone!

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.”

The ScrumMaster keeps interrupting Team Members’ updates

Experiment 1 - Haven't I answered this already?

Much like the problem with the intrusive Product Owner, during the Daily Scrum, I’d say many of the same things about the ScrumMaster.  Take a look at the answers to “Product Owner assigns tasks to Team Members during the Daily Scrum”.

Experiment 2 - Buzzzzzz

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

Experiment 3 - Talking Token

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…

Experiment 4 - Let's Talk it Out

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.

If we have to stand, why don’t the people on the phone have to stand?

Experiment 1 - There is no spoon

You ARE the people (person) on the phone.

This is a perspective thing.  It doesn’t matter what side of the phone you are on.  You are STILL on the phone.

Experiment 2 - If you make the rules, you have to enforce the rules

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.

Experiment 3 - What are you standing around for?

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.

Our ScrumMaster keeps diving deep into our development and testing practices. Can we get her to leave us alone?

Experiment 1 - Burn the Witch!!!

Yes.

Stop inviting her to the meeting.

Experiment 2 - Talk Talk Talk

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!

Experiment 3 - I'm down with that

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.

Day-to-day we don’t have a good idea of how much work is left for the Sprint. Shouldn’t we talk about that?

Experiment 1 - There's this thing called a Sprint Backlog...

Look.  You’ve obviously started, or strayed, very far from Scrum already.  During the Daily Scrum, focus is on the discussion about what’s been completed recently, and what’s coming. To best see what’s left, look at the Sprint Backlog.

  • If you don’t have a Sprint Backlog, you’ve strayed too far from Scrum.
  • If you aren’t talking about what’s next, you’ve strayed too far from Scrum

Now, let’s say you have a Sprint Backlog, but you’re still in the dark.  Make a physical Sprint Backlog, using a wall or window, and gather around it during the Daily Scrum.

Experiment 2 - What are we doing here?

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.

The ScrumMaster spends most of our allowed 15 minutes managing the meeting.

Experiment 1 - Don't shoot the messenger

We spend a lot of time beating up ScrumMasters who try to control things. Try to figure out why the ScrumMaster is ‘managing’ the meeting in the first place. They might be reacting to pressure from above.  They might be reacting to what they believe is a lack of structure in how the team operates.

If you don’t like how your Scrum events are being held, one of the best things you can do to change them, is to talk about why they are structured the way they are.  You can do this before or after a Daily Scrum, or during a Retrospective.  You can even do this in a private conversation with the ScrumMaster.  It doesn’t have to be a formal conversation.  But, I suggest you include the entire team – so that it doesn’t seem like a ‘squeaky wheel’ type of thing.

Experiment 2 - Out with the old. In with the new.

Trade your current ScrumMaster with another.

Rinse and repeat until you find one you like.

(This is really bad advice, by the way)

Experiment 3 - Reformation

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.

I don’t think anyone is listening to me, because they are all looking at their mobile phones

Experiment 1 - You're going to like us - TWA

Talk about this with the team, and either create an item in your Team Working Agreement that addresses the presence or usage of phones in Scrum events, OR create an item that describes the penalty for using phones during Scrum events.

Experiment 2 - You've heard of Respect, right?

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.

Experiment 3 - Teach 'em a lesson!

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!

If we are all collaborating all day long, what good is the Daily Scrum?

Experiment 1 - It's the rules

Scrum is dogmatic and says you have to have the Daily Scrum everyday and there’s no getting away from that. So there.

Experiment 2 - Wellllllll

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.

It’s hard to understand the off-shore people’s accents over the phone, can’t they just email us their updates?

Experiment 1 - Email is a GREAT way to convey messages!

Of course you could have them email their updates.  Let’s think about that conversation though.

“Hey, off-shore people! How’s you day been?  While you were working all day we’ve been sleeping.  Hey, by the way, we were talking yesterday, and we think we’d understand you better if you just emailed your updates to us.  That way, we wouldn’t have to decipher your thick accents and try to respond right away.  The only thing we’d have to parse is the poor grammar and misuse of terms.  We’ll spend more time sending emails back and forth, lengthening the feedback loop, and trying to centralize/agree on shared solutions, but at least we would not have to listen to your accents.”

I’m going to go out on a limb, and say that’s not going to be received very well.  I’m also going to assume that you didn’t think about that prolonged feedback loops thing.  You’ve already made things more difficult by not co-locating your team.  Don’t make it worse by using the absolute worst modern medium for conveying messages too.

Experiment 2 - No

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.

Experiment 3 - Don't even start

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.

I don’t understand this Green/Yellow/Red or percentage of done stuff. Can’t I just say what I did yesterday?

Experiment 1 - Yes! Do that!

Absolutely!  Talk about what you’ve done. Talk about what’s left.  Don’t give things colors.  Don’t talk in percentages of doneness.  No one can fully grasp a percentage of doneness anyway.  I mean to say that, you only comprehend doneness from a stance of knowing what the end state will be and exactly how to get there.  Any deviation from that, and your comprehension of doneness was assumption, not understanding.  See, it was easier said the first time – no one knows what done is, until you get there. So, no more percentages.  OK?

Experiment 2 - Why not? It's so easy!

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.

We report the same impediments everyday, but nothing changes

Experiment 1 - You! Go get help!

Impediments should be considered as emergencies. In training for emergencies, we yell at some random-but-specific bystander to go get help.  It breaks them out of gawker mode, and almost guarantees that help will soon be on the way.

Treat impediments this way too. If the ScrumMaster isn’t listening, or just accepts that these impediments are a constant annoyance that the team needs to start living with – WAKE THEM UP! Call attention to the fact that impediments are not acceptable. If your impediments are not being addressed, AND they are outside of your control or influence, then get someone else on the job of fixing them for you.

Normally that’s the ScrumMaster, but if the ScrumMaster is ineffective, unavailable, or doesn’t have the change capital to get it fixed, find someone that can help.

Experiment 2 - Live with it

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.

Experiment 3 - No is a future Yes

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.

Experiment 4 - YOU are the impediment

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.

The ScrumMaster attends a department meeting every Tuesday during our Daily Scrum. So we just skip Tuesdays.

Experiment 1 - Why?

The world doesn’t revolve around the ScrumMaster.  Have the meeting without them.

Experiment 2 - WTF? What's more important?

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.

Experiment 3 - Scribe!

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

Experiment 4 - So what?

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.

We tend to bring up a non-team member’s name a lot in the Daily Scrum. Shouldn’t he attend our Scrum’s?

Experiment 1 - Yes

Yes. Invite them.

Experiment 2 - No

No. This is a Members Only event.

Experiment 3 - Maybe

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.

I don’t like going to the Daily Scrum meeting anymore. The ScrumMaster argues with us about the technical details of what we are doing.

Experiment 1 - Ditch 'em!

A ScrumMaster doesn’t argue with the team over technical details. I’m not sure who that person is you are describing, but they are not a ScrumMaster. Get rid of them and get yourself a real ScrumMaster.

Experiment 2 - Getting to know you

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.

Our remote people call in late and announce themselves. This interrupts people that are already giving their updates.

Experiment 1 - We've addressed this, yeah?

If you are still trying to get some advice on how to deal with annoying situations that you’ve created by distributing the team all over the globe, please stop.  I’m really not in the mood, and my manager that works 3 time zones away is calling me.  You think you have it bad?!

Experiment 2 - Team Working Agreement, to the rescue!

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.

Still Need Help?

If these suggestions do not solve your problem, please accept our apologies for any dysfunctions that your Scrum has revealed to you. You may find related organizational dysfunctions in the section Advice & Preventative Maintenance