This Wednesday we held the third event of the Budapest Lean and Kanban Meetup Group, which was excellent in my point of view, and we had great discussions.
In the beginning we collected the following topics:
-
How to handle parked or stalled items in the workflow (8)
-
How to help people to get rid of requirement specifications (7)
-
Is it possible to implement a pure top-down pure Kanban system? (1)
-
Taiichi Ohno’s Toyota Production System: Beyond Large-Scale Production (9)
-
Balance between improvements and production code (11)
Everybody had three votes, and we voted on each topic in a round-robin fashion. The received votes are given in brackets. We started with the most voted topic, then we continued with the second and closed the evening with the third one.
Balance between improvements and production code
A couple of the participants had a discussion prior to the event about the amount of improvements done by a team, while being also committed to deliver features requested by their Product Owner. They started to implement previously collected improvements, because the test hardware required for the implementation became available. On the other hand, they also committed to deliver certain features. Unfortunately, they spent too much time on improvements so that they had no time finishing those features. Additionally, they realised this problem too late (they didn’t have a Kanban board, which could have shown the stalled state of the features all the time).
The discussion went a bit off-topic, but we continued anyway, because the group was interested in it. We had a couple of pros and cons about having improvements in the Product Backlog and how Product Owners are supposed to handle them.
After a certain time it turned out that there was a reason why the team started to work on a larger amount of improvements instead of working on them continuously: the hardware they were supposed to use for testing wasn’t available all the time, or its availability wasn’t predictable. However, a while back the availability had been predictable when the scheduling tool of the test system was working.
We closed this discussion with the idea that the team should re-establish the previously working scheduling system for that particular test hardware, and in general it is better to do the improvements more continuously than in a large batch at a certain time.
Toyota Production System: Beyond Large-Scale Production by Taiichi Ohno
@csapoz told us a bit about Taiichi Ohno’s TPS book, how Lean has emerged, how Toyota had to adapt to the financial situation of the fifties. In was an interesting introduction, and it put us back to on-topic.
Parked or stalled items in the workflow
One of us told an interesting scenario about the usage of the parking lots at his current team. They have a column called Reproduction/mail for those items which are under discussion with its reporter, and while the team is waiting for a response, the item goes to the parking lot.
So far so good, but the team member who worked on that particular item moves on, and when the response arrives, she cannot work on it because she is busy with something else. So the work accumulates in the parking lot. This wasn’t acceptable for the team so they decided to get rid of the parking lot, but now the work accumulates in the very same column but under the avatars of the team members.
The first question was a bit provocative: is this a Kanban-related problem, or a problem with the attitude of the team? It turned out that they are trying to solve the problem, and it is a reoccurring topic at their retrospective meetings.
There was an idea on how to solve the stalling situation: instead of collecting items in the Reproduction/mail column, the idea suggests to put the stalled item to the bottom of the Queue, and when it reaches the top again, the team can take it and check whether the reporter did something with the item.
There were great improvement proposals for the item circulation idea:
-
it is not necessary to put the stalled item to the bottom of the Queue, it can be put, for example, in the middle when it is a high priority issue
-
it is worth measuring how much cycles an item does in the system. With this approach the team could locate the problematic items, those that are stalled all the time
-
when an item has been in the system for too long, get rid of it
-
be cautious when putting the item back to the Queue - what happens if the reporter *responds within an hour, but it will take 2 days for item to reach the top of the *Queue? the reporter won’t be very happy
-
the team will need somebody who can prioritize the Queue, maybe several times a day
Plus one(s)
At the end we started to talk about Kanban and Kanban boards for development, not just for maintenance. I talked a bit about our current Kanban board *and how we use *Kanban for development, but we agreed that next time we are going to draw a nice Kanban board for development together.
When we were talking about Queues, it turned out that writing good items is not trivial, so we also agreed that besides the board drawing, we’ll talk about how to write Kanban items effectively.
It was a great night, thanks everyone for coming and participating. See you next time.
comments powered by Disqus