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

61–70 of 118 posts

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

#61

Post by BurningFrog »

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.

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.

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

#62

Post by dsmithatx »

sageikosa wrote: post #47
ChuckMcM wrote: post #40

Earlier quoted context omitted.

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.

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 not doing anything etc.

4.) Social engineering shouldn't work here much as far as being lazy. Good team leads and coworkers will ask to help out should they see someone dragging there feet. Your coworker should be doing code reviews or know about how long it takes to setup a server. It should be pretty obvious if you manipulating, at least I've found it is.

5.) In the past 2 months we have let two people go because standups revealed they weren't really doing anything. Stand ups gave us a chance daily to ask what have you done? It gave the chance for a coworker to step in and help out. It identified this person just didn't want to work and we replaced him with someone who did.

>>> If a manager doesn't know what his team is up to before the meeting, he's not doing a good job. Perhaps because he doesn't already command the respect of the team?

I disagree. A good manager should have a broad overview of what's going on but, he should be busy in his own job planning etc. to not have to micromanage. A 15 minute stand up each day gives him insight he needs without standing over anyone's shoulder or worse making false assumptions about what they might not be doing.

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

#63

Post by keithba »

nickpsecurity wrote: post #56

Waiting for this title: "Ignoring waterfall and agile fads while sticking with Boehm spiral model (1986), good management, minimal meetings/paperwork, regular code reviews, and usage-driven testing. Best decision I ever made." Haven't seen it yet but it's worked for many organizations and projects. For decades. Surely some improvements since then but one has to wonder what the useless-to-critical ratio is in activiti…

+1. I was taught this as a young lad at Intel by a graybeard who'd been developing since the 60s. It made a lot of sense then, and it makes a lot of sense now.

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

#64

Post by perlgeek »

darkerside wrote: post #29

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

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

#65

Post by theinternetman »

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.

Sounds like being treated like a school kid to me

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

#66

Post by T-hawk »

PaulHoule wrote: post #7

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

And this is exactly the difference between Scrum and Kanban. Scrum fixes the time periods and allows for adjusting scope, by cutting stories and features. Kanban fixes the scope while allowing the time period to be open-ended. Which methodology is more appropriate depends on which constraint a business wants or needs to optimize for.

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

#67

Post by PaulHoule »

T-hawk wrote: post #66
PaulHoule wrote: post #7

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

And this is exactly the difference between Scrum and Kanban. Scrum fixes the time periods and allows for adjusting scope, by cutting stories and features. Kanban fixes the scope while allowing the time period to be open-ended. Which methodology is more appropriate depends on which constraint a business wants or needs to optimize for.

It is even better to do something hybrid that is tuned to the application.

A bad thing about scrum is that it introduces a lot of phony deadlines that have nothing to do with the business; this is like the common practice of the boss setting a short deadline on the hope that they can control the cost (total hours) by controlling calendar time.

On the other hand having a release every two weeks means you actually need a release. There are so many projects where a few programmers spend say 1.5 years building a components and hypothetically the application is feature complete, but they are nowhere near running it on a real server or packing it up for the customer with an installer and all that and it takes another 0.5-1 yr to figure out how to make a release.

Then there is a stressful process of making a few more releases to fix the inevitable problems, then they go off and work another 2 yrs on the next release and then find they've forgotten how to make a release. The best thing about scrum is that it avoids that.

The idea that the phony deadline is fixed is another problem. If you can slip the schedule by 2 or 3 days in scrum to address critical things in the scope there that is no problem but many agilists will fight that.

Another failure mode is the project that is hitting the goals for milestones well (estimating things about 10% accurately) and that makes people feel good, but somehow you never get to the last milestone.

I came in late and helped finish one of those severely troubled projects where there was a huge amount of blame to go around. Scrum and Kanban concepts were being used by teams involved, but a lot of people on my team including the boss and star programmer would not do what scrum required. My boss would bitch me out for making "rediculous" estimates of 4 hours to do something that involved a 45 minute build process and I wondered how the other people on the team didn't have this and I found I was the only one who was serious about estimating and that the star programmer did not do it at all.

In the end we gave up on scrum and got heavy on checklists. We made a checklist with about 300 steps for a release process and it a was a stressful process but we learned how to do it reliably. Also we had a checklist of things to have done before the final release.

It was not pretty but we did cross the finish line and get the product in front of customers and they liked it, so I felt I did my part and felt free to move on when it was done.

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

#68

Post by Nursie »

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 more effective than any agile status tool I've used, be that a physical board or an online system.

>> I only find them helpful if some people in the team generally don't communicate well what they're up to (e.g. during daily work, over lunch).

I communicate well with people I'm working with in the microcosm of what I'm doing right now, but there may be a few other people on the team doing related tasks that I'm not talking to every day.

And lunchtime is my time to get a few minutes away from screens and work, take a walk, have some food etc.

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

#69

Post by conradfr »

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 usually can't admit that DSM are mostly worthless.

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 guess maybe Scrum and agile appeal more to young devs ? They seem to like the gamification aspect of it, moving post-its, feeling great by under-estimating tasks' length, the flatness of the team.

Myself I would prefer a competent project manager instead of those empowering retrospectives and those velocity charts that could be turning against you by management any day.

Over dramatization aside :) and in good spirit about the article I would prefer Kanban to Scrum but it seems way less used (at least in webdev).

Post reply on HN