Sunday, February 25, 2018

What happens left of the Scrum-board?

In the early days of Agile, Agile was very much about customer collaboration and concepts like the on-site customer were at the core of Agile. Nowadays, most on-site customers (actually a term from eXtreme Programming) are some derivative of Scrum’s Product Owners and most instances I have seen are far from the role Ken Schwaber and Mike Beedle described in their seminal work on Scrum in 2002.

Things have changed over the years, and nowadays a product owner (PO) in many places, especially at enterprise scale, is someone who devotes ‘a couple of hours’ each week to support ‘some team’. And even though this is definitely an anti-pattern from my point of view, it still is a reality we have to deal with.

The Agile Manifesto states quite clearly that “Business people and developers must work together daily throughout the project.” (4th principle) and one the biggest benefits of agile approaches in my experience is that they enable projects to start developing (and delivering!) before “all” the requirements are discovered. A huge part of this approach has to do with the fact that the whole team works on requirement discovery and the honing of the product vision.

But those teams are rare.

And while process-frameworks like Scrum – and the secondary literature around it – provide a lot of helpful guidance on how to deliver the solution there is very little said about the process of requirements discovery.

So I would like to challenge you to a little experiment.

  • Have a board “left of the board”
    • Instead of just having a backlog and backlog refinement meetings where requirements magically appear try to build a board for this part of your process as well!
    • Have just a few columns like “idea”, “described”, “accepted”, and “ready for planning” – whatever fits the real way of work at your place.
    • And here is another idea: Unlike on the Scrum board, perhaps here it is not necessary for all items to reach the stage - perhaps it is good if some ‘die’ on their way to the iteration planning.
    • And then observe... What happens on this board?
      • Do items ‘starve’ in some states?
      • Are there items with different speeds?
      • how many items ’make it’ to the next stage?

Who knows - you might learn a thing or two...

till next time
  Michael Mahlberg

P.S.: Inspired by Discovery Kanban of course... ;-)

No comments: