One of my most listened to podcast is with a relative unknown Agile guy named Eric Landes. In the Agile world, I expect he is well-known and has spoken at a few of the conferences I have attended. I was re-reading the transcript today after seeing how highly rated the original podcast was on my iTunes list and took a few treasures from the review.
Related Podcast and Transcription: Agile Discussion with Landes
An excerpt from the podcast:
Joe: Well a lot of my listeners are from the Lean manufacturing background so Agile may be a little foreign to them. We think of agile more what I have heard from different people that it is really from concept to consumption is a buzz word I have heard a little bit. Can you explain a feature in a story to me?
Eric: Sure. So, I am going to a couple of differences in Kanban. You can use feature and story within Scrum, as well. Most peoples do tend to use stories in Scrum. Usually, a term used… A minimal marketable feature. It’s the smallest feature we can deliver on software that is going to be used by the customer. That makes a difference for the customers.
If you are in a software development shop and you have software or website that you are selling something digital like software. That feature is going to be something, say like a marketing person is coming up, whereas if it’s an internal software application you might actually talk directly to the customer and get that feature. The feature verses story, normally what I would say is those features normally break out into stories from the feature. You can almost think of stories that’re a smaller set of a feature if you will that probably have to be grouped together if you are actually going to sell your software.
What happens when you are moving from, say Scrum into Kanban… A lot of the Kanban teams are using their ideas of features. And then, the idea is, they want to take the feature from… As you said, from concept to cash or whatever, and bring that through their system of software development. When I look at the differences between what we call like a Scrum or XP, and the Kanban process. The Kanban processes really are the lean process that the software development uses. We are looking at mapping your process as it stands. Seeing where the bottlenecks are, using a board to map your flow, see where the bottlenecks are, and then try and fix those bottlenecks as you’d go.
You’re going to use a lot of the Agile methods for software engineering. Some people even use iterations during their Kanban. But, for the most part, you’re looking in the flow of things. You aren’t really doing fixed link iteration, time?box iterations. You’re doing more of… I don’t want to say one piece flow because that’s wrong.
I mean, we would love to get to one piece flow. But I don’t know anybody who would claim that they’re doing one piece flow in a software Kanban. At least, I’ve not heard of anybody doing that.
Lean Sales and Marketing: Learn about using CAP-Do
Lean Engagement Team (More Info)