Practical advice for Scrum Masters – Organizing ceremonies in Outlook

Respect and Time – this is Important!

Scrum has a set of ceremonies, some considered essential, some optional.  What’s important is that they are held at consistent times. 

Er… ok. Why’s that important?

Well, firstly, this allows for the attendees, both participants and observers, to plan their time well.  It sets the heartbeat of the team, and allows for the measures that we use for a team’s predictability (velocity, Say/Do, cycle time) to have some basis in reality.  Reality!  Yay!

(Favorite theme: operating in reality works better than operating in make-believe!)

This is good. If your team is consistent and reasonably predictable, this is highly valuable to the business, as it allows them to do high level planning with increased confidence.  Benefit to you: they’ve got fewer reasons to ask you to do crunch-work.

Secondly, there’s a bad side to not doing this, setting up regular ceremonies.

What does the bad look like, and why is it bad?

One of my favorite life principles is that you can always make more money, but you can’t make more time.  (Despite claims to the contrary.)  So respecting others’ time is fundamental.  Being late or inconsistent around appointments is basically sending the message “My time is more important than your time, actually.  Nyaah!”.  It’s incredibly rude, and it’s a sure-fire way to undermine credibility, trust, and team cohesion.  Is that worth it?


Don’t do it. 

Don’t tolerate it.

I’ll be writing in due course about the SCARF model (see David Rock, “Your Brain at Work”)  The “S” stands for Status.  Sending a message that they are less important than you, even if that’s true, is an assault on their status.  It activates a threat response, either having them unable to think clearly, or if strong enough, activating a fight / flight / freeze / appease response.  That’s no way to run meetings.

Said another way, it’s a great way to get people pissed.

Can you see how much sense it would make to show respect for people’s time?

So what’s the first step?

So here’s what I suggest.  Schedule your teams ceremonies, schedule the times when you’ll protect their ability to get on with work, and get the team to set rewards and sanctions (Reward: chocolate gift? Public cheer?  Sanction: $1 fine? How about having to sing at the Stand-up? Or dance?)

Outlook tips:

Here’s an example of the kind of schedule you might want to set up, and how to use Outlook to support the team.

Let’s say your team has two week sprints, starting on a Wednesday.  Here are the meetings you’ll need to set up:

  1. Sprint Planning: Wednesday 10:00 am to 11:00 am, recurring every two weeks on Wednesday, starting on first day of first Sprint.  Invite Team, Product Owner can forward to stakeholders, also possibly engineering managers if they can act as technical consultants not bosses.
  2. Story Grooming: First Friday 3:00 pm until 4:00 pm, recurring every two weeks on Friday, starting of first Friday of first Sprint.  Same invite list as for Planning.
  3. Sprint Demo: Second Tuesday 11:00 am until 12:00 pm, recurring every two weeks on Tuesday, starting last day of first Sprint.  Same invite list as for Planning.
  4. Sprint Retrospective: Second Tuesday 2:00 pm until 4:00 pm, recurring every two weeks on Tuesday, starting on last day of first Sprint.  Invite to Team only.
  5. Daily stand-ups:
    1. First Thursday and Friday, 10:00 am to 10:15, recurring every two weeks on Thursday and Friday.  Invite to Team as contributors, anyone else as observers.   
    2. Every weekday (middle week), 10:00 to 10:15, recurring every two weeks, starting on First Monday of first Sprint.  Invite as 1.1.
    3. Last Monday, 10:00 to 10:15, recurring every two weeks, starting on last Monday of first Sprint. Invite as 1.1.

A fiddly recurring meeting

Outlook recurring meeting for first two Stand-ups.

Wow, that’s a bunch, am I right?  But you only do it once!

Schedule work, not interruptions.

Get the people in the team to schedule the time they want to protect at work, so to other’s it’s clear that this time is Busy in Outlook. 

In Outlook, have them add something like Daily, 9:00 through 10:00 Deal with email; Daily 11:00 through 5:00, Concentrate and Collaborate.


Outlook always allows you to Tentative Accept or Decline just one meeting instance.  Use that sparingly.

