Hacker News Reader

Comment by justspamjustin | Hacker News Reader

My team moved from scrum to a kanban style process a couple years ago. The benefits were immediate. We no longer have drawn out sprint planning meetings where we discuss requirements of features that we never end up working on in that sprint. We don’t waste time debating complexity of features. Everything is now just ad hoc. When we need more requirements definitions, we pull the necessary members of the team together and discuss it. When we see that there needs to be architectual discussions and high level planning, we do it immediately when we recognize the need for it. The idea that you can try and commit to or even forecast how much can be completed for a period of time is pretty absurd. Just identify the minimum requirements of what needs to be done and do it. Retrospective is still productive. But sprint planning is a waste of time IMO.

View on HN

Scrum is a sad joke. But corporate loves feeling "safe", with estimates in hand, even if they readily blow out. Usually it ends up with "watergile", a total mess.

You can just time kanban tickets vs estimated size (all the forecasting, tracking, etc, should be done by a manager, without wasting the team's time) combined with pulling from the right hand side and vigorous action towards blockers. Optimise for throughput.

During the best version of this, as I experienced, we spent about 5 minutes in the morning as a team, and occasionally visited the board throughout the day (not as a team, sometimes as a pair, to discuss something and add/move tickets). My manager at the time spent some time at the end of each week by himself collecting cards and doing the tracking to make the higher-ups happy.

If you read the actual Agile manifesto, what you are doing now is more agile than scrum :)

A lot of the artefacts of a process are intended to help teams transition from the old way of doing things and to help teams who have stalled or failed to deliver. Sprints, as far as I understand them, were intended to get the wheels turning and to demonstrate results at regular intervals so the customers for any software development effort could see progress and gain confidence that the team was going to deliver. Once everything is up and running smoothly then it's entirely reasonable to drop all that and just focus on delivering - you don't need a lot of packaging an rituals to do that.

But Scrum is working! Why would we ever change?

I’m familiar with some of the artifacts of a kanban style system - do you have any documentation of what your particular kanban process looks like (that you can share)?

> We no longer have drawn out sprint planning meetings where we discuss requirements of features that we never end up working on in that sprint. We don’t waste time debating complexity of features. Everything is now just ad hoc.

I'm curious about a few things, if you don't mind answering.

When do tickets get broken down into manageable chunks? Who does the breakdown?

When is a rough cut of effort put on a ticket? S/M/L often matters when making priority decisions.

A breakdown step in your development process breaks down work into equally sized chunks, that all count against WIP limits. If you're interested in using Kanban for software development I suggest checking out Eric Brechner's book and youtube videos.

Scrum doesn’t prescribe enough techniques to be successful. Somewhere, maybe in an interview, I heard someone say that they never saw a successful Scrum team save that they were doing half of XP too.

So far I have not found an exception to this. Thing is that means everyone is doing Scrumbut (we do Scrum, but...) Which means you have to relearn or reargue with every single team about the exact same concerns. It’s gotten old.

Scrum does not discourage adding additional tools as needed. It tries to provide a minimal framework and nothing more.

Same here. Just pick the next item from the backlog and do what needs to be done. It's much easier.

> But sprint planning is a waste of time IMO.

Agreed. Don't forget to throw daily standups in their. My current project spends 2.5 person hours per day on the daily standup.

Have any good resources on your team's kanban system?

Do you not have due dates or stakeholders that want predictability?

In a waterfall organization many of those due dates are months out.

Finish and deliver don’t have to be the same thing. Especially when features depend on each other.

A group of unaffiliated contractors slipped kanban into Boeing in part because we never said what we were doing. But every time there was a hiccup we proposed another kanban process. WIP limits took a while but saved a lot of headaches. If we are over the limit and you finish a story you had to help someone else or get a special dispensation for the leads (sometimes we had stories that depended on other teams and the next story was straightforward).

It is by far the biggest silent conspiracy to do good that I ever participated in.

Unfortunately after we got reported into a sustaining team there was some peer to our manager who would not shut up about Scrum. If you’ve done Kanban, Scrum is like when your parents make you hang out with your kid brother’s friends.

I agree, I have the same experience.

Reply on news.ycombinator.com