
Kanban can not save you from the engineering death spiral - bdehaaff
http://blog.aha.io/index.php/the-engineering-death-spiral
======
lmm
Huh? I'm pretty sure Kanban helps with all of these.

Why are we building this feature? With a strict limit on work in progress,
someone must have explicitly decided that it was more important than all the
other features in your backlog. Sure, you can still disagree with their
weighting, but at least it forces them to prioritize, rather than delaying the
product with a kitchen sink of everyone's ideas.

We can't release until quality is better? If you keep cards in progress until
they're released (and you should), you very quickly reach a point where you
_have_ to release, or it's simply impossible to do any more work. In fact this
is pretty much the core problem Kanban was meant to solve.

I'm blocked? A blocked card is filling up a valuable work-in-progress slot,
and a manager should notice very quickly. If particular issues keep blocking
several cards, that means the manager is seeing those same issues every day;
sooner or later they should take notice.

~~~
acdha
You can't solve social problems with dogma. Every single thing you mentioned
above will work if it's done right but if you're in a toxic, poorly-managed
environment each of those assumptions is wrong.

It is absolutely the case that you will find managers who make everything
priority 1, ignore problems for far too long, keep piling features into
dreadnaught-sized releases, etc. The only thing which can change that is a
different manager – either because the previous one is sacked or because the
development team threatens to resign en masse unless they are given enough
control to do their jobs responsibly.

~~~
lmm
> It is absolutely the case that you will find managers who make everything
> priority 1, ignore problems for far too long, keep piling features into
> dreadnaught-sized releases, etc. The only thing which can change that is a
> different manager

But Kanban _doesn 't let them_. You are required to prioritize upcoming cards
in a linear order, not equally. Limiting work in progress is literally the
definition of Kanban. If your manager won't do that, it's not that Kanban
isn't solving your problems, it's that your manager isn't adopting Kanban.

~~~
JimboOmega
What happened for us is we tried to adopt it, but it was just so unworkably at
odds with our current process, it got mostly ignored.

The manager had no hope to prioritize and minimize work in progress. As a
developer I spent more time managing tasks than coding, as it was. For
instance - sending out an email explaining how this task needs requirements,
that task needs database work, and X, Y, and Z are all done but QA can't test
them because we can't get a deploy in because.... etc.

The manager who tried to implement also struggled valiantly against these
systemic issues, but he was powerless - a higher power than him had decided
that QA (for instance) had to work on project Y _right now_ , and there would
be no testing for a few weeks, and so things just fill up.

"I have nothing to work on and I am forbidden from improving quality" was a
_very_ common state to be in.

One solution that was attempted was to create more queues that could be worked
on for different parts of the app, or to create more buckets...

The point is, he was very aware of our problems, but Kanban couldn't fix them.
I don't know what could. When stories got blocked, I definitely made him
aware... so the visibility was there with and without Kanban.

~~~
bdehaaff
I would suggest the core issue was that you did not have the freedom to go get
the important work down and be responsible for it. Too often work is
subdivided so no one actually owns anything important -- because the bits are
too small.

~~~
JimboOmega
That's a very interesting observation.

I've always been taught that breaking things down as small as possible is good
- easier to estimate, easier to understand, easier to track.

You don't want to give a developer a week long task - that turns into two
weeks, for instance. There just isn't the visibility.

I'd agree, there's a huge issue of none of the work feeling important, and an
issue of Developers having no real power in the process (other than to
unilaterally dictate how long we thought things would cost, strangely enough).

But is it a result of subdividing tasks too small? I'm not sure; it's an
interesting concept to explore.

~~~
derefr
I find that the best thing that's ever happened to my task-delegation is
Service-Oriented Architecture. You break a project down into a tree of tasks--
then find the nodes are the most weakly coupled, and call each such subtree a
"service."

Each service gets assigned to one developer to build and own. Each developer
then publishes a protocol/API for their service, and other developers--instead
of needing to talk to them to consume their service--just consume its API.

This means each service can be developed, tested, mocked, gateway-ed, and made
Highly Available in isolation from synchronous/blocking work by other
developers.

------
ecesena
A friend of mine, CTO at Elfo [1] (a 60-ppl Italian software basically-unknown
company) is successfully using Kanban for software development since almost 2
years.

Each team/project (6 to 10 developers) has it's own Kanban board, each person
has no more than 1-2 tasks/phase and they focus on keeping the phases
balanced, i.e. with the same amount of tasks. They're happy since its a light
weight way to have a full picture of what's going on.

