Re: [scrumdevelopment] Re: kanban korrection
- You can't be doing scrum without Sprints. However, you don't have to do
batch planning, it can be incremental. The sprint is mainly there as a
big feedback loop for inspect and adapt of product and process. Adapting
scrum to include WIP is pretty easy, actually, but it causes new risks
as well as solves existing problems. I call it the KanBan(ish) variant
of scrum, and is one of the chapters in a book I'm writing. I'll get it
posted somewhere, but for now, here is a PDF...
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
Karl Scotland wrote:
> Tobias: I read the article. Good stuff. Honestly, if you changed every
> occurrence of the word "Kanban" for "Scrum" your article would still
> read intelligently and accurately. What does Kanban add that is not
> already in Scrum?
> Karl: The most noticeable difference is that Kanban Systems directly
> limit work in progress, as opposed to using a time-box to limit work
> in progress.
> Tobias: Scrum remember is not a defined process. It is simply a
> framework that allows teams to create a process for themselves that
> suits their context/people/product/business environment and so on. The
> mistake people often make with Scrum is to think they have to do it a
> certain way, according to a book -- or more often a tool. That is a
> mistake, and one that causes people to say "Scrum doesn't work".
> Karl: Yep. Replace Scrum with Kanban and that still applies :)
> Tobais: As far as I can make out, "Kanban" as a new software
> process/methodology/whatever was invented because someone's (limited)
> idea of what Scrum is didn't work for them. Finding ways to be
> creative within the Scrum framework is to be applauded, but believing
> one is doing something radically new and giving it a new name just
> seems like unnecessary overhead.
> Karl: Wrong - unless you are suggesting you can still be doing Scrum
> without Sprints (i.e. time-boxes)? It sounds to me like you are saying
> "If your process works then we can call it Scrum, and if you process
> doesn't work then we can say its not Scrum".
- Interesting comments, Victor,
> I would like to add here that common sense is very different from using aGood reasoning is also dependent on culture and background. For some, the _logical_ ("I mean, it's not reasonable to expect me to give you a quote on what it will cost if you can't be more specific than that!") way to buy software is waterfall...
> good reasoning.
> Common sense depends a lot more on culture than reasoning and good
Anyway, you're right in that "common sense" is defined by each person, and it's usually used to demean something "stupid" someone else does. :)
> In many aspects I think, today, common sense is actually the enemy of anThere may be conditioning in the picture, too.
> empirical control method.
Process Development Manager, Agile Coach (CST)
Digia Plc., Finland