Sublime and ridiculous

Here’s the sublime: http://arlobelshee.github.io/AgileEngineeringFluency/Stages_of_practice_map.html?  Arlo Belshee’s clarity is just dazzling.

And here’s the ridiculous http://lafable.com/  You Agilists should find this highly entertaining, and you may be surprised when you find out who’s behind it.

I’m clear that oddly, the message in the comical one is what’s missing from the serious one.  Arlo’s graphic is fantastic, but it is dazzling, and dazzled you might miss something.  What is it? Take a look, what do you think?  How would you express that message?

Why are estimates nearly always low?

Why oh why?

How often is an estimate correct? Why do we seem to under-estimate so often? We can’t always blame the pointy-haired boss.  Can we?

2015-02-16 Estimates DilberWell, no we can’t.  Really, we could have some sympathy for those pressuring us to higher certainty and lower costs.  They’re just trying to reduce risk, even if the risk is of looking bad. Maybe they’re stuck in a world of cost accounting, unaware of its impact or alternatives.  If a project has overrun, and if all you know is detailed estimation, then it’s easy to assume that you can’t have done enough detailed estimation.  So there’s an urge to do more of it!

Doing more estimation is a waste of time and energy.  Let me show you what is going on here.  It is something simple and fundamental.

Let’s Estimate Something

Here’s some work we’re estimating. Let’s consider everything that could be known about this piece of work.

IMG_1212

First, there’s some of it about which we have a high degree of certainty.  We know what we know about this.  Let’s call this KK – Know what we Know.

IMG_1213

Then there’s the rest, the stuff we Know we Don’t Know. Call this KDK. This must have a degree of uncertainty, by definition. We could manage the uncertainty if we buffer the estimate.  With a mature and wise customer, we could provide a range.  The risk is that we assume the high end is more realistic, and those employing us turn the low end into a deadline.

IMG_1214

So, we’re done.  That’s our reasonable estimate.  Quick! Commit!

Easy, tiger!

Wait!  We’ve missed something.  It’s not a reasonable estimate.  As it stands, it’s pretty much a guarantee of failure.

What are we up to here? We’re developing something new.  If we were developing something that wasn’t new, we wouldn’t have to estimate it, would we?

If it’s new, there must be parts of it that we Don’t Know that we Don’t Know (DKDK), by definition.  I mean – it’s new!

Here’s my question: will DKDK lead to more  work or less work?  (Hint: it’s MORE work!  Duh!)

IMG_1215

Well, here’s a grain of solace.  Inside DKDK is DKK: what we Don’t Know we Know.  Some stuff  turns out to be very like something else we’ve already done, and we hadn’t realized it until we started work on it.  This will account for those occasions when the estimate turns out to be high – sound of heavenly trumpets!  But since we usually remember what we know, these occasions are not the norm.

IMG_1216

The point remains: it’s all pretend until we start work on it and start realizing – making real – what’s actually involved. Nothing is certain until– when?– until it’s actually finished!

The truth is out there

Take a look at Steve McConnell’s classic work on the Cone of Uncertainty.

 

Note that the broad end of the cone, at the time of producing the estimate, gives a range of accuracy of the original estimate of from 25% to 400% of the actual. 

The Standish Group’s CHAOS report shows this clearly.  Here’s the table of Time Overruns from the report.

Time Overruns  % of Responses
Under 20%  14%
21 – 50%  18.30%
51 – 100%  20.00%
101 – 200%  35.50%
201 – 400%  11.20%
Over 400%  1%

Look at this as a histogram:

image

Thanks to DKDK the work more often ends up running long.  Sometimes, sure, it’s early thanks to DKK.  Only 20% of the time does the combination of KK and KDK prove roughly accurate. 

Over to you

This is why the wise thing to do is turn the iron triangle upside down and declare that the team is fixed, the time is fixed (by sprints), and the scope is variable.  This isn’t just wise, it’s because there is no such thing as a fixed scope!  The scope of anything that hasn’t yet been created is unknown, and so must be variable.  It’s all pretend!

Now, do I need to explain the genius of relative size estimation using story points, limiting work in progress, and reducing cycle time?

The only sensible thing to do is to estimate using a scale that is course grained, recognizes that the larger something is the more uncertainty there will be, and is local to those doing the work. Hence Story Points and Relative Size Estimation.

It’s only sensible to limit the amount we do to the smallest possible amount so we can check with our customers if it’s actually useful to them quickly, and adjust course accordingly. Continuous planning makes sense.

It’s only sensible to minimize up front detailed specification and estimation, as that’s the point when we know the least. Understand what is meant by Last Responsible Moment.

So give an estimate, sure.  Estimate the whole thing.  But it is unprofessional and irresponsible to then allow yourself to be held to a fixed scope in an Agile world.  Don’t do it.  You’ll only disappoint your customer when the intention was to delight them.

Comments, as ever, are more than welcome.

One touch dial-in to meetings on an iPhone

Today, a tip, nothing to do with Agility other than being a move towards a world where technology makes life better, not worse.

The story

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!!!!!!This is you when this happens

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.

No, I don't know why your hair's a different color and you're wearing different clothes, iPhones aren't that smart Explanation:
When the reminder pops up, touch the number to dial. The commas are 2 second pauses, so they allow for the call to be connected. 

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

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?

Nope.

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.

Exceptions

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!

“Exceptional” not required

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?

Video of my presentation “The Seven Wastes” at Portland

Thanks to Sanjeev Raman for inviting me up to Portland Agile & Scrum Meetup Group.  My topic was “The Seven Wastes”, also known as Type II Muda (Wastes of Activity).  There’s a spot of Lean for you!

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.