Planning for Failure

One of the great things that has come out of The Lean Startup movement is the focus on customer validation.

Too many organizations I work with either gloss over this step or skip it entirely.

The process usually looks something like this:

1. Customer reports a bug/requests a feature.
2. Bug gets “fixed”/feature gets built.
3. Bug/feature gets deployed.
4. Profit?

It all seems well and good and you might expect “profit?” to be “profit!”, but is it? Did that bug actually get fixed? Does that feature actually solve the problem your client is having?

Most organizations don’t follow up to confirm that the customer is actually happy with the new situation or if they are even using the new feature! To make things worse, if the customer does complain that the bug isn’t fixed or the feature doesn’t solve their problem the response is typically, “We did what you told us to do”.

These days, being an order taker is not enough. If your organization sells itself on its ability to follow orders, then the customer will either go for the cheapest option they can find, or they’ll just do it themselves.

When customers come to you, they pay you to think! They’re looking for you to solve a particular problem they have. And someone who never validates the results with their customer isn’t a very good problem solver!

In one organization I worked with, we had set up a large Kanban-like wall that showed the progression of a feature through the system from when it was received until it had been deployed.

Once this wall had been setup and was being used, I added a column to the board called “Validated?” after the deployment column.

At first, the response was,  “Well, it’s deployed, of course it’s validated” or “[internal person in the company] saw it and is fine with it”, to which I would typically respond, “Well, have they checked with the actual customer?”

In the latter case, the next time I checked in, the person had followed up with the internal person and discovered that no one had told the customer that their issue had been fixed!

This was a frustrated customer who was working around the issue in the interim and was very close to no longer being a customer. And now, a month after the bug had been resolved, no one had told the customer!

I wonder how many customers the organization had lost over the years just because no one told them when their problems were solved? 

The impact of not validating your results is not just limited to customers. There is nothing more demoralizing and demotivating than working on a feature that never get used.

While investigating a separate issue, a developer I once worked with discovered that a feature he had spent three months developing had not been used once. He was furious! Three months of his time wasted on something no one was using!

Every organization I visit has a business case for why the feature they want should be built, but so few actually check that what they built was worth the effort.

That’s why it’s always important to build the smallest thing you can and validate it as soon as possible.

Today’s image by joeltelling.

I recently came across an article on The Hacker Chick Blog called, “Lean Startup: It Rocks Far More Than Agile” and now it’s time to rant about it.

First, a disclaimer: I love the ideas in The Lean Startup. I ordered my copy of The Lean Startup by Eric Ries when it became available for pre-order, I bought The Lean Startup course on Udemy via AppSumo and I already have a copy of Running Lean by Ash Maurya.

In addition, I follow Abby Fichtner ( @hackerchick)  on twitter and I enjoy her content and I’ve got nothing against Joshua Kerievsky (@JoshuaKerievsky) who put the source chart together.

What I am ranting about, is this notion that Agile Vs. Lean Startup is a thing. That they are somehow opposed and that people will have to choose between them and that somehow they must be convinced that one (The Lean Startup) is superior to the other (Agile).

This is just stupid. It makes no sense and it does more harm than good to both the Agile and Lean Startup communities.

So what’s this about? Well, if the article and table are to be believed, then The Lean Startup “rocks far more than Agile” and everything in The Lean Startup is “more real” than in Agile. I won’t go line by line through the table, because I tried and it just got too ridiculous, so instead I picked out some gems and I’ll leave the rest to you.

Product Roadmap (Agile) vs. Business Model Canvas (Lean Startup)

Business Model Canvas is great, no arguments there. However, who said Agile requires a Product Roadmap? I haven’t heard anyone suggest that a Product Roadmap is an Agile thing at all. I’m pretty sure the idea of a Product Roadmap existed long before Agile. There’s no reason why an Agile team couldn’t use the Business Model Canvas instead of a Product Roadmap. Nothing about Agile prescribes a Product Roadmap.

Product Vision (Agile) vs Product Market Fit (Lean Startup)

I see no reason why you can’t have a Product Vision and discover your Product Market Fit. I’d be worried about working for an organization that didn’t have at least some kind of vision.

Release Plan (Agile) vs Minimal Viable Product (Lean Startup)

