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.