Hacker News Reader

Comment by gjmulhol | Hacker News Reader

I 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."

View on HN

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.

Aligns with my experience. We're always continuously delivering, with madeup goals stuck in to align with arbitrary sprints. The real activity takes as long as it takes. Sprints are a stilted reporting structure, adding drama but little real value.

The crunch approach to sprints is the killer. If you know you can't complete all the work in a sprint the answer should not be to bust yourself to try and complete it. Have a conversation with yourselves and the product owner to readdress what you can realistically achieve in the time remaining and then do that.

It's a really hard thing to do, we all want to be the hero that saves the sprint. It also encourages you to end up with lots of discrete chunks of work in a sprint so you can complete 80% of your initial commitment and salvage a sense of achievement rather than getting 80% through a few big tasks but none of them actually done.

A sprint with 4 developers and 4 tasks each estimated to take 2 weeks will almost never succeed. A sprint with 4 developers and 20 tasks each estimated to take a day or two stands a much better chance of success. Combine that with some metrics around "complexity per developer per available day" and you quickly end up with some charts showing productivity that is hopefully improving which will hopefully improve morale.

in that case, do you use retrospectives at all ? if you dont have a goal post, then how do you retrospect.

...ending a sprint with a couple of late-night panic sessions to get everything out of the door...

My first reaction is you are not sufficiently grooming your backlog. Stories are left too large, with too many unknowns. If you tend to have a small number of large tasks, this is likely the case.

That, or you just aren't very good at estimating. A large number of small tasks would indicate this problem.

In the second case, you need to circle back with the PO and discuss which items can push to the next sprint. And make a concerted effort to estimate better during grooming and planning sessions.

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.

I really like this idea. We groom our Kanban board, which creates a similar effect, but not so explicitly.

In your case or ours, one of the nice things about stepping back is reprioritization, which happens nicely in Scrum but not so much in Kanban. It is easy to define a path and never diverge only to wake up and realize you built an old vision.

Reply on news.ycombinator.com