again on the story wall… the hold zone

Yesterday I’ve got a nice comment from JK on the previous blog post about the story wall and we talked a bit about our story walls (he’s a the same client but on a different project).

I didn’t realize we both have an hold zone at the bottom of the story wall, for blocked stories/stories on hold.

He pointed out and I totally agree that that is the most dangerous thing you can do.

Stories are prioritized top down, putting them down there it’s like saying that they have no value, low priority.
That horizontal section is also so low that you almost don’t see them.

At that point I’ve realized that we actually had that section, I’m still shocked I didn’t remove it earlier in the project!

So, what is JK doing in his team now? He keeps the stories on hold on the same position as they were, with a visible block-sticker on them.

With that he is avoiding:

a) the mistake of forgetting a story
b) the mistake of change the priority of a story for no reason

He’s achieving more visibility on the blockers in the project and with few blockers on a lane it will be hard to pull more stories there, so you will be naturally forced to solve those blocking issues. (a bit of TOC always helps)

on putting tasks on the story wall

Somehow it happened, the wall was full of cards, literally there was no more space for adding anything anymore. I didn’t count them but probably we had more cards this week than in the last 2/3 iterations summed up together.

I went mad, I started grouping them. Then I realized why I hated so much all those cards sticked on the wall: it seemed impossible to make it.

Putting tasks on the story wall is a very dangerous activity, basically you loose in the blink of an eye all your knowledge on the team work load and on the team todo and done.

A card is like a tile, the lanes on the wall have fixed size, it’s a constrain, it’s a choice, you cannot change the size of the smallest story while the project is ongoing, you will loose track of what’s going on.

Extending this then I thought about our bigger story cards, we are currently using three sizes, 1 story point (S), 2 story points (M), 4 story points (L).

In theory you may try having three different sizes of paper cards, probably in that way you will better understand the load on the wall, or even better try to split those huge cards in smaller ones, as much as possible (always good).

Putting tasks on the story wall using the same card format/color as stories is seriously dangerous, use a dedicated swim lane, group them or write a card that contains similar tasks all together.

Kanban with Pomodoro, it’s like spaghetti with sushi but it might work

I’ve read a couple of tweets today (demonstrating that Twitter perhaps sometimes makes sense)  and I’m aggregating them here:

Jason Yip twitted a link to this short, clever blog post from Matt Wynne defining kanban:

• There are no iterations: only now. Work at a pace you can truly sustain.
• Done means it is in the user’s hands. Nothing less.
• Limit the Work in Progress. This forces you to get things done, or you’ll have nothing else to do.
• Get better all the time. Keep tuning your process and tools to fit the way you need to work today – make kaizen a culture, not an event. Everyone is responsible.
• Decide with data. Collect the data you need in time to make responsible decisions.

What scares me is the lack of iterations in the Kanban system, how can you keep the focus high on the team?

Just few minutes earlier Henrikk Niberg was twitting:

Ouch, Kanban + Pomodoro hurts. Tells you exactly how inefficient and behind schedule you are, and why. Pain leads to learning…

What’s scares me about the pomodoro is the too fined grained knowledge of what’s going on, with the big risk of introducing waste in the process… And its rigidity…

It seems that a lot of people around the world are now using those two techniques, anybody has some real experience of using them together in a project?