Who says your release plan can’t be your Minimal Viable Product? In fact, before it was hip to have a Minimal Viable Product, people in Agile were talking about Minimum Marketable Features (see Software by Numbers by Mark Denne), but hey, that book came out way back in 2003 and we can’t be expected to remember that far back, can we?

Sprint (Agile) vs Kanban (Lean Startup)

Since the term “Sprint” was used, I’ll assume this is jumping on the Scrum vs Kanban bandwagon, which I’ll go into a bit more later, but the real interesting thing about this statement is that I don’t recall Eric Ries spending a lot of time talking about Kanban in software development. In fact, it looks like most of the organizations he talks about have been using XP (Agile) on the development side of things.  Eric also seems to work under the assumption that you’re applying Lean Startup ideas to an already Agile development team.

I have no idea how Scrum vs Kanban or Sprint vs Kanban relates to The Lean Startup, nor do I see any evidence that Kanban is required as part of The Lean Startup.

User Story (Agile) vs Hypothesis (Lean Startup)

I remember a day not too long ago, when it wasn’t Agile vs Lean, but Agile and Lean. Which makes more sense, since both Agile and Lean software development draw heavy influences on Lean Manufacturing.

I remember when Mary Poppendieck (Lean) wrote the forward to Ken Schwaber’s Agile Project Management with Scrum, and back when Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck was part of the Kent Beck (XP) Signature Series with a forward by Jeff Sutherland (Scrum).

I also remember Implementing Lean Software Development talking about 90% of the things in The Lean Startup including developing a Hypothesis and performing experiments to prove it. This was back in 2007 and I’m sure quite a few Agile type people read and implemented a lot of the ideas in that book including the use of Hypothesis.

I also don’t know of any reason why a Hypothesis can’t be a story.

Definition of Done (Agile) vs Validated Learning (Lean Startup)

While Validated Learning is great and important, it has nothing to do with the Definition of Done. The Definition of Done gets everyone on the same page as to what we mean when we say this feature is “done”. Was it tested? Code reviewed? What about load tests?

It might be interesting to include Validated Learning as part of what it means to be done, but Validated Learning in no way replaces the Definition of Done.

Red-Green-Refactor (Agile) vs Learn-Measure-Build (Lean Startup)

Is this a joke? I can’t believe I even have to write about this. While Red-Green-Refactor is a practice that comes from Test Driven Development (TDD) and describes how you write your code in a TDD environment, Learn-Measure-Build isn’t talking about how you code at all. One has very little to do with other. You might say they both come from Deming’s Plan-Do-Check-Act cycle which was one of the core influences in Agile.

I see no reason why you would stop using TDD to develop your software simply because as a business you now do the Learn-Measure-Build cycle.

Mock Object (Agile) vs Feature Fake (Lean Startup)

This can’t be serious anymore, can it? Again, we’re comparing how you test your code vs. how you test your business hypothesis. Apples and Oranges people…

Continuous Integration vs Continuous Deployment

*Sigh*, show me one organization doing Continuous Deployment that doesn’t have Continuous Integration. It’s one of the first steps to doing Continuous Deployment. Is it April 1st?

Ok, I’m done ranting about the article itself, I can’t take any more. Time to move on.
The real problem here isn’t that it’s factually inaccurate (it is) or that it’s stupid (it is), it’s that we’re trapped in this cycle where in order to gain mind share, rather than simply spreading your successful ideas, it seems like it’s required that the new thing (The Lean Startup, Kanban) gain its ground by attacking the old thing (Agile, Scrum) even when it’s building on the old!

It would be one thing if the new thing were something radically different to the old (think Toyota Production System vs the US assembly line) or something that had opposing values (think Agile vs Waterfall), but it’s not. These are complimentary things.

You can do both Scrum and Kanban in your organization, you can use Lean Startup concepts on your Agile team, and you can apply both Agile and Lean principles. There is no conflict here.

Earlier I said this does more harm than good to both communities. Here’s why:

Let’s say you’re a change agent and you’re trying to introduce Agile in a waterfall organization back in the days before The Lean Startup became a big deal. You’re starting to make progress, but people are still struggling. Then suddenly you turn around and say “Lean Startup rocks way more than Agile! Let’s stop doing this thing I pushed hard for and hop on this new trend!”. How credible are you now in your pursuit of change?

