
Ditching Scrum for Kanban - The best decision we’ve made as a team - fearenales
https://medium.com/cto-school/ditching-scrum-for-kanban-the-best-decision-we-ve-made-as-a-team-cd1167014a6f
======
seanwilson
> 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 daily work, over lunch).
Otherwise I find most people zone out during the standup and it just
interrupts work.

~~~
Nursie
You get a quick status update of all the bits everyone is working on.

    
    
      Oh, Bob finished the xyz bit? Great I'll get started on abc now.
      Jim's stuck with the autobuzzulator? I've used those before, I'll jump in and give him a hand after the standup.
      Katie's not been able to deliver the turnip functionality? Still can't test the beets either then...
    

It should take no more than a few seconds per person and I find it far more
effective than any agile status tool I've used, be that a physical board or an
online system.

>> I only find them helpful if some people in the team generally don't
communicate well what they're up to (e.g. during daily work, over lunch).

I communicate well with people I'm working with in the microcosm of what I'm
doing _right now_ , but there may be a few other people on the team doing
related tasks that I'm not talking to every day.

And lunchtime is my time to get a few minutes away from screens and work, take
a walk, have some food etc.

~~~
slavik81
If you were waiting on Bob to finish xyz, why does he wait up to a day before
telling you he's done?

After doing scrum for a few years, my impression is that stand-ups are useless
because you can't depend on them. They're frequently too far away to be used
for the purposes you're talking about, so you always need an alternative. If
that alternative is good, you might as well always use it and cancel the
meeting.

~~~
Nursie
I'm not sure I was waiting for bob, I probably have other tasks too.

I don't know of a better alternative that maintains the face to face element.

------
daigoba66
> 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 not scale or coalesce well
with long-term development and maintenance.

> Perhaps there is indeed a natural progression of engineering teams adopting
> Scrum, then moving to Kanban.

This also mirrors my experience.

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

------
darkerside
Was the author's team just totally lacking a leader who could point out the
patterns in underestimating the scope of work. If you are consistently missing
your estimates, you adjust. Get to a point where you are consistently under-
promising, and over-delivering. Morale problem solved. It's not rocket
science.

That said, I agree that regular timelines aren't the only way to create a
sense of urgency in your team.

~~~
perlgeek
It's not that easy.

If a team member gets sick for a week, it can already be impossible to meet
the goals of a two-week sprint.

It happens (not so often, but it does) that we underestimate the complexity of
a task by a factor 5 or so; that alone can also make it impossible to meet the
goals.

There are just too many things that lead to building pressure when there's no
actual need for pressure from a business point of view.

~~~
darkerside
Estimation is just educated guessing. If you were guessing a non-randomly
generated number, and you found you were guessing high every single time,
wouldn't you eventually try reducing by orders of magnitude?

Team members do get sick, scope tends to sprawl, and life just generally gets
in the way; but good estimation includes a buffer. Under-promise and over-
deliver, at least until you figure out what you're doing.

------
gjmulhol
I love this. We briefly flirted with scrum but now just have a much more
Kanban-like system now, too. The only issue I foresee long term is that the
sprint mentality of Scrum might recharge people and get them to, well, sprint,
at product goals. Kanban, because it is never ending, might start to feel like
a slog. There is never a way to have that feeling of "wow, we crushed it and
cleared out our list. We are awesome." The list just extends forever. We have
put measures in to help with this: primarily just having our engineers say at
the beginning of the week what they hope/plan to get done this week (or two).
Sometimes that is just noting subtasks in pursuit of a larger feature, but at
least it borrows some of what is a very powerful part of Scrum: the social
commitment that comes from standing up and saying "this is what I will finish
this sprint."

