Thoughtful parable from Johanna Rothman on the feeble manager’s fall-back “Don’t bring me problems, bring me solutions”.
Today, a tip, nothing to do with Agility other than being a move towards a world where technology makes life better, not worse.
You’re on the move, and that important meeting is about to start. Your iPhone’s in your hand, but now you’ve got to find the invite. Wait, you remember you set up the dial-in number as a contact… but what’s the meeting code? Aaahhhh!!!!!!
Here’s a tip if you’re setting up online meetings. This works for an iPhone, I don’t own anything else, so please test it on your own smart phone and let us know in the comments how it works for you.
If you have a dial-in that’s a phone number, and a meeting id, and the nice electronic lady asks you to dial “#” at the end, there’s a way to set up the meeting invite so all your attendees could just tap once on the meeting reminder when it pops up on their phone – and they’re in!
The Tip – help your attendees
Enter the whole number and meeting ID in the following format, and iPhone users can just tap on the screen when the reminder pops up, and it will dial automatically.
Format: “+1 (555) 123-4567,,,999999999,,0#” where 999999999 is the meeting ID.
(If you want to put in a hard pause, use a semi-colon. The phone will them display a message “Dial <number>” that you can tap again and it’ll dial. E.g. “;0#” at the end means you will need to touch again as the phone asks “Dial 0#” so just touch where is asks and the hash is dialed.)
Why the “0” before the “#”? It’s a workaround for the iPhone bug that has a number ending in a “#” fail to dial. Neat, huh?
Note, don’t put a space into the meeting ID, the phone will take it literally and this tip won’t work!
So this trick would mean I could simply tap my screen once when the meeting reminder comes up and I’m into the call.
Sub-Tip – help yourself
If you’ve already received a meeting invite, open the appointment in your calendar and edit it to match this format, that works too. I’ve found that keeping the number in the meeting location field works well.
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?)
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:
- 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.
- 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.
- 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.
- 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.
- Daily stand-ups:
- 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.
- Every weekday (middle week), 10:00 to 10:15, recurring every two weeks, starting on First Monday of first Sprint. Invite as 1.1.
- Last Monday, 10:00 to 10:15, recurring every two weeks, starting on last Monday of first Sprint. Invite as 1.1.
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”!
Have you noticed all the job postings boasting that they’re looking for “exceptional” candidates? That, to my mind, is almost as daft as wanting ten years’ experience in a technology that’s only five years old.
If someone’s exceptional when they join your spiffy little company, where are they going from there? How about creating a company culture that brings out the exceptional in ordinary people?
The hosts, ISITE Design, kindly recorded the session. They set it up to record the laptop I was using, so as I ran PowerPoint in presenter mode, you get to see the “cheat sheet” side of the presentation. The recording stopped as we went into a live exercise.
Here it is:
The exercise was started during the talk, with people making notes on sticky-notes of aspects of their working world that they could now see qualified as waste. We then had everyone swarm and group their notes, cross referencing them with Agile practices that could handle these wastes.
We also found that folks gained a new appreciation of why Agile practices work so well.
I gave an extra mini-talk afterwards, “How to Sell Agile to the Bean-Counters” but that is a story for another day.
I’ve was asked some time back to be a panel member on a discussion about estimation. The other panel members are all business analysts. The audience is going to consist of business analysts and project managers.
Following a planning call with the organizer and other panelists, I realize that I’m dealing with some folks who are used to estimation being a quest for certainty, regardless of the fact that it’s an uncertain world.
To prepare myself, I’ve been thinking of an analogy I can use to explain agile thinking about estimation. Here’s what I’ve come up with:
Scenario The First
You’re going to play golf with some friends on a course with which you’re all familiar. How long will it take to play each hole? How long for the entire round?
Can you hear people answering already “It depends…”?
Scenario The Second
You’re going to play golf with some friend on a course with which none of you are at all familiar? How long will it take to play each hole? How long for the entire round?
Can’t you just hear people saying “Well, we could guess if we looked at a plan of the course” or “We wouldn’t really know until we’d played a few holes”. Right.
Scenario The Third
You’re going to play gold with a group you’ve never met, at a course at which none of you have ever played.
… The Fourth
…this time not even on a course, but across country! You have a map, but it’s not clear if the map is current.
Now, back to the unfamiliar course with your buddies, but this time you have only four hours to play. How many holes could you complete? How about if you were only allowed a budget of seventy-five shots, how many holes then?
How about if I told you to play exactly eighteen holes, no more, no less, and they all had to holes in one, or you lose your bonus this year? On three courses. At the same time. I’ve got a buddy who’s no longer a project manager as a result of roughly that scenario. Which is one of the reasons I’m serious about agility.
Anyhow, that’s the analogy I ended up using.
Dear and Gentle Reader,
Attending the local Lean Agile Coffee, the question arose “How can we get a team to start pair even if they all hate the idea”?
Ever heard this question before?
I thought so.
Well, I’m going to tell you the answer I gave, and if it’s useful to you, then good. It’s based on an exercise I tried with one of my teams, and it seemed to be effective.
To begin with, I explained to them how were were going to work in the retrospective, proposed a few ground rules on which we voted for agreement, and got underway.
We spent five minutes brain-dumping onto stickies things that puzzled us or that we felt needed attention. Then we grouped them leaving us with a small handful of things to consider.
I asked the team to spend five minutes writing down ideas to resolve the puzzles or that would have us make progress, one per sticky. But it had to be in absolute silence, and so, they had to work alone. I had fun enforcing the silence with comedy shushing and angry-librarian looks.
Next, they were to pair up, the rule being that like could not pair like with like. Dev could not pair with Dev, nor QA with QA. Now they could spend ten minutes discussing their subjects, even coming up with others if they felt they had time.
Next they had to stand up, pair by pair, and sell their solutions to us. They had a couple of minutes each. After their pitch, I asked them to comment on what it was like working alone compared to working with the other person.
Finally, with all the solution up on the board, we grouped them again, dot-voted to select one as an experiment for the next Sprint, and wrapped up with a discussion about what it had been like to decide on this as a team. We did a quick low-to-high line for return on time invested, and the consensus was high.
So, not only did we follow the basic framework for a retrospective (set the stage, gather data, draw conclusions, propose an experiment, retro the retro) but this was also an exercise to have them experience pairing, being bold and open, and working together as a team. I didn’t need to point out to them what I was doing, they got it.
I’ve had to say to some people before now “You’ll hate it before hand, but you’ll love it afterwards”. In this case, I didn’t need to be that obvious, they just did the exercise and got it.
It’ll need refreshing to help it stick, so I might look for a variant.
Full disclosure: I pinched the basic idea for this from Thiagi’s Hundred Favorite Games, a phenomenal resource of training games and exercises. Snag a copy for yourself, it’s pure gold.
Folks at the Lean Agile Coffee liked the sound of this exercise, so I hope that they try it, and bring back reports of their experience.
That is all for now, dear Reader. Go with Agility.
P.S. In looking for a link to Thiagi’s book, I found this link to 350 of his games – free!