Well, I was not disappointed. The articles talks about everything, except anything marginally related to the meaning of "kanban" in manufacturing.
Ditching Scrum for Kanban - The best decision we’ve made as a team
81–90 of 118 posts
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#82I 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
#83From 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"
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#85Earlier 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…
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#86Would 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?
'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> 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…
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
#88Earlier 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.
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…
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
#90Earlier 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…
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.