Comments on: The Kanban Story: Throwing Sticky Notes Out http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html Dealing with software projects in real life Fri, 10 Feb 2012 19:07:34 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Simonas http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html#comment-25576 Simonas Mon, 03 Jan 2011 18:29:39 +0000 http://blog.brodzinski.com/?p=1499#comment-25576 To Joshua. It is always more effective to ask from people directly what you want instead of making complex systems. Ask to improve requirements when you get them right away. Tell what you need. Remember, that it is not about Them to deliver requirements. It is about Them and _You_ to discover requirements. Most likely you know technical part better than Them, don't you? If you want to create multifunctional teams, then sell it to Them (if that's the problem?). Find Their problem and show how can you solve it with cross-functional team. Ask Them to let experiment or do it yourself, but then remember to sell it to other party :) Now you will need to discover Other Party problems to sell :) To Joshua. It is always more effective to ask from people directly what you want instead of making complex systems. Ask to improve requirements when you get them right away. Tell what you need. Remember, that it is not about Them to deliver requirements. It is about Them and _You_ to discover requirements. Most likely you know technical part better than Them, don’t you?
If you want to create multifunctional teams, then sell it to Them (if that’s the problem?). Find Their problem and show how can you solve it with cross-functional team. Ask Them to let experiment or do it yourself, but then remember to sell it to other party :) Now you will need to discover Other Party problems to sell :)

]]> By: Joshua Lewis http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html#comment-2935 Joshua Lewis Tue, 19 Jan 2010 12:35:38 +0000 http://blog.brodzinski.com/?p=1499#comment-2935 There is a discussion on 'status tags' for cards on a Kanban Board here: http://www.xqa.com.ar/visualmanagement/2010/01/status-tags-revisited/ There is a discussion on ‘status tags’ for cards on a Kanban Board here: http://www.xqa.com.ar/visualmanagement/2010/01/status-tags-revisited/

]]> By: Joshua Lewis http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html#comment-2884 Joshua Lewis Thu, 14 Jan 2010 09:44:04 +0000 http://blog.brodzinski.com/?p=1499#comment-2884 Great, I will try. Unfortunately, I've again lost momentum with the blog again, will try get it back on track soon. Also, the environment is such that it takes a while to implement changes, and I'm planning on limiting my adoption WIP (with a dynamically prioritised backlog ;) ) so feedback might take a while. Thanks for reading it and commenting. Great, I will try.
Unfortunately, I’ve again lost momentum with the blog again, will try get it back on track soon.

Also, the environment is such that it takes a while to implement changes, and I’m planning on limiting my adoption WIP (with a dynamically prioritised backlog ;) ) so feedback might take a while.

Thanks for reading it and commenting.

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html#comment-2866 Pawel Brodzinski Wed, 13 Jan 2010 09:57:29 +0000 http://blog.brodzinski.com/?p=1499#comment-2866 About the board being adjusted to the process and not vice versa - fully agree. Write an update from time to time on your blog how things are going, what works and what doesn't. I'm looking forward to read about that. About the board being adjusted to the process and not vice versa – fully agree.

Write an update from time to time on your blog how things are going, what works and what doesn’t. I’m looking forward to read about that.

]]> By: Joshua Lewis http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html#comment-2864 Joshua Lewis Wed, 13 Jan 2010 09:48:30 +0000 http://blog.brodzinski.com/?p=1499#comment-2864 Sure, there is that risk. I think a more fundamental issue exists upstream though, i.e. issues with specifications/requirements. I think it'll be easier to change that before trying to change the quality of development work (which will probably be a large and difficult change here). Most sources I've read say structure the board to the process to begin with, not vice versa. Limiting WIP and creating a proper pull system is probably a multi-year goal in this environment, but I'm also trying to find easy wins and start the process with baby steps. The biggest barrier in my opinion is education and 'stubbornness' Sure, there is that risk.
I think a more fundamental issue exists upstream though, i.e. issues with specifications/requirements.

