It's so much better to see the results from the REPL.
user=> (defn testing [dev tester]
(if (and (= dev 'f) (<= (compare tester 'b) 0)) (testing dev tester) 'ship))
#'user/testing
user=> (testing 'a 'b)
ship
user=> (testing 'f 'c)
ship
user=> (testing 'f 'b)
java.lang.StackOverflowError (NO_SOURCE_FILE:0)
Friday, May 22, 2009
Tuesday, May 19, 2009
Thinking about Kanban
I've been giving some thought to trying Kanban in about a month or so. The nature of the work that I'm hearing may be coming our way sounds like it may lend itself well to trying Kanban. For almost the last year or so, we've tried to force our work to fit into having one major ongoing project at a time, and a steady stream of small unrelated enhancements. For some reason, this forcing seems to constantly leave gaps where some people on the team are always too busy all of the time, and some people on the team aren't ever busy enough.
I don't suspect that Kanban is going to solve this problem, but it might do a better job at exposing the problem and providing a different perspective on the solution. I suspect that we may either have too much specialization on the team, or not enough people in the right specialties. I'm hoping that through combining Kanban with reflection, we can clearly start to determine how much work-in-progress we can tackle given our current set of resources and their specialties, and maybe try to figure out an answer such as "What if we had one more developer, or one more tester, or a dedicated project manager? What would that mean for the work in progress as a whole?" I'm well aware of The Mythical Man Month, but the idea here would not be to try to speed up a single project, but rather, an infinite collection of unrelated backlog items.
I do like the idea of throwing out estimation. I respect the work that has been done with Planning Poker, and other forms of estimation, but there is something very liberating about tossing that to the side, and tossing sprints aside, and just constantly working to move work in progress items to a release ready state. After all, the manifesto says nothing about sprints. The highest priority is satisfying the customer through frequent releases.
I'm trying to come up with some clever, cynical ways to break Kanban so that I can detect ways that it might get abused. The first one that came to mind is that work may get stuck for everyone, and nothing moves anywhere, and the limiting of work is an excuse to not do anything. I'm hoping that if a daily standup is done right (David Anderson's description at http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html seems pretty good) that this shouldn't happen.
I've read through http://theagileexecutive.com/2009/05/11/john-heintz-on-the-lean-kanban-2009-conference/ and I want to go through some of the links and really start to build a strong mental model of all of the reinforcing concepts. I've had my eye on various articles on http://www.poppendieck.com/ for some time now, and I feel like it will become much more clear after reading one of their books.
But in the end, it really couldn't hurt to just try it. It seems pretty natural already to what some teams were already doing without being given any direction before.
I don't suspect that Kanban is going to solve this problem, but it might do a better job at exposing the problem and providing a different perspective on the solution. I suspect that we may either have too much specialization on the team, or not enough people in the right specialties. I'm hoping that through combining Kanban with reflection, we can clearly start to determine how much work-in-progress we can tackle given our current set of resources and their specialties, and maybe try to figure out an answer such as "What if we had one more developer, or one more tester, or a dedicated project manager? What would that mean for the work in progress as a whole?" I'm well aware of The Mythical Man Month, but the idea here would not be to try to speed up a single project, but rather, an infinite collection of unrelated backlog items.
I do like the idea of throwing out estimation. I respect the work that has been done with Planning Poker, and other forms of estimation, but there is something very liberating about tossing that to the side, and tossing sprints aside, and just constantly working to move work in progress items to a release ready state. After all, the manifesto says nothing about sprints. The highest priority is satisfying the customer through frequent releases.
I'm trying to come up with some clever, cynical ways to break Kanban so that I can detect ways that it might get abused. The first one that came to mind is that work may get stuck for everyone, and nothing moves anywhere, and the limiting of work is an excuse to not do anything. I'm hoping that if a daily standup is done right (David Anderson's description at http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html seems pretty good) that this shouldn't happen.
I've read through http://theagileexecutive.com/2009/05/11/john-heintz-on-the-lean-kanban-2009-conference/ and I want to go through some of the links and really start to build a strong mental model of all of the reinforcing concepts. I've had my eye on various articles on http://www.poppendieck.com/ for some time now, and I feel like it will become much more clear after reading one of their books.
But in the end, it really couldn't hurt to just try it. It seems pretty natural already to what some teams were already doing without being given any direction before.
Subscribe to:
Posts (Atom)