Agile gave us a wonderful head-start in a different direction than the one we’ve used to (heavy weight methods.) Personally I feel we’ve got as much value we could. Now its time to start thinking from a different direction, building on what we already know and to some extent unlearning some things we know.

Wait a second, isn’t Agile all about “Inspect and Adapt”?

There is a limit to “inspect and adapt”. If you look at the Lean movement, most people talk about Kaizen (small gradual change, change for the good, which is in-line with inspect-and-adapt). But very few people talk about Kaikaku (disruptive change or transformation).

Remember Agile was Kaikaku for most of us in late 90s. And then we’ve applied Kaizen to it for many years. IMHO now its time to apply Kaikaku again.

Recently TV tweeted saying:

Is “measure twice, cut once” an #agile value? Why shouldn’t it be – it is more fundamental than agile.

To which I responded saying:

“measure twice, cut once” makes sense when cost of a mistake & rework is huge. In software that’s not the case if done in small, safe steps. A feedback centric method like #agile can help reduce the cost of rework. Helping you #FailFast and create opportunities for #SafeFailExperiements. (Extremely important for innovation.)

To step back a little, the proverb “measure twice and cut once” in carpentry literally mean:

“One should double-check one’s measurements for accuracy before cutting a piece of wood; otherwise it may be necessary to cut again, wasting time and material.”

Speaking more figuratively it means “Plan and prepare in a careful, thorough manner before taking action.”

Unfortunately many software teams literally take this advice as

“Let’s spend a few solid months carefully planning, estimating and designing software upfront, so we can avoid rework and last minute surprise.”

However after doing all that, they realize it was not worth it. Best case they delivered something useful to end users with about 40% rework. Worst case they never delivered or delivered something buggy that does not meet user’s needs. But what about the opportunity cost?

Why does this happen?

Humphrey’s law says: “Users will not know exactly what they want until they see it (may be not even then).”

So how can we plan (measure twice) when its not clear what exactly our users want (even if we can pretend that we understand our user’s needs)?

How can we plan for uncertainty?

IMHO you can’t plan for uncertainty. You respond to uncertainty by inspecting and adapting. You learn by deliberately conducting many safe-fail experiments.

What is Safe-Fail Experimentation?

Safe-fail experimentation is a learning and problem solving technique which emphasizes on conducting many simultaneous, small, controlled experiments with small variations. Since these are small controlled experiments, failure is an expected & acceptable outcome.

In the software world, spiking, low-fi-prototypes, set-based design, continuous deployment, A/B Testing, etc. are all forms of safe-fail experiments.

Generally we like to start with something really small (but end-to-end) and rapidly build on it using user feedback and personal experience. Embracing Simplicity (“maximizing the amount of work not done”) is critical as well. You frequently cut small pieces, integrate the whole and see if its aligned with user’s needs. If not, the cost of rework is very small. Embrace small #SafeFail experiments to really innovate.

Or as Kerry says:

“Perhaps the fundamental point is that in software development the best way of measuring is to cut.”

Also strongly recommend you read the Basic principles of safe-fail experimentation.

I’ve seen some teams getting so caught up in answering the 3 questions of the stand-up meetings, that they even forget the objective behind the standup meeting.

Following are NOT the goals of a standup meeting:

• Get in-sync or to know who is doing what & where they stand. 
  • That information can be achieved through the story-wall (virtual story-wall if you are using a Agile PM tool). If you are a team of 3-4 people and sitting next to each other, you’ll anyway have this information (you better).  
• To identify impediments. 
  • Why wait till the standup meeting to identify something is blocking you. If you can’t solve something yourself, bring it up to others notice immediately. Don’t sit on it.
• Status report. 
  • This is the worst goal you can have for standup meetings. We are moving away from micro-management. 
• Communication to the chickens. 
  • Again they can look at the project status on the story-wall. Or they can stop by in the team room and talk to someone informally. We don’t need to have a meeting for them.
• And so on…

IMHO the real goals of a standup meeting is

• To come up with a Game Plan till the next standup meeting. 
  • Its an opportunity to inspect and adapt 
  • Helps in doing micro-re-prioritization 
  • Helps in keeping everyone on the same page as far as the goals/vision is concerned

If answering the 3 questions helps towards this goal, then go ahead. But don’t think of them as an end in themselves.