~~~
regularfry
I see it the other way round. We're doing Scrum (ish, I guess) right now, and
the see-saw between either ending a sprint with a couple of late-night panic
sessions to get everything out of the door, or ending it with most of the team
kicking their heels with one pair still going up to the deadline is what feels
like the slog. I see Kanban as much smoother: I don't see artificial, self-
imposed crunch mode every fortnight as a positive. It's all very well aiming
at a social commitment, but the way it works in practice is either a) you
under-estimate and have dead time; b) you over-estimate and crunch; or c) you
nail it and one sprint runs smoothly into the next. The trap is that c) never
happens.

I think what makes the difference is that we're continuously delivering, so
there's no delivery ceremony between one sprint and the next to make the
crunch mode mean something.

~~~
cmdkeen
The crunch approach to sprints is the killer. If you know you can't complete
all the work in a sprint the answer should not be to bust yourself to try and
complete it. Have a conversation with yourselves and the product owner to
readdress what you can realistically achieve in the time remaining and then do
that.

It's a really hard thing to do, we all want to be the hero that saves the
sprint. It also encourages you to end up with lots of discrete chunks of work
in a sprint so you can complete 80% of your initial commitment and salvage a
sense of achievement rather than getting 80% through a few big tasks but none
of them actually done.

A sprint with 4 developers and 4 tasks each estimated to take 2 weeks will
almost never succeed. A sprint with 4 developers and 20 tasks each estimated
to take a day or two stands a much better chance of success. Combine that with
some metrics around "complexity per developer per available day" and you
quickly end up with some charts showing productivity that is hopefully
improving which will hopefully improve morale.

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

~~~
keithba
+1. I was taught this as a young lad at Intel by a graybeard who'd been
developing since the 60s. It made a lot of sense then, and it makes a lot of
sense now.

------
vincentkriek
I really like KanBan and think it's a better fit for a lot of teams than SCRUM
is. SCRUM works great for teams which have a stable backlog of work and an
incidental problem that might pop up. If you can't keep a backlog stable for
three weeks, you shouldn't do scrum. KanBan allows you to pick and choose
practices from scrum that do add value, and ignore the ones you are just doing
to follow the book.

I worked in a team for 2 years that tried to do scrum because it's new thing
that everyone should be doing and I feel it added nothing of value.

~~~
cmdkeen
If you can't keep a backlog stable for a few weeks then you aren't doing
project work you're on support or firefighting. Scrum is all about IT project
work, Kanban is a more general "efficiently get a pile of tasks done" process
which can apply to small IT tasks or building a car.

~~~
peterbell_nyc
Depends where you are in your product lifecycle. Pre-product market fit, it's
often a bad idea to build and keep a stable backlog a few weeks in length.

------
_Codemonkeyism
The context and mode defines your process: agile, lean or six sigma. Most
companies have no clear understanding about their context (should read Simon
Wardley [1]) or mode.

Very good video from Markus Andrezak explaining the three "modes":

