Friday, June 11, 2010
Reflections on a Couple of Others’ Thoughts on Scrum Compared to Kanban
A couple of guys both longer in the tooth than me, who have authored more books than me, have also published their experienced thoughts on Scrum and Kanban this past week.
First Alan Shalloway, The Real Differences Between Scrum and Kanban.
Alan lists a number of practices that he sees as different between the two approaches: some of them are core fundamental elements of the Kanban method - the seed properties that generate the emergent Lean behavior in the organization.
Kanban differs from Scrum in the following ways…
1. Make process policies explicit
2. Visibility of process, not merely results
3. Inclusion of Management
4. Flow as an option instead of time-boxed iterations
5. Controlled change management
You need to read Alan’s full post. I feel it is fair and balanced and represents an alternative perspective that broadly follows mine
Secondly, Ken Schwaber posted his own thoughts. Ken had evidently been attending the Microsoft TechEd conference and had seen a presentation on Scrum and Kanban by Joel Semeniuk and Steven Borg. This prompted him to post, Waterfall, Lean/Kanban, and Scrum
This article talks a lot about complexity theory and understanding processes as simple, complicated, and chaotic, and how Ken’s motivation for creating Scrum was based on providing something that worked in the chaotic space. This is all fair enough and interesting in itself. However, the post seems biased by Ken’s assumption that we’re doing manufacturing kanban systems on software development. Ken has no actual experience using Kanban. His post also highlights a fundamental principle of Scrum that the underlying process for software development cannot be mapped. This point is reinforced in an older post by Tobias Mayer, Scrum and Kanban - different animals, that was referenced by Alan Shalloway.
This reveals a truly fundamental difference between Scrum and Kanban that I missed in my post yesterday or more accurately between the Scrum community and the Kanban community. It’s not an accident that Tobias’ blog is called Agile Anarchy. The underlying assumption is that trying to map the creative process that produces software is futile and there is no point in trying. It simply has to be contained in a black box. Ken refers to this as a “container” in his post and that container is a Sprint. The Kanban community believes in a scientific approach and the use of models to understand the natural philosophy of what is at work in our universe. While we recognize that all models are wrong, we recognize the value in some models. A value-stream map is a model of a process, it is probably not an entirely accurate model, more an approximation. The question is whether it is useful or not?
Once we have that model, and can observe actual behavior against it, we can then use other models such as the Theory of Constraints, Theory of Profound Knowledge, Systems Thinking and Lean’s Waste (or the economic models of transaction and coordination costs), to analyze what is happening and suggest changes. We accept that these models are incomplete and that any suggested changes will not work in all circumstances. The question is whether they work often enough to be useful?
It seems to me that we have an overwhelming quantity of evidence that has been reported from firms large and small from all corners of the world at the Lean & Kanban 2009, UK Lean 2009, Lean & Kanban Exchange, Lean Software & Systems 2010 and much more to come at Lean & Kanban Europe 2010, and LESS 2010 later this year, to demonstrate that this scientific approach is working and genuinely helping organizations and teams improve both their economic performance and also the social capital of their organizations - resulting in a better sociological outcome for everyone involved.
[I’ve decided to update this post on June 12th following a private email from a Scrummaster who has been a lifelong believer in the anarchist ideal]
It appears that few practicing Scrum followers realize the underlying anarchist ideals held by the leadership of the community and designed into Scrum as a method. It appears that this Scrummaster sees Scrum as very prescriptive…
“I think of scrum as being a very strict system of prescribed practices that are imposed whether they fit your needs or not.”
and then provides an explanation of true anarchy as
“Anarchy means “no government”, and as practiced by modern anarchists, is a system of total self regulation, living a life of personal responsibility, and the abstention from imposition of one’s own will onto others as happens with violence, oppressive social behavior (even aggressive driving) and voting. It is closer to a religion in this way and it is more like perfect order than chaos.”
It appears that these ideals are not obvious in Scrum but I believe it is a fair assessment to characterize at least some of the leadership in the Scrum community as true anarchists. They believe in “no government”, “total self regulation”, “a life of personal responsibility”, and “abstention from imposition of one’s own will onto others.” This particular Scrummaster went on to say that…
“I can’t even tolerate a queue that is force ranked. Too command and control.”
And this highlights an incongruence in how Scrum is articulated, taught and practiced. Both Scrummaster and Product Owner training contain advice, guidance, and practices (belonging to the role) that are considered antithetical by a true anarchist.
The second issue that became obvious to me from this email exchange is that few people appear to understand my linking of the “use of models” and “science.” Perhaps this is a reflection of how poorly science is taught in our schools? So let me explain. Newton’s Law of Gravity is a model for a small part of the natural philosophy of the universe. It explains, in part, how things are attracted to each other and stick together, and why objects fall to earth. Newton’s Law of Gravity is known to be in inaccurate model. It only works at relatively large scale and has needed modified several times since Newton created it to accommodate concepts like distance from the center of gravity, varying levels of gravitational pull, and the other core forces of the Universe that were not known to Newton in his day. However, we need to ask whether Newton’s Law is useful or not despite its lack of completeness? The answer to this is surely “Yes!” for many common everyday commercial, scientific and military applications around planet Earth Newton’s Law is perfectly adequate. It is this pragmatic approach that is commonly held in the Kanban community. Models can be useful. They can allow us to make improvements even when they do not work in all circumstances. There are many in the Agile/Scrum communities who do not share this pragmatism and believe that in the absence of a complete model that defines the full natural philosophy of the domain that only an emergent solution based on empirical observation, experimentation and feedback is possible. The concept of predicting an outcome based on a scientific model is not acceptable nor does it exist within their paradigm. This can lead to discussions where individuals talk past each other. Kanban community folks using a scientific paradigm talking with Scrum advocates with an Edge of Chaos paradigm fail to comprehend what the other is saying. This pattern has happened frequently in the Kanbandev Yahoo! group when new folks arriving with a strong Scrum background try to understand Kanban by force fitting it to their existing mindset.
It appears that Scrum leaders like Ken and Tobias openly position Scrum as as a solution for Chaos, that values Anarchy and Revolution. While Lean and Kanban leaders like me, Alan Shalloway and Donald Reinertsen position Kanban and Lean as a scientific approach that approximates chaos as merely complicated or complex and delivers an Economic, Scientific and Evolutionary approach. This juxtaposition seems useful as a selection criteria for organizations. Do you wish to use a framework for change that tames chaos through anarchy and revolution, or a framework for change that models complexity incompletely but usefully and uses science to generate significant evolutionary economic and sociological improvement? (even if those improvements are theoretically less than optimal?) Choice is good! It is only right that one approach should not fit all and that you should have the best information available in order for you to make an informed choice that is appropriate for your business and organization. It’s been refreshing that folks like Ken and Tobias have published their thoughts on how Kanban differs from Scrum and we’ve been able to raise the quantity and quality of information available to the market.
Posted by David on 06/11 at 04:19 PM
Page 1 of 1 pages
I am confused about the intent of this post.
The last paragraph is equating Kanban with science and Scrum with chaos and anarchy. My understanding that Scrum is about emergence. So is Kanban. They travel different roads to get there.
I know KenS wrote a divisive and damaging blog. There is no need for others to follow.
Peace.
Posted by Michael Sahota on 06/14 at 11:18 AM
Hi David,
I understood from another very recent post of yours that you weren’t interested in comparing Scrum and Kanban, that each served different purposes. Yet in this post you resort to a better/worse comparison again. Too bad :(
> It appears that Scrum leaders like Ken and Tobias openly position Scrum as Chaos, Anarchy and Revolution.
I have never positioned Scrum that way, and I have never heard Ken Schwaber say anything like that either. There may be some misunderstanding due to the use of terms such as chaos and revolution which cause a lot of emotion, even fear in many people.
Scrum is a framework for managing complexity. It operates on the edge of chaos. Human systems are inherently complex, as is software, therefore using a framework like Scrum to help manage that bordering-on-chaos complexity seems sensible. Such complexity requires an empirical process, and the ability to embrace change. Scrum isn’t chaos, it helps harness chaos, box it up if you like into manageable portions.
My use of the term anarchy is also non-threatening. I use the American Heritage Dictionary definition of the word on my blog: “Anarchy: the rejection of all forms of coercive control and authority” Not something I think you or many people in the Agile field will disagree with. You can read my thinking behind the use of the term “anarchy” in my blog introduction: http://agileanarchy.wordpress.com/2009/06/10/anarchism/ In which make the statement
“The compassionate anarchist values his fellow humans on an equal footing, encourages emergent solutions, supports individual empowerment, and seeks to avoid dehumanization and marginalization.”
Not threatening, surely.
I agree with your observation about revolution and Scrum. I believe there is a spirit of revolution in the air within the software industry. I see this as a positive thing, but equally I would hate to see a software revolution go the way of so many revolutions where the oppressed become the oppressors. I have seen hints of this with Scrum and XP adoptions, and believe me I don’t like it.
We need change in our industry really, really badly. My concern with denying the revolutionary spirit is that nothing will really change. We’ll just get better at working the way we do, maybe with some raised awareness of the waste we build in to our processes. Good things to be sure, but I have a belief that there is more we should be striving for, a new paradigm we should be seeking. And I think Scrum asks people to open their hearts and minds to that possibility.
Your blog posts are always articulate and thought-provoking. I enjoy reading, and welcome the opportunity to contribute.
Posted by Tobias Mayer on 06/15 at 12:06 PM
Hello David,
Thank you for the quality discussion in this area. Its refreshing to stay away from the politics and to explore the assumptions underlying our positions collaboratively. I’d like to continue in that vein following from your statement that:
“The underlying assumption [in Scrum] is that trying to map the creative process that produces software is futile and there is no point in trying.”
I would say that differently. From my experience, the underlying assumption in Scrum is that the environment surrounding the team(s) is so chaotic that mapping the internal process of the team would not be useful, as it is unlikely that it would usefully describe the activities of the team in the next iteration.
This articulation of the assumption provides a useful dimension for decision-making.. We can ask of our context - how chaotic is the environment? If we make a map of our current activities, how likely will the map still be useful in 2-4 weeks?
I think Ken’s post may have been pointing at this as well, in that Scrum was designed for chaotic *environments*—not chaotic creative processes, as you state.
The fact however is that many software development environments are /not/ chaotic. They are complicated and maybe a little complex. Perhaps this is the range where Kanban techniques apply more directly.
A question I would pose is whether the potential overuse of Scrum has more to do with mischaracterization of a company’s environment, than it does with the usefulness of the process.
What I mean is, if you look broadly at the media, everyday we are told that the world is a chaotic place, just on the edge of chaos, about to fall apart. There is some good evidence for this. We have the financial crisis, the environmental crises, the political characterizations of a “democractic crisis”. Recent change management methods reinforce these beliefs with metaphors like the “burning platform” or the “melting iceberg”.
All of the attention to crises has created a lens on reality where we are prone to look for more crises. From this perspective a process for making progress in a crisis or in chaos is valuable.
But if we honestly ask, if our daily work-life is really in crisis, our answer is likely to be “no”. There is a fair chance that the work we will be doing next month is a lot like the work we are doing this month. If this is true, then Scrum may not be the process for you. Said differently, whether Scrum forces a revolution or not is not important, what is important is if your context is in revolution. If it truly is, then Kanban may not be the process for you.
I’ll be curious to hear others thoughts on this perspective.
Best,
Evan Leonard
P.S. - If you decide that your environment is not-chaotic, beware of the Black Swan[1] and take steps to be ready for the next one in your neck of the woods.
[1] - http://en.wikipedia.org/wiki/Black_swan_theory
Posted by Evan Leonard on 06/24 at 12:48 PM
As someone who has a degree in science, I have not seen anything in Scrum or Kanban that approaches the rigor of either pure or applied science. What both Scrum & Kanban use is the scientific method to observe a phenomenon in the environment, formulate a hypothesis and think of ways to collect data that either proves or disproves a hypothesis. Nothing wrong with formulating a hypothesis and collecting data to see if reality matches your test case.
I am glad you find model-driven approach to be an interesting way to approach what is mostly what I consider a people problem. The Kanban focus on tools and process, models and numbers unbalances the Agile equation which places added weight on people and interactions. IMO, Kanban as it is currently described is cold, sterile and uninteresting as it leaves out the Lean pillar of respect for people. If this community would talk more about respect for people and less about XP task boards, I might find your conversation more interesting.
Posted by Carlton Nettleton on 06/25 at 01:21 PM
Hi David,
There is always more then one way to skin a cat  I like the idea of choice. I don’t really see Scrum as the bogey man, it is just one approach that works rather well in the rightcontext. The problem arises when the culture doesn’t support the values and principles behind Scrum. I wouldn’t describe any of the leaders of Scrum as anarchist, but I can see how they could easily be perceived that way in some environments
Personally I’d much prefer to talk about Kanban. Your bold stance not to be beholden to Agile dogma is commendable. By following only a few constraints Kanban offers a path to improvement that is open to any organisation irrespective of its values. I think it is still very early days for Kanban and I think their is still a lot of work to do to distil out all the different flavours of Kanban and identify where each flavour is best suited and has a “sweet spot”.
People know what Scrum is, we are still discovering what Kanban can be. As you know I’m not a believer in all the Lean theories out there as applied to software. I’m much more interested in peoples real world experiences. Your case studies have tended to be in the realm of what I would describe as repeatable, predictable work (support, maintenance, bug fixes etc). My type of work tends to be more exploratory.
It makes sense to me to stick to Scrum/XP for exploratory stuff, and Kanban for repeatable stuff. I’m kind of getting that message from parts of the community too, but I must admit that the message is mixed.
Regards,
Paul.
Posted by .(JavaScript must be enabled to view this email address) on 07/06 at 07:21 AM
Apologies for the tardy reply to these comments…
Evan, useful thoughts… if indeed it is the uncertainty in the environment and process and not the nature of the work that suggests the appropriate context for Scrum then this would be a useful way to assess context and select an approach appropriately.
Tobias, I didn’t resort to better/worse comparison, you made that judgment in reading what I wrote. Good catch on the “chaos” thing. I’ve re-worded using “as a solution for” which better communicates my intent with that sentence.
I am perplexed by the Scrum leaderships continued assertion that “Scrum is an empirical process” as if everything else wasn’t. The truth of the matter is that every software development lifecycle and project management process I am aware of is an empirical process.
The fact of the matter is that empirical does not nor should it imply that the process cannot be mapped and observed in operation against that map. I am a control systems engineer by educational background - I was accepted to study a PhD in this stuff back in 1991. I chose to take a job as a manager at a software company instead. Ken’s use of empirical and characterization of control systems is and has been (since publication of his first book) in error.
Paul, see the comment from Tobias. He is both a declared anarchist and a revolutionary. There are many anarchists in the Agile movement. 
I agree with your thoughts about repeatable, predictable versus exploratory. My observation is that most of our 30 million plus person industry/profession spends its time in the repeatable, predictable space and not in the exploratory space. We’re not trying to solve everyone’s problems with Kanban. As you indicate correctly, we’re still learning where it is applicable. It has a lot of traction in the Media sector for example. This knowledge is useful. We need more like that.
Michael, the intent of this post was to add to the list from the previous post given the stimulus from both Ken’s and Alan’s posts. It was clear to me that I had missed an important point and that it needed to be included.
Regards,
David
Posted by David Anderson on 08/26 at 10:04 PM
Page 1 of 1 pages
<< Back to main
|
