Ditching Scrum for Kanban - The best decision we’ve made as a team
1–10 of 118 posts
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#2I love this. We briefly flirted with scrum but now just have a much more Kanban-like system now, too. The only issue I foresee long term is that the sprint mentality of Scrum might recharge people and get them to, well, sprint, at product goals. Kanban, because it is never ending, might start to feel like a slog. There is never a way to have that feeling of "wow, we crushed it and cleared out our list. We are awesome." The list just extends forever. We have put measures in to help with this: primarily just having our engineers say at the beginning of the week what they hope/plan to get done this week (or two). Sometimes that is just noting subtasks in pursuit of a larger feature, but at least it borrows some of what is a very powerful part of Scrum: the social commitment that comes from standing up and saying "this is what I will finish this sprint."
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#3I love this. We briefly flirted with scrum but now just have a much more Kanban-like system now, too. The only issue I foresee long term is that the sprint mentality of Scrum might recharge people and get them to, well, sprint, at product goals. Kanban, because it is never ending, might start to feel like a slog. There is never a way to have that feeling of "wow, we crushed it and cleared out our list. We are awesome…
Our crew use a Kanban approach, and to counter the 'slog' mentality, we have a retrospective every 2 weeks. I find that it really helps air what good we've done, and where we could improve. If we've accomplished a lot it's a great place to reflect and think positively.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#4The context and mode defines your process: agile, lean or six sigma. Most companies have no clear understanding about their context (should read Simon Wardley [1]) or mode.
Very good video from Markus Andrezak explaining the three "modes":
https://vimeo.com/146522220 (Must see)
"The biggest mistake companies can make is to define their (one) process, culture, way of work. The work that needs to be done in a sustainable company differs in at least three fundamental ways."
[1] Simon Wardley and Markus also explain why bimodal IT does not work
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#5The context and mode defines your process: agile, lean or six sigma. Most companies have no clear understanding about their context (should read Simon Wardley [1]) or mode. Very good video from Markus Andrezak explaining the three "modes": https://vimeo.com/146522220 (Must see) "The biggest mistake companies can make is to define their (one) process, culture, way of work. The work that needs to be done in a sustainab…
Any text links? Thanks.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#6The context and mode defines your process: agile, lean or six sigma. Most companies have no clear understanding about their context (should read Simon Wardley [1]) or mode. Very good video from Markus Andrezak explaining the three "modes": https://vimeo.com/146522220 (Must see) "The biggest mistake companies can make is to define their (one) process, culture, way of work. The work that needs to be done in a sustainab…
Any text links? Thanks.
Simon Wardley blogs at http://blog.gardeviance.org/
One link is http://blog.gardeviance.org/2015/10/agile-vs-lean-vs-six-sig...
(I'm sure his view and his value maps on strategy will be huge in 5 years, although he is relativly unknown today)
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#7Remember the triple constraints of cost, scope and time. If you are going to commit to releasing at a certain time you are going to have to let the scope slide. (Sometimes you can add more people on a 2 week basis but the ramp up time makes it usually impractical.)
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#8We've used Kanban (or something like it) for 20 years. Long before Kanban existed as a thing. Near the end of a project, we'd draw up the "finishers' list" with numbered items and initials next to each. Daily team review of each remaining item, reassign priority or responsibility as needed.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#9> The rituals, mainly the standups and grooming sessions, were fantastic. Standups are a great way to keep everyone aligned on the work.
Can anyone elaborate why they find standups useful? The planning board should already communicate what's being done, what's been done and why people are blocked. I only find them helpful if some people in the team generally don't communicate well what they're up to (e.g. during daily work, over lunch). Otherwise I find most people zone out during the standup and it just interrupts work.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#10I love this. We briefly flirted with scrum but now just have a much more Kanban-like system now, too. The only issue I foresee long term is that the sprint mentality of Scrum might recharge people and get them to, well, sprint, at product goals. Kanban, because it is never ending, might start to feel like a slog. There is never a way to have that feeling of "wow, we crushed it and cleared out our list. We are awesome…
I see it the other way round. We're doing Scrum (ish, I guess) right now, and the see-saw between either ending a sprint with a couple of late-night panic sessions to get everything out of the door, or ending it with most of the team kicking their heels with one pair still going up to the deadline is what feels like the slog. I see Kanban as much smoother: I don't see artificial, self-imposed crunch mode every fortnight as a positive. It's all very well aiming at a social commitment, but the way it works in practice is either a) you under-estimate and have dead time; b) you over-estimate and crunch; or c) you nail it and one sprint runs smoothly into the next. The trap is that c) never happens.
I think what makes the difference is that we're continuously delivering, so there's no delivery ceremony between one sprint and the next to make the crunch mode mean something.