Tag Archives: safety

Lean Enterprise Presentation by Barry O’Reilly and Gary O’Brien of Thoughtworks

We witnessed a short and sharp presentation on Lean Enterprise: Adopting Continuous Delivery, DevOps, and Lean Startup at Scale by Barry O’Reilly and Gary O’Brien.  It was a bit of a plug for the new book.  Quite a good talk but I fear the audience didn’t have enough of the heavy hitters in town for it to make an impact. I mean Government Ministers, CEOs, Directors. Preaching to the converted.  Well we will all try our best at the level we are at.  The groundswell is building I hope.

Gary Barber did a great illustration of the evening’s events:

LeanEnterprise

https://www.flickr.com/photos/cannedtuna/14092742843/

The talk was essentially about bringing Lean Startup and other Agile and Lean concepts into the boardroom.  Here’s my recollection of the presentation with some opinions and interpretations, experiences interspersed and links to my other content.  Admittedly some of this new as well so I try and relate it back to what I know and maybe, hopefully, generate positive feedback to increase mine and other’s knowledge .

Getting to the Right Thing Quicker

Essentially we should be getting to the right thing quicker.  Us in the Agile space have been working in the ‘Sandwich’ where by delivery is stuck between two very thick inception and delivery phases.   The inception phase is the largest waste with much theorizing instead of experimentation and collaboration and top down command and control.  What we need is a new organisational design – something that has been talked about on the fringes but seems to be gaining some traction.

Change the Design Means Creating Safety

So the new design needs to be adaptive and resilient.  To achieve this fear needs to be driven out and an environment of safety should be created.  This idea of safety is gaining more and more discussion.  The Japanese called it Anzen and Josh Kerievsky has made it his next focus insofar as software delivery is concerned.   Governance changes completely.  Instead is contracts which are laden with many clauses, this calls for complete transparency and implies greater collaboration.  Less adherence to contract and process and more to the end result, that is customer value!  Customers cannot and should not value contract adherence and process driven metrics.  The example of GOV.UK is an example others are looking to.

Traditional Process is W.R.O.N.G.

So, you may not have noticed but something startling has occurred in the last 50 years.  87% of Fortune 500 companies are gone.  If this is something you find acceptable then stop reading NOW!  If your values include long lived, purposeful and humane then this is more for you.

For us in I.T. with been managed as a cost centre.  A cost engenders a mindset of cost reduction.  But the successful organisations going forward value IT as a strategic capability.  Therefore this is something used to increase competitive advantage or value creation.

Creating value needs to factor in observation and adaptation.  This looks like Demings PDCA cycle.  Most organisations don’t explicitly include Check and Act, only cycling on Plan and Do and not reacting to feedback is a coherent manner or not all.

PDCS-Lean-Enpetrise-Talk

 

Dangerous Mindsets Persist

It seems like common sense.  But the excuses are often the same.  “I’m too Busy’, ‘It’s too Complicated’.  But we can see those who reject these mindsets are succeeding.  And just to prove it we have the case study of GOV.UK, the all inclusive website for the public in the UK which began with startup principles with only a team of 6 people and is now grown organically to 600 people via proving up concepts at a small cost rather than expensive feasibility, discovery and planning phases that aren’t nimble enough or reject new information inputs.

Budgets Create Opaque Organisations

The annual budget cycle does not promote transparency.  Budgets are allocated and each group will guard them.  It’s not safe to give up your budget when you don’t need it.  Your spend it to ensure your retain your budget.

This is an instance of not providing safety.  It’s not safe to give up your budget for another area that may need it.  This creates the gaming organisation and management by accountancy rather than the ultimate goal of customer value.  By  creating safety this begets transparency and this will eliminate duplication.  Therefore reallocation of capital can occur and therefore the most efficient use of that capital.

Safety Creates Positive Behaviour

Creating openness and transparency results in extraordinary changes in behaviour.  Instead of hoarding allocated budget, the unnamed company mentioned as an example during the talk, had a director return $18 million back to be reallocated to the next most important item on the backlog.

Agile and Lean Tools Operate at the Board Level

Directors and/or members of the board are speaking more often generating feedback and sharing learning’s.  They apply rapid estimation techniques based on relative sizing (Planning Poker anyone) to size up and value capabilities they think they need.  They have built up an intimate understanding of their teams abilities over a period of months to be able to spend relative small amounts of time on this task.

The progression to actually trying to development these capabilities.  This requires some more agility.  Without going into too much detail or specifics the following formula is utilized.  These terms should be familiar to those will versed in Agile and Lean:

