
So Long Scrum, Hello Kanban - cpeterso
https://stormpath.com/blog/so-long-scrum-hello-kanban/
======
vannevar
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.

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

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

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

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

------
kken
Anyone know a good comparison between Kanban and Scrum?

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

