Live data from Hacker News

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

medium.com

51–60 of 118 posts

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

#51

> Say what you want about our supposed inability to estimate, but I challenge any team to nail estimates within a 20% margin for a large feature on a large app. Not to be pessimistic but this sounds like stories and tasks needed to be broken out in even finer detail.

I think that's a fair assessment. If people can grasp creating small independent deliverables for their projects (of any size) then things become a lot easier to estimate. Monitor velocity and pull less into future sprints if you're still getting it wrong.

If there is a piece of functionality that brings unfamiliarity to the delivery team then create a spike ticket to investigate (though use them sparingly).

If you break things down small enough, really understand your velocity and have a transparent relationship with your product owner then there should be no need for any stress from anyone.

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

#52

Earlier quoted context omitted.

> I find most people zone out during the standup Out of curiosity, how long do your standups last? How big is the team?

15 (goal) minutes with a 10 person team. Everybody didn't zone out every day, but most did, most of the time.

Exactly. It's a waste of time. Best to give a direct message or face-to-face telling the person what they need to know. Or not say anything if nothing is needed. At most, I'd say weekly meetings that were a mix of tracking project status and fun just for team-building purposes. Keeping people connected.

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

#53

Earlier quoted context omitted.

> I find most people zone out during the standup Out of curiosity, how long do your standups last? How big is the team?

15 (goal) minutes with a 10 person team. Everybody didn't zone out every day, but most did, most of the time.

It's also detrimental to morale when you realize that other people are zoned out through standup. Nothing much more frustrating than when a coworker asks a question that was answered in the "meeting" we were all just in.

Frankly, it's a huge opportunity for the listeners to shine. (Yay for being a listener)

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

#54
post #44
post #32

Earlier quoted context omitted.

One of the biggest problems with Scrum (as mentioned in other comments) is that in a lot of large companies you have strong top-down enforcement of budgets, deadlines & expectations, which usually means the PMO is in control. This means you end up with a project manager as an awkward intermediary between the stakeholders & the product team. In almost every case, the product owner should be the project manager, but th…

I agree with that assessment except for "the product owner should be the project manager". I do internal dev so product owners are from the business and know the problem domain and (with our help) know what they want. It's going to be different for software for selling - but still, the project owner should be the person with the vision who is the "single wringable neck", they should be responsible for negotiating on…

I should have been clearer. I meant the tech-side PO. There has to be a PO in the IT org If there isn't, the product will languish under the weight of mounting technical debt and eventually die. The same often happens if there's no biz-side PO, but in those cases someone from the tech org usually adopts the product and just does their best, for better or for worse.

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

#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 activities of the new things. It still isn't clear to me.

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

#57

Earlier quoted context omitted.

Yes but either you don't know what they're talking about (different part of the project), or already know what they're talking about (because you are a tight team). So, zone out. Who's the Punch and Judy show for?

At least where I work (Pivotal) where we are often rotating between pairs, and changing tracks of work in the order of every day to every few days, being kept up to date on the state of the rest of the work is useful. Additionally, we use it as a chance to bring up anything we need help with, or anything we found interesting in the last day, which wasn't important enough to interrupt the rest of the team with.

> where we are often rotating between pairs, and changing tracks of work in the order of every day to every few days

These sort of working arrangements sound horribly inefficient. How do you ever get enough real familiarity with what you're actually doing when you're getting jerked around to something different every couple days? It sounds like being constantly on the treadmill.

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

#58

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.

No matter how tight you make the stand up, it still creates an artificial time to do a disruptive start/stop. A 5 minute meeting really leads to close to an hour of derailment. http://paulgraham.com/makersschedule.html summarizes it better than I ever can.

If your team communicates effortlessly with each other and the stakeholders anyway, you don't really needs scrum, at least not now. But most places where scrum has made a difference, individual maker productivity is not the limiting factor, so even an hour of disruption is worth the cost.

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

#59

> Perhaps Kanban is better suited towards long-lived product development than Scrum. This is the key take-away. And in my experience this is absolutely true. On the other hand, working now as a consultant where I am frequently on shorter-term projects with a definitive "end" for the engagement, the time-boxed sprint approach (or "Scrum") actually seems to work well. Scrum might work for individual "projects". It does…

I completely agree with this.

In shorthand, having been Product Manager for a number of teams at a variety of companies in several industries, I've found that Scrum is better for teams developing mostly new features, with relatively little maintenance; and Kanban better for teams focused primarily on maintenance, with fewer large features.

The rationale is really simple: for new feature launches, reporting and tracking vs. schedule is key; for maintenance, throughout is key.

That said, regularly missing predicted story points by more than about 10% is not the sign of a healthy team. Being bedeviled by routine bug fixes is not the sign of effective management. Both are routine issues that most highly-effective teams, whether Scurm or Kanban, deal with well.

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

#60

The team I was previously on tried to use Scrum and seemed to naturally fall into a similar model to Kanban; we got rid of what helped, and stopped doing what didn't. It was an amazing relief, especially since Scrum sprints and the numbers just weren't working. Sadly, our Scrumlessness was found out and it was implemented again shortly before I left. Morale was dropping steadily on the team already (unrelated reasons…

It is really stupid to NOT allow any team choose its own process. Your scrum leader is not a wise person, to put it lightly.
Post reply on HN