Hacker News Reader

Comment by lmm | Hacker News Reader

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

View on HN

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.

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.

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.

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 they key. Give folks responsibility for owning big ideas and allow them to get their in an agile, incremental way.

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.

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

My issue with this criticism of kanban and many other agile practices is that it pretty much boils down to "X does not work; we did not actually do X".

I think there are all types of tools and techniques that can work. The fact is that Kanban or any other tool can not fix lousy strategy, culture, or leadership.

You are correct that the problem is the manager and not Kanban, but in my experience it has been the case that the problem is always the management at some level. The point of this article is that if you think adopting Kanban is going to solve long standing organizational and inter-personal issues, you're in for disappointment.

I have personally experienced this situation more than once. A manager/team/organization who claims to be adopting (Scrum/Kanban/etc) but when push comes to shove they immediately discard any discipline imposed by any approach their team has decided to commit to, thereby rendering it completely pointless.

If your manager is competent enough to understand the reasons for the rules of Kanban (or any Agile methodology), and has the power to enforce those rules despite pressure from other parts of the organization, then it's likely you don't need to ascribe to a particular methodology anyway. Your team will adopt an approach that works best for them, borrowing best practices from various methodologies, and will get the job done regardless.

> But Kanban doesn't let them.

My point was simply that Kanban is helpful for solving non-pathological cases: people who don't really understand how to manage a software project and find the framework helpful for pushing them towards a known-productive decent workflow. What it – and any other productivity system – can't deal with are the pathological cases, so a key skill for engineers is recognizing when you are likely to be able to make a cultural change and when you should simply move on because the company isn't yet ready to break bad habits.

True. As you point out it starts with understanding why something needs to get built and its importance to the business. If you do not have clarity on that, everything looks like a priority.

Reply on news.ycombinator.com