We're not ready for Kanban

As an industry, we're not ready for Kanban. We can hardly do Scrum, which is just barely iterative at all. Forget one-piece flow...most teams can't even make a user story small enough to fit in an iteration, much less a day or two. Before we start talking about the next great project management paradigm, we need to take stock of our most essential skill: Our ability to deliver.

So you work on an "Agile" team? Let me ask you this: When you hit the end of an iteration or sprint, what do you do with your product? I'm sure you do a demo. Everyone does a demo. Do you actually ship it? To real users? Who really use it to do their real job and make real money?

If you don't, I'm sorry, but you're missing a key point of Agility. Yes, we have standups now. Yes, we have big visible charts. We have team rooms, and retrospectives, and even pair program from time to time. But if you were shipping to customers every 6 months back when you were using RUP, and you're still shipping every 6 months now that you're doing Scrum, all that stuff is just ceremony. From the customer's view, you haven't changed at all.

Not that the customer is the most important thing. Making money is the reason we all get up and go into work every day. If our customers won't pay for our products, it doesn't really matter how often we ship. Which is why I think most people under-rate the value of shipping early and often. Sure, customers are great. Revenue is great. What we really want out of shipping early and often is validation of our vision. Getting the real, hard data that shows we can make customers happy make money using the approach we've chosen, or alternatively, that we need to change course. That information is more valuable than the actual revenue because it validates our strategy. Operating for prolonged periods with an unvalidated strategy is one of the most costliest mistakes an organization can make.

Of course, the reason you don't ship your demos isn't because you don't want to, it's because you can't. Fear of your product crashing and burning once it gets into the hands of real users keeps you from shipping. You know those technical practices that XP talked about, that were left out of Scrum because they were "hard"...yeah, turns out, you're gonna need those if you want to jump on the Kanbandwagon. If you want to split up your work into Minimum Marketable Features, stop doing iterations, and ship every few days (instead of every few months), you're going to need some seriously hard-core test and deployment automation. And I don't mean those selenium scripts that Steve over in QA wrote after your last release. I mean fast, reliable developer tests that give you enough confidence with a press of a button (or, in the case of Infinitest, the press of the save button) to ship your code to the people who are actually supposed to use it.

Technical excellence is the key. It's the only way to advance to where you want to go. The good news is that once you get there, the focus is on value delivery. IT stops being just one big cost center, and starts contributing to the top line. Priorities shift. Goals become clear and story points give way to dollars. That's when you really start to walk the walk of early and continuous delivery of valuable software.

Comments

[Matt Wynne]

Woot Woot!

Great post. Reminds me of one I wrote a while back about Scrum teams churning away at 'potentially shippable' without ever getting anything finished:

http://blog.mattwynne.net/2008/01/16/where-scrum-gets-dangerous-potentially-shippable-make-sure-you-mean-it/

[J. B. Rainsberger]

"Of course, the reason you don't ship your demos isn't because you don't want to, it's because you can't. Fear of your product crashing and burning once it gets into the hands of real users keeps you from shipping."

You make a pretty strong assumption here, and not a well-founded one. I work with teams who don't ship because they form part of a large product that takes 18 months to install. (No, that's not a typo. 18 months.) Of course, this leads to apathy: even shipping perfect working software every weeks wouldn't improve the bottom line.

More to the point, however, there is no "the industry", just like there is no "management". It's a fiction we might use to drive traffic to our weblogs, but it doesn't exist. To say "the industry isn't ready for X" provides no information.

Finally, even if we could somehow define the notion that "the industry" is or is not ready for X, what exactly do you want your readers to do with that information? You advocate for technical excellence, but you could easily advocate for that without leading with a spurious, unfalsifiable claim.

It's a shame, since these blemishes mar an otherwise valuable contribution.

[Ben Rady]

You're right JB. There is no "Industry". It's a metaphor. Perhaps it would be better if I had said "The majority of teams" are not ready for Kanban. Part of this is because a lot of teams aren't working iteratively, and are just totally unequipped to do anything like Kanban for lots of reasons. Some of them however, particularly a lot that have adopted Scrum, are working iteratively but aren't ready either...but I've heard an increasing number of people say that Kanban is the next Scrum. My point is: As (a community of software developers that I previously referred to as 'An Industry'), we need to work on some technical fundamentals (the XP practices, basically), before we start talking about the next great product management paradigm.

What I'm saying, however, is not an assumption. The next time you're speaking at a user group or conference, ask the people in the audience how many of them work iteratively. Then ask how many of them actually ship to customers at the end of each iteration or sprint. In my experience, you'll either get total silence, or nervous laughter. If you talk to them, they'll tell you the main reason they don't ship is because of quality concerns. It might be demo-able, but it's not shippable.

