Scrum and Kanban — different animals
“Nice description. It also gives me a nice way of contrasting Scrum and Kanban. Kanban says nothing about Roles, Artefacts or Ceremonies, but leaves the team to self-organise what works best. Instead, Kanban (as I describe it) suggests focussing on understanding the value stream, visualising it, limiting work in progress, establishing a cadence, and continuously improving [...]“
Karl’s comment helped me to see clearly that any comparison between Scrum and Kanban is utterly pointless. It is like comparing a hammer with a screw driver, or an soufflé with a kangaroo. Which is better?
It was that phrase “value stream” that did it. It has always made me vaguely uncomfortable when I have heard it spoken in relation to software, and I wasn’t sure why. I have been thinking more about it, and I think I understand. There are two things.
Firstly, I fundamentally disbelieve that there is any such thing as a “value stream” when you are working in a complex environment, in a creative process, building new products or generating new ideas. Once you have mastered something, and go into building variations of it (e.g. web sites, or hand-crafted wedding dresses) then perhaps value-stream mapping comes into its own (there would need to be more similarities than differences). But before such time of repetition I suggest that to focus on a value stream is specious, and misleads people into believing that the creative process is mappable and repeatable. It is not.
Secondly, and more importantly, Scrum is a framework for organizational change It is people-centric. The focus of Kanban —as described here by Karl— is on business value. It is profit-focused. Focusing on profit will rarely transform an organization. Focusing on people and culture stands a better chance. The goal of Scrum —or at least, the goal of the Scrum Alliance, of which I am a member— is to transform the world of work. To do that, we must start with the individual, and we must focus on human values, not business values.
It has become clear to me that Scrum and Kanban are in place for different reasons. Sure, using Scrum you may increase your productivity and build better products (one would hope so!) and using Kanban may make people happier at work, but these are secondary concerns.
And lastly, a word for XP. If you are working with a software team, regardless of the process, and they are not using the principles of software craftsmanship suggested by XP, then please start there. Anything else will be a facade.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)