5 ms·

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

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 13y ago
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 13y ago
  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.
  - bdehaaff 13y ago
    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.
  - derefr 13y ago
    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.
hackula1 13y ago
> 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".
- bdehaaff 13y ago
  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.

bdehaaff 13y ago

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 13y ago
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.
- bdehaaff 13y ago
  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.
- derefr 13y ago
  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.

hackula1 13y ago

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

bdehaaff 13y ago
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.