His original notes (in Italian, sorry) [2].

[1] [http://www.elfo.net](http://www.elfo.net) [2]
[http://www.robertocappelletti.com/2012/01/kanban/](http://www.robertocappelletti.com/2012/01/kanban/)

~~~
bdehaaff
Great. Thanks for sharing this success story. It would be interesting to know
if the engineering team is motivated and understands the why they are building
what they are.

~~~
ecesena
As far as I got a lot. The main reason is that, with limited effort, you see
your progress (tasks move). Moreover the management is really enthusiastic of
the approach, so they're often showing to guests (like I was) and promoting
the activity as something unique of "their guys", so I guess this also makes
people proud of what they're doing...

------
karlkfi
The real silver bullet behind Kanban has nothing to do with Kanban. It's the
desire for continual improvement and willingness to start where you are and
improve from there.

Anytime you attempt to make a huge process shift you are tempting fate and
risking failure. The short term drawbacks to huge change can often stifle the
process before it reaches maturity. The trick is to work through the
rationalization with the team based on current observable problems and lead
them towards self-realization and analysis of their own problems.

Most people have ideas of how to make things better, but if you lead them
towards the desire for slack, optimizing for the bottleneck, rather than
maxing out everyone as if they're all the bottleneck, then you can easily get
from there to Kanban-like WIP limits. From there you can adopt other solutions
as the problems they tackle are realized.

Smart people frequently arrive at similar approaches whenf aced with the same
problems, but not always. Your team may find some novel approach that works
better for your context, or they may go looking for options and find Kanban.
But the goal should begin with being able to communicate process problems, ask
how they can be improved, test the potential solutions, and adopt the best
ones.

Unfortunately, the biggest hinderance to gradual process improvement (once
your team is on board) is that software tools tend to offer a "whole solution"
and don't have the ability to grow with your team's maturity, unless they're
writing it themselves.

~~~
bdehaaff
Thanks for the detailed thoughts. I am not sure though that Kanban or an other
agile tool can solve the problem when it is one of leadership or direction.
Strategy and management do not rise out of the incremental planning bits.

~~~
karlkfi
One of management's jobs is to enable and empower the workers. One of the
principals that enables Kanban development is that management should not
dictate worker process. If management doesn't know that they may be tempted to
fix the development problems with more process, which actually disempowers the
workers. Adding more dictated process may work in the short term, but it's a
tactical fix, not a strategic one. A well run business keeps tactics and
strategy in balance, and hopefully delegates the tactics as low as possible,
to retain empowerment. Good management acts as a multiplier to worker
productivity. Bad management cripples what it's trying to manage.

So yes, you need good management, but good management alone does not guarantee
success. Management cannot be the source of the solution to every problem.

The other bit to take into account is that management can benefit just as much
from its own cycle of metrics, feedback and retrospective action. All levels
of an organization need to be able to improve, not just the developer teams.
However, that's usually a completely different set of tools and skill sets.

~~~
bdehaaff
Agreed. The point I am trying to make is the following: I think you need to do
both and that's why building great products/software is hard. You need to see
the big picture yet deliver against it in bite-sized chunks. Good PMs and Engs
are capable of doing both at the same time. That's the key. Give folks
responsibility for owning big ideas and allow them to get their work done in
an agile, incremental way. Kanban really is about the incremental "getting
there" part.

------
hacknat
In people' experience(s) how likely is it that a company can salvage a
situation like this? I'm starting to experience this at work and I've been
thinking about leaving (for other reasons than just this), and I wonder if
anyone has actually seen a turnaround in an engineering team's culture.

~~~
RogerL
I have seen a turnaround, a dramatic one. I forget the number, but this was
for something in the range of a $60MM contract. I will not identify the
company or product for various reasons.

How was the turnaround accomplished? By firing everyone in charge, and
replacing them with people that could actually make reasonable decisions. Some
lower level people were also let go; we had some people without the chops to
do the job. But that was not the main problem. The problem was consistent
management focused entirely on 'process' without regard to what we were trying
to accomplish. In the form of "MIL-STD-1234 says we have to produce
documentation in the form of X. Therefore, produce X". Documentation does not
result in a great product. Documentation can only, wait for it, _document_
what was done. That was just one sliver of it, but entirely representative.
Methodology X, process Y, 5 levels of sign offs all focused on what color ink
you used or if your document's headers use the right capitalization. Just
shuffling requirements along an endless document chain, without actually
trying to figure out how to meet those requirements.

A really smart systems engineer who had the bosses ear was able to say 'they
will never make it', he eventually listened, she was put in charge, our best
engineer was finally put in charge of the SW, and from there we recovered.

In the interim we hired a bunch of outside consultants to come in. I don't see
that they did anything of value. Lot's of interviewing, lots of 'do x, y, z';
meanwhile the people that had _successfully produced this sort of project
before_ were still being ignored.

That is one story. The problem was mid-level management, and only once they
were all fired (actually, there were several rounds of getting rid of person
A, and replacing them with an exact clone, and of course that person had
identical results) did we recover. This probably doesn't apply to any place
where the problem is not middle management (say, a team full of cowboys, or a
PM that sends you off on wild goose chases, or whatever).

~~~
bdehaaff
Exactly. Put the folks who can get the work done in charge of actually getting
the work done. Give them the responsibility and allow their courage to
flourish 9and remove barriers when needed). Celebrate their accomplishments.

~~~
zobzu
yep - full management replacement is often the only thing that can help, and
boards generally dont have that level understanding. plus the management wanna
stay in place and advance personal careers/salary without effort and thys
deflect issues and pressure the board. it even happens in non profits.

------
msaspence
The key word (that is admittedly missed from the title) is "blindly": 'blindly
applying "agile shock therapy" or introducing Kanban will only suck you
further into the abyss'.

Which is a bit of truism: do anything blindly and your chances of succeeding
are based entirely on luck.

Depending on the specific circumstances Kanban, or any other agile
methodology, may or may not be part of the solution to the so called "death
spiral".

------
bayesianhorse
One problem with this article is the absence of any reasoning process.

How do you know there is such a thing as a death spiral? How do you know these
symptoms apply to the "death spiral" condition. How do you know your solutions
actually alleviate the symptoms or abandon the condition?

~~~
seiji
Death spiral: When you keep creating products with no demand in the real world
[1]. You create things, release things, nobody uses it, but by then, you're
working on the next version nobody wants either.

Death spiral: Working on components of a larger project with no hope of ever
integrating all pieces into a coherent final release. Everything gets
incrementally improved in isolation, but nobody can figure out how to cut a
product out of all the pieces.

[1]: Plenty of demand exists in the delusional minds of executives, PMs, and
clueless employees though. It just doesn't match the real world.

~~~
bdehaaff
True. That's one of the ways that you end up in this engineering death spiral
-- bad market / product fit and thrashing strategy.

------
pkananen
The article has some good points, but I'm not really sure what it has to do
with Kanban.

~~~
cjensen
Kanban is the silver bullet of the day which sinking enterprises reach for.
I've been a software engineer since 1989, and the entire time has been filled
with process/method fads "which will fix everything." In 1989 it was Yourdon's
institutionalized bureaucracy. Today it's Kanban.

Doesn't make Kanban broken; it just means that it is the non-solution for
today's desperate souls.

~~~
bdehaaff
Very true. There is always some new "fix it." The problem is often that the
engineering tools do not improve product management in the least and if the
product strategy is bad and customer understanding is missing, no engineering
team or tool can solve that.

~~~
RogerL
But "Aha" does solve it?

------
jonathandart
Can anyone here recommend some references for someone wanting to learn about
Kanban?

~~~
karlkfi
[http://www.amazon.com/Kanban-
ebook/dp/B0057H2M70/](http://www.amazon.com/Kanban-ebook/dp/B0057H2M70/) Note
the subtitle: Successful Evolutionary Change. Don't try to change everything
all in one go.

And if you already know Scrum, here's some differences:
[http://www.infoq.com/news/2009/05/kniberg-kanban-v-
scrum](http://www.infoq.com/news/2009/05/kniberg-kanban-v-scrum)

~~~
bdehaaff
There is a good overview here for Kanban for development:
[http://en.wikipedia.org/wiki/Kanban_%28development%29](http://en.wikipedia.org/wiki/Kanban_%28development%29)

------
3pt14159
The article's own link to the authors product is broken.

~~~
bdehaaff
Thank you for pointing that out. Grateful for the call out. Best.

------
coryfklein
Warning: title not reflective of content.

~~~
bdehaaff
Thanks for the comment. The point is that using Kanban or implementing "agile"
is not a savior from the engineering death spiral. The post includes that
exact point in the first paragraph.

