On my last blog post Simple Scrum, Karl Scotland commented:
“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.
click to subscribe
Agile Anarchy 
Good distinction – certainly something to think about! I used the word contrast, rather than compare deliberately. I would agree that Scrum and Kanban are different, but compatible, beasts. I’d also say that there is value in contrasting them if it helps us generate useful insights such as this. Thanks for the continued dialogue.
Karl
I appreciate the continued dialogue as well. Thanks Tobias & Karl. Tobias, I’m busilly trying to deal with at least one of the subjects you bring up here: creative work – or saying slightly different: discovery as apposed to pure delivery. The talk I need to give at the uk lean conference will attempt to address that. I think you’re smelling in kanban the neglect of values important to you. I often smell in scrum and kanban both values important to me. But, I keep all babies before discarding bathwater. There’s lots of nuggets of value in all approaches, and no approach results in me changing my values.
Thanks again for the continued engagement.
“they are not using the principles of software craftsmanship suggested by XP” – Here is a common basis that everybody can agree on, and one that we need to continually advocate regardless of the rest of our different opinions, else we’ll confuse the new learners we all cherish.
I also agree that there is little point in directly comparing Scrum and Kanban other than to facilitate discussions on where the practices differ. The ‘vs’ aspect is absurd, the value lies in understanding the proper context for each approach.
I do, however, believe that statements like “It is people-centric” or “It is profit-focused” are both misleading and inconsistent across contexts. When you, Tobias, utilize any approach I suspect it will feel to the people involved that it is very people-focused, and I additionally suspect that those people’s management will appreciate the profit-focused nature of your approach. I don’t believe there’s an inherent conflict between the two until you reach the realm of context-specific trade-offs (eg death march), and even then sustainability suggests that you’re actually trading short vs. long term profits, not profits vs. people)
Conversely, I suspect there are managers out there that can make Scrum feel very mechanistic and profit-focused and utterly miss the people aspect. Many will argue this is not Scrum, but we ought to have the same option to argue that it’s not kanban (or lean) if the people are ignored. (It’s not Taylorism!)
Thank you for posting this, Tobias!
I think of a value stream rather like a musical phrase. People then play variations on the tune and harmonise alongside it, stopping for the necessary pauses which help to frame the melody. The Kanban board is just the living musical score, there so that people know what chords are coming up, how to join in, and when to let go so that the solos can be heard. I guess I got this image because of what the word “cadence” conjures up for me.
When we put the Kanban board into Eden Development, we did so to free up some of the creativity in both the clients and the development team, because of the frustrations they were experiencing with maintaining a backlog and pushing work through the system. I think it’s perfectly possible to use Kanban in the same way as you use Scrum, and I believe many of the Kanban community are doing this (to the best of our abilities, anyway).
Maybe all we need to do is talk about that aspect of it more?
I’ve been thinking about the term ‘value stream’ and wondering if it is any different than the ‘definition of done’. I’ve been working with groups both at the team level (what does it take to get stories done) and at the organizational level (how projects get to done) and see some parallels to each other, and value stream analysis.
I was also tickled to see someone outside of all of this call the value chain as ‘yesterday’.
http://blogs.harvardbusiness.org/haque/2009/10/apples_next_revolution_and_wha.html
Pingback: Fridays Digest #18 Scrum vs. Kanban
This is rather an old writeup, which I’ve read before, but Alan S pointed me to in in a tweet exchange.
I believe the assertion that there is no value stream in a complex environment is false. Since it’s clear that value streams are used in complex environments all the time (and even clear that almost all environments are complex), I suspect that you (Tobias) and others who use the term are using it differently.
An elementary example is a v.s. for a hypothetical company showing that a software product sits in the project eval queue for 3 months, then in the funding queue for 1 month, then gets developed in 3 months, then waits for a deployment window for 3 months. (Not an uncommon pattern BTW.)
This is exactly a value stream, and it is profoundly meaningful as it demonstrates that only 30 percent of the delay from idea to market is in software development. If this hypothetical company wants to improve, they would do better to reduce decision, funding, and deployment time. That’s where the leverage is, and that’s just what a value stream can show.
I think it’s a perfectly valid tool in most any company attempting a transition, and I should think you’d agree with the analysis above. This is what makes me think the “value stream” that you say does not exist is not the “value stream” that I think I somewhat understand.
In the article that Aaron refers to (above) Umair Haque states “As I’ve advised for many years: the future of strategy lies in markets, networks, and communities. They allow us to rewire what yesterday were known as value chains into complex webs of production and consumption.”
I don’t deny there are optimizations we can make in work environment (that would be foolish). It is just that the idea of linear “value streams” seems so outmoded, and it is possibly detrimental to new thinking to be applying an optimization process from the manufacturing age to the knowledge age.
Rather than attempting to map work linearly, just because it has worked well in the past, perhaps we’d all do well to challenge that idea, and think in terms of webs and the interconnectedness of everything.
I don’t have any answers, but I do think we can start exploring new questions.
I appreciate the exploration (certainly has inspired some great conversation and clarifications!) – I think that mapping a value stream is potentially easier for businesses with a mature product and team around it as you often have established aspects of your product that are generally agreed upon; for instance qualities such as aesthetics and performance; responsibilities such as having UX input on UI changes etc.
The value stream you map will never be comprehensive of all interactions but it may provide insight across most of your interactions (the common baseline interactions). As per some of the comments I think the relationship to the people involved is important (consider a continuum with a business of one where code is written directly on the server it is run for production as one extreme where creativity is maximal and flows are potentially unique everytime to a much larger corporation on the other end where there are Product Managers & BAs, UX, Dev, QA and Deployment teams etc.).
Looks like there is A LOT of confusion by overcomplication: all Kanban means is “Paper Ticket,” it is “A PART” of Just-In-Time (JIT) production methodology for effectively managing a *process* — please look up Kanban on Wikipedia.
In Scrum *process,* the Task Post-It Note would be the Kanban and Task Backlog, In-Process and Done are the Bins for the Kanbans. Value Stream Mapping (VSM) is outlining how *value* (something that the customer/ user is willing to pay for) flows through a *process*. The way I think of Scrum is it’s the translation, application, of Lean/ Toyota Production System into Project Management process.
Well, kanban (small k) originally meant that, but it (big K) has acquired a new meaning. Language evolves.