[https://vimeo.com/146522220](https://vimeo.com/146522220) (Must see)

"The biggest mistake companies can make is to define their (one) process,
culture, way of work. The work that needs to be done in a sustainable company
differs in at least three fundamental ways."

[1] Simon Wardley and Markus also explain why bimodal IT does not work

~~~
bryanlarsen
Any text links? Thanks.

~~~
_Codemonkeyism
Simon Wardley blogs at
[http://blog.gardeviance.org/](http://blog.gardeviance.org/)

One link is [http://blog.gardeviance.org/2015/10/agile-vs-lean-vs-six-
sig...](http://blog.gardeviance.org/2015/10/agile-vs-lean-vs-six-sigma.html)

(I'm sure his view and his value maps on strategy will be huge in 5 years,
although he is relativly unknown today)

~~~
sandGorgon
thats' a very interesting blog on strategy. Thanks for that - the only problem
I see is that the "settlers" analogy has no real life mapping (unlike Pioneers
<-> scrum and TownPlanners <-> six sigma).

------
cmdkeen
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 which Kanban lacks. There may well have been a
Scrum Master, one of the things I've experienced them doing is guiding my team
down from 1 month sprints through 2 week ones down to a single week. "It's
really hard to plan for 2 weeks work" is a classic moment for the Scrum Master
to say "what about..."

"We tossed out the retrospectives" \- Despite acknowledging them as a good
thing? For me retrospectives are the most powerful part of Scrum. Stopping
retrospectives might save you a few hours and some awkward conversations but
is likely to hamper your continued development. Scrum is really good about
moving a team to the "conscious incompetent" phase - i.e. you are forced to be
aware you are bad at something and really need to work on it. Retrospectives
are the way to improve and grow.

"We kept our deadlines" \- That you had deadlines (again the sign of a PM
somewhere), and view them as important enough to mention again is interesting.
It hints at quality not being the most import factor, which is one of the keys
to doing Scrum well.

For me moving to Kanban was a fix for a Scrum team that wasn't working well.
I've worked on a good Scrum team, that took a while to get going, but got
there by being able to be open and honest about poor morale and then dealing
with it. The new team didn't get there, we moved to Kanban and while everyone
is happier our productivity is much, much lower. I do feel there is a place
for switching to Kanban - when the scope of the project has moved into "we
know how to do this" space, often close to a major release (if you do
infrequent releases) where 3rd party involvement plays havoc with planning. If
you're dealing with points high on the "the business don't know what they
want" or "we don't know how to do this" chart then, for me, Scrum is still
king. If you're high on both axes then you might want to switch projects /
companies...

~~~
eitally
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 this very rarely happens in
enterprise, and Scrum fails.

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

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

------
rabbitheart
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), reimplementing the parts we already knew didn't work was a bummer,
and the Scrum leader talked down to me when I tried to advocate for the team.

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

~~~
rabbitheart
I think the most frustrating part was that I explained we had tried Scrum and
adapted it for our team's needs. We weren't anti-Scrum, we just found a way to
make it work for us. I was then told "[Company] is a Scrum company. We all use
Scrum as it is" and was brushed off. Same Scrum leader would yell at the
operations team for failing to complete sprints in time when servers fell
over, and other nastiness that becomes the priority when you work in a
position where you prioritize server health and function over new builds and
features.

The other Scrum leader we had was pretty great, but, unfortunately, was not
the one assigned to my team.

Sorry if this borders on ranting. I really enjoyed working for that company,
but it was a rough time toward the end of duration there. Apparently I have
lingering frustrations, especially since I'm still friendly with many on the
ops team. :)

------
tootie
I think the value of Scrum is that it provides great visibility into
development for stakeholders. They can see the progress of the backlog and
know what's being committed to every sprint. It does put some artificial
boundaries on work getting done, but I think it strikes a good balance between
pure agile and keeping business happy.

------
PaulHoule
Remember the triple constraints of cost, scope and time. If you are going to
commit to releasing at a certain time you are going to have to let the scope
slide. (Sometimes you can add more people on a 2 week basis but the ramp up
time makes it usually impractical.)

~~~
T-hawk
And this is exactly the difference between Scrum and Kanban. Scrum fixes the
time periods and allows for adjusting scope, by cutting stories and features.
Kanban fixes the scope while allowing the time period to be open-ended. Which
methodology is more appropriate depends on which constraint a business wants
or needs to optimize for.

~~~
PaulHoule
It is even better to do something hybrid that is tuned to the application.

A bad thing about scrum is that it introduces a lot of phony deadlines that
have nothing to do with the business; this is like the common practice of the
boss setting a short deadline on the hope that they can control the cost
(total hours) by controlling calendar time.

On the other hand having a release every two weeks means you actually need a
release. There are so many projects where a few programmers spend say 1.5
years building a components and hypothetically the application is feature
complete, but they are nowhere near running it on a real server or packing it
up for the customer with an installer and all that and it takes another 0.5-1
yr to figure out how to make a release.

Then there is a stressful process of making a few more releases to fix the
inevitable problems, then they go off and work another 2 yrs on the next
release and then find they've forgotten how to make a release. The best thing
about scrum is that it avoids that.

