Slides from the presentation given at GeekUp Sheffield 20

1. Sheffield - Nov 2009
Elephants
in the Meeting Room
Dealing with risk, blame and failure
in software development
Creative Commons Attribution-No Derivative Works 2.0
Ashley Moran
UK: England & Wales License PatchSpace Ltd

2. This is an elephant
(There will be a test at the end to see if you remembered)

3. This is a meeting room

4. This is a client meeting

5. Quote from GeekUp Sheffield
Nov 2009
“Who here has had a client deliberately omit requirements with
the intention of sneaking them in later as bug reports?”
- anonymous (but feel free to claim it)

6. Observation
This is behaviour you would expect from a client
involved in a fixed-cost, fixed scope project.

7. Client Motivations

8. Client Motivations
• Ifa client wants to approach new software development on a
fixed cost basis, are they trying to:

9. Client Motivations
• Ifa client wants to approach new software development on a
fixed cost basis, are they trying to:
• move risk, or

10. Client Motivations
• Ifa client wants to approach new software development on a
fixed cost basis, are they trying to:
• move risk, or
• move blame?

11. Developer motivations

12. Developer motivations
• When a developer enters a fixed scope project and accepts a
fixed fee and deadline, are they:

13. Developer motivations
• When a developer enters a fixed scope project and accepts a
fixed fee and deadline, are they:
• entering a contract biased to their financial gain?

14. Developer motivations
• When a developer enters a fixed scope project and accepts a
fixed fee and deadline, are they:
• entering a contract biased to their financial gain?
• entering a contract in the best interest of their client?

15. What is Software Development?

16. What is Software Development?
• Software development is not manufacturing

17. What is Software Development?
• Software development is not manufacturing
• Software development is new product development

18. What is Software Development?
• Software development is not manufacturing
• Software development is new product development
• New product development carries inherent risk
• If there was no risk, there would be no point in doing it

19. The Two Risks of
Product Development

20. The Two Risks of
Product Development
• Identify the right problem, design the wrong solution
• Traditionally, a failure of the development team

21. The Two Risks of
Product Development
• Identify the right problem, design the wrong solution
• Traditionally, a failure of the development team
• Design the right solution, but to the wrong problem
• Traditionally a failure of the client (but blamed on the BAs)

22. The Third Risk of
Product Development

23. The Third Risk of
Product Development
• You design the wrong solution, to solve the wrong problem

24. The Third Risk of
Product Development
• You design the wrong solution, to solve the wrong problem
• Who gets blamed?

25. Think Lean

26. Think Lean
• The seven forms of software waste (and corresponding forms of industrial waste),
from Mary & Tom Poppendieck 2003:
• Partially Done Work (Inventory)
• Extra Processes (Extra Processing)
• Extra Features (Overproduction)
• Task Switching (Transportation)
• Waiting (Waiting)
• Motion (Motion)
• Defects (Defects)
• The underlined forms of waste are most relevant here

27. Lean Product Development:
Failure

28. Lean Product Development:
Failure
• New product development has inherent risk (of failure)

29. Lean Product Development:
Failure
• New product development has inherent risk (of failure)
• If a new idea fails, this generates valuable knowledge

30. Lean Product Development:
Failure
• New product development has inherent risk (of failure)
• If a new idea fails, this generates valuable knowledge
• The faster you can fail, the less waste you incur

31. Lean Product Development:
Failure
• New product development has inherent risk (of failure)
• If a new idea fails, this generates valuable knowledge
• The faster you can fail, the less waste you incur
• It’s not really failure - it’s identifying incorrect solutions

32. Let’s Start a Fight

33. Let’s Start a Fight
• From the incentives of typical software contracts, you can derive a
bold conjecture:

34. Let’s Start a Fight
• From the incentives of typical software contracts, you can derive a
bold conjecture:
• Clients do not understand or accept risk;
change and failure is blamed on developers

35. Let’s Start a Fight
• From the incentives of typical software contracts, you can derive a
bold conjecture:
• Clients do not understand or accept risk;
change and failure is blamed on developers
• Developers do not highlight risk;
change and failure is blamed on clients

36. Let’s Start a Fight
• From the incentives of typical software contracts, you can derive a
bold conjecture:
• Clients do not understand or accept risk;
change and failure is blamed on developers
• Developers do not highlight risk;
change and failure is blamed on clients
• Risk, blame and failure belong to the family Elephantidae

37. Let’s Start a Fight
• From the incentives of typical software contracts, you can derive a
bold conjecture:
• Clients do not understand or accept risk;
change and failure is blamed on developers
• Developers do not highlight risk;
change and failure is blamed on clients
• Risk, blame and failure belong to the family Elephantidae
• Before we start the discussion, there’s one thing to check...

38. What is this?

39. What do we do?

40. Credits

41. Credits
• Thanks to @marcjohnson for co-presenting
• Photographs from www.sxc.hu:
• Thanks to Thad Zajdowicz (thadz) for the meeting room
• Thanks to Elvis Santana (tome123) for the elephant
• Thanks
to @jagusti and @yorkhannah for organising
GeekUp Sheffield 20