LSSC11-Relationship between Assumptions, Risks and Flow (delay)

I had planned to write a series of what came out of the Lean SSC 2011 conference.  However, I know that many other people will be talking about this and feel this may be of limited value.  Instead I have decided to write about some of my own insights that resulted from attending the conference.   One of the bigger ones was from a conversation initiated by Alison Vale which I then connected to a long-time running conversation between Robert Charette and myself.  Chet Richards also was involved.  Here’s what happened.

Each level in an organization wants, and must therefore see, different things.

First, one must recognize that each level in an organization (C-Level, VP, Director, Manager, Team, …) has its own motivations, concerns and fears. While these may not be opposed to each other, trying to do something at one level that will not be in the interest of a level above you – or more accurately stated:  will not appear to be in the interest of a level above you – will likely not happen.   Second, one must recognize that since each level has different motivations, they are interested in looking at different things to see if what they want is happening.   That is, not every role will be motivated by the same information or viewpoint.  This means that although one must create visibility into the process so that everyone can get aligned, the information being looked at and the perspective in which it is considered are likely to be different at each level.

Executives are interested in risk; management are interested in flow; developers are interested in assumptions. Fortunately, these are all related.

This is actually the heart of this blog.  Alison started things off by describing to me some of his thoughts about assumptions.  Hopefully I’ll get this right. An example is that Test-Driven Development is a way of minimizing assumptions.  For example, writing 200 lines of code has more assumptions built into it (that the code works) than writing 10 lines of code.  Test-Driven Development is a way of writing smaller amounts of code and validating that, in fact, the code does what it does. He also described how IDEs remove the assumptions of proper syntax by compiling the code on the fly.  I mentioned how the writing of test specifications during acceptance test-driven development is a way of minimizing assumptions about what the customer wants.

Reducing Assumptions – A Developer’s Perspective.

Thus, we can see defining test specifications for stories as a way of reducing assumptions in understanding what was intended, test-driven development as a way of reducing assumptions on the efficacy of the written code, IDEs compiling code as you type as a way of reducing assumptions about syntax, etc.

As Alison was talking, I was already reflecting on how this conversation related to a series of conversations I’d already been having with Bob Charette about risk. While I tend to think of flow and time to market, Bob tends to think of risk.  Are we building the right product? Will we run out of money before we can build it? What will our competition do? What are the chances that our quality will be too low?  Now I can translate his risk into my flow but I was actually thinking it would be better to do just the opposite – translate my flow into his risk.  Why? Because executives care more about and can understand risk.  Translating my understanding of flow into a language executives not only can understand, but want to hear, only makes sense.

I decided to find Bob – he was sitting next to Chet Richards, perfect – and dragged Alison over to tell Bob and Chet his ideas.  We had an all too short talk (Bob had to get ready for his track) about the relationship between risk and assumptions.  Pretty clear once one considers it:

Assumptions are highly related to flow since feedback can validate them.

Assumptions often live as unexplored ways things are until we provide feedback to validate them.  Sometimes we are so sure of our assumptions that when we prove them wrong, we call the action doing so an error.  For example, multiple teams that have provided means of coordinating with each other often discover errors in how they thought (assumed) they were, in fact, working together.  These “integration errors” as we call them are actually errors made much earlier in the process, but just discovered during integration. If we were consistent in our nomenclature, we’d call what we call “bugs” “test errors.”

Further Exploration Needed.

I’m not going to go into this much further.  Thought I’d mention the connection and then look to explore it on-line on a user-group.

The Real Value of the Lean Software and System Consortium Conferences

This is an example of what I have repeatedly seen at the Lean Software and Systems Conferences (as well as most of their related European ones). It is the integration of different thought processes that result in a new perspective, one more useful than before.  This has repeatedly happened for me.  The beautiful blend of sessions that make me realize I have so much to learn as well as I must challenge what I know (not just challenge those areas I think I know, but challenge even the things I know I know).  This provides the setting, the primordial soup, so to speak, of new thoughts and connections.

I have been doing conferences for 15 years – starting in ’97 with OOPSLA and C++ World.  I’ve averaged 4-5 conferences a year over that time (I now go to 6-7 a year).  The Lean SSC conferences have been unique.  They are not conferences designed to provide information and then discuss things in the hallways.  They are conferences designed to challenge our thinking, to solve some problems and to create community amongst the participants.  This is one of the reasons I both love them so much and find such great value in them.  Perhaps the difference can be summed up in that most other conferences I go to primarily to market, with learning/networking as a secondary motivation.  At the LSSC conferences, it is just the opposite. While it’s still early, I’d advise you to already start making plans for what I am sure will be the best conference of 2012 – the Lean SSC Conference in Boston – May 13-16. I hope to see you there.

Alan Shalloway

CEO, Net Objectives, Board Member Lean SSC