Get our video course, "Improv Your Agile or Scrum Stand-up", for free when you subscribe to our mailing list!

You're viewing all posts tagged with kanban

No One Told the Customer! The Importance of Validation

Share/Bookmark Subscribe 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.

Sign up and get our video course "Improv Your Agile or Scrum Stand-up" for free!


Orange: It Rocks Far More than Apple - A Lean Startup Rant

Share/Bookmark Subscribe

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.

Sign up and get our video course "Improv Your Agile or Scrum Stand-up" for free!


On Improv, Agile, and Fear at Agile Coach Camp Canada 2010

Share/Bookmark Subscribe

Back in June, I attended Agile Coach Camp Canada 2010 and it was an amazing experience.  As some of you know, I had some issues getting to the camp, but once I was there I had the time of my life.

You can read Michael Lant’s excellent summary of the event or Selena Delesie’s great write up on the open space experience.  You can even watch all the lightning talks or see the session summaries.

For this post, however, I’m going to relate to you my personal experience attending the conference, since this conference single-handedly changed the way I approach working with Agile teams.

This was my first Agile conference and also my first open spaces conference, so I wasn’t quite sure what to expect.  I was familiar with the concept of lightning talks and had been kicking around the idea of giving one.  But on what topic?  Would I go through the details of some of my previous Agile experiences?  Talk about what worked, what struggles I and the team went through, or what issues never got a satisfactory resolution?  Maybe.  But the more I thought about it, the more I wanted to talk about my other passion: Improv.

Improv has played a significant role in my life ever since I first read Truth and Comedy back in High School.  This book made me aware of the possibility that a group of performers could get together and perform an entire artistic piece without having a writer or director telling them what to do.  That on the spot these performers could organize themselves and produce a unique and valuable artistic experience that is greater than what the individuals themselves would have created had they been left to plan it out on their own.  That by working as a team, and by trusting each other, they could take risks with the confidence that their team would be there to support them.  And not just for short-form games like those featured on “Whose Line Is It Anyway?”, but for longer durations, producing stories and characters with depth and meaning.

So when I first came across Agile software development in my professional career, it didn’t strike me as “ridiculous” or “crazy” at all.  The idea that we could have self organizing teams producing great software was not only possible, it was obvious.

However, I took the connection between Improv and Agile for granted.  While it clearly informed me and my approach, I was often hesitant to fully explore it with teams and organizations for fear that it might be a little too “artsy” for them and cause some people to pull away from the whole process.

When I gave my brief talk about how Improv informs me and my approach at Agile Coach Camp, I was shocked with how well it resonated with others in the room.  I owe a large debt of gratitude to Michael Sahota for being excited enough about the idea to convince me to propose an open space for it the next day at the conference.  Something I was more than hesitant to do.

The session went better than I could have ever hoped and it was clear there was a place for this sort of hands on “artsy” approach in the community.  In fact, it seems to be gaining momentum.  I was told at the conference that Tobias Mayer, Creative Director of the Scrum Alliance has an Improv background.  Also, Matt Smith ran an Improv session at Agile 2010 this year which I hear was a hit.

And I realized, I never would have discovered any of this, or had this wonderful experience if I hadn’t gone to the conference and if I hadn’t gone up and given that original lightning talk.

Which brings me back to one of the core points of Improv.  A point that I often refer to when talking about making changes in an organization or when talking about the rules of various Agile approaches.  I studied for a bit with Keith Johnstone, one of founders of modern Improv, and he told us (paraphrasing), “You can do anything you want on stage, break any of the rules, as long as you don’t do it out of fear.”

I also recently found this great quote on fear and Improv from TJ and Dave from their amazing DVD “Trust Us, This is All Made Up”,

Most of being good at it… of being good at the work of it is… is to get over fear.

That everything that corrupts it comes from fear.  Fear is the root.  It brings that ego to the forefront of “How am I doing?  How’s it going? How am I being perceived right now?”

Yeah, most of my day is spent trying not to think about it.  What’s going to happen that night because I don’t want to become fearful about it.  And most of what happens in this room is about that.  Trying not to get fearful about it.

I think it’s not to overcome fear.  Fear just disappears.  It’s just not there.

This faith, this trust, and this confidence, when those things are in place, there’s no room for anything else.

If you’re thinking of making an Agile transition in your organization, the only question you have to ask yourself is, what are you afraid of?

So thank you to everyone at Agile Coach Camp Canada for allowing me to bridge the gap between my two passions and for helping me realize that once again, the only thing that’s stopping us is fear.

