Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Deborah Hartmann Preuss on Nov 14, 2009
Although not new, awareness of Kanban is now growing among users of Agile software methods. Talks, workshops and entire conferences are springing up, and Agile trainers are combining Kanban into their courses.. Practicing Agilists are investigating what this method, adapted from Lean, offers their teams: attractive benefits are cited, from making bottlenecks visible to making more progress faster and happier teams experiencing more "flow". Into this ecosystem, Simon Bennett's The Philosophy of Kanban is Kryptonite to Scrum offers a warning to those who are thinking of incorporating Kanban into their Scrum process. Proponents of Kanban agree with Bennet that Kanban's less agressive approach to impediments is at odds with Scrum's call to remove impediments immediately.
Bennett's blog post, which he declares as neither an anti-Kanban rant nor a "keep Scrum pure" diatribe, states that
If you’re going to use Scrum, but ignore or hide the impediments, (or even not raise them in the first place) then you are asking for a world of pain, and a lack of progress. This is what Ken Schwaber and Martin Fowler are talking about when they speak of flaccid Scrum. (at least from a technical debt perspective)
Both Scrum and Kanban prize transparency; but they handle it in different ways – and Scrum builds-in an explicit call to action, which needs to be answered for Scrum to succeed.
Kanban allows for you and your team to simply “accept” impediments, and measure their effect.
His position: their philosophies are at odds: your "Scrum project will weaken as long as the Kanban philosophy is nearby." However, applying a pure philosophy is not the goal: it's quality software, frequently delivered. To this end, he encourages practitioners to examine what kind of projects they have and how successful they are with Scrum, and he provides guidelines on how to choose which to use.
Corey Ladas' 2008 paper "Scrum-ban" described an evolutionary process toward Kanban which, if taken far enough, replaces most of Scrum. Ladas' approach would modify or even replace many of the traditional Scrum practices, such as the daily standup and burn-down charts. Interestingly, Anderson, whose Kanban experience report from Corbis made a splash at Agile2007, and who appears now to be largely focused on Kanban adoption, cites his original intent as not "converting people from Scrum" but rather helping those struggling to adopt Agile. Bennett's post suggests that teams carefully consider before incorporating Kanban: are they getting enough value from Scrum alone? He adds:: "if you really are dancing on the bleeding edge then I imagine you’ll come to depend on Scrum."
While Bennet isn't listed among the thought-leaders at Limited WIP Society (intended as "the home of kanban for software development community"), many of those listed have offered supportive comments on the blog's comment thread, including Karl Scotland and David J. Anderson. Anderson agreed:
Yes, Kanban is evolution while Scrum is revolution. I am very comfortable with that positioning.
Of course, any tool can be misused: Chris Sims' article Are Kanban Workflows Agile? reminds readers that if the kanban board is being used to make sure that each of the required activities has occurred, it is being used to enforce the team's definition of done, a job better suited to a simple checklist. And Mitch Lacey was recently overheard reminding us that at the "end of day there are no magic answers. Saying one solves people's problems over another is just that: fairy dust."
There's more about Kanban on InfoQ: Articles, Presentations.
Learning to be a Good Product Owner: Foundation Skills
Technical Debt and Design Death
One that is annoying about Scrum is its insistence on conformance: "If you can't do Scrum, you need to change!". Although correct in Scrum-theory, in the real world even Scrum needs to be fit to the current context. The Kanban method inspired me to replace some parts of Scrum with things that worked better for us.
A few things that Scrum enforces, but aren't always the optimal solution (in my experience):
- The use of iterations
- The use of story estimation
- Synchronized release, demo and retrospective.
Bottom line is: Scrum is a valuable set of practices, but be prepared tune Scrum for your situation. Most Kanban initiatives show that you can change Scrum or even replacing it altogether to get better performance and transparency.
I will be presenting on XPDays with my improved Scrum story.
Actually, Scrum says nothing about story estimation, in fact nothing about "stories". Also, nothing in Scrum suggests you have to release at the same time you do a retrospective. So I guess you are not really dropping Scrum practices, except iterations... and I'd be wary of that. If you can find another way to hit a rhythm, and leverage the empirical process for feedback it's probably fine. Often when people (perhaps not you) drop iterations they are more likely to hide things than expose them. Thus, less learning.
You are right about the stories, I should have called them backlog items.
Both are great tools. Mix and match. Here's an article that compares them in objective terms.
www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
I'm doing a talk on this at QCon SF this week.
Hi Henrik, I think the point of Simon Bennett's article (bit.ly/v898m) was exactly the opposite to this: don't mix and match.
In fact Scrum says nothing about backlog item estimation. It is simply a practice that some people find useful, like a visual task board.
It is probably important to assign to Scrum what should be assigned to Scrum, and nothing more or less. It leads to all kinds of confusion. All Scrum says is "get it done by the end of the agreed time period". Not a bad goal, I reckon.
It's so irritating to read the constant back-and-forth between the Scrum and Lean camps. Not to mention, passe. So two-thousand-and-late.
Scrum, Kanban, Lean, blah blah. What is important in each of these named-methodologies is not following them, but rather to learn the specific practices in each and apply them to your team as your team sees fit. I think the best part of retrospectives is that a team can look at the agile practices it has been using and change them, remove them, or add to them to see what works.
What usually ends up is not "pure" scrum/xp/lean/etc... but rather, a mix of useful practices as unique as the team members themselves.
I like what Henrik says above - "both are great tools. Mix and match." Exactly. And I look forward to hearing your talk at QCon! :)
Yes, and I respectfully disagree.
Everybody is entitled to their own opinion, but don't let other people make decisions for you. If some people advocate a revolutionary approach with Scrum that doesn't mean you have to. If some people see Scrum and Kanban as conflicting that doesn't mean you have to.
If whatever you do works in your context then it is right, call it what you will. Mix and match has worked well for me & my clients so far.
I think the problem here is that Scrum/XP et al are well established and its clear how they work. Kanban isn't as well established and so its less clear where the boundaries are. Henrik is making a success of mixing Scrum/Kanban while Simon Bennett raises some interesting concerns. As time goes on we will see if Simon's concerns manifest themselves and whether other's mimic Henrik's success. My point - its too early to be certain of anything.
Mark Levison
Co-Founder and Consultant - TheAgileConsortium
Great comment Michael, I agree with Henrik as well. We are far too focused on the label and discussing definitions as opposed to finding what is going to work for the team/organization to deliver value to the business.
My team sits at their standup. We work in iterations to help the business get predictability into releases. Another team I've worked with is trying to force Scrum into day-to-day production support and it ain't working. Kanban would suite them well.
Scrum, Kanban, Scrum-kan, ban-scrum, who gives a crap what you call it, as long as what you are doing works, the label you put on it doesn't matter.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
10 comments
Watch Thread Reply