I think it’ll be easier to change that before trying to change the quality of development work (which will probably be a large and difficult change here).

Most sources I’ve read say structure the board to the process to begin with, not vice versa. Limiting WIP and creating a proper pull system is probably a multi-year goal in this environment, but I’m also trying to find easy wins and start the process with baby steps.

The biggest barrier in my opinion is education and ‘stubbornness’

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html#comment-2862 Pawel Brodzinski Wed, 13 Jan 2010 09:18:24 +0000 http://blog.brodzinski.com/?p=1499#comment-2862 You're trying to do pretty difficult things. I thing changing people approach from focusing on completing only their part of the task and instantly forgetting about the rest to collective responsibility for delivery is one of the hardest thing in transition to agile approaches. Anyway, what you think of does make sense when I think about it. It probably won't do very good job in terms of limiting work in progress but at least there will be big visual showing which team actually owns the task. That should add motivation to push tasks further as soon as possible to avoid big stacks of started work. On the other hand there's risk of low-quality work (e.g. let's just apply dirty fixes and push the task back to tests so we have less tasks here). You’re trying to do pretty difficult things. I thing changing people approach from focusing on completing only their part of the task and instantly forgetting about the rest to collective responsibility for delivery is one of the hardest thing in transition to agile approaches.

Anyway, what you think of does make sense when I think about it. It probably won’t do very good job in terms of limiting work in progress but at least there will be big visual showing which team actually owns the task. That should add motivation to push tasks further as soon as possible to avoid big stacks of started work.

On the other hand there’s risk of low-quality work (e.g. let’s just apply dirty fixes and push the task back to tests so we have less tasks here).

]]> By: Joshua Lewis http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html#comment-2860 Joshua Lewis Wed, 13 Jan 2010 08:29:30 +0000 http://blog.brodzinski.com/?p=1499#comment-2860 You describe the ideal situation, i.e. a cross-functional team focused on delivery, not task. As you mention, that would be difficult in my environment, since the teams are quite separate and quite silo'ed. In my earlier comment, I mentioned that I want to make these bounces explicit, in order to prove something about the system. Maybe the proof I'm seeking will be good motivation to move towards cross-functional teams, i.e. if I can prove that this bouncing is a problem, one of the possible solutions will be cross-functional teams. Again, in my first comment, I did note that my board won't be a pure Kanban board. We will not start off with WIP limits. To answer your question, yes, we will push cards backwards in the system. Again, I'm trying to expose problems such as 'what is done', since that concept isn't really apparent in the environment. Hopefully we can realise the problem by tracking the amount of reword we're having to do (both pre- and post-production). Also, when a card bounces back from the QA team, it will interrupt whatever is being worked on right now. I've written some thoughts on rework and interruptions in this blog post: http://joshilewis.wordpress.com/2009/11/16/jidoka-and-multi-tasking/ You describe the ideal situation, i.e. a cross-functional team focused on delivery, not task. As you mention, that would be difficult in my environment, since the teams are quite separate and quite silo’ed.

In my earlier comment, I mentioned that I want to make these bounces explicit, in order to prove something about the system. Maybe the proof I’m seeking will be good motivation to move towards cross-functional teams, i.e. if I can prove that this bouncing is a problem, one of the possible solutions will be cross-functional teams.

Again, in my first comment, I did note that my board won’t be a pure Kanban board. We will not start off with WIP limits. To answer your question, yes, we will push cards backwards in the system.

Again, I’m trying to expose problems such as ‘what is done’, since that concept isn’t really apparent in the environment. Hopefully we can realise the problem by tracking the amount of reword we’re having to do (both pre- and post-production).

