Unlikely Heroes – Imagine

  1. Scrum Gathering 2015 – South Africa
  2. Unlikely Heroes – Imagine ← You are Here
  3. Unlikely Heroes – Empower
  4. Unlikely Heroes – Mastery


As with the other two streams, there are 7 talk slots to write about, how do I even begin?!


The solution of course, is to be picky.  So I’ll start with the afternoon of day 1, which was an all-afternoon workshop about user story mapping.  The general idea is to look at an app or website that is to be developed, examine the system (business model) behind the software and map the user’s journey through the system. The first pass is at a very high level and in a happy-day scenario, then going down into more detail – including corner cases and alternative paths through the system.  From the resulting forest of stickies on the wall, one can then get the initial product backlog for the software that is to be written & have a fairly clear sense of what should be prioritised highly.  This could be quite a useful approach for doing an exploratory sprint 0, as an alternative or addition to our currently developing vision workshop format.


I realized during this workshop that we speak of MVP and mean one thing, while our customers hear the word “product” in there and understand something quite different.  MVP is a process for testing the product owners’ assumptions by putting something “just-usable” in the user’s hands.  What our customers frequently understand by the term MVP, is that it’s the minimum thing their customers will pay for.  THAT, is in fact the MMF (Minimal Marketable Feature set). It occurred to me that some of this miscommunication can be addressed by listening for the implicit assumptions the customer is making, and calling them out explicitly.  Once that is done, we can work together to design a quick and cost-effective experiment to test the assumption.


Another highlight was at the end of day two, in the superb product owner dojo run by Pavel Dabrytski and Steve Holyer. We explored some really powerful ways for the product owner to steer the conversation with the project’s stakeholders by asking the right questions.  Also that you need to be deliberate about defining what “value” means for your product!  This is one of those questions that seem like it has to have an obvious answer until you try to answer it for some specific products.  It’s all about saving money or making money right?  Well… what if your product is Wikipedia?  What does “value” mean then? (left as an exercise for the reader)


In that same talk, Steve gave us a very quick introduction to the agile fluency model, which is a way to map your journey from just building code to becoming a full scale “holacracy”.  He highlighted that a team to becoming fluent in Agile is analogous to a person becoming fluent in a language.  There are increasing benefits every step of the way: At first, you can maybe say the words for “food” and “water” – which is very useful if you need one of those two things!  Later, there are bigger benefits as you become more fluent (maybe eventually you can start writing romantic poetry?)  The list below attempts to give you some sense of how the model works – more information can be found at http://martinfowler.com/articles/agileFluency.html

  1. Focus on Value.  This is where the team is aware of value – but not necessarily delivering value yet.
  2. Deliver Value.  Technical debt has been paid down, continuous integration & regular delivery of shippable, valuable product.
  3. Optimise value.  This is where the organization’s culture starts shifting to eliminate handoffs.
  4. Optimise for systems.  This is where the whole is managed by the whole – which you might call a holacracy.


In closing, I’ll share an article that was highlighted at one of the keynotes.  It was written in the 60’s for HBR by Frederick Hertzberg: One more time: how do you motivate your employees.  If you detect signs of suppressed exasperation in the title of the article, your perception would be quite correct.  Even in the 60’s, it seems this was a tired old subject that organizations were just not getting right.  Many organizations still are not getting this right, treating people like cogs in a machine rather than valuable individuals with intuition and all the other amazing faculties that come with being human.