Release Planning, Release Retrospectives, company All-Hands and Offsites, sure they will take precedence.  Give people robust feedback if these get scheduled at the last minute, that’s not acceptable professional behavior.

But what are you telling the world if they look at your Outlook schedule and just see that it’s mostly free?  It’s permissions to mess with your days my throwing meetings at you any old time.  You’re asking for a drop in “S”!

Let the team choose!



While I’m finishing the wool-gathering for the last post in my Social History/Neuroscience of Agile series, here’s some reflections on the last couple of retrospectives and what’s going on around them

I’m still fairly new to the team. When I joined them, they were halfway through a sprint, and since then we’ve completed three sprints. They’re one of many teams, in a very complex business environment, and the code they’re producing operates as an integration point for the code from several other teams.

The major challenges they’re facing are, in no particular order:

  • Environmental delay
  • Cross-team coordination
  • Starting too much work

Environmental delay

By this I mean the impact of discovering that an environment (say a QA Integration server) is not ready, and it turns out that the infrastructure team have a ten day lead time on building the server. Or an essential service needs to be configured to expect new connections and this has a four week lead time. Or opening a firewall takes four weeks to pass security review.

Why’s this a problem?

Two reasons: first the lead times are not widely publicized or, in some cases, even predictable. This would suggest that the teams involved probably could use a Kanban approach to track their lead time and cycle time and then be able to publicize a more reliable service level.  For instance, “A request to open the firewall typically can be completed within 20 working days 80% of the time.”  An escalation path could be offered as well “Urgent and important requests (i.e. to resolve production outage) can be processed in twelve hours, and must be followed by a risk mitigation review to minimize repetition of the issue”.”

The second problem is that often these lead times are longer than the sprint length. So if work in sprint n reveals a need for an environment change in sprint n+1, tough! You ain’t getting it until sprint n+x, buster! We all know that in the real world, no matter how good our release planning, all the time we discover things only during story grooming. So having environment teams work to reduce their lead time to be less than one sprint’s length would be a major step forward.

Cross-team coordination

Do I need to tell us why this is a problem?  Oh, ok.

So in this case, it’s basically because more than one team is working on the same code base.  Probably not the same code modules, but all the time we see that Team A does x, that break the code for Team B in module y.  Team A’s code is essential, so Team B updates code y to take this into account.  Team C’s code z promptly breaks.  Guess what happens when they fix it.

Oops.  Test Driven Development and Continuous Integration anyone?

Both of these problems require collaboration across boundaries, and that’s one area that is being worked on.  Remember this: Scrum is designed to reveal organizational dysfunction.  Taa-daa!

Starting too much work

When does value become real? When we put working features into (paying) customers hands. So we need working features.  They’re working when they are finished, so finishing is a good thing.  Duh, right?

So imagine a team that for one reason or another seems to be “falling behind” (read: their progress is not visible). Their workload increases as they have to keep dealing with the work on hand, and of course, someone up there keeps piling on more.

If the team’s capacity has been reached, and you add in more, it MUST mean that stuff ends up being late.  Adding more cars into traffic slows the traffic. My calendar is full, if you give me something else to do, something I can’t magic up more time, so either it’s not going to happen for a while, or something else is going to be late.  Fact.

Put another way, we want to stop starting and start finishing.

What do I mean?

Try this: Know the names of all the members of your team? Good.

Exercise A

  • Set the timer on your phone for, say, twenty seconds.
  • Start writing their names.
  • When the timer goes, stop writing.
  • Your score is the number of names you wrote completely.

e.g. Abir , Bill, Cameron, Devon, Edw… Ding! That’s a score of 4.

Exercise B

  • Set the timer again, same amount of time.
  • Now, for all their names write the first letter, then the second letter, then the third letter.
  • When the time goes, stop writing.
  • Again, your score is the number of names you wrote completely.
A b i
B i
C a
D e
E d
G r

Oops! Did you even score 1?

That’s what happens when you keep starting and don’t finish.

So, Stop Starting and Start Finishing!

