5. The software development industry worldwide - as generally perceived Distribution of Organisations vs. Effectiveness % of organisations Effectiveness 1 median
6. % of organisations Distribution of effectiveness is severely left -shifted. Benefits derive from shifting to the Right. [Courtesy: Steve McConnell: After the Gold Rush] Reality: The Basic Rightshifting Curve Effectiveness 0 1 2 3 4 5 median
7. The Four Mindsets % of organisations % waste Ad-hoc Synergistic Chaordic Effectiveness 0 1 2 3 4 5 Analytic 100 75 50 25
9. Waste = All those activities that don’t add stakeholder value. (N.B. Some essential non value-adding activities always remain). Waste % of organisations % waste Effectiveness 0 1 2 3 4 5 80% Wasted effort 100 75 50 25
10. Not a direct reciprocal of waste. Can - and does - go negative. Productivity = unit of output per unit of input or value per unit of effort . Productivity % of organisations % waste Wasted effort Effectiveness 0 1 2 3 4 5 Productivity A B F 100 75 50 25
11. Straw Poll ! Quality of Life at Work? % of organisations % waste Effectiveness 0 1 2 3 4 5 100 75 50 25 Aspiration Gap!
12. The Challenge We Face % of organisations % waste Ad-hoc Analytic Chaordic Synergistic Effectiveness 0 1 2 3 4 5 100 75 50 25 Wasted effort Productivity
13.
14.
15. Software Development Life Cycle % of organisations Effectiveness 0 1 2 3 4 5 Code & Fix Waterfall Agile Beyond ?
16. Flow Mode % of organisations Effectiveness 0 1 2 3 4 5 Random Batch & Queue Per-project sprints / Backlog / User Stories / Use Cases Systems Thinking – e.g. Single piece continuous flow?
17. Feedback delay % of organisations Effectiveness 0 1 2 3 4 5 Random 3 – 6 Months 2 – 4 weeks Daily or better
18. Administrative Project Management % of organisations APM Fun a.k.a. Job Satisfaction, Work-life balance Fun APM a.k.a. Ceremony, bean counting, and exemplified by command & control management style (transactional leadership). Wasted potential Effectiveness 0 1 2 3 4 5
19. Perspective on the Individual % of organisations Respect . Heroism Effectiveness 0 1 2 3 4 5
20. Measurement % of organisations Metrics Effort Rightshifted organisations put less effort into measurement because they have a better idea of their Rightshifting goals, therefore the questions to which they need answers, and thus what to measure. Plus, measurement is generally part of their BAU. (Effort a.k.a. cost) Effectiveness 0 1 2 3 4 5
21. Inductive vs. Deductive % of organisations Focus Rightshifted organisation focus collectively on fundamental principles (deductive), in contrast to a focus on the practices of effective development (inductive). Few indeed seem to have studied or understand the principles of effective development. And the implications ? Principles Practices Effectiveness 0 1 2 3 4 5
22. Toolheads % of organisations Predilection Showing the relative predilection for tools (as the answer to e.g. ignorance), not so much the actual deployment or utilisation of tools. Effectiveness 0 1 2 3 4 5
23. Quality and Testing % of organisations How can Rightshifted organisations get away with so much less testing, yet still have very low defect rates? Testing effort High Low Quality Philosophy Inspection (test after) Zero defects (test first) Many Few Effectiveness 0 1 2 3 4 5 Defects seen by users
24. Development Focus % of organisations Effectiveness 0 1 2 3 4 5 CV-centric Code-centric Requirements-centric Learning-centric
25. Maturity % of organisations e.g. CMMI 1 2 3 4 5 Effectiveness 0 1 2 3 4 5 APM
26. Risk awareness % of organisations Awareness Left-shifted organisations avoid talking (even thinking!) about risk. Agile practices more-or-less implicitly mitigate risk. Rightshifted organisations transcend risk management in favour of opportunity management. Effectiveness 0 1 2 3 4 5
27. % of organisations Learning Learning = knowledge systematically captured, and with BAU designed such that knowledge assets must be “Pulled” - and thus re-used - across projects. Systematic Learning Effectiveness 0 1 2 3 4 5
28. Even though e.g. Agile practices such as refactoring reduce the impact (cost) of design loopbacks, they may actually exacerbate their frequency . % of organisations Frequency Unplanned design loopbacks Many Few None Impact Dip in frequency for e.g. Waterfall organisation is bought at the expense of product quality (fit for purpose) Effectiveness 0 1 2 3 4 5
29. a.k.a. Due Date performance. i.e. How often products are shipped on time, milestones and deadlines met, etc.. Best = circa 98% on-time delivery. % of organisations Conformance Conformance to Schedules Good Poor Effectiveness 0 1 2 3 4 5
30. Third Parties here include benchmarking partners and organisations, consultants, etc. in the pursuit of (external) knowledge and skills. % of organisations Involvement Use of Third Parties High Low Effectiveness 0 1 2 3 4 5
31. Problems with the product found “post-live” % of organisations Deployment problems Many Few Effectiveness 0 1 2 3 4 5 Problems
32. Rightshifted organisations have much more uniform results across projects. % of organisations Variability in Project Success High Low Effectiveness 0 1 2 3 4 5 Variation Individuals The System Unsure
33. The Four Mindsets (Reprise) % of organisations % waste Effectiveness 0 1 2 3 4 5 100 75 50 25 Ad-hoc Analytic Synergistic Chaordic
34. Although this data is for projects (2087 separate projects), it looks surprisingly similar to the rightshift curve for organisations. ISBSG = International Software Benchmarking Standards Group Corroborating data from ISBSG
35. % of organisations The Four Management Measures High Low Effectiveness 0 1 2 3 4 5 Rightshift Turbulence Metrics Effort Left drift Drag
36. % of organisations Metaphor in use Effectiveness 0 1 2 3 4 5 Office work Software Factory Product Design (Studio) Value Stream Design
50. FlowChain ™ evolving the Software Development Organisation Enough of the Theory, already!
51. FlowChain ™ evolving the Software Development Organisation What is a Business?
52. FlowChain ™ evolving the Software Development Organisation A business as a System Customer Seeking Value Shareholder Seeking a Return on Investment
53. FlowChain ™ evolving the Software Development Organisation Value Stream Development as a System Operational Value Stream Owner Creating an Operational Value Stream Enhancing an Operational Value Stream
54. FlowChain ™ evolving the Software Development Organisation FlowChain in Practice Operational Value Stream Owners Backlog Pool WIP
Here’s a pretty standard bell-curve. Thus illustrates how most people, even those within the software industry itself, think that the distribution of organisations across the range of effectiveness from poor to excellent is fairly normal.
But in actuality, the distribution is significantly skewed to the left. This means that most organisations are much less effective at software development than one might expect. It also means that most people may have spent their entire working lives in significantly left-shifted businesses, not even realising that right-shifted businesses exist and prosper.
“ The most dangerous kind of waste is the waste we do not recognize.” - Shigeo Shingo . Types of waste: Bananas analogy (ex: Ohno) Ok. Here’s the left-shifted distribution curve overlaid with a line showing the amount of waste (wasted effort, percentage of regular BAU activities that don’t add stakeholder value) one can expect to see for organisations at the different levels of effectiveness. Note how some very left-shifted (ineffective) organisations can be wasting 100% of their time (i.e. adding no value at all). But you can bet they still *look* very busy people! Some highly Rightshifted organisations, on the other hand, have reduced their non-value added activities to around 15-18% (e.g. Toyota product development) – and even this 15-18% is “essential” non-value-adding activity – stuff that still has to be done, given the way they’re working at the moment.
Here the green line shows the relative productivity of organisations along the effectiveness axis (with the previous waste line greyed-out but retained for comparison). The points labelled A, B and F show for example some organisations the author has seen recently: A is a top-5 global systems integrator (circa 2008); B is a top-3 UK and European mobile company circa 2005; and F is the author’s own (Agile) software house circa 2000.
“ The most dangerous kind of waste is the waste we do not recognize.” - Shigeo Shingo . Types of waste: Bananas analogy (ex: Ohno) Ok. Here’s the left-shifted distribution curve overlaid with a line showing the amount of waste (wasted effort, percentage of regular BAU activities that don’t add stakeholder value) one can expect to see for organisations at the different levels of effectiveness. Note how some very left-shifted (ineffective) organisations can be wasting 100% of their time (i.e. adding no value at all). But you can bet they still *look* very busy people! Some highly Rightshifted organisations, on the other hand, have reduced their non-value added activities to around 15-18% (e.g. Toyota product development) – and even this 15-18% is “essential” non-value-adding activity – stuff that still has to be done, given the way they’re working at the moment.
This chart shows the various Life Cycles typically found in use in organisations along the effectiveness scale. Note the relatively large overlaps – these might imply that the transition between different Life Cycle models happens fairly lackadaisically. Also note that the currently acknowledged best-of-breed (Agile) runs out of steam around the 3x effectiveness multiplier. There has not yet emerged a consensus on what kind of Life Cycle model might be needed to Rightshift beyond Agile, although some indications do exist (TPDS, Motek and various other flavours of Lean). This lack of consensus doesn’t seem to be itself a barrier to some organisations reaching the 4x and 5x effectiveness levels, though. Finally, note the broad range of effectiveness *within* a given band: this shows that e.g. some folks “do Agile” (or Waterfall) much better than others.
Here we look at flow mode – essentially how well work flows through the software development organisation. Highly left-shifted organisations tend to allow work to flow at random – it often will be impossible to tell when a particular product, feature, upgrade or bug fix is likely to come into operation. Batch & Queue is the predominant Flow mode for waterfall Life Cycle organisations, where a whole Product's worth (or release's worth) of features (requirements) will be lumped together in a large batch (typically 6-months to 2 years worth of effort) and passed through the design and development engineering pipeline and into operation as an indivisible unit. Agile organisations typically Flow better, with batch size reduces to some economic minimum, typically around 2-weeks worth of effort (i.e. a Sprint). To transcend this economic minimum (where control / setup / teardown overhead balances value-adding work) requires a paradigm shift of some kind – for example to some form of single-piece continuous flow. c.f. Motek, a small software firm in Beverly Hills. Founder and CEO Ann S. Price (American Way magazine 15 March 2006)
APM e.g. status reports, standards, PERT, GANTT charts, etc
Key “respect” indicators include the company’s safety record, the degree to which individuals are rewarded or acknowledged for doing what’s right – as opposed to what’s expedient – etc. Here, “Heroism” means the organisation’s propensity to believe that individual performance is a function of individual traits such as motivation, talent, working harder, intelligence, and so on. Of course, this belief is hogwash - it’s just as Deming told us – it’s the system that’s responsible for (95% of) an individual’s performance. BTW We could also label this line “perceived power of extrinsic vs intrinsic motivation”, or even “Theory X” vs “Theory Y”.
Watch out for the Toolheads! (c.f. John Seddon – paper on his website) Seddon: “ Toolheads’ is used to signify an unthinking approach to change; people who ‘follow the book’ rather than ask the right question” Marshall: Toolheads = people who prefer deploying tools to i.e. learning, finding out and changing the way one thinks. Lean manufacturing, Lean Service (and their respective tools) are NOT automatically transferrable to product (and software) development – but maybe (some) of the thinking and lessons learned are. c.f. The previous slide (principles vs. practices (a.k.a. tools), in the more general sense).
Answers include: instituting ‘test first’ and “zero defect” approaches rather than habituated ‘fix on fail’ (test after) methods. Shigeo Shingo said something along the lines of “testing to find defects is waste; testing to prevent defects is value” (courtesy e.g.: Kevin Rutherford’s Blog, recently) Anecdote: An engineer, manager, and a programmer are in a car going down a steep mountain road. The brakes fail and the car careens down the road out of control. Halfway down, the driver manages to stop the car by sliding against the embankment, narrowly avoiding careening off the cliff. They all get out, shaken by their narrow escape from death, but otherwise unharmed. The manager says, "To fix this problem we need to organize a committee, have meetings, and through process of continuous improvement, develop a solution." The engineer says, "No that would take too long, besides that method never worked before. I have my trusty pen knife here and will take apart the brake system, isolate the problem and correct it." The programmer says, “No, no! We should all push the car back up to the top of the hill and see if it happens again."
Do not be misled by the “requirements-centric” division on this chart. Whereas the left-hand side (leftwards of circa 2.5) corresponds mainly to big-design-up-front (batch and queue) methods, more progressive organisations (i.e. around 2.5 and further right-shifted) have learned the folly of large swathes of requirements and tackle the issue of specifying requirements (both functional and non-functional) in a much more iterative, even just-in-time fashion.
Interesting points: ML5 only buys you effectiveness level 3 To go beyond EL3 needs something more than CMMI This applies not just to CMMI, but also to ITIL, ISO20000, CoBIT, AutomotiveSPICE, etc.
And not only captured so it can be re-used, but actively maintained up-to-date and aligned with typical decision structures and actually used, with feedback re: the results.
Left-shifted organisations tend to be inward-looking and subject to a strong not-invented-here prejudice. As we move to the right, organisations begin to learn that suitable interventions from skilled or knowledgeable third parties can add significant value – much more value that their fees. Rightshifted organisations retain this perspective, but have more difficulty in finding consultants, partners, etc. with more knowledge or skills than they themselves have already acquired. At this stage we sometime find these organisations in partnership with e.g. Universities and other advanced research bodies.
Where do managers (and other folks) attribute the responsibility for variation? c.f. Deming – 95% of variation in performance (of the individual) is due to the system. Many people won’t believe this – until they actually invest time to go and look! N.B. The System != The Process – invite the audience to draw the distinction then illustrate The One and Only Necessary Question to ask Managers: “What measures are you using to help you understand and improve the work?“
Same pattern applies to productivity and speed-to-deliver. The #2087 projects were selected from a much larger dataset - as being those projects with the most reliable data.
Timo Hannay – The Future is a Foreign Country Star Trek VI – The Undiscovered Country i.e. the future Shakespeare – The Undiscovered country – i.e. death
And what about e.g. Kennedy’s Entrepreneurial System Designer, Responsibility-based planning & control, Set-based (or knowledge-based) concurrent engineering and Expert Engineering Workforce?
Anecdote: “An engineer is someone who can do for a dime what any fool can do for a dollar”. Concurrently – or “contemporaneously” Endeavours: i.e. non-trivial (or even complex) endeavours - a.k.a. “Work” Masters (a.k.a. stakeholders): Sponsors (the person / people with the budget; those who shall pay) Users (the end-users of the product) The Business (the organisation buying and using (or selling-on) the software) The Software Organisation (the organisation producing the software) Others (project teams, including developers, managers, etc; regulators; unspecified others)
+ Minimises the effect of ‘stop-the-line’ (Jidoka) if defects are spotted?
Responsibility: for problem solving, fact finding, and delivering value to stakeholders at agreed dates belongs to the workforce. Responsibility to remove barriers, resolve process problems, & issues, find 7 fix root causes, etc. lies with the managers. OOB = Out-of-Band (i.e. explicit change initiatives, programmes, e.g. SLAMit!)
Let’s take a quick look at FlowChain in reality… c.f. An Exceptionally Simple Theory of Everything by Garrett Lisi: http://arxiv.org/PS_cache/arxiv/pdf/0711/0711.0770v1.pdf
Legal and General House, Kingswood
[UML Use Case diagram notation] A business is a collection of Operational Values Streams, delivering value to customers, shareholders and other stakeholders. Where do these operational value streams come from?
[UML Use Case diagram notation] “ Product” development, especially the development of a “Whole Product” is fundamentally about creating (and then enhancing) an Operational Value Stream. C.f. Allen C Ward – Lean Product and Process Development (Pub: Lean Enterprise Institute, 2007) See also: Kaizen or Rework: Lean in Product Development article by Jim Womack at http://www.wmep.org/Articles/proddevelkaizen.aspx
[Context diagram] This (animated) diagram shows the essence of a FlowChain organisation: The Operational Value Stream Owners request items (e.g. individual Use Cases, User (Stakeholder) stories, etc) from the system These requests go into an Organisational (system) backlog (ideally, empty or near-empty) for prioritisation according to prevailing policies. As soon as people with suitable skills are available in the pool, they coalesce into a small (3-5 people) team, pull the top item from the backlog and start on delivering in (into production) The blue item entering the organisational backlog as a result of "delivering" a yellow item is a process improvement "Stakeholder story", which can then be prioritised and worked-on "in-band", just like any other backlog item - i.e. single locus of control for all work within the system. Also note: FlowChain supposes that the status of all items in the Backlog will be widely published (i.e. via an intranet website, plasma screens whatever) with the business as a whole. It also supposes that the backlog items will be characterised as some form of executable use case / user story specification, to make it easy to track the status of the items (i.e. Arrived, Prioritised, Waiting, In Process, deliverable, In production, etc.)
![Why It Matters to Me ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)