Our Detective's Blackboard

My colleague Attila and I had an interesting discussion several days ago:

- Zsolt, I feel that sometimes we are missing the big picture.
- That’s not cool, and it may explain the high number of work items moved back.
- Maybe, but can we do planning together again? I miss it.
- Sure we can, but no regular planning meetings, right?
- Of course not.

As my friend @keksz_i pointed out, regular planning meetings aren’t that effective and I’m also not a great fan of them: talking to the product owner is a brilliant idea, but the traditional task breakdown is just a tremendous waste of time. After our discussion, it was clear to us that we had to bring the planning back, but we needed something new, something effective. So we came up with the following detective’s blackboard for our next feature:

It is drawn on a large piece of paper and hangs on the wall right next to our Kanban board. It has all the information we need in order to do our work: the big picture, how our user interfaces will look like and how they will communicate with other parts of the application. Additionally, we also have work items, prioritisation, test plan and estimation.

Let’s take a couple of steps back and see how the blackboard above has emerged. First, we had to realize that something wasn’t going well - see the introductory discussion and our “moving work items back rate”. Although I don’t like moving items back, I had to realize that it happens no matter what I do or who I’m working with, and while it keeps happening I have to do two things:

  • count the occasions of moving work items back

  • discuss the reasons, and deal with the consequences

In our case, the majority of the work items were turned back at the validation phase, because we implemented things that missed small or larger details. Attila was right, the big picture was missing.

So the second thing was to draw the big picture. We are software engineers so we did the engineering part first and left the organisational part for later. It could wait.

When it was done, and together we’ve discussed it thoroughly by adding notes, drawings of the user interfaces and TODO lists to the picture, it was time to organise how we were going to do the implementation, testing and deployment of the feature.

The red circles mark work items. They aren’t MMFs, MVPs or features on purpose, they are just work items we are comfortable with and confident that we can implement. The cards hold unique identifiers which serve as prioritisation as well. The major number gives the global order and minor number gives the order between equal major numbers. So the order is: 1, 2.1, 2.2, 2.3, 3.1, 3.2, 4.

Finally but not least, every circle has either an AUTO or a MANUAL tag, which defines whether we’ll write automatic test cases for the work item or we’ll test it manually. The number following the tag is the estimated time to complete the work item.

After the discussion, the blackboard ended up next to our Kanban board, the new work items went to the Queue column, and the estimations were registered in redmine. There is one important thing left to mention, which is that we put a Planning column next to the Queue. The intention is to talk more about the work items in this phase, because we had skipped the implementation details while drawing the blackboard.

That’s it. Our daily way of working changed a bit thanks to the blackboard, because we have more discussions in front of it, and less in front of the Kanban board. Furthermore, we have regular design discussions about the upcoming work items and we do planning when necessary, so we also reduce waste. The overall feedback is quite promising up to now, so we’ll definitely do the very same thing with our next feature.

comments powered by Disqus