Hacker News Reader

Comment by lmm | Hacker News Reader

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.

View on HN

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.

Great insights. Give the folks who can get the work done the freedom and responsibility to get the work done. Managers should remove barriers -- not impose additional ones ever time something goes wrong. It's hard enough to build great software.

Excellent comment/reply. Kanban is a tool, but its not a solution to a cultural problem.

Totally agree. The challenges are multi-faceted, but one of the biggest issues is that it's not for deciding the "whys" or "whats." Why we are doing something is strategy and what and when we are going to deliver is the roadmap. Kanban can be used for working on the "hows" (even though it was never intended to be a software development framework).

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

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.

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.

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.

Yep.

Productivity frameworks can be helpful in a context with people who are smart enough to process the central insights and genuinely interested in playing a longer game than an immediate problem or narrow personal/career agenda.

But in some hands, the important insights either don't get absorbed, or they're wielded selectively to poor effect. Bad decisions can actually be justified with situational appeal to some guiding principle -- but when it cuts the other direction, the principle gets played down and the other side of any tension present gets played up.

Kanban does nothing to solve the product strategy and market fit questions and is often applied as a fix-all for much deeper rooted problems. I would also argue that Kanban has the tendency to turn engineers into widget builders and is demotivating. Here, take this tiny piece of work and when you finish it I will reward you with another. Keep your head down and just trust me.

I would say Kanban is the opposite of keeping your head down - you have to come up for air every time you finish something and priorities can change each time. Waterfall is the classic head-down approach, work on something for months/years and then release it and see if there is still a market for it. I think there are strong tendencies towards waterfall in many tech personalities - "I'm just going to disappear and come back with something brilliant at some unspecified point in the future." People don't want to feel that they're building widgets when they could be making a cathedral but that's often what is needed. Agile and Kanban fight this tendency and are therefore not always popular.

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 in an agile, incremental way. Kanban really is about the incremental "getting there" part.

Reply on news.ycombinator.com