You're also right about this simply being a device to drive people to my blog. I'm trying to connect with them. I'm trying to let them know that I'm seeing the same things that they're seeing, that it's very, very wrong, and they're not alone. THAT is the information that I want to convey to my readers, and I think it's helpful and valuable to them.

Which is also why I wrote the blog speaking to the reader in the second person, and not referring to "The Industry". You. You don't ship your demos. You are letting poor technical practices hold you back. If that doesn't apply to your situation then you probably will have stopped reading by now. That's OK. This post isn't for you. It's for that "Agile" team I talk about in the second paragraph.

But perhaps this metaphor does more harm than good. Maybe by trying to connect with a particular group of developers I'm making it harder for the rest. In this case at least, you seem to have interpreted my use of "Industry" as "Everyone who writes software". That would certainly be a very harmful message to communicate to someone who wasn't familiar with the realities of software development.

So I won't call it an industry. How about a community?

[Liz Keogh]

Hey Ben,

The other reason that a team might not ship is because they're protecting their investment - building up enough of a differentiator to ensure that it can't easily be spoiled. I've heard arguments from some of the Kanban crowd that if you can keep ahead of the game using Kanban you'll be fine anyway, and won't need this protection. I can still see how it might minimise the risk. (This comes from conversations with both David Anderson and Chris Matts).

In the situations where I've seen this form of agility work successfully, it's been coupled with access to an expert who really gets the target audience. That might be a really bright sponsor, a domain expert, one member of a team of users, etc - a proxy who really can act as a proxy. I've also heard of companies paying real users to try their new software alongside the existing version - using it to give feedback, rather than to make real money. That also seems to work.

There's only one company I can think of where the team have gone from knowing very little about Agile to shipping every two weeks to production successfully. It took over a year to make that transformation, and about half their staff were contractors hired to help them change.

I love this whole paragraph in your comment: "I'm trying to let them know that I'm seeing the same things that they're seeing." Thank you. I don't take the message personally, nor will the successful teams I know. I shall point the teams who are still learning in this direction.

[Ben Rady]

Liz,

Thanks for the comment. I think you make some great points here.

I would probably lean (no pun intended) toward the side of the argument that says you should just keep ahead of the game, but you've got to do what works for the team.

Totally agree that a really good product owner/domain expert/customer proxy is key. I think the interesting stuff starts to happen when the act of delivery provides information to the product owner that can make their knowledge of the market substantially better. More delivery => better Product Owner => better product.

I also wouldn't advocate this approach for an entire company. I'm kind of old school in that I think Agility really works best with small teams...which is not to say it only works in small companies. I think many large companies would do well to create a few select teams that are capable of exploring new markets and products through rapid delivery.

[Ted M. Young]

I like your post, but I do think you need to more explicitly target it. As JB says, there are some teams who might want to ship every iteration, but due to the nature of the product, or, more often, the nature of the customer, that's simply not possible. For any "enterprise" software company (such as mine), there is no value to the customer by shipping every two weeks, since it takes 6-18 months for them to integrate and/or upgrade.

However, we _do_ make our builds available every iteration for documentation, training, and even a preview for customers. So I think if you define "release" to be something you'd be comfortable letting your customers play with, even if it doesn't go in "production", then I'm with you.

[Ben Rady]

Thanks for the feedback, Ted. I define release as when, if a salesperson or other stakeholder asks you "Can I send this to customers now?", you can say "Yes" (and mean it). Whether or not it actually gets sent depends on a lot of other factors.

However, I disagree with your statement that there is no value in "enterprise" software companies releasing often. Indeed, it is these very companies where installation and deployment times take months where early validation is most valuable. For example, being able to demo newly created features to a potential customer, and make commitments to that customer based on functionality that really exists in the product, can create a huge advantage and allow you to get feedback much quicker than your deployment cycle time might indicate.

[J. B. Rainsberger]

"What I'm saying, however, is not an assumption. The next time you're speaking at a user group or conference, ask the people in the audience how many of them work iteratively. Then ask how many of them actually ship to customers at the end of each iteration or sprint. In my experience, you'll either get total silence, or nervous laughter. If you talk to them, they'll tell you the main reason they don't ship is because of quality concerns. It might be demo-able, but it's not shippable."

I enjoyed this version much more than your original, absolute version. This version allows the possibility of other causes of teams not being ready to shed iterations.

Let me clarify: I agree that many teams don't ship because they don't take the end of the iteration seriously. Still, when you wrote this...

"Of course, the reason you don't ship your demos isn't because you don't want to, it's because you can't. Fear of your product crashing and burning once it gets into the hands of real users keeps you from shipping."

...you blamed a bunch of people for something over which they have no control.

[Ben Rady]

True enough. That blame may lie elsewhere. But I still believe that fear is the root cause.