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... ;-)

Why I hate "Inspect and Adapt"

Because more often than not, people don’t.

They way I grew up with agile, one of the basic tenets of all agile approaches was the notion that there is no prescribed ‘right’ process, but you have to do what it right at this point in time. There even was a lengthy discussion whether the approach should be called ‘agile’ or ‘adaptive’ when the agile manifesto was created.

Now I see people ‘doing agile’ all around in manners I sometimes fail to understand. And I hear complaints that the agile stuff doesn’t really work. And more often than not, the explanation I get is along the lines of “But agile says ‘inspect and adapt’ and we adapted.”

IMHO one of the best answers to that was written by Ron Jeffries and is called We tried baseball and it Didn’t work.

And what I see quite often when I hear that teams ‘adapted’ the approach they try to use, is exactly that – they adapt without doing the inspection of the real thing first. Go ahead - read it! :)

So if you want to use the inspect and adapt approach, please make sure that you have something to inspect before you adapt it.

till next time
  Michael Mahlberg