Comments on Business Oriented Development: Guerrilla Kanban

Oh, hey Jason. OpenID has a way to go, or at leas...

2010-02-22T23:00:22.654-06:00

Oh, hey Jason. OpenID has a way to go, or at least blogger.com's comment engine. The same seems to happen to me to on other sites.

Good luck with your Kanban work. If you will be at the Atlanta conference, would like to chat about your experience. If not, let me know how your WIP limiting progresses.

This makes a lot of sense and appeals to Things I...

2010-02-22T20:30:24.738-06:00

This makes a lot of sense and appeals to Things I Already Know. What I need to do is show my WIP over time. I should have enough information to do this.

BTW, I'm Jason Felice on the Kanban list. Don't know why my OpenID insists on "eraserhd". :(

@TK Yes, seeing the whole is the goal. Project X i...

2010-02-19T21:10:22.258-06:00

@TK
Yes, seeing the whole is the goal. Project X is close to that given the current board. Needs Prioritized is the first state a newly discovered bug (in production) would be placed. The board could have a "releasing" state, but typically, the cards would just be removed from the board.

The important point to consider is whether your board layout will effectively show problems along the value stream as they happen.

@Brian I think localized workflows are acceptable. Some in the Kanban community use multiple boards to show this. But at some point, they still employ a big picture board that shows the entire stream from idea to cash.

@TK It really depends on the hats that you wear ...

2010-02-19T13:17:06.286-06:00

@TK

It really depends on the hats that you wear in your shop. If the earliest that you see an item is after it has been approved by a BA and laid out by an architect then your board might start at 'Needs-Prioritzed' but if you start from the requirements gathering from the customer then you will most likely care about value streams such as 'Gathering Requirements', 'Awaiting Customer Approval'. If you happen to be formal QA doing your own board then you will probably not care about value streams during development or after testing.

So I believe it depends on the intended visibility and context of the board you are on, even other teams in the same department can have differing value streams.

I see you are calling out "states" withi...

2010-02-19T12:09:03.279-06:00

I see you are calling out "states" within a development work flow as a value stream. Although this is just part of the value stream, should one look at the complete value stream from moment customer request shows up to the point of delivery and support? i.e see the whole

@eraserhd I have to concur with Derick. WIP limi...

2010-02-19T08:53:48.490-06:00

@eraserhd

I have to concur with Derick. WIP limits can be a goal for the team to work towards.

I would just add that conext is still king. Depending on your environment, you may want to have explicit WIP policies. In Project X, a hard limit for Dev work is possilbe immediately. But hard limits on the work downstream toward Release is much harder due to project constraints. But those would be areas the stakeholders should concentrate on improving.

Does that help?

@eraserhd you don't make a case for imposing ...

2010-02-18T21:04:16.765-06:00

@eraserhd

you don't make a case for imposing wip limits. trying to impose limits will just cause friction. instead, you should focus on setting goals to reduce your wip. start by having conversations about the problems that wip causes - delayed feedback and rework, etc. and continue those conversations into the benefits of reducing wip. appeal to the human sense of being overworked, of not being able to focus when too many things are going on. ask people how they feel when there's too much going on, and use that sensibility to suggest reducing the current wip. set small goals... for example, if you have 25 items currently in your system, set an initial goal of getting it down to 20 items. this is a simple goal on the outset and should be easy to get people to agree to. but the key is that you never enforce those limits... ever. instead you measure how often you are able to meet that goal. you won't meet it initially - expect that. what you will do, instead, is begin the discussions with your team members to identify the things that prevent you from reaching that goal. then you start to work on fixing those things. over time, you will reach the goal more and more often. when you begin to reach the current goal on a very consistent basis (say, 25 out of 26 working days a month), then you set a new goal of a little lower and you start the process again

Excellent post. I've been a Guerilla kanbanne...

2010-02-18T20:30:04.371-06:00

Excellent post. I've been a Guerilla kanbanner for about five months with much luck so far. It works!

A few things to point out...

1. The visibility of the kanban board is important. It starts discussions, makes problems visible to managers, and it _decouples the information from your opinion on what to do about it_. My backlog is now entirely managed by management types... before it was a mess because I've got five teams which feed my input queue and they wouldn't coordinate. This all happened because it became really apparent there was a problem.

2. Here is the question I'm currently struggling with... how do you make the case for imposing WIP limits? Say you have a limit, and you hit the limit, but you can't send your finished work to QA because they have their limit, how can you make the case and tell them you can't start on the next thing?

Indeed. Great post Troy. thank you. I really think...

2010-02-18T09:33:49.321-06:00

Indeed. Great post Troy. thank you. I really think strategies / tactics such as these if used properly will help move Kanban to the next level of adoption, as I think the hardest part, as with most things, is starting.

Very nice. Guerilla Kanban may just start the cult...

2010-02-17T00:17:47.496-06:00

Very nice. Guerilla Kanban may just start the cultural change needed in some disfunctional shops.