Agile GuildAgile, a Mechanism for Managing Stakeholder

Expectations; and focussing the delivery

Richard CowlingPrincipal SEiT, EMIS Health, PCC

Richard Cowling

1982

1987

1990

1992

1993

1995

20042008

2012

2014

2010

The continuing “Software Crisis”

• It’s difficult to deliver software• It’s often late and over budget• It’s often bad

• Over the years - you’ve only to watch the news or read a newspaper … or visit somewhere software is used to know this! See Wikipedia, or visit here : http://www.computerworld.com/article/2533563/it-project-management/it-s-biggest-project-failures----and-what-we-can-learn-from-them.html

Why?• Lots of reasons

– Lack of discipline– Abstract intangible nature– Highly conceptual– People and perception filters– Underestimating complexity– Underestimating size– Changing world / changing minds / moving targets– Lack of visibility– Creeping scope – Misunderstandings / Ambiguity / Communication interference– Failing to engage key stakeholders– Chinese whispers

Communicating Specifications

Model Traditional Engineering / Manufacturing

• Initial attempts to solve the “Software Crisis” – on the face of it seemed rational and sensible– Bring in engineering rigour, discipline and create

“Software Engineering” – modelled on “Civil Engineering”, “Electrical Engineering”, “Mechanical Engineering” …

– Engineering means “specify, plan and design”– And utilise “Project Management” best practice …

follow standards and procedures – process models - CMM etc.

Focus on Specification & Design First• “Before writing a line of code let’s just be sure

we know exactly what it is we’re developing – let’s first try to fully describe the system – if we put this upfront effort in now – it’ll save us time later!”

• Business Analysts head off eliciting and writing down requirements for months and months until they finally achieve analysis paralysis and stop – then the design phase begins … WATERFALL ...

• Lots of documents get written …

Taught at Uni :

• Software should be planned and designed and manufactured like anything else – Bridges– Shoes– Tractors– Tower blocks– Engines– Boats

• Thing is, they’re all visible concrete things.

Turns out delivering software is

• More like playing chess

• Than building a bridge.• And you DON’T PLAN a game of chess

move my move – you HAVE A GOAL and STRATEGY.

Trad. Manufacturing/Factory Model : QC Inspector is Too Late

Big-Bang / Waterfall Delivery

Why … Again?• Lots of reasons

– Lack of discipline– Abstract intangible nature– Highly conceptual– People and perception filters– Underestimating complexity– Underestimating size– Changing world / changing minds / moving targets– Lack of visibility– Creeping scope – Misunderstandings / Ambiguity / Communication interference– Failing to engage key stakeholders– Chinese whispers

Another School of thought …

Sir Francis Bacon 1561 - 1626

• Scientific Method

What about this guy ?

William Edwards Demming 1900-93

• Quality Management, Continual Improvement, Toyota Lean Manufacturing – the Japanese Industrial Boom - KAIZEN

So, there’s an alternative approach to getting things done – and done well!

• The thinking and work done by Demming starts to get applied to thinking about how to develop software.

• IT’S ALL ABOUT THE FEEDBACK LOOP AND MAKING FULL USE OF THE ALL THE FEEDBACK.

• Tom Gilb’s EVO and Barry Boehm’s Spiral

Feedback Loops

Incremental Construction

Agile – the incremental approach toolkit

• Agile provides the tools to enable incremental approaches, principles, and benefits

Benefits should be …• Early and continual verification and validation• So, that’s building quality in - and de-risking project/product• Incremental Acceptance is possible and can be used to

manage change.• Short feedback loops focus more on expectations than

requirements – so genuine customer/stakeholder satisfaction AND allow you to track the moving targets.

• Lean – waste and rework restricted to last small increment.• Visibility and predictability – rolling re-estimation – a

continual conversation.• Is its own early warning system.• Relieves deadline pressure.• Continual Improvement of processes and practices

Quality!

What is quality?

What does Software Quality mean?

• The amount of stakeholder satisfaction• How well the expectations of the

customers / users / stakeholders are met or exceeded.

• How well the requirements have been met – depends on the how good the requirements are …

• “Fitness for Purpose” … ???

Remember that feeling …

• You ordered your favourite meal at a new restaurant …

• It wasn’t what you were expecting – you were disappointed.

• Your perception of the quality of the meal, and establishment is affected – to you it was not a high quality experience.

• The menu is like the written requirements.• The proof is in the eating.

Conclusion ...

Benefits should be …• Early and continual verification and validation• So, that’s building quality in – and de-risking

project/product• Incremental Acceptance is possible and can be used to

manage change.• Short feedback loops focus more on expectations than

requirements – so genuine customer/stakeholder satisfaction AND allow you to track the moving targets.

• Lean – waste and rework restricted to last small increment.• Visibility and predictability – rolling re-estimation – a

continual conversation.• Is its own early warning system.• Relieves deadline pressure.• Continual Improvement of processes and practices

Failure Reasons… Again?• Lots of reasons

– Lack of discipline– Abstract intangible nature– Highly conceptual– People and perception filters– Underestimating complexity– Underestimating size– Changing world / changing minds / moving targets– Lack of visibility– Creeping scope – Misunderstandings / Ambiguity / Communication interference– Failing to engage key stakeholders– Chinese whispers

Questions!• Are we using Agile, as a mechanism to manage

stakeholder expectations; and focus the delivery on the moving target?

• Are we feeling the benefits of incremental small step construction … (sprinting)

• Are we more about “expectations” or still thinking in terms of “requirements”.

• Are we more about project “Strategy” or “Plan”?• Is Incremental Acceptance what we do – should it be?• Is Sprint Review being made maximum use of – in terms

of feedback and adapt?