Fundamentals: The first line of the Agile Manifesto

How much wisdom is in the first line of the Agile Manifesto?

Well, what is the first line? I ask, because I all too often see people think that it’s “Individuals and interaction over process and tools”. That not the first line. That’s the first value, and I’d argue that missing the first line means that you’ve totally missed the deeper context for all of Agile thinking.

“We are uncovering better ways of developing software by doing it and helping others do it.”

That’s the first line. If you doubt me, check

Before you think I’m just being pedantic I’d like to walk through this sentence and really bring out its glory.

  • We”: this is something that’s done collectively, not alone.
  • are”: it’s done in the present, in other words all the time. This is not an invocation of past insights, it’s a reminder that you need to be present, in the present, conscious to what’s going on right now, and not relying on what might have happened in the past.
  • uncovering”: not inventing, or selling, or theorizing, or proposing. By being present, by paying attention to what’s going on here and now moment by moment, we can uncover what is emerging. Paying attention to the work will reveal how the work is actually working.
  • better”: not best, but better. In a creative field there is no best but there could always be better.
  • ways”: what ways? We’re not saying. We can’t. We don’t know. We are uncovering them. Agile has no answers! Sorry about that. If we thought we had the answers – the ways – we’d be selling you something that had worked for us in some situation we were in. Not your situation now. So we might achieve compliance if we had enough authority, but can you smell the hubris in that? The whole point is that we’re doing something creative. Something we’ve never done before. If we had done it before, we’d be using that! The trap is thinking you have done something before when you haven’t and relying on the “ways” that worked back then. The word “playbook” – I’m looking at you! And you, “standard operating procedure”! Those ideas are useful, even necessary, but they’re simply not sufficient in an rapidly changing world.

Where was I?

  • of developing software”: the authors of the Manifesto were at the time only thinking of software. But by taking out these words and replacing them with “working” we have a much more broadly applicable philosophy emerging. For developing software of course this all applies. But starting to work consciously, always being present to what’s emerging, that’s helpful in any field. It’s dogmatic to insist this only applies to software, and it’s closed-minded to think, for example, that “hardware can’t be Agile”. Remember “ways”? Uncover some better ways for hardware, why not? For accounting? Why not? For facilities? Why not?
  • by doing it”: the ways are being uncovered by the actual practitioners. Not theoreticians. Now theory and academic work is essential, I grant you. It can shift the paradigms of thought in which the work occurs, so it can actually accrue as “experience” not just “time served”. Ten years thinking the same way is not ten years experience. So think, and do. But theory on it’s own, no matter how fascinating, is ultimately of no value unless it’s applied.
  • and helping others do it”: which rounds us back to doing this not just collectively but also collaboratively. You get more done working with people than you do alone. More than that, it speaks to a deep principle of life: you can get whatever you want if you help enough other people get what they want. Remember where the money comes from.

This is the first line of the Agile Manifesto:-

“We are uncovering better ways of [working] by doing it, and helping others do it.”

It goes on “Through this work we have come to value-”

Now go read the values and principles and see if they don’t taste different than they did before you read this article. Delicious, eh?

Social Automation

I do love finding a couple of words that sum up a subject neatly. The latest: “Social Automation”.

This popped into my mind (thank you, Subconscious Me) as the point of regular scheduling for meetings and ceremonies. Once their times, locations, and where possible, standard agenda and so on are all set, the brain-burning cognitive load has been lightened.

This is very like David Allen’s thinking behind GTD. If you have a system to capture all your outstanding “open loops”, and use the system reliably, the cognitive load of holding all those open loops is gone. Lower stress, more brain power available for doing the things rather than grinding on all the almost remembers things to do.

So ( favorite question) hands up those here who are not professional. Right? Merriam-Webster has “professional” as “relating to a job that requires special education, training, or skill”. I want my energy to go into the job or increasing my “special education, training, or skill” not into the noise around it.

Remember, our brains are phenomenal pattern-matching threat-management engines. The more habitual the pattern, the less fuel the engine requires. Habit rocks!

So use habit to lighten the load.

The trap? Using habit to lighten the wrong loads. Or to go unconscious. Or to rely on “How it’s done round here” for something that actually requires some active thought.

That’s the point. Use habit aka Social Automation to lighten the load so you have the fuel available for the active thought.

Did I just reinvent Scrum?

They took the Null Set! From beyond!

I had one of my occasional agile dreams last night.

Because we’re rewriting the product owner training, I needed an exercise to challenge the participants to create a truly innovative product.  (Remember, this is a dream.)

The challenge is this: something is poking through from beyond our dimensions, just like a finger descending from above into Flatland.  It has taken the “null set” from us.  The product challenge is to resolve this situation.

I told my wife this dream as we both woke up.  Sensible woman that she it, she responded “Alien from another dimension eh?  Have you tried communicating with them?  They’ve taken all your zeroes?”  I didn’t point out that zero and null aren’t the same, it didn’t seem to be the right moment.

This dream, of course, felt like it had taken up half the night, and was so important, I should have gotten out of bed and immediately updated our training material.  I didn’t, and perhaps this is an opportunity missed.

So, dear reader, if you have a solution for aliens from another dimension stealing your null set, an innovative solution mind, then please write in on a 3×5 card, attach it to a mint-condition R-series Bentley Continental Tourer Fastback and submit to your author through the usual channels.

Sublime and ridiculous

Here’s the sublime:  Arlo Belshee’s clarity is just dazzling.

And here’s the ridiculous  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.


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.


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.


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


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.


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:


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.

How to handle Engineering Stories as a Business Product Owner.

Keep it simple.  As a Product Owner, you’re responsible for the “What” and “Why”.  The team are responsible for the “How”.  You’re responsible for prioritizing the backlog, in fact this is your main responsibility.  So for those engineering stories that you simply don’t understand as they’re technical gobbledygook, then just come back to the basics of user stories: the Three Cs.

  • Card
  • Conversation
  • Confirmation

You can write the card with the team’s guidance very easily.  Story: Ranking engine research.  As the customer options system, I need a ranking engine so that it is possible to present options in preferred order defined by a combination of business rules and customer preference.”  There, that wasn’t so hard.  There’s your Card.

Now for the Conversation.  “Guys, I need some help to prioritize this…” will lead to a conversation about size, difficulty, dependency, value from learning, buy versus build, and so on.  That’s great.  And it might not need to be written up in the story, as what value would that give.  If there’s a core agreement you want to document to remind yourselves during the sprint, sure, write that.BritGirlCatBoyDogknit

Now, how about the Confirmation.  That will probably mean the team needs to help write the Acceptance Criteria.  They’ll have some idea what required for the story to be complete.  Document that in the story’s acceptance criteria.

Now, you’ve done your job.  You’ve written the Card, you’ve had the Conversation so everyone’s got as much understanding as they need in their role, and you can Confirm with the team that they’ve met the Acceptance Criteria, so you can know that you actually can accept it.

Do it the way it’s designed, it turns out it’s pretty straightforward.  Don’t get caught in the weeds.

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!

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.

In my estimation…

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.

…The Fifth

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.

Pairing and Teamwork for The Uninitiated and Resistant

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!