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

41–50 of 118 posts

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

#41

Post by chrisp_dc »

patrickmay wrote: post #12
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 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.

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

#42

Post by alkonaut »

daigoba66 wrote: post #14

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

My experience too. A short deadline (few months to a year) and a green new codebase is a good place for scrum.

A medium/large project (200 man years in the code over 10 years say), then it's a lot harder. A required refactoring in the codebase that would take 200h is a common discovery in issues estimated at a few h.

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

#43

Post by jusuchin »

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

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

#44

Post by cmdkeen »

eitally wrote: post #32
cmdkeen wrote: post #16

As someone in similar circumstances a couple of things jump out which trouble me: Project Managers - That this role is mentioned, but not that of Scrum Master, is odd but unsurprising. PMs aren't mentioned in Scrum at all and often the way they want to do things clashes with the Scrum way of doing things. In the given example of the PM moaning about estimation Scrum at least forces that realisation quickly, something…

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 budget, deadlines etc. The job of being a PM is always going to be in tension with that of the PO, I can see them forming a good team but fundamentally the PM is the representative of management imposed from above.

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

#47

Post by sageikosa »

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.

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 software engineering, not social engineering. Social engineering only supports the manager hierarchy which is probably at that point misaligned with value production.

If I were a deep cynic (instead of just a natural contrarian), I could say they expose the manager as someone who cannot command respect unless they are intimidating subordinates into the social risk of showing themselves impotent to achieve on a day to day basis.

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?

Can "drum-beat" scheduling help in crunch times? Probably. If you are always in a crunch time, the scale of your efforts probably are probably going to shrink, and/or you may lack time to make longer range plans and are effectively navigating without a map.

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

#48

Post by dpark »

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.

I think stand-ups are valuable, but not for this reason. It is simple to exaggerate the unexpected difficulties of a task. You can watch videos on YouTube all day today and tomorrow say, "Yesterday I worked on auto frobbing widgets but ran into difficulties with the foo widget because it didn't frob correctly. Today I'll be fixing the foo widget and completing the auto frobber".

No one will bat an eye (so long as you put meaningful terms in there) until this happens for several days in a row. Nor should they, because the micromanaging alternative is worse.

Stand-ups aren't a motivating factor for typical developers. It drives some accountability for people who are just accomplishing nothing for weeks, but that could be accomplished by looking at the checkins once a week, too.

[edit: phone typos]

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

#49

Post by manigandham »

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…

Usually it's the managers who find it helpful - for them. Getting verbal confirmation from everyone of what's on the board.

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

#50

Post by metamet »

manigandham wrote: post #49
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…

Usually it's the managers who find it helpful - for them. Getting verbal confirmation from everyone of what's on the board.

Which can be incredibly important if the manager has to report to someone as well.
Post reply on HN