Lean Systems Thinking Bob Marshall
4 likes855 views
The document discusses a model called FlowChain for running a software-oriented organization based on lean principles. It introduces key FlowChain concepts like customer purpose, covalency, single-piece continuous flow, in-band improvement, emergence, systems thinking, and allowing people to self-organize against demand. FlowChain aims to improve responsiveness, reduce waste, and minimize work-in-process through these principles. The document then discusses what life might look like in a highly rightshifted organization that follows FlowChain principles.
![% of organisations Effectiveness 0 1 2 3 4 5 Distribution of effectiveness is severely left -shifted. Benefits derive from shifting to the Right. [Courtesy: Steve McConnell: After the Gold Rush] Reality](https://image.slidesharecdn.com/leansystemsthinking-bobmarshall-091001045838-phpapp02/85/Lean-Systems-Thinking-Bob-Marshall-5-320.jpg)
Lean Systems Thinking Bob Marshall
- 1. On Belief An Enterprise Perspective on Software-Intensive Product Development with Bob Marshall @flowchainsensei
- 2. Bob Marshall Transformational leadership specialist Advisor to senior management in technology-led organisations Champion for Rightshifting of e.g. technology product development organisations and teams 15+ years leading and coaching technology business transformations Recent Clients in Finance, Telcos, Govt, Logistics, Embedded Originator of e.g. Javelin, FlowChain, Rightshifting, Emotioneering and Covalency 15+ years OO, Agile and Lean coach Co-founder of the UK Rightshifting Network Founder and CEO of UK’s first 100% Agile software house (97-2000) Owner and Chief Coach at Falling Blossoms - Est. 2000 Influential in the global Agile and Lean software community
- 4. Does this reflect your understanding of the software development industry worldwide? Distribution of Organisations vs. Effectiveness % of organisations Effectiveness 0 1 2 3 4 5
- 5. % of organisations Effectiveness 0 1 2 3 4 5 Distribution of effectiveness is severely left -shifted. Benefits derive from shifting to the Right. [Courtesy: Steve McConnell: After the Gold Rush] Reality
- 6. So what do you believe? Is software development fundamentally broken everywhere? In your organisation?
- 7. % of organisations Effectiveness 0 1 2 3 4 5 Where are you on the effectiveness axis? Reality: The Basic Rightshifting Curve
- 8. Waste = All those activities that don’t add stakeholder value. (N.B. Some essential non value-adding activities always remain). Waste % of organisations Effectiveness % waste 0 1 2 3 4 5 Wasted effort 100 75 50 25
- 9. 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 Effectiveness 0 1 2 3 4 5 Wasted effort Productivity A B F 100 75 50 25
- 10. Software Development Life Cycle % of organisations Effectiveness 0 1 2 3 4 5 Code & Fix Waterfall Agile Beyond ?
- 11. Flow Mode % of organisations Effectiveness 0 1 2 3 4 5 Random Batch & Queue Sprints / Backlog / User Stories / Use Cases Systems Thinking – e.g. Single piece continuous flow?
- 12. Feedback delay % of organisations Effectiveness 0 1 2 3 4 5 Random 3 – 6 Months 2 – 4 weeks Daily
- 13. Administrative Project Management % of organisations Effectiveness 0 1 2 3 4 5 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
- 14. Perspective on the Individual % of organisations Effectiveness 0 1 2 3 4 5 Respect . Heroism
- 15. Measurement % of organisations Effectiveness 0 1 2 3 4 5 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)
- 16. Inductive vs. Deductive % of organisations Effectiveness 0 1 2 3 4 5 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
- 17. Toolheads % of organisations Effectiveness 0 1 2 3 4 5 Predilection Showing the relative predilection for tools (as the answer to e.g. ignorance), not so much the actual deployment or utilisation of tools.
- 18. Quality and Testing % of organisations Effectiveness 0 1 2 3 4 5 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 Defects seen by users
- 19. Development Focus % of organisations Effectiveness 0 1 2 3 4 5 CV-centric Code-centric Requirements-centric Learning-centric
- 20. Maturity % of organisations Effectiveness 0 1 2 3 4 5 e.g. CMMI 1 2 3 4 5 APM
- 21. Risk awareness % of organisations Effectiveness 0 1 2 3 4 5 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.
- 22. % of organisations Effectiveness 0 1 2 3 4 5 Learning Learning = knowledge systematically captured, and with BAU designed such that knowledge assets must be “Pulled” - and thus re-used - across projects. Systematic Learning
- 23. Even though e.g. Agile practices such as refactoring reduce the impact (cost) of design loopbacks, they may actually exacerbate their frequency . % of organisations Effectiveness 0 1 2 3 4 5 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)
- 24. 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 Effectiveness 0 1 2 3 4 5 Conformance Conformance to Schedules Good Poor
- 25. Third Parties here include benchmarking partners and organisations, consultants, etc. in the pursuit of (external) knowledge and skills. % of organisations Effectiveness 0 1 2 3 4 5 Involvement Use of Third Parties High Low
- 26. Problems with the product found “post-live” % of organisations Effectiveness 0 1 2 3 4 5 Deployment problems Many Few Problems
- 27. Rightshifted organisations have much more uniform results across projects. % of organisations Effectiveness 0 1 2 3 4 5 Variability in Project Success High Low Variation Individuals The System Unsure
- 28. 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
- 29. % of organisations Effectiveness 0 1 2 3 4 5 The Four Management Measures High Low Metrics Effort Rightshift Left drift Drag Turbulence
- 30. % of organisations Effectiveness 0 1 2 3 4 5 Metaphor in use Office work Software Factory Product Design (Studio) Value Stream Design
- 31. End of Part 1
- 32. FlowChain ™ evolving the Software-Oriented Organisation Part 2 – The Undiscovered Country
- 33. FlowChain ™ evolving the Software-Oriented Organisation So now we’ve taken a look at the state of the software industry today. Let’s think about the journey ahead for all of us: the Journey into the Undiscovered Country of the Future. What does life look like - and what does work work like - in organisations way over to the right?
- 34. FlowChain ™ evolving the Software-Oriented Organisation % of organisations Effectiveness 0 1 2 3 4 5 What could life look like in the sunny uplands of a highly-Rightshifted organisation? Reality: The Basic Rightshifting Curve ?
- 35. FlowChain ™ evolving the Software-Oriented Organisation What is FlowChain? One model for how to run a software-oriented organisation Based on principles from Lean Product Design, Systems Thinking, Theory of Constraints Takes a top-down “Systems” view A concrete example of a Rightshifted organisation
- 36. FlowChain ™ evolving the Software-Oriented Organisation The next few slides introduce the fundamental concepts underpinning FlowChain: Customer Purpose Covalency Single-piece Continuous Flow In-band Performance Improvement Evolution Emergence Systems Thinking People Self-Organise Against Demand
- 37. FlowChain ™ evolving the Software-Oriented Organisation Any system exists to serve a purpose The most useful perspective on purpose is your CUSTOMERS’ perspective Do you orient your organisation to best serve your customers’ purpose? Customer Purpose
- 38. FlowChain ™ evolving the Software-Oriented Organisation Term appropriated by me for use in this context Conveys the idea (and ideal) that: “Endeavours have to deliver value to many masters, concurrently”: Sponsors Users The Business The Software Organisation Others At the root of all Engineering disciplines Covalency
- 39. FlowChain ™ evolving the Software-Oriented Organisation Improves responsiveness to demand Reduces cycle times Enables incremental delivery of value (ROI) Accelerates feedback (=> faster Rightshifting) Minimises stakeholders’ financial exposure Less waste Minimises work-in-process (inventory) Single-piece Continuous Flow
- 40. FlowChain ™ evolving the Software-Oriented Organisation Embeds both incremental and step-function change within the daily operational rhythm of an organisation Increases staff engagement Places responsibility on the front line Supports Evolution Widespread alternative – OOB improvement In-band Performance Improvement
- 41. FlowChain ™ evolving the Software-Oriented Organisation Heraclitus: “Change is the only constant” Build some kind of “Sense and Respond” ability into the fabric of an organisation’s daily operational rhythm Does away with BDUF Evolution
- 42. FlowChain ™ evolving the Software-Oriented Organisation Allow your approach to emerge “in vivo” – by observing how people actually do things, and laying the paths where the trails appear. Just a few simple principles (rules), cause complex and optimal behaviours to emerge (c.f. ants, bees, fish, etc.) Emergence
- 43. FlowChain ™ evolving the Software-Oriented Organisation Deming: 95% of an individual's performance is dictated by the System. Whole product = Operational Value Stream Optimize the throughput of the whole System (i.e. the organisation, not any given project or sprint) C.f. Senge; Goldratt; etc. Systems Thinking
- 44. FlowChain ™ evolving the Software-Oriented Organisation An effective process, system is necessary but not sufficient Engaged, motivated, focused people are also necessary Any effective system enables people to achieve their potential Transformational Leadership (not administrative management) is the path to making this all happen People
- 45. FlowChain ™ evolving the Software-Oriented Organisation You ain’t gonna need it! Defer decisions until the last possible responsible moment. The best chance to have the necessary information to hand. C.f. Set-based Concurrent Engineering (SBCE) YAGNI
- 46. FlowChain ™ evolving the Software-Oriented Organisation Understand demand (on the system) Arrange things so the system can organise itself in response to demand (best known example: “Pull” a.k.a. Make to order) Standards reduce variation – great for manufacturing but death for innovation and excellence in design engineering. Self-Organise Against Demand
- 47. FlowChain ™ evolving the Software Development Organisation Enough of the Theory, already!
- 48. FlowChain ™ evolving the Software Development Organisation What is a Business?
- 49. FlowChain ™ evolving the Software Development Organisation A Business as a System Customer Seeking Value Shareholder Seeking a Return on Investment
- 50. FlowChain ™ evolving the Software Development Organisation Why Product Development is Key Customer Evolving the operational value stream Seeking value Board
- 51. 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
- 52. FlowChain ™ evolving the Software Development Organisation FlowChain in Practice Operational Value Stream Owners Backlog Pool WIP
- 53. Questions
- 54. The Beginning – Thank You!
Editor's Notes
- #2: My three key points: Software development is not hopelessly broken any more. An enterprise perspective pays dividends (to wit: product development is about creating operational value streams). Software development and Product development are inextricably intertwined nowadays.
- #5: 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. We define effectiveness as the sheer ability of an organisation to reach its declared goals.
- #6: 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.
- #9: “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.
- #10: 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.
- #11: 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.
- #12: 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)
- #14: APM e.g. status reports, standards, PERT, GANTT charts, etc
- #15: 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”.
- #18: 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).
- #19: 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."
- #20: 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.
- #21: 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.
- #23: 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.
- #26: 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.
- #28: 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?“
- #29: 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.
- #33: 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
- #37: 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?
- #38: 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)
- #39: 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)
- #40: + Minimises the effect of ‘stop-the-line’ (Jidoka) if defects are spotted?
- #41: 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!)
- #42: BDUF = Big Design Up Front
- #46: SBCE a.k.a. Knowledge-based concurrent engineering
- #48: 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
- #49: Legal and General House, Kingswood
- #50: [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?
- #51: Seeking value aka: Buying products and services
- #52: [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
- #53: [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.)