Live data from Hacker News

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

medium.com

111–118 of 118 posts

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

#111

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

The commonly understood aspects of Kanban is that it is a pull (team members assign themselves work based on priorities) system that has a 'work in progress' limit - ie the most number of items a team/person can work on at once. If something urgent comes up that needs working on right now, something else will need to go back on hold.

Kanban works best when tasks are explicitly prioritised against each other.

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

#112
post #68

Earlier quoted context omitted.

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.

I'm not sure I was waiting for bob, I probably have other tasks too.

I don't know of a better alternative that maintains the face to face element.

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

#113
post #68

Earlier quoted context omitted.

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

Personally I hate weekly meetings as, unless you have strong leadership (rare) they turn into long, boring gripe-fests.

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

#114
post #87
post #68

Earlier quoted context omitted.

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

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

I don't believe this is true. I can be interested but not directly involved all the time.

>> And you should already know what your team members are working on

This is exactly what the standup is for.

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

#115
post #68

Earlier quoted context omitted.

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…

I prefer ditching standups in favor of constant communication, people should know who they need to talk to and avoid waiting for specific checkpoints. A not-too-long team meeting once or twice a week to talk about big themes is pretty reasonable, but usually I can't even remember what is said in a standup, because much of it isn't things I need to remember. If it's forced short, there's usually not enough data, if it…

As I said to the other response like this, I dislike team meetings as without strong leadership (something I have found lacking in a lot of places) it usually degenerates into an hour or more of griping and grandstanding.

You don't really need to remember exactly what's said in a standup, IMHO, participate in it and offer your skills or resources to help other people who are stuck, and get an idea of what's going on.

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

#116

Remember 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.)

There is a fourth one - quality. It is important to acknowledge its existence, otherwise you can find yourself in a position where you can alter "all 3" constraints for the better at the cost of a hidden fourth one.

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

#117
post #115

Earlier quoted context omitted.

I prefer ditching standups in favor of constant communication, people should know who they need to talk to and avoid waiting for specific checkpoints. A not-too-long team meeting once or twice a week to talk about big themes is pretty reasonable, but usually I can't even remember what is said in a standup, because much of it isn't things I need to remember. If it's forced short, there's usually not enough data, if it…

As I said to the other response like this, I dislike team meetings as without strong leadership (something I have found lacking in a lot of places) it usually degenerates into an hour or more of griping and grandstanding. You don't really need to remember exactly what's said in a standup, IMHO, participate in it and offer your skills or resources to help other people who are stuck, and get an idea of what's going on.

Yeah, those could be bad. I've always seen it done with strong team leads or technical managers when they existed instead of standups. I have seen that devolve though, and I know what you mean.

I was very hands on when running meetings when I did it that way. Usually had an agenda, broke when we didn't have anything else to do, and kept on topic.

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

#118

Was the author's team just totally lacking a leader who could point out the patterns in underestimating the scope of work. If you are consistently missing your estimates, you adjust. Get to a point where you are consistently under-promising, and over-delivering. Morale problem solved. It's not rocket science. That said, I agree that regular timelines aren't the only way to create a sense of urgency in your team.

It's not that easy. If a team member gets sick for a week, it can already be impossible to meet the goals of a two-week sprint. It happens (not so often, but it does) that we underestimate the complexity of a task by a factor 5 or so; that alone can also make it impossible to meet the goals. There are just too many things that lead to building pressure when there's no actual need for pressure from a business point of…

Estimation is just educated guessing. If you were guessing a non-randomly generated number, and you found you were guessing high every single time, wouldn't you eventually try reducing by orders of magnitude?

Team members do get sick, scope tends to sprawl, and life just generally gets in the way; but good estimation includes a buffer. Under-promise and over-deliver, at least until you figure out what you're doing.

Post reply on HN