Sign up and get our video course "Improv Your Agile or Scrum Stand-up" for free!


Greyhound Knows How to Fail

Share/Bookmark Subscribe had the pleasure of attending Agile Coach Camp Canada this year. It was an amazing experience.  I’ll be writing about that experience in a future post, but in this post, I would like to address what I had to go through just to get to the conference. 

Two days prior to Agile Coach Camp Canada, I received an email informing me that a spot had opened up and that I would be able to attend the event.  I immediately began to make my travel arrangements.  I got my room taken care of, directions, etc.  All I needed to do was get there. 

I hop on over to the Greyhound web site and proceed to try and purchase a ticket for my trip.  During the purchase process I’m given the option to print my ticket or pick it up at the station.  I opt to print my ticket so I don’t have to worry about getting it at the station. 

I’ve paid for my ticket, the transaction has been processed, and I’m at the confirmation page which clearly says, “This ticket purchase confirmation page is NOT A TICKET”.  The page also tells me I can print my ticket by clicking the “Print ticket” button.

No problem…

I click the button and I get presented with a plain white page with plain black text saying “Reservation not found”.  That’s odd.  I just bought the ticket, why wouldn’t it be found?  I look at the URL and and see that the page gets passed my reference number and my postal code.  I check it against the information I received on the confirmation page and they match.  So I refresh it a few times.  Same error.  Try another browser, same error.

Ok, fine.  No big deal, I’ll just call them up and ask them about it.  After waiting on hold for a few minutes I get told that this particular issue “happens sometimes”. 



You mean you know that your website is taking orders and payments and not providing tickets?  And this isn’t a big deal?  This just “happens sometimes”?


Now, I worked for many years in the e-commerce industry, and let me tell you, that sort of thing would have been considered completely unacceptable.  As in, people would have been losing their jobs over something like this.  It wouldn’t be something that “happens sometimes”.  You know, because there are laws about taking money from people and not providing them with what they purchased in return.

Ok, but it “happens sometimes”, so I assume they know what to do when it just “happens”.  The guy walks me through their reprint ticket “feature” which should allow me to print my ticket.


No such luck finding my reservation again.

Unfazed, the customer service rep informs me that I can just print the “This ticket purchase confirmation page is NOT A TICKET” page, bring it in to the station with some photo ID and they’ll hook me up with a ticket there.

So by trying to avoid having to go through any hassle at the station, I now have to go through hassle at the station…

Travel day. 

Get to the station extra early because who knows what’s going to happen here?  I wait a good 15 minutes in line to get to speak with someone.  I explain my situation, get told once again that this “happens sometimes”.  It turns out they can’t help me.  Instead, I have to go to this makeshift booth over in the corner manned by guys in yellow jackets.  Those guys for sure, I’m told, can get my ticket for me.

So I make my way over to the booth, wait another 10 minutes in line.  Explain the situation again.  They’re familiar with the problem, but inform me that if I can’t print my ticket, neither can they.  So what I’m going to have to do is call this number, (they have scraps of paper with the number on it for just this sort of situation), and get them to refund my purchase and buy a new ticket at the booth.

Time’s getting short to catch my bus, so I hop in line for another 15 minutes and purchase my ticket.  My new ticket costs $2 more than the original ticket, but whatever, I just need to catch this bus.

While I’m waiting in line for the bus, I try to call the number they gave me, so I can get this issue taken care of once and for all.  I get another customer service rep who also seems to be familiar with the issue with the web site.  I give him my original reference number (though he called it a confirmation number) and he finds my original online ticket purchase.  He then asks for the confirmation number on my new ticket.  He tells me it should be in the bottom left hand corner.  Unfortunately, there is a blank box in the bottom left hand corner of my ticket.  I give him the 9 digit ticket number in the bottom right corner of the ticket I have, but he needs a 10 digit ticket number.

He then asks for the credit card number I used for the second ticket purchase. I tell him it’s the same card as the online purchase, but he needs me to tell him the whole number.  After shouting the number four times in a crowded bus terminal, he finally gets the number only to inform me that he doesn’t see a second purchase made with that credit card.

So here I am, in the bus station, ticket in hand, receipt in hand, in line, waiting for the bus, but apparently I haven’t purchased a ticket?

I tell him, “I can tell you what station I’m at and what wicket and agent I purchased the ticket from” (it’s on the ticket).  He can call them up if he wants to to confirm my purchase, but apparently that won’t do.

No, he tells me I have to fax him a copy of my receipt in order to do the refund.  Fax? What is this 1998?  Do I look like I have a fax machine on me?