Or let’s say you’re a change agent and you’ve been trying to introduce Agile in a waterfall organization. You used to hear people say “Agile is just a fad, it’ll go away”. Now when they hear about The Lean Startup and how it rocks way more than Agile, they say “I told you so. And this one will go away too.  No reason to change.”

And if you’re trying to introduce a Lean Startup approach, good luck getting solid development practices in. “We don’t need Agile, Lean Startup is way better! We don’t need continuous integration or TDD, we’ll just ship!”

Or “Agile was a passing fad, so is The Lean Startup. We’ll catch the next one…”

Or even, “Yesterday you were selling Agile, now you’ve ditched that for The Lean Startup. You’re all just snake oil salesmen…”

Articles like The Lean Startup Rocks More Than Agile don’t help. Maybe they can get you some short-term publicity, but they’re not helpful in the long run. It just makes it harder to overcome organizational complacency.

What you really need is a  “Yes, and” approach. An approach that says, “What you’re doing in Agile is great, and hey, have you tried a Business Model Canvas? How about Validated Learning? Check out The Lean Startup there’s some great things you might want to add to what you’re doing”.

You might even say that The Lean Startup turns your Agile up to 11!

Today’s image by TheBusyBrain.

As someone who brings change into organizations, at some point I will usually come up against someone who will resist the change.

Sometimes this resistance is not resistance to the change itself, but because the person cannot see the path from the current world to the desired state.

The process of changing can seem so overwhelming and so perilous that it prevents people from taking even the smallest of steps.

Most times, people can only see the barriers or worse, they make assumptions on what is and isn’t possible without exploring what options are out there. They’ve become so conditioned to the their current situation that they feel that that’s “just the way it is”.

Initially, there’s probably a desire to ask “Why can’t you make this change?”.

The problem with ‘Why’ questions is that they put the person being asked the question on the defensive. They now feel that they have to justify themselves personally and will seek to find any reason not to make any progress. And as Jerry Weinberg pointed out, “People will never run out of reasons.”

And while people may have some of good reasons, that’s not really what we’re looking for. What we really want to know is, “What would it take?”. This is a much more powerful question.

I prefer questions like these because they move you forward. They allow you to get beyond why something can’t be done and start getting you into a creative/problem solving mind-set.

For example, a few months ago, I attended Agile Open Toronto and was involved in a side conversation with a colleague of mine who had recently been exploring the concept of the Lean Startup. One of the main concepts of the Lean Startup is to develop a hypothesis about your product and test it in the market as soon as possible.

My colleague had been giving us the background on the new product he had been building when it came to light that he hadn’t released anything yet. Naturally, one of the questions he was asked was, “Why not?”. This led him to defend why he hadn’t released yet.

When the question turned to “What would be the minimum feature set you need to release?”, the conversation took off. Now we had some real practical discussions on what steps needed to be taken. As a result, we discovered that many of the things he had originally thought were required for the initial launch, actually weren’t. By the end of the discussion, he had publicly committed to having his product released by a date much sooner than he had originally anticipated.

In a similar situation, I was working with a client and noticed they had set a code freeze date one month prior to when they had scheduled the release. When I pointed this out, they began to justify all the reasons why this was the way things were.

After hearing them out, I followed up with, “What would it take to release in two weeks instead of four?”.

There was silence in the room for a good minute as the question hung in the air. Eventually someone said, “I don’t know, we haven’t really looked into it.”, followed by “We should probably find that out.” from another person in the meeting. Here, simply asking why would have allowed them to maintain the status quo, asking “What would it take” spurred them into action.

There are a couple of times when asking why is appropriate.

1. When seeking a sense of purpose, “Why do we do the things we do?”. See Simon Sinek’s book, Start With Why.
2. When doing Root Cause Analysis using 5 Whys.

In the case of the latter, always make it explicit that you are using the technique. I once saw someone attempt to do this in a conversation without making it clear what she was doing and she only succeeded in irritating the person she was trying to help.

So next time you run into someone who has a million reasons why something can’t be done, perhaps try asking them “What would it take?”

Today’s image by permanently scatterbrained