H

Our Blogs  

 

Please, not more of the same (2 of 3)

By Dave Snowden  ·  September 21, 2014  ·  Reflections

I had to get up at 0400 this morning to make the morning flight for Berlin.  The reason was that I had an indulgent thirty hour period which stated on Friday night with a Blues match at the Arms Park, followed yesterday by a walk on Pen-y-fan followed by a performance of William Tell by the WNO in Cardiff.  OK we lost the match, but with considerable improvement over the previous week and it will take time for the new coach and players to jell.   I also got to take Kim Ballestrin to her first ever Rugby match.  I'd driven her down from our software design session showing off the length of Wales in the process via the glories of the A470 with the odd mountain road diversion.   The walk was good, although not as good as y Garn!   The opera was brilliant, a glorious peon to freedom and I will try and get to it again.  So I don't deserve sympathy for the early rise.

It's always a pleasure to return to Berlin and thanks to the rush it was my first cup of coffee in over 24 hours which is a very long time.  On the flight I was thinking through the opening keynote I have to give tomorrow at the Scrum Global Gathering. I argued in yesterday's post that more of the same would not work.  Nearly everything listed in the McKinsey report referenced yesterday as a solution is not an argument for radical rethinking of how we do things, although their analysis (which is good) demands it.  Also some of it may be plain wrong and I will deal with that tomorrow when I plan to slay some sacred cows, including said recommendations.

So what do we do differently?

Key I think is to getting things right earlier in the cycle and to avoid the linear process by which strategic objectives are distilled to needs, requirements and then deliveries.   Now I have written about this before in a series of posts on scaling.  The picture here is drawn from those posts which provide more of the background.  The normal linear process takes us from strategy defined at a high level to a series of needs that are then converted into requirements, matched to capabilities and delivered.   I'm talking about software here but the ideas are more generally applicable.

Every now and then we get capabilities that move directly into strategy.  This is common in the fad cycle and the marketing hype such as SAFe and oh so many other examples of group think, blindly following the pack without any evidence of sustainable practice.

The approach I will outline tomorrow will aim to build to this and a very different argument based on complexity thinking.   That says at its heart that we have to abandon linear or aggregative approaches as they are a priori inappropriate for a complex space.  Instead we need to identify patterns that can emerge from the interaction of the three elements identified above:

  1. The strategic needs, goals and frustrations of those who direct the organisation
  2. The needs of those who have to execute those goals (and who need to influence them) on a day to day basis
  3. The capabilities of the wider organisation and technology in general.

Now capturing that is something we can do with SenseMaker® using some of the principles of distributed ethnography that Cognitive Edge was established to create.  With three systems with polymorphic signifier structures we can allow continuous capture of day to day observations, capabilities, frustrations and opportunities from multiple communities, then bring those together to create cluster patterns that identify areas of investigation (or in the case of IT prototype development) that are informed at multiple levels.  Top down requirements are always bound by the limits of past potential and frustration rarely future plausibilities.   By presenting novel patterns we create an evidence base that allows small safe-to-fail investments to enable serendipitous or exaptive novelty.   

This is important as in most cases people would have needs if they already understood the capabilities and strategic goals might change.   All three are interdependent, co-dependent and co-evolutionary.   We need to take a non-linear approach to understanding that before we move into conventional projects (in Agile that means SCRUM).   Of that, more tomorrow after my presentation along with the the sacred cow slaughter.