Well, now the bus is boarding, so I postpone this adventure for now…

By the way did I mention I had a great time at Agile Coach Camp Canada?

Ok, back home.  Time to get this refund.

Call the same number again, hey, I got randomly selected to take part in a customer satisfaction survey!  Awesome.  They’re going to call me back after my call to ask me some questions.  I can’t wait!

I immediately ask to speak to a manager or supervisor.  I’m not interested in going through the same routine again, especially because I want to make an explicit complaint about the lack of actual customer service I have received so far and how no one has been able to help me with a problem that is a direct result of their broken web site.

I let Shalene, the “Elite Agent” I’m speaking to, know that I’m going to be taking part in a satisfaction survey after this call.  I explain my situation again.  Shalene tells me to call head office.  I ask her if she understands what is wrong with this situation.

She says, “yes”, and proceeds to recite back to me the details of the incident.  I explain to Shalene that she seems to have missed the point.  Why do I have to go through all this trouble to get a refund when it is your web site that failed?  Why am I being punished for your failure?

Shalene refused to be of any further assistance.

Survey time!

A few minutes after my pleasent discussion with Shalene, I receive a call from an automated computer survey service!  Nothing says we care like a cold harsh computer voice.  I proceed to rate Greyhound as low a score as possible in every customer service category.  They even have breaks where you can record a message for them describing your issues further.  Unfortunately they don’t give you enough time to go into details before they cut you off and bring you to the next question.  Nice!

Next, head office!

First thing I’m asked, “What’s your customer ID number?”.  Uh, what?  What is this and why should I have to know this? 

Apparently Shalene and the others I spoke to were supposed to provide me with one of these, but then, who can expect any sort of level of service or organization from these people…

Now I have to sit through creating a profile on the phone.  I give the guy all the contact information that they should already have since I already filled it out when I placed my order!  Why don’t you already have this information?

Turns out, the second ticket wasn’t issued by Greyhound.  All tickets purchased at that terminal are sold by the terminal on behalf of the bus companies.  How did no one prior to this know this?  And knowing this, how could the people at the terminal ask me to go through a process which they knew would fail?

I get put on hold.  This conversation goes on and off hold for 20 minutes still going nowhere.  Finally, I ask again to speak to a manager. 

Here comes Mr. Maestro. 

Yes, that’s his name.  No first name basis either.  He’s so important he has to be Mr.  He’s also the “Supervisor of Customer Service”.  He wants me to mail in the receipts.  Mail? Now we’re back to 1958 here!

And why do I have to mail in the receipt?  Because it’s “policy”.  And he stresses to me that, “the policy must be followed”.

Well, surely, after knowing my whole story and what I’ve gone through trying to get this refund, and knowing where I bought the ticket and the relationship you have with the terminal, you can clearly put the information together to confirm that I did indeed by the second ticket, right?  Right? 

Nope. Policy.

So I ask him why?  What is the purpose of this policy?  To confirm that I purchased the second ticket?  I’ve still got the receipt in front of me and will gladly give him whatever information he needs off of the ticket right now so he can confirm that I’m not lying to him. 


Why do I need to convince him that I’m not a liar when it’s his web site that is broken and everyone there seems to know that?!?


"So, Mr. Maestro, you’re in customer service, right?  You provide service to customers, right?  Do you think I’ve received good customer service?  Is this how customers should be treated?  Is that what’s in your job description?  What is your job description by the way?"

He responds, “To provide customer service within our policy”.

"Do you believe that because your web site failed to provide me a ticket that I should be made to jump through these hoops?"

"Yes, that’s correct."

Well, that was thirty more minutes wasted.

So what did I do?  Did I go pay for a photo copy of my receipt and an envelope and a stamp to mail it to them?  Go somewhere and pay someone to fax them the receipt?


I called my credit card company and did a charge back.  I paid for something that I did not receive and that’s not my fault.  It’s yours Greyhound.

I gave you plenty of opportunities to do the right thing, to make up for your poor web site and your poor customer service and you failed at every opportunity.

You want to plan for failure?  Start by not caring about your customers.  Be just like Greyhound and you’ll achieve failure soon enough.

Quality and service matter. 

Those who care, win. 

I’ll be following this up with another post analyzing step by step what happened and how Greyhound could have turned this failure into a customer service success story. 

Have any ideas on what they could have done differently?  Leave them in the comments section below.


Today’s image by anselm

Sign up and get our video course "Improv Your Agile or Scrum Stand-up" for free!