Live data from Hacker News

Ditching Scrum for Kanban - The best decision we’ve made as a team

medium.com

81–90 of 118 posts

Re: Ditching Scrum for Kanban - The best decision we’ve made as a team

#81
I was curious to understand what exactly software managers were calling by "kanban" now that the name is fashionable.

Well, I was not disappointed. The articles talks about everything, except anything marginally related to the meaning of "kanban" in manufacturing.

Re: Ditching Scrum for Kanban - The best decision we’ve made as a team

#82

I was curious to understand what exactly software managers were calling by "kanban" now that the name is fashionable. Well, I was not disappointed. The articles talks about everything, except anything marginally related to the meaning of "kanban" in manufacturing.

Can you elaborate?

Re: Ditching Scrum for Kanban - The best decision we’ve made as a team

#83
I read this article hoping to learn what "kanban" really is.

From the text, it seems like it's scrum, but without having a deadline every sprint for what you committed to at the start of it.

And... that sounds exactly like the Pivotal school XP I've been doing for 10 years.

Words, words, words...

Re: Ditching Scrum for Kanban - The best decision we’ve made as a team

#84

> 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 dail…

I think the standup meeting is there because it follows the first principle of the Agile Manifesto: "Individuals and interactions over processes and tools"

I thought that the scrum meeting is a process. The whole Agile thing is a strictly defined process. That needs a lot of specific tools too.

Re: Ditching Scrum for Kanban - The best decision we’ve made as a team

#85

Earlier quoted context omitted.

Yes thank you. I think the reality of DSM don't live up to their theoretical usefulness. I think even in a small team where everyone keep it short it's just too much information. I can already see what everyone is doing on Jira/etc and later on git in my IDE, the rest don't stick. I have tested people by asking them less than 30mn after a DSM questions about who is doing what and nobody could answer and yet they usua…

> I also hate DSM when I'm on a long task because I just say the same thing everyday and feel like a slacker. At which point do you start to game the system and only pick short easy tasks ? I've had that feeling too. You feel like dropping the long tricky important task you're doing to complete a couple of easy ones so you have something better sounding to say for the impending standup. A similar and much worse situa…

If you have a long important task, then surely you can break it down into sub-tasks that take less than a day to implement? Not just for the sake of having something to say in the daily status meeting, but to be able to manage your own work and evaluate your progress? In my own work, I find that anything taking longer than a day benefits from my doing some planning and task breakdown.

Re: Ditching Scrum for Kanban - The best decision we’ve made as a team

#86

Would people recommend a team moving directly to Kanban, or is it useful to learn/use Scrum first? What books/resources would people recommend to learn Kanban effectively?

>is it useful to learn/use Scrum first?

'Smart people learn from their mistakes. But the real sharp ones learn from the mistakes of others.'

Re: Ditching Scrum for Kanban - The best decision we’ve made as a team

#87
post #68

> 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 dail…

You get a quick status update of all the bits everyone is working on. Oh, Bob finished the xyz bit? Great I'll get started on abc now. Jim's stuck with the autobuzzulator? I've used those before, I'll jump in and give him a hand after the standup. Katie's not been able to deliver the turnip functionality? Still can't test the beets either then... It should take no more than a few seconds per person and I find it far…

The point is: are you really interested in what those people are working on? If you are, then you should communicate with them much more often than once every 24 hours, or have decent conversations with them. A few seconds aren't enough anyway. If you're not, then scrum is a frustrating waste of time.

Also, if the company has more than a few devs, scrum meetings are usually limited to your team. And you should already know what your team members are working on - if you don't, then your team has serious communication issues, scrum or not scrum.

Re: Ditching Scrum for Kanban - The best decision we’ve made as a team

#88

Earlier quoted context omitted.

> I also hate DSM when I'm on a long task because I just say the same thing everyday and feel like a slacker. At which point do you start to game the system and only pick short easy tasks ? I've had that feeling too. You feel like dropping the long tricky important task you're doing to complete a couple of easy ones so you have something better sounding to say for the impending standup. A similar and much worse situa…

If you have a long important task, then surely you can break it down into sub-tasks that take less than a day to implement? Not just for the sake of having something to say in the daily status meeting, but to be able to manage your own work and evaluate your progress? In my own work, I find that anything taking longer than a day benefits from my doing some planning and task breakdown.

If it's possible, sure, but you always get these problems you never predicted where you burn hours getting nowhere. I really meant a task that turns out to be unpredictably lengthy, annoying and tricky.

Re: Ditching Scrum for Kanban - The best decision we’ve made as a team

#89

> 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 dail…

The value is in creating a summary, to collect all the stream of conscience updates into a coherent statement about status and next steps. A daily standup of summaries removes the burden of mentally remembering yesterday's minutiae to reconstruct the current state.

I mean, if you want to know the status of a system do you go to the dashboard or do you go review every system event for the past few hours? I hope not the latter! That's what you do when something seems off, which is exactly the case too for daily standups. If something doesn't seem right, you go review discussions and updates.

Also, at the risk of triggering on standup philosophy, I do believe that zoning out during standups mean it's being done poorly: updates are too long or people are not engaging each other. That's the problem to fix, by setting an example of good habits yourself: cut off rambling, encourage active cross-questioning and ideas, etc.

Re: Ditching Scrum for Kanban - The best decision we’ve made as a team

#90
post #78

Earlier quoted context omitted.

One thing is you can have a conversation about things and ask questions about what you're stuck on. It's also much faster and more fun than writing some mini-report on a planning board people may or may not read. But the most important thing is that it is quick and encapsulated. Only about things the whole teams need to know. You need to be happy with reporting that nothing interesting for the whole team happened.

No, at the standup you shouldn't have conversations about things. You should just do a quick recap of what you've been doing and what you'll work on. It's a standup because it's meant to be very quick. On the other hand, if you need a standup to ask questions about stuff you're stuck on, then your work environment has serious issues. It might be 24 hours until the next standup. You need to have colleagues who are ava…

It should not turn into long discussions, but if standup is for mentioning what you're stuck on, it seems really strange that others are forbidden from mentioning how to get unstuck.

I'm used to pair programming and communicating all through the day. This is incompatible with the surly loner programmers you describe in the last paragraph.

Post reply on HN