The idea that the phony deadline is fixed is another problem. If you can slip
the schedule by 2 or 3 days in scrum to address critical things in the scope
there that is no problem but many agilists will fight that.

Another failure mode is the project that is hitting the goals for milestones
well (estimating things about 10% accurately) and that makes people feel good,
but somehow you never get to the last milestone.

I came in late and helped finish one of those severely troubled projects where
there was a huge amount of blame to go around. Scrum and Kanban concepts were
being used by teams involved, but a lot of people on my team including the
boss and star programmer would not do what scrum required. My boss would bitch
me out for making "rediculous" estimates of 4 hours to do something that
involved a 45 minute build process and I wondered how the other people on the
team didn't have this and I found I was the only one who was serious about
estimating and that the star programmer did not do it at all.

In the end we gave up on scrum and got heavy on checklists. We made a
checklist with about 300 steps for a release process and it a was a stressful
process but we learned how to do it reliably. Also we had a checklist of
things to have done before the final release.

It was not pretty but we did cross the finish line and get the product in
front of customers and they liked it, so I felt I did my part and felt free to
move on when it was done.

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

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

------
JoeAltmaier
We've used Kanban (or something like it) for 20 years. Long before Kanban
existed as a thing. Near the end of a project, we'd draw up the "finishers'
list" with numbered items and initials next to each. Daily team review of each
remaining item, reassign priority or responsibility as needed.

------
arielweisberg
It sounds like you got a lot of positive things out of it. Which is great.
Also great that you are iterating and not sticking to what the coach gave you.
My take on what made many elements of SCRUM work for me follows.

2-3 hour backlog grooming sessions is a warning sign. Of what I couldn't say
but maybe it is time to evaluate team size or how meetings are being
conducted. Push as much stuff out of meetings as possible.