Worst sprint so far, they’d started sixteen stories, and finished one.  They split (ow!) fifteen and didn’t recognize what this was concealing as they pretended that they’d finished all sixteen.  Hmmm….

How did we fix it?

Well we haven’t – yet.

But here, much abbreviated, are the exercises we did for the last two Sprint Retrospectives.  By the way, I always follow the format Set the Stage, Gather Data, Draw Conclusions, Design an Experiment, Retro the Retro. I’m only going to talk here about the middle three exercises.

Sprint N

Gather Data: We had the burn down, that showed we’d done only 35% of what we’d set out to achieve. So then we did a real quick Start Doing, Stop Doing, Keep doing exercise where the team brain-dump onto stickies and put them up on the board under these three headings. (Five mins.)

Then we had the team swarm on the board and group the stickies into related themes, and finally dot vote on the as things they were interested in.

Draw Conclusions: Now I had the team undertake three exercises. First, they had to sit in silence, and write on stickies any ideas that they had about the number one topic. I enforced the silence with librarian-like shushing.  It was kinda fun! Next I had them pair up, and the rule was you couldn’t pair with someone with the same role as you. Then in pairs, they could compare stickies, discuss them, come up with something else if they wished.

Lastly, I had each pair pitch their conclusions to the rest of the team for two minutes. At the end of the two minutes, they were invited to comment on what it had been like to do this alone, and what it had been like to do this in a pair.

By the time each pair had gone, the place was a frenzy of people demanding another go to pitch again, discussions where breaking out all over the place.

In effect, we stepped from being lone guns, through pairing, to working as a team in this one exercise.

To wrap it up, once again, up went the stickies on the board, and we swarmed and grouped them.

Finally, once again, we dot-voted, and we had a topic for consideration for the experiment.  In this case it was Focus on Story Grooming (with a strong hint of Cross-Team Coordination).

We decided that the experiment was to focus on this in the Sprint Planning session, and in the next Story grooming session.


About six days into the sprint, the question was asked in the daily stand-up “Hey, are we tracking our experiment?” We all looked blank, and guilty, as once again the Sprint was off track.

On reflection (Failure Bow time!) I realized that of course we were tracking it.  That’s what the Burn-down chart was doing.  It was showing that we’d sucked at Story Grooming!  We’d been adding tasks up the wazoo!

Sprint N+1

This time, to gather data, I displayed the burn-down.  We’d done much better, but there’d been some gaming of the numbers still, and stories were all getting finished at the last minute.

So here’s the exercise we did.

Gather Data: I had them stand in two rows, pairs facing each other.  The instructions were A interviews B “Tell me two things that you think we should pay attention to” and write them down.  Then B interviews A with the same questions.  When we’re all done, the person on the end of row A runs round to the other end and all the A’s move along one spot.  Then we repeat the interviews.  We do this until you meet your original partner again.

This actually took something, it was fascinating seeing the guys struggle to understand what I was asking them to do.  They hated it to begin with!

Oh, and one of the guys was on a video link, so one of us was interviewing a laptop!

But by the time were were done, it had turned fun and noisy! They loved it.

They we went to the board, of course, and started to cluster the stickies.

Draw Conclusions: This was simply a brainstorming exercise.  I quietly left to go to the restroom, and by the time I’d got back, they were working on this on the whiteboard themselves.

The Experiment: We had realized that we tended not to create a decent support structure for our experiments.  So as we came up with the things we wanted to do, we simply recorded them in Story format in Rally (not an endorsement, good though Rally is, it’s just the tool we happen to have).

This ensures that the stories will be sized and included in the upcoming Sprints.

Next Sprint

At the start of the Sprint Planning, I’m going to have the guys use the “Write your team’s names” exercise.  It’ll only take a couple of minutes, and may have them get what’s going on with taking on too much work and trying to start it all.

But what about…?

Did any of this progress towards solving the Environment Delay and Cross-Team Coordination issues? Not directly, but it’s looking to me like the team are getting very quickly more skillful at undertaking the kind of exercises and using the kind of thinking that has people collaborate to produce solutions.

I’ll blow more about this as we progress.