So Long Scrum, Hello Kanban | Hacker News Reader

So Long Scrum, Hello Kanban

stormpath.com

14 pointscpeterso9 comments

I'm not going to judge the author's transition to kanban, it may very well be a better fit for what they do. But there are two significant misstatements about the sprint-based process that need to be corrected:

1) Scrum tries to drive productivity by imposing a time limit on work.

No, reality imposes a time limit on work. Scrum just provides a framework for partitioning work to improve visibility so that time limits can be rationally traded off continuously against goals, instead of in the context of sporadic self-induced crises.

2) Scrum assumes you’re good at estimation.

Scrum assumes that you are relatively consistent at estimation, as a team. There's a reason that scrum uses story points and not person-hours---every team is unique, and if you track velocity for a few sprints your team should converge on a velocity that they fairly consistently achieve. A good scrum master is also cognizant of the granularity of the tasks in the backlog, so that the team is wary of accepting a story whose point value is a large portion of the target velocity.

One issue I see here is working with other processes that aren't Kanban - namely, app store releases.

You can't do iterative deployment on apps, you have to submit a finished binary with a specific version number and in the case of Apple, it takes 7 days to get it reviewed, so you're tied to their release schedule.

Scrum, at least, has hard targets that fit into that structure.

In either Scrum or Kanban, it's important to separate your development cycles from when you release or deploy cycle.

For example: In Kanban, our developers work in a flow model to get anything and everything they can get done as fast as they can get it done (regardless of when the release is planned). We manage the work by using work in progress limits. However, we have a public releases that are scheduled every two weeks. So on that scheduled release date, we take all the completed tasks lump them into a release. Nothing holds up a release. For high priority feature, we'll do a hot fix. For big announcements, we'll usually schedule it after we've completed most of the work.

Scrum is the same in this regard at most companies. A public release could happen after 1, 2, or 200 sprints. It really just depends on what you're trying to do.

In the Apple AppStore model, Kanban or Scrum should have no impact on how you deploy. You deploy when you're ready. Kanban no Scrum guarantee that it'll happen by a certain date.

It is still a very good idea to review your process periodically in order make changes to your process.

How about, so long labels and snake oil, hello independent thought.

Work out a process that suits your project and team members, evolve, drop the buzz.

Anyone know a good comparison between Kanban and Scrum?

Hi, writing a book on Kanban...

A lot depends on what you mean by Kanban - the kanban systems (inspired by Toyota's systems but with very different mechanics), some locally-designed flow-based development process, or the Kanban Method - a thing you apply to what you do now (eg Scrum) to help it evolve. The David J Anderson book mentioned in the article describes the last of these; so will mine (disclaimer: David and I are colleagues).

Scrum and Kanban (in the last sense especially) actually work together very well. Whether the end result remains recognisably Scrum is somewhat in the eye of the beholder. Two techniques that seem particularly provocative (in a good way) in a Scrum context are tracking work items until they have been validated in production, and planning (or simply doing) releases later rather than up front (perhaps in conjunction with technical moves in the direction of continuous delivery). There has been a lot of debate in recent months about estimation but neither method stands or falls according to which technique (or none) you use.

It comes as no surprise to read that burnout reduced and productivity increased. Quite apart from the timebox thing (which works fine in some contexts, but can be very unhelpful in others), limiting work-in-progress (WIP) is often key to achieving sustainability at team level, and it almost inevitably leads to work being completed sooner with higher quality.

A lot of teams stop there and it's hard to blame them, but paying attention to flow end to end can be just as big. For a team that is turning inwards or over-protected from real-world customers (as opposed to their proxies), Kanban might be just what they need too.

While Scrum is a rigidly defined methodology, kanban is less rigidly defined, but the linked article here covers the main difference and provides useful additional links.

The huge overarching difference is this: Scrum is based on timeboxed releases (sprints) into which individual units of work are grouped, while Kanban is flow-based allowing each unit of work that delivers independent business value to proceed independently. This, in theory, eliminates friction that exists in Scrum around managing sprint size/content.

I did Kanban for a few years. The process was something like this:

1. (bi)weekly review of backlog items for prioritization 2. When a dev is free, they pick a story from the board, and work on that exclusively (more or less) until it's done. 3. When a task is done it goes over to the QA area 4. QA grabs tasks that are ready for testing. They do the testing and then approve for deployment 5. Dev picks up a new story.

We pushed to production pretty regularly as soon as features were done. It is nice to not have this idea of "end of sprint" and having your task done by then. You just work, push to test, and pick up something else.

Reply on news.ycombinator.com