How to find the cards

When teams turn towards kanban as a process control method I often see people standing in front of the board asking “Where the #*$+%+ is the card with task #12345?“

Is that a problem of physical boards?

One could easily argue that this is because it is much harder to find a card on a board than it is by using an electronic search engine.
And I guess that is true.
But that is not the problem here. In my opinion the real problem here is that the board is not yet used as a tool but only as a reporting system.

If you use the board as a tool you never have to search a card

If you use the board as a tool to drive your work it is hard to image a situation where it would be necessary to really search a card. Since you would be working on one, and only one topic at a time you would know exactly where the card you’re working on right now is. And when it’s finished you would move it to the respective «done» column and select a new card on the board according to the station you're working on and the prioritized cards on the board.
In most cases that card would be the topmost card in the «done» sub-column upstream from the one you're going to work in. And once you select this card as your new item to work on, you would move it in the «doing» column of your selected station (e.g. development).
Since this is the card you are working on (perhaps together with somebody else, but in your responsibility) that card won't move on it's own. So you know exactly where it is. So once you're finished with it you would move it to the respective «done» column... (see above)
Rinse and repeat.
No need to search for a card.
Unless you let your work be driven by another system – then of course the question arises “which is the leading system?”

till next time
  Michael Mahlberg

We don't do sprints any more ...

... we do iterations instead.

A couple of month ago a client of mine started with an effort to work in an agile way – inspired by scrum, as far as possible.

One of the first things we agreed upon was to avoid scrum-speak whenever possible. For example we don't (yet) deliver (potentially) working software to the end-user at every iteration. So we do not call the iteration a sprint.

There are many other things –like not having a truly cross-functional team etc.– that would make it a plain lie to say that we are using scrum in this project, so we don't call it scrum. We don't call the process-coach a scrum master and so on.

The surprising by-product: better communication

The most fascinating thing here for me was the effect the wording had on upper management. "Cancelling a sprint because the sprint-goal is no longer attainable" is somewhat hard to discuss with people outside the agile world without some in-depth discussion of the terms. "It makes no sense to continue with this iteration because the thing we wanted to achieve with it is no longer achievable" is much easier to grasp.
[Language remark: And this was German by the way – for those who know the language "Wir müssen den Sprint cancelln, weil wir das Sprint-Goal nicht erreichen" is way harder to understand for outsiders than "Wir brechen die Iteration ab, weil das Iterations-Ziel unerreichbar geworden ist"]

There is an adage from Jerry Weinberg wich comes to my mind here:

«If you call the tail of a dog a leg – How many legs does the dog have? Still only four – just calling the tail a leg doesn't make it a leg!»

So, how about you? Do you do Sprints? Do you do Scrum? Do you have a Product Owner? Really?

Why not try an experiment? Instead of using vaguely fitting terms from a process framework, start using terms that describe what you’re doing in “layman's terms” and see what happens.

You might spark a whole new conversation.

till next time
  Michael Mahlberg