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

One common practice I see in the organizations I work with, is the use of the term “resources” to describe the people who do the work.

I often overhear things like “managing resources”, “assigning resources”, “not enough resources”, and even the “resourcing plan”.

What are we really talking about here?  Pencils?  Paper?  Toner? Oil?  These are the kinds of things I picture when I hear the term resources.  Things that are used up and/or thrown away when they are used up.  Things that are both disposable and replaceable.  Except, when I hear this term in organizations, they’re typically referring to people.

So if you’re using a term like “resources” to describe your people and if other things that are referred to as resources are disposable and replaceable, how might you treat your people?  In what way does an organization that views their people as disposable “resources” behave? When we erect entire departments around managing our human “resources”, how might that department view its role?  As an organization, how much will you invest in training and learning for your disposable and replaceable “resources”?

When I teach Scrum, I often refer to the chicken and the pig joke that is used to describe the different participants in organizations using Scrum. I reference this joke purely for historical value and always emphasize that these are not terms you should be using to refer to each other.  After all, calling each other chickens and pigs is no better than being called a “resource”.

In one session, while explaining why you shouldn’t actually use the term chicken or pig, I also mentioned the negative effects of using the term “resource”.  When I did, someone in the session gasped and blurted out, “Oh my God!  I do that!”.  To her, it was a revelation.  The reasons not to do it made perfect sense when explained to her, but she was just so used to doing it because that’s what everyone else did. After that, she encouraged everyone in the group to call her on it if she ever used the term.  A tough habit to break for sure, but at least she was now aware of the effect it had within the team and the organization.

Later, one of the other people in the session asked, “What do we call them?”.  The rest of the attendees gave her a bit of a quizzical look and then someone said “People?”.

Using terms like people, teams, or individual names changes the interaction. It makes you frame the discussion in a different way.  It’s not just semantics either, it changes the way you represent people in your organization.

For example, Ronald Baker, author of the fantastic book Pricing on Purpose, introduces the term Human Capital.  I’m not sure I’m sold on that term, but at an organizational level, capital seems far more appropriate.

From his book,

Human Capital (HC). This comprises your team members and associates who work either for you or with you. As one industry leader said, this is the capital that leaves in the elevator at night.  The important thing to remember about HC is it cannot be owned, only contracted, since it is completely volitional. In fact, more and more, knowledge workers own the mean of your company’s production, and knowledge workers will invest their HC in those organizations that pay a decent return on investment, both economic and psychological. In the final analysis, your people are not assets (they deserve more respect than a copier machine and a computer)-they are not resources to be harvested from the land like timber when you run out.  Ultimately, they are volunteers, and it is totally up to them whether or not they get back into the elevator the following morning.

Now imagine if you were to start referring to your “resources” as volunteers? How might that change your organizational behaviour?

In every organization there is knowledge in the heads of the people you hire that can be documented or passed on through training, but there is also tacit knowledge that cannot be easily transferred from person to person. If that volunteer chooses not to get back in the elevator the following morning, that knowledge goes with them.

That seems more than a resource to me.

In the organization I’m currently working with, without any influence from me, they have renamed their Human Resources department “Employee Experience”. I suspect a department focused on employee experience will behave very differently from a department focused on managing human “resources”.

What do you think?

Today’s image by Ha-Wee

I recently started a new coaching engagement and for the first time in my career I’m pairing with another Agile Coach.

I met briefly with the other coach a few days before my scheduled start date.  He had been working with the organization for several months and was going to be absent my first week on site. We used the time we had to prepare for the week to come.  We went over some documents, notes, and some of the areas they were trying to focus on.  One of the critical notes was a feeling that there was a missing sense of urgency around the transition they were undertaking.

When I arrived on my first day, we were supposed to have a discussion on the topic of urgency.  The scheduled talk on urgency was postponed.  Not a good start.  Most of the day I was left to my own devices and mostly stayed in observation mode. I didn’t know where the teams were at, what they had done, or how the existing coach was interacting with the teams.  I was looking to get a hint at what the teams expected from their coach.

The next day was similar to the first.  Meeting postponed and more observation with a little more interaction with the teams.

That evening I went to the monthly XP Toronto get together.  After the meeting, I sat down with Michael Sahota and we spent a few minutes playing catch up. Through the course of our discussion we got to discussing my current situation.  Michael, as usual, gave me some great advice.  He encouraged me to not worry so much about what the other coach had been doing and to just do my own thing.  He also referenced Alistair McKinnell (update: Turns out the original source was Jason Cheong-Kee-You.  Thanks for the correction!) on the importance of beginnings.

This simple prodding immediately removed my hesitancy about stepping on the toes of the other coach as well as freeing me to bring my own sense of urgency to the teams.

The next day we had our first discussion on urgency and I started taking action on my original observations.  Things were finally getting started.

Most Agile teams start their day with a team stand-up meeting. The way this meeting goes is often a good indicator around how the rest of the day will go.  If people are showing up late, coffee in hand, not fully awake, stumbling through their responses and not paying attention to what other people are saying, you can bet the rest of the day will be just like that.

I do a lot of improv and as a result I bring a lot of my learnings there to the teams that I work with.  I always like to do a quick warm-up with teams before the stand-up starts.  That way everyone is engaged, awake, and paying attention to what is happening for the rest of the meeting.

With this group, I chose to start by introducing clap focus to the teams.  This is a quick, high energy game that brings eye-contact, focus, and attentiveness to teams.  I also added using names during the passing to help me remember the names of the people playing.

I really like this concept for stand-ups because it also introduces the idea that you don’t have to speak in order.  By continuing the clap focus into the meeting itself, people have to keep on their toes, remember who has gone and who hasn’t, as well as always listening to each person.  After all, they may get the focus passed to them next.

Sometimes, even improv teams forget how important beginnings are.  An improv team I coach, recently did a show and instead of coming out united and together, they came out more casually, individually and gradually made their way on to the stage in a seemingly disjointed fashion.  As expected, the show ended up feeling disjointed, low energy, and lacking focus.

Beginnings are important.  They set the stage for what will come after.  After all, you wouldn’t want your beginning to look like this, would you?

What could possibly come after a message like this?

Today’s images by rkramer62 and CJ Sorg