« Inline Assertion Templates for Eclipse | Main | Test Driven Development in Java: Live and Uncensored »

09/17/2009

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e54fb013da88340120a57cd40b970b

Listed below are links to weblogs that reference We're not ready for Kanban:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

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.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.