What’s your Agile Number

The Bacon Number

Kevin Bacon is a prolific actor who has appeared in diverse films.  That sparked a game called “three degrees of Kevin Bacon.”  One person would say the name of an actor, and then you’d have to connect to Kevin in less than three steps.  Each step was a movie.  So for example

Nicholas Cage was in Leaving Las Vegas with Elizabeth Shue
Elizabeth Shue was in Hollow Man with Kevin Bacon

So they connect in two steps.

This also gave us the idea of “Bacon Number”;  Kevin has a Bacon Number of zero, Elizabeth Shue 1, and Nicholas Cage 2.

The Agile Number
I coined this phrase a while ago to describe how many steps a team had to go through to reach an actual user.  That is to say is it via a Product Owner (Agile Number of 2) or are their more layers (a Product Manager, a marketing research team etc.)…

This matters a lot.  Every hand-off between people is a place where a delay can happen, and an error misunderstanding occur.  While many teams claim to be using “user stories” the question is whether that story is actually what the users would say?  And whether what they say is really what they want?

Extreme Programming
User stories were an element of Extreme Programming (XP), one of the lightweight techniques in the 1990s.  A lot of the authors of “The Manifesto for Agile Softeare Development” had an XP background, with a couple promoting Scrum and some using Crystal and other approaches.

XP had the notion of “the onsite customer” who was always there to answer the teams questions.  The original idea of a user story was “a placeholder for a conversation”, not some fixed format.  It was on a 3″x5″ index card to limit what could be written, and maximise what was said.  If it was more complex than that, start again until the idea is simple.

The team’s Agile Number was one, or maybe even zero.  The user was fully integrated into the team, understood the domain, and could make decisions on the fly with them about the product.  No delays.  No errors.

The Product Owner
The very best product owners I have worked with have been user-domain experts, and fully capable of being the on-site customer.  They can – and will – make decisions on the fly about the detail of the product, and they also know who the right people are to get into the room for a Sprint Review.

The Sprint Review is where the team is getting together with users and other experts to look at the product-market fit, and how that has changed in the last Sprint.  Should we end-of-life our product?

Again, the team is engaged and involved with people who use the product and know the market.  Agile Number is one.

Gemba
Gemba is a term from lean ideas and Toyota;  it’s Japanese for “in the place” or : at the scene of the crime” and it exhorts managers to get out from their offices and go back-to-the-floor for honest, psychologically safe inspections of how the work is really done, so they can aid and support teams through systemic improvements.

We can take that a step further.  We can go to the place where our products are used, and see them in action.  We can sit along side users and see what they really do, and what really slows them down, and what they have to do in other tools (with hand-offs, errors and delays).  We can make their world better.

If someone else is doing that not the team members?  The Agile Number goes up.

Some of the best insights we had on one team came from deploying a developer into a field crew in the Australian Outback to see how the product was used on site doing surveying.  Prior to that our Agile Number had been three or four, handed up through line management chains and across.  Or had been via e-mail, and as Jeff Patton comments in User Story Mapping – a shared document is not a shared understanding.

TLDR;
If you want to be more agile, make better products and have fewer errors, your Agile Number needs to be one, or even zero.  More than that slows you down.