Tag Archives: DevOps

Webinar: Case Study Agile Testing results in DevOps Success

I recorded a webinar for CodeGenesys on a case study on Agile Testing involving my Australian Client called AgWorld.

Hopefully it conveys that quality is owned by everyone and quality starts well before a line of code is written.

Quality right through the value stream is cornerstone of DevOps success. This carries on right through the software development life cycle starting with requests and turning those into executable specification with BDD/ATDD, automation of unit and integration tests and with the aid of automation tools (Build and Deploy) to increase the delivery rate of completed software to increase the frequency of feedback lloops.



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:



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.



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.



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!

Project Phoenix: A light introduction to Systems Thinking, Theory of Constraints, Lean –> DevOps

 For me this was not a great read despite the hype surrounding the book.  But don’t let that stop you from reading this book.  In fact if you are interested in learning something about Systems Thinking, Theory of Constraints, Lean and Kanban this is the perfect introduction in the form of a business novel.

Now a novel is usually read for enjoyment, but I found the rubber doesn’t hit the road till about Chapter 14.   It’s a bit a long introduction til we start getting into solutions.  Then it starts to shine and the disaster looking like having a horrible death goes through a remarkable transformation.

Again if you’re not familiar with any of the concepts this is a great introduction.  If you’re interested in improving the state of your workplace grab yourself a copy.  It’s especially important for demonstrating the need for a more symbiotic relationship between all parts of service delivery and hence the rise of DevOps.