If you have a morale issue due to stuff slipping (and I suspect maybe you
didn't capture everything in this post) then it may not be planned sprints
that are the issue. Expectations that people have of themselves and of the
team are something you are free to set. I think SCRUM tend to end poorly for
developers because they are placed on top of dysfunctional systems of
expectation that discourage many kinds of failure.

I am perfectly happy abusing SCRUM and letting things slip from sprint to
sprint sometimes excessively. Fitting things into 2 weeks was a goal to gain
the benefits of constrained scope and clearly articulated and designed
implementations or requirements, but failure is something I made sure to
embrace. Sure we had retrospectives to see what could be learned and what we
could do better, but you have to be very careful to make sure it isn't second
guessing or moving the goal posts. You shouldn't fault people pretty much ever
as part of SCRUM, but definitely don't fault them for slippage. There should
be next to no onus on an assignee for a task to prove they did the right
thing.

IMO That kind of feedback comes best out of band on a very macro scale when
there is a pattern of failure for an individual to address AND you must get
buy in from the individual that there is improvement to be had. The reason I
stress this is that I don't want people to try and avoid things that they
might fail at. That pushes people away from important work that needs to be
done.

I think that planned sprints and retrospectives are the 1-2 punch of SCRUM. By
estimating what you should be capable of you are then capable of reasonably
identifying WHY you didn't achieve that and trying things until there is
improvement or you establish that the estimates are wrong. SCRUM without high
functioning retrospectives is missing 50% of the goodness IMO.

It's great that you kept regularly scheduled meetings. There is a huge amount
of buy in, knowledge sharing, and consensus you get for relatively low cost by
having regularly scheduled meetings. With small enough teams you can get it
all done with one hour long interrupt per week. Socially it's also good
because it discourages backroom deals, planning, and cliques which are toxic.
Doubly so if you have remote workers.

~~~
mpdehaan2
That long grooming session _IS_ a warning sign. I recall working for one
disaster where we were required to have one grooming session for us (1 hour)
and then it got re-groomed the same week where we heard all the tickets again.

It should be sufficient for someone to lead and assign tickets as they come
in, and for people to talk to people and reassign them as needed.

Again, if you need status on something, don't have a 2-3 hour long meeting,
just ask... because when you have a long meeting and only 2 people out of,
say, 8, are engaged at the same time, those other people are being very
expensive and are getting bored fast.

The team's velocity is what it is - retrospectives can be boiled down to a
"hey, how are things working out" that you can fit into a standard team
meeting IMHO. Doesn't need it's own time slot, and this can also prevent
retros turning into "throw X under the bus / CYA" type meetings. You can also
get a lot of this from 1:1 conversations, and probably in greater depth in
that context.

------
biehl
I've preferred Kanban for a while now.

When I started doing work on a git-flow/feature branch basis, the sprints lost
their value to me. I've begun to wonder if the sprints were simply an artefact
from poor practices in old CVS/SVN workflows (like needing a short, regular
stabilizition and release cycle)?

------
BurningFrog
I read this article hoping to learn what "kanban" really is.

From the text, it seems like it's scrum, but without having a deadline every
sprint for what you committed to at the start of it.

And... that sounds exactly like the Pivotal school XP I've been doing for 10
years.

Words, words, words...

~~~
antod
The commonly understood aspects of Kanban is that it is a pull (team members
assign themselves work based on priorities) system that has a 'work in
progress' limit - ie the most number of items a team/person can work on at
once. If something urgent comes up that needs working on right now, something
else will need to go back on hold.

Kanban works best when tasks are explicitly prioritised against each other.

------
kemiller
Scrum is supposed to be about regular feedback and sustainable pace, not
motivation.

------
bsg75
Can anyone recommend a good, concise book on Kanban in software - preferably
without mingling in Scrum?

There are multiple titles that come up on an Amazon search, all with similar
review scores.

------
adrianmacneil
Would people recommend a team moving directly to Kanban, or is it useful to
learn/use Scrum first?

What books/resources would people recommend to learn Kanban effectively?

~~~
trhway
>is it useful to learn/use Scrum first?

'Smart people learn from their mistakes. But the real sharp ones learn from
the mistakes of others.'

------
marcosdumay
I was curious to understand what exactly software managers were calling by
"kanban" now that the name is fashionable.

Well, I was not disappointed. The articles talks about everything, except
anything marginally related to the meaning of "kanban" in manufacturing.

~~~
sbuk
Can you elaborate?

~~~
marcosdumay
In physical production (where it comes from), kanban is a lean method for
ensuring that you don't spend on producing right now something that is not
needed right now.

It works by tokens that "pull" the production from other productive unities
that are ultimately "pulled" from external (client) demand.

The article talks about all kinds of rituals and gains, but never once touches
that "pulling" activity that is central to the concept, nor the lean
objective.

~~~
sbuk
Thanks. I'll confess to being a Kanban noob. Do you have any resources that
you can share? Looking with Google seems to present more of this sort of
article.

~~~
marcosdumay
Wikipedia has a surprisingly good explanation:

[https://en.wikipedia.org/wiki/Kanban](https://en.wikipedia.org/wiki/Kanban)

There's a link to Toyota's site at the bottom, as the inventors, they have
plenty of authority on it.

Wikipedia has also an article about Kanban in software development. As
expected, the introduction does not even make sense, but the methodology
section contains a form of continuous improvement, what could work. Also, I
could not understand how any of the experiences related on the article could
come from the Wiki's methodology - it has probably no relation at all with was
implemented at the author's place.

------
slavik81
This really resonates with me. My experience with scrum was very similar, and
I thought Kanban might be a nice answer to the arbitrary deadlines that
frustrated me. Never got a chance to try it, though.

------
LeicaLatte
Waiting for the follow up post on how he's ditching kanban for X next.

~~~
themodelplumber
Wampaku has worked out very well for my team.

------
shockzzz
Sounds like they're about to throw out Kanban in favor of quitting

