Trevor Lalish-Menagh shares his experience introducing Kanban, what has worked and what hasn’t.
Trevor Lalish-Menagh is a senior web developer at Comcast Interactive Media where he spearheaded the front-end unit testing initiative, and co-created EnvJasmine. He has been involved in organizing Philly.rb, Philly Lambda, Functional Fall, A.I. Winter, and Philly ETE. He has spoken at Philly ETE, CULTUREcon, FOSSCON, JS.everywhere(), Philly BarCamp, Ruby DCamp, and JSConf.
The ETE Conference has established itself as the most diverse and interesting conference on the East Coast. Curated by developers, for developers, it brings together the brightest minds in software development. Visit emergingtech.chariotsolutions.com we provide content throughout the year and you can subscribe to our Chariot TechCast podcast.
a relevant discussion I started in LinkedIn, that relates to this
Strawman against Scrum
This presentation is a strawman tirade against Scrum, which manifests as an over-simplified description / understanding of both Scrum and Kanban. All the problems that are claimed to be solved by Kanban have virtually nothing to do with the methodologies themselves. The observations are at best correlation, as nothing is said of how the team controlled the "experiments" (although glad to hear they used metrics).
Sounds more like (even basic) Scrum was poorly applied; the roles (both Product Owner & ScrumMaster) were not being performed properly (even at a basic level); and, at the very least, the culture was not conducive at the time Scrum was in play on the presenter's team. These are classic symptoms of failure for any method, Lean-Agile or o/w.
Fortunately, the presenter did mention the core of Agility, and that each team must (be allowed to) find its own specific path. And glad to hear that Kanban has worked out for this team, where "Scrum" did not (false-choice aside).
I did appreciate the mention of "fog of war".
Re: Strawman against Scrum
The execution of the Scrum processes obviously had some hick-ups: retrospectives did not get acted upon, tasks did not get assigned according to capacity, committed-to work got changed during a sprint etc.
If that happens: it should be clear that this is not what Scrum asks for. Corrective action should be taken.
Agree with your next point though as well: Should you then find out that, for whatever reason, you can't get Scrum to work in your environment, try something else. And it looks like Kanban worked better for them.
As for the "environmental factors" I mentioned: If changing scope, even during a Spring, can't be avoided (if only because business upstream simply won't stick to the (Scrum) rules) then I see why Kanban is the better option in your case. Likely, too, workload is made more obvious by Kanban as well.