Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

71–80 of 118 posts

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

#71

Post by jimbobimbo »

seanwilson wrote: post #37
patrickmay wrote: post #12

Earlier quoted context omitted.

You need to tighten up your standups. Each person should be saying what they did yesterday, what they're going to do today, and identify any dependencies or blockers. It's important for everyone on the team to know what others are doing in order to share knowledge. If people are zoning out, you're not getting that benefit.

> You need to tighten up your standups. Each person should be saying what they did yesterday, what they're going to do today, and identify any dependencies or blockers. Why do this in a standup though? This information isn't on your planning board? I don't find standups efficient for this.

Because some things just pop up during the conversation.

Another benefit of hard allocated blocks of time for standup - they're explicitly grabbing people's attention. It's very easy to ignore stuff on the board, if you're not directly involved in it, but if you are simply in the room, listening to other people, you may contribute something useful to the otherwise unrelated conversation.

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

#72

Post by seanwilson »

conradfr wrote: post #69
seanwilson wrote: post #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 dail…

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 situation happens when you have to give client demos too often I find.

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

#73

Post by vpeters25 »

seanwilson wrote: post #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 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

#74

Post by seanwilson »

Nursie wrote: post #68
seanwilson wrote: post #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 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…

> It should take no more than a few seconds per person and I find it far more effective than any agile status tool I've used, be that a physical board or an online system.

Isn't that information already on your planning board? Likewise, it should only take a minute to review the planning board updates each day and you should be getting direct notifications for things you're suppose to be helping on.

I can see the value in you all getting together to have a high-level chat on how things are going maybe once a week but every single day is way too much for me.

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

#75

Post by kylequest »

dsmithatx wrote: post #62
sageikosa wrote: post #47

Earlier quoted context omitted.

It adds impetus to appear busy and/or find something to report. I think it was said higher in this discussion: recurring meetings are a form of "social engineering"; and I'll follow that with an assertion that they have more affect on the structure of the team (and individuals therein) than they do on the effort the team is nominally working to achieve. If you want to build software systems, you should engage in soft…

I think motivating factor is the least helpful thing stand ups provide so your assertions are slightly correct if that was the goal of stand ups. Stand ups actually provide: 1.) Better communication of what everyone is working on. 2.) This leads to faster cross training as people are able to ask questions. 3.) Making others on the team aware of issues you are working on so they don't make bad assumptions that you're…

"better communication" and "cross training" are the biggest misconceptions about the stand-ups. A good/proper standup is short and there's no way to communicate and exchange enough detailed information and context to make it a meaningful communication and especially cross training tool. Standups are meant for peer-to-peer coordination on the dev team. This leads to another misconception... Standups are not status reports for managers. The manager's primary job is to support his/her team and to be aware of what's going on to facilitate the team needs and to resolve external blockers. Sitting in his/her ivory tower planning stuff is not it :-)

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

#76

Post by gjmulhol »

adamjc wrote: post #3
gjmulhol wrote: post #2

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…

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.

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

#77

Post by slavik81 »

Nursie wrote: post #68
seanwilson wrote: post #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 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…

If you were waiting on Bob to finish xyz, why does he wait up to a day before telling you he's done?

After doing scrum for a few years, my impression is that stand-ups are useless because you can't depend on them. They're frequently too far away to be used for the purposes you're talking about, so you always need an alternative. If that alternative is good, you might as well always use it and cancel the meeting.

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

#78

Post by Udik »

BurningFrog wrote: post #61
seanwilson wrote: post #37

Earlier quoted context omitted.

> You need to tighten up your standups. Each person should be saying what they did yesterday, what they're going to do today, and identify any dependencies or blockers. Why do this in a standup though? This information isn't on your planning board? I don't find standups efficient for this.

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 available and willing to communicate during most of the office hours - confining this to the standups means that there are issues either at the organization level or, more probably, at personal level.

Personally, I've had more than enough of work environments where standups are used "because we have to communicate" - and then some of your colleagues spend the whole day with earphones on (= impossible to shout a question on the fly) and other look pissed off whenever you ask anything.

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

#79

Post by ChuckMcM »

ChuckMcM wrote: post #40
seanwilson wrote: post #37

Earlier quoted context omitted.

> You need to tighten up your standups. Each person should be saying what they did yesterday, what they're going to do today, and identify any dependencies or blockers. Why do this in a standup though? This information isn't on your planning board? I don't find standups efficient for this.

There is a unique motivating factor to standing in front of your peers and saying you didn't get anything finished yesterday. That is, in my opinion, the entire point of the stand up. Everyone knows they are going to have to say something tomorrow and that adds some impetus to finishing their task as quickly as possible.

Interesting conversation, I appreciate it.

While it is always possible to use any activity for social engineering or shaming (feeling like a school kid) I don't really see that as a good description of the stand ups effect. It is a "deadline" that is artificially imposed, on a particular task.

In my experience good developers have a wide variety of things they could be working on at any given time, and those things have different weights and different "fun" factors. Without some sort of time limit it is possible to get lots and lots and lots of stuff done without the rest of the team being able to move forward. So once you've agreed on the tasks that need to get done, having a deadline to finish them helps prioritize and focus the activity.

My experience is that bad management is completely orthogonal to process. Any process can be abused by a poor manager in ways that are detrimental to the team, and a good manager can keep a team motivated and productive even with a bad process.

So I don't think stand ups are about "managing" teams, they are a good tool to focus you on what, of the many choices you have, you should be working on right now. Oddly enough, the more senior you get as a developer, the harder it is to get that level of clarity.

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

#80

Post by kylequest »

conradfr wrote: post #69
seanwilson wrote: post #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 dail…

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…

Pretty often it's also a sign that Scrum and DSMs have been imposed on the team by their managers and/or PMs. Scrum is meant to be a tool for the dev team to self-organize. When it's not a bottom up effort (coming from the dev team based on their actual needs) it devolves into a micromanagement framework.
Post reply on HN