WSJF = (Customer Value + Cost of Delay + Risk of Opportunity) / Job Size

WSJF is the weighted shortest job first.  A simple way to prioritize.  Job Size is the relative measure and is not time based (see my previous article).   The Job Size cannot be so large that important feedback cannot be gained.  We need to get feedback to be able to pivot and cancel the project at minimal cost or continue on, reacting to that feedback and continue to fund and build that capability.

We should be able to ask the question – ship or not.  This is a key agile concept captured through several abbreviations like MVP, MUST, MMF, PSI.  The graph below reminds me of the stacked pareto that Jeff Sutherland talks about in mentioned in my Product Owner article.  Kind a like that one better.

LeanValue

 

Some Nuts and Bolts

  • Avoid the CAPEX/OPEX dichotomy to drive decision making.  It’s all directed to customer value so it’s all the same. (admittedly this may be an oversimplification, but I found this article from Dan Greening interesting)
  • Stop Pushing as this generates more cost.  Pull systems work best and don’t overload.
  • Use the true meaning of earned value.  Value delivered to the customer.
  • Value is a Yes/No question.  It’s unequivocal.
  • But value is a qualitative measure as well.  Develop new metrics.  A great example is the Love Metric.  How much do the customers love the product.
  • Accept small losses to get the big win
  • Validate with Evidence!
  • Create Long Lived Teams, Cross Pollinate Knowledge – This can halve the Cost of Delivery!
  • Leave time to innovate. It was described as horizon 3 in the presentation. I just call it a component of slack which I wrote about here.

More Big Ticket Takeaways – Go and See

Ignore the meetings just and go and see for yourself.    This means eliminating the hierarchy, a transformation from a Hierarchy Aligned organisation to a Value Aligned organisation.

See what is really happening and make it visible.  Map your value stream and see what the components of delivery of a product contains.

Measure the value and have a systems approach to improvement.  Measurements occur at team levels and should factor in the entire system not just your sphere of influence. That is eliminating the gaming culture.

Factor in time for innovation.

And as GOV.UK shows – start small!

Advertisements

Is Age an Issue with Agile and Lean Improvements

This past Monday we were treated to a fantastic talk from Joakim Sunden who is an Agile Coach visiting from Spotify.  There were many great talk aways from the talk which you can read about here in the article Scaling Agile at Spotify.

The article talks about the scaling model at Spotify from Squads -> Chapters -> Tribes -> Guilds (not strict linear and hard boundaries).  All great stuff, however a question from the audience got me interested.

The question from the audience was something along the lines: ‘How old are the people at Spotify?’

This drew a pause from Joakim, not really expecting the question I suspect.   He drew breath and said that they we all younger than himself.  Now Joakim is not old, in fact I’m older, and he wears a funky hat, tshirt and sneakers.  He looks younger than he is, he later revealed his age and it was 39.

But this has got me thinking.  Why would someone ask a question like that?  Is it because it’s because as we age we become less amenable to change.  I was shocked to think this.  I regard myself as reasonably progressively and I’m actually a little annoyed that these better and more humane practices for working in software development are still taking so long to take hold or worse not applied correctly (flaccid agile).

It would seem that the younger generation are more inclined to take on these improvements.  One can even go so far as to say that Spotify could not have succeeded without a younger person’s mindset.  This mindset in more attune to Lean Start-up and they carry on the Lean Startup philosophy now that they are a larger company with 300 or so people.   If we were to apply traditional thinking we would not be enjoying the great product Spotify provides today.  In fact there are numerous sorry stories of venture capital funds being used up on starting a company without actually producing a product.

So older companies and companies that stick with older styles of working could be in trouble.  Not right now, but lets see in 5 to 10 years time.  It seems apparent to me at least, that these older companies aren’t changing because of the older people running them (yes a sweeping generalization).  We would like them to change for a number of reasons but is Age a barrier?  Do we need to wait for the next generation to come through?

Now I’m not proposing any fast fix to the problem, if indeed it’s perceived as one.  Going back to the questioner in the audience, his question seemed to implicitly assume an age hierarchy and that because older people were still present we could not progress with these changes out of ‘respect’.   Respect for people is a core component of Lean Philosophy and is called out explicitly in Agile Methodologies as well like eXtreme Programming.  Here is just one suggestion for a way forward.

Provide Safety

Allow mistakes to occur in small batches and ensure learning occur.  Toyota used the Japanese word – ‘Anzen’ which means safety.  This word will become more well known going forward.  Joshua Kerievsky is his company Industrial Logic is a major driver for this.

Will be writing some more about this in upcoming posts.