Also, when a card bounces back from the QA team, it will interrupt whatever is being worked on right now. I’ve written some thoughts on rework and interruptions in this blog post: http://joshilewis.wordpress.com/2009/11/16/jidoka-and-multi-tasking/

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html#comment-2849 Pawel Brodzinski Tue, 12 Jan 2010 12:37:30 +0000 http://blog.brodzinski.com/?p=1499#comment-2849 That's another thing we do the other way around. We don't 'bounce' sticky notes between developers and QA. I'd say we have some kind of collective ownership over features. Of course when a feature is tested leading role goes to QA guy but he won't fix bugs or something. It's role of everyone to push cards further to the right side of the board. Bouncing cards between two sub-teams can be a bit counterproductive. I don't know whether you push cards on the board between testing and fixing stages back and forth but if that is so it can bring some issues with keeping the work under limits. Having said that I'm aware that introducing 'collective ownership' can be damn hard if people aren't used to work this way and they expect it is clearly stated which tasks are theirs and which are not. Most of the time revolution in this area is way worse idea than evolution. That’s another thing we do the other way around. We don’t ‘bounce’ sticky notes between developers and QA. I’d say we have some kind of collective ownership over features. Of course when a feature is tested leading role goes to QA guy but he won’t fix bugs or something. It’s role of everyone to push cards further to the right side of the board.

Bouncing cards between two sub-teams can be a bit counterproductive. I don’t know whether you push cards on the board between testing and fixing stages back and forth but if that is so it can bring some issues with keeping the work under limits.

Having said that I’m aware that introducing ‘collective ownership’ can be damn hard if people aren’t used to work this way and they expect it is clearly stated which tasks are theirs and which are not. Most of the time revolution in this area is way worse idea than evolution.

]]> By: Joshua Lewis http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html#comment-2848 Joshua Lewis Tue, 12 Jan 2010 12:22:13 +0000 http://blog.brodzinski.com/?p=1499#comment-2848 Those are good pitfalls, thanks for pointing them out. I think the main reason I want to track this is to prove my suspicion that there's a lack in the way requirements are formulated/documented/communicated. I.e. to motivate why we should move to some other system (maybe something like BDD or TDD), or to have closer relationships between development and the customer. I want to make this 'back-and-forth' visible and explicit (which is one of the aims of the Kanban board), so that I can point it out. I plan to implement the same kind of tracking mechanism for cards bouncing back and forth between dev and qa teams, again to make the fact explicit and to measure it (i.e. x 'bounces' per card). Those are good pitfalls, thanks for pointing them out.

I think the main reason I want to track this is to prove my suspicion that there’s a lack in the way requirements are formulated/documented/communicated. I.e. to motivate why we should move to some other system (maybe something like BDD or TDD), or to have closer relationships between development and the customer.

I want to make this ‘back-and-forth’ visible and explicit (which is one of the aims of the Kanban board), so that I can point it out.

I plan to implement the same kind of tracking mechanism for cards bouncing back and forth between dev and qa teams, again to make the fact explicit and to measure it (i.e. x ‘bounces’ per card).

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2010/01/kanban-story-throwing-sticky-notes-out.html#comment-2844 Pawel Brodzinski Tue, 12 Jan 2010 08:31:13 +0000 http://blog.brodzinski.com/?p=1499#comment-2844 That's an interesting idea. However you may want to consider two things: - Effort needed to find the right sticky note and add another one to it every time a bug appears. It will stack up to significant amount of time and the only thing you get is visualizing which feature brought the most problems. - Problems with connecting specific bugs with specific features (sticky notes). There are some bugs which can be hardly ascribed to a specific functionality. For bugs we just use bug tracker and even though we don't chain bugs with MMFs it it clearly seen whenever we happen to have lower-quality feature. The other thing is finding out why it is so which almost always leads to some objective difficulties (e.g. complex design etc). That’s an interesting idea. However you may want to consider two things:

- Effort needed to find the right sticky note and add another one to it every time a bug appears. It will stack up to significant amount of time and the only thing you get is visualizing which feature brought the most problems.

- Problems with connecting specific bugs with specific features (sticky notes). There are some bugs which can be hardly ascribed to a specific functionality.

For bugs we just use bug tracker and even though we don’t chain bugs with MMFs it it clearly seen whenever we happen to have lower-quality feature. The other thing is finding out why it is so which almost always leads to some objective difficulties (e.g. complex design etc).

]]>