enterprise_lean-agile_coach_course
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
| enterprise_lean-agile_coach_course [2018/03/12 09:46] – hpsamios | enterprise_lean-agile_coach_course [2018/03/12 10:01] – hpsamios | ||
|---|---|---|---|
| Line 120: | Line 120: | ||
| ===== Day 1 ===== | ===== Day 1 ===== | ||
| - | # Content | + | ==== Content |
| - | | + | - Intro |
| - | 1. Complex Adaptive Systems (CAS) | + | |
| - | 1. Mindset and culture | + | |
| - | # Important Ideas | + | ==== Important Ideas ==== |
| - | * Overall aim when dealing with CAS is to " | + | |
| - | * When to use lean vs CAS? If you cannot leverage variability, | + | * When to use lean vs CAS? If you cannot leverage variability, |
| - | * Powerful question - litmus test for organization - "How do we treat variability and uncertainty?" | + | * Powerful question - litmus test for organization - "How do we treat variability and uncertainty?" |
| - | * Complex adaptive systems defn "a system, the properties of which cannot be derived from the properties of its components" | + | * Complex adaptive systems defn "a system, the properties of which cannot be derived from the properties of its components" |
| - | * CAS cannot be directly changed. We can provoke change but only through experimentation | + | * CAS cannot be directly changed. We can provoke change but only through experimentation |
| - | * Characteristics of CAS | + | * Characteristics of CAS |
| - | | + | * Emergent Properties: system manifests qualitatively new behaviors that none of its components have (e.g. Ability to evade falcon) |
| - | | + | * Non-determinism: |
| - | | + | * Non-linearity: |
| - | * In CAS context matters | + | * In CAS context matters |
| - | * Don't ignore current reality (e.g. Informal networks) | + | * Don't ignore current reality (e.g. Informal networks) |
| - | * Adopt empirical mindset is fundamental - This means worry about improving feedback loops | + | * Adopt empirical mindset is fundamental - This means worry about improving feedback loops |
| - | * Improve feedback efficiency by understanding " | + | * Improve feedback efficiency by understanding " |
| - | * (Action) as coach user feedback markers to understand where the real problems in the system are | + | * (Action) as coach user feedback markers to understand where the real problems in the system are |
| - | * alternative approach to transformation - find cracks / blind spots, then stitch together with feedback loops, then start working to tighten the loops | + | * alternative approach to transformation - find cracks / blind spots, then stitch together with feedback loops, then start working to tighten the loops |
| - | * (Action) Notion of semi conductor organization anti-pattern. Biased feedback loop always positive. Need to fix with gemba, for example | + | * (Action) Notion of semi conductor organization anti-pattern. Biased feedback loop always positive. Need to fix with gemba, for example |
| - | * (Book) Gerd Gigerenzer - heuristics of decision making | + | * (Book) Gerd Gigerenzer - heuristics of decision making |
| - | * Implementing agile on traditional mindset means still will end up trying to folllow the master plan. This is because of cognitive bias - risk adverse so don't like uncertainty | + | * Implementing agile on traditional mindset means still will end up trying to folllow the master plan. This is because of cognitive bias - risk adverse so don't like uncertainty |
| - | * Another set of reductionist thinking that results - thinking point based solutions, thinking outputs not outcomes, chasing predictability over value | + | * Another set of reductionist thinking that results - thinking point based solutions, thinking outputs not outcomes, chasing predictability over value |
| - | * reductionist mental model effects every practice. E.g. Priorization means return / investment. We map to value / size. All good. To to improve value we must experiment with multiple options and validate frequently. This is hard (requires change in mindset). What I can do instead is maximize scope which I understand. Results in deliver more crap faster. Even if you lecture people about this they will still do this. Message is that we manage amount of uncertainty as we move forward. We reduce options as we go. | + | * reductionist mental model effects every practice. E.g. Priorization means return / investment. We map to value / size. All good. To to improve value we must experiment with multiple options and validate frequently. This is hard (requires change in mindset). What I can do instead is maximize scope which I understand. Results in deliver more crap faster. Even if you lecture people about this they will still do this. Message is that we manage amount of uncertainty as we move forward. We reduce options as we go. |
| - | * Be careful of lean - it's the new cult - anything that is good is lean, but lean is actually (based on tps) manufacturing approach | + | * Be careful of lean - it's the new cult - anything that is good is lean, but lean is actually (based on tps) manufacturing approach |
| - | * (Action) Metrics as ranges always, not a single number | + | * (Action) Metrics as ranges always, not a single number |
| - | * (Quote) (Sarcasm). "If you are not part of the solution there is plenty of money to be made in prolonging the problem" | + | * (Quote) (Sarcasm). "If you are not part of the solution there is plenty of money to be made in prolonging the problem" |
| - | * (Book) The Art of Business Value - Mark Schwertz | + | * (Book) The Art of Business Value - Mark Schwertz |
| - | * (Action) Get all the videos and distribute / save | + | * (Action) Get all the videos and distribute / save |
| - | * Most important function - spot biases then help people see these. Mindset / mental models | + | * Most important function - spot biases then help people see these. Mindset / mental models |
| - | * Law of large numbers does not apply to exponential (long tail) distributions. Only applies to distribution with mean and SD and exponential doesn' | + | * Law of large numbers does not apply to exponential (long tail) distributions. Only applies to distribution with mean and SD and exponential doesn' |
| - | * Any form of planning creates a confirmation bias. Someone has to have an interest in falsify the result (e.g. Dev test relationship - test interested in falsifying) | + | * Any form of planning creates a confirmation bias. Someone has to have an interest in falsify the result (e.g. Dev test relationship - test interested in falsifying) |
| - | * Be careful of case studies. Use for exploring but don't apply directly. Case studies work when problem space is normal distribution. And with case studies there is never a control group (therefore confirmation bias) | + | * Be careful of case studies. Use for exploring but don't apply directly. Case studies work when problem space is normal distribution. And with case studies there is never a control group (therefore confirmation bias) |
| - | * Aligning mental models across participants make model more accurate. Two mental models of interest - what to do; how to do it | + | * Aligning mental models across participants make model more accurate. Two mental models of interest - what to do; how to do it |
| - | * (Action) Model alignment technique - identify facts, affinity map / label facts, identify connections, | + | * (Action) Model alignment technique - identify facts, affinity map / label facts, identify connections, |
| - | * Alignment requires empathy - requires significant overlap in mindset | + | * Alignment requires empathy - requires significant overlap in mindset |
| - | * Defn -a learning organization is one purposely and collaboratively evolves shared mental models, relying heavily on a system of feedback loops | + | * Defn -a learning organization is one purposely and collaboratively evolves shared mental models, relying heavily on a system of feedback loops |
| - | * You cannot directly change a mindset (as CAS). You can only attenuate factors that encourage wrong mindset, and amplify the ones that discourage wrong mindset. | + | * You cannot directly change a mindset (as CAS). You can only attenuate factors that encourage wrong mindset, and amplify the ones that discourage wrong mindset. |
| - | * (Action) Let understand existing mindsets we need to overcome with SDM | + | * (Action) Let understand existing mindsets we need to overcome with SDM |
| + | ==== Thinking tools ==== | ||
| - | # Thinking tools | + | * Hidden Constraint: helps identify additional areas of flexibility not obvious at first glance. Look for assumptions that are taken for granted |
| + | * Hybrid: instead of A vs B, try A and B. E.g. Hybrid fixed and fluid teams | ||
| + | * Endgame: visualize the result and ask questions like why do we need to do this, what do we need to do to get there, how are we going to use it? | ||
| - | * Hidden Constraint: helps identify additional areas of flexibility not obvious at first glance. Look for assumptions that are taken for granted | + | ==== Introduction |
| - | * Hybrid: instead of A vs B, try A and B. E.g. Hybrid fixed and fluid teams | + | |
| - | * Endgame: visualize the result and ask questions like why do we need to do this, what do we need to do to get there, how are we going to use it? | + | |
| - | + | ||
| - | # Introduction | + | |
| Mindset is important | Mindset is important | ||
| Line 211: | Line 210: | ||
| E.g. | E.g. | ||
| - | * Choose between feature and component teams -> | + | |
| - | * Choose between fixed feature and component teams -> | + | * Choose between fixed feature and component teams -> |
| - | * choose between feature / component orientation and fixed / fluid structure | + | * choose between feature / component orientation and fixed / fluid structure |
| Thinking tool | Thinking tool | ||
| Line 245: | Line 244: | ||
| On going mindset for coaches - explorer mindset | On going mindset for coaches - explorer mindset | ||
| - | # Complex Adaptive Systems | + | ==== Complex Adaptive Systems |
| Iterative and incremental approaches can be dangerous | Iterative and incremental approaches can be dangerous | ||
| Line 382: | Line 381: | ||
| This is lean startup thinking | This is lean startup thinking | ||
| - | # Mindset and Culture | + | ==== Mindset and Culture |
| Most important function - spot biases then help people see these | Most important function - spot biases then help people see these | ||
| Line 441: | Line 440: | ||
| {{image File: | {{image File: | ||
| - | |||
| ===== Day 2 ===== | ===== Day 2 ===== | ||
| - | # Content | + | ==== Content |
| 1. Building Organizational Habits | 1. Building Organizational Habits | ||
| 1. Organizational Structure and Flow | 1. Organizational Structure and Flow | ||
| - | # Important Ideas | + | ==== Important Ideas ==== |
| - | * Don't turn into a car salesman if you are a change agent - transformation is hard | + | |
| - | * Job as coach is to break the cycle - to help manage the fear associated with trying a new practice | + | * Job as coach is to break the cycle - to help manage the fear associated with trying a new practice |
| - | * Have to help org leadership understand that new approach may look like being adopted but is not in actuality - need permission to hear bad news | + | * Have to help org leadership understand that new approach may look like being adopted but is not in actuality - need permission to hear bad news |
| - | * Building new complex habit is hard. Misunderstand effort to sustain. We Take Big Bang approach instead of more incremental approach. "If you have trouble remembering a process, you are already in trouble" | + | * Building new complex habit is hard. Misunderstand effort to sustain. We Take Big Bang approach instead of more incremental approach. "If you have trouble remembering a process, you are already in trouble" |
| - | * Technqiue - relax a constraint on a practice - purposeful | + | * Technqiue - relax a constraint on a practice - purposeful |
| - | * Sometimes right answer is to not introduce new practice as this time (too much change, too many constraints) | + | * Sometimes right answer is to not introduce new practice as this time (too much change, too many constraints) |
| - | * Minimize practices that have long feedback loops | + | * Minimize practices that have long feedback loops |
| - | * We mostly plan before we do research when it should be the other way around - do research first, then do the plan. | + | * We mostly plan before we do research when it should be the other way around - do research first, then do the plan. |
| - | * We cannot really reduce value to a single number (e.g. WSJF). In fact, science says this is impossible. Also a problem wrt how to do explorations | + | * We cannot really reduce value to a single number (e.g. WSJF). In fact, science says this is impossible. Also a problem wrt how to do explorations |
| - | * How we view probability - only 3 states none, risky, freak out | + | * How we view probability - only 3 states none, risky, freak out |
| - | * (Action). What is benefit of cadence for storage (does it really make sense) | + | * (Action). What is benefit of cadence for storage (does it really make sense) |
| - | * People are not machines. To continuously do a practice / process they need to continuously experience the benefits the practice / process offers. I.e. Need continuous feedback | + | * People are not machines. To continuously do a practice / process they need to continuously experience the benefits the practice / process offers. I.e. Need continuous feedback |
| - | * Need to be empathetic about feedback loop. What does practitioner (Natasha) see? | + | * Need to be empathetic about feedback loop. What does practitioner (Natasha) see? |
| - | * If feedback takes a long time to come back, or if action takes a long time, then feedback has no effect. Question - how to make retro more effective. Do action immediately to see if works. Don't wait to next retro to see results | + | * If feedback takes a long time to come back, or if action takes a long time, then feedback has no effect. Question - how to make retro more effective. Do action immediately to see if works. Don't wait to next retro to see results |
| - | * 5 whys dangerous in CAS as this is not a simple system, but rather complex. Not linear. | + | * 5 whys dangerous in CAS as this is not a simple system, but rather complex. Not linear. |
| - | * Practice maps show relationships of practices in connected ecosystem. Apply vertical slices approach to implement piece by piece | + | * Practice maps show relationships of practices in connected ecosystem. Apply vertical slices approach to implement piece by piece |
| - | * (Action) Consider creating practice map next time want to introduce new idea | + | * (Action) Consider creating practice map next time want to introduce new idea |
| - | * We operate in a continuous operate / learn cycle (its own empirical cycle) | + | * We operate in a continuous operate / learn cycle (its own empirical cycle) |
| - | * Practice is made up of ways of thinking (practice specific mental model) and ways of doing. So we need to understand the mental model that we need someone to have and then coach to reinforce (sure train as well). | + | * Practice is made up of ways of thinking (practice specific mental model) and ways of doing. So we need to understand the mental model that we need someone to have and then coach to reinforce (sure train as well). |
| - | * Different roles people etc will have different mental models they will need e.g. Estimation from viewpoint of developer to viewpoint of manager | + | * Different roles people etc will have different mental models they will need e.g. Estimation from viewpoint of developer to viewpoint of manager |
| - | * This is way to develop useful catch phrases | + | * This is way to develop useful catch phrases |
| - | * (Action) Make sure I understand mental models we need people to have for practice and catch phrase to use | + | * (Action) Make sure I understand mental models we need people to have for practice and catch phrase to use |
| - | * (Action) Need to have this coaching discussion with local coaches - get more explicit about what is required from them. Perhaps session by session develop these mental models? | + | * (Action) Need to have this coaching discussion with local coaches - get more explicit about what is required from them. Perhaps session by session develop these mental models? |
| - | * (Action) Shared cognition. Figure out opportunities to leverage | + | * (Action) Shared cognition. Figure out opportunities to leverage |
| - | # Thinking tools | + | ==== Thinking tools ==== |
| - | * Benefit - constraint: for practice, collaboratively as group wherever possible | + | |
| - | * Reinforcing feedback loops: practices need continuous feedback of benefits to become effective | + | * Reinforcing feedback loops: practices need continuous feedback of benefits to become effective |
| - | * Practice maps: show relationships of practices in connected ecosystem. Apply vertical slices approach to implement piece by piece | + | * Practice maps: show relationships of practices in connected ecosystem. Apply vertical slices approach to implement piece by piece |
| - | * Embedded mental models: practice is made up of ways of thinking (practice specific mental model) and ways of doing. So we need to understand the mental model that we need someone to have and then coach to reinforce (sure train as well). Model is (class of person) specific (e.g. Dev vs manager). Catch phrases live here. | + | * Embedded mental models: practice is made up of ways of thinking (practice specific mental model) and ways of doing. So we need to understand the mental model that we need someone to have and then coach to reinforce (sure train as well). Model is (class of person) specific (e.g. Dev vs manager). Catch phrases live here. |
| - | * Shared Cognition: Leverage others to help learn. We operate in a continuous operate / learn cycle (its own empirical cycle) | + | * Shared Cognition: Leverage others to help learn. We operate in a continuous operate / learn cycle (its own empirical cycle) |
| - | # Building Organizational Habits | + | ==== Building Organizational Habits |
| Expectation that we create when we sell transformation - after the sale it will be smooth transformation | Expectation that we create when we sell transformation - after the sale it will be smooth transformation | ||
| Line 528: | Line 527: | ||
| Tools for building organizational habits | Tools for building organizational habits | ||
| - | * Benefit-constraint | + | |
| - | * Reinforcing feedback loops | + | * Reinforcing feedback loops |
| - | * Practice maps | + | * Practice maps |
| - | * Embedded mental models | + | * Embedded mental models |
| - | * Shared cognition | + | * Shared cognition |
| - | ## Benefit-constraint | + | ==== Benefit-constraint |
| A different view of a practice - instead of a procedure treat it like a set of enabling constraints (e.g. CI - constraint is "flow of coding frequently interrupted by integrations" | A different view of a practice - instead of a procedure treat it like a set of enabling constraints (e.g. CI - constraint is "flow of coding frequently interrupted by integrations" | ||
| Line 610: | Line 609: | ||
| Not linear. | Not linear. | ||
| - | ## Practice Map | + | ==== Practice Map ==== |
| Practices for connected ecosystem | Practices for connected ecosystem | ||
| Line 620: | Line 619: | ||
| {{image File: | {{image File: | ||
| - | ## Embedded Mental Models | + | ==== Embedded Mental Models |
| We don't learn to ride cycles by training. We learn by doing. | We don't learn to ride cycles by training. We learn by doing. | ||
| Line 644: | Line 643: | ||
| Need way to validate that hypothesis - what is experiment | Need way to validate that hypothesis - what is experiment | ||
| - | ## Shared Cognition | + | ==== Shared Cognition |
| When we work with people we have a different (better) experience | When we work with people we have a different (better) experience | ||
| Line 668: | Line 667: | ||
| ===== Day 3 ===== | ===== Day 3 ===== | ||
| - | # Content | + | ==== Content |
| - | 1. Organization Structure and Flow | ||
| - | 1. The System Under Development | ||
| - | 1. Adaptive Economics | ||
| - | # Important Ideas | + | - Organization Structure and Flow |
| + | - The System Under Development | ||
| + | - Adaptive Economics | ||
| - | * Once you see something work, hold onto it, and use it to build something else | + | ==== Important Ideas ==== |
| - | * Problems with value streams as org principle for teams -Too big, Too small, Too convoluted, Variable business demand: value stream looks this way one day, different the next | + | |
| - | * Defn Value stream can go in any sustainable direction in which we increment value | + | * Once you see something work, hold onto it, and use it to build something else |
| - | * Work team organization through dependency structure made up of IVA | + | * Problems with value streams as org principle for teams -Too big, Too small, Too convoluted, Variable business demand: value stream looks this way one day, different the next |
| - | | + | * Defn Value stream can go in any sustainable direction in which we increment value |
| - | | + | * Work team organization through dependency structure made up of IVA |
| - | | + | * I - team a depends on team b |
| - | * Hub and spoke model flow visualization | + | * V - platform and two consumers |
| - | | + | * A - two teams supplying one before then can complete work |
| - | | + | * Hub and spoke model flow visualization |
| - | | + | * Kanban board - Product/ |
| - | * (Action) Hub / spoke model flow visualization for PI planning? | + | * CFD on feature and each team (related) - arrival feature starts when any team starts on feature, departure feature finishes when all teams have finished |
| - | * Understand the effect medium you are working with has on economics - benefit of pair programming is that the medium is not code (tangible, slower, after the fact of being made concrete) but rather communication (intangible, | + | * Slice features across teams to validate incremental progress |
| - | * For org (or any design) keep system open for intangible and closed for tangible connections | + | * (Action) Hub / spoke model flow visualization for PI planning? |
| + | * Understand the effect medium you are working with has on economics - benefit of pair programming is that the medium is not code (tangible, slower, after the fact of being made concrete) but rather communication (intangible, | ||
| + | * For org (or any design) keep system open for intangible and closed for tangible connections | ||
| For intangible want to spread information - actively communicate e.g. Using cop, Yammer, wiki, virtual conference | For intangible want to spread information - actively communicate e.g. Using cop, Yammer, wiki, virtual conference | ||
| - | * Hierarchy of (business) demand being fulfilled by (team / capacity) supply through a portfolio (of products). | + | |
| - | * Cannot reduce priority to a single number (e.g. CoD). Idea to use Story Mapping (Patton) / Impact mapping (Adzic) approach to reason about multi-product / smaller number of teams to get some of value | + | * Cannot reduce priority to a single number (e.g. CoD). Idea to use Story Mapping (Patton) / Impact mapping (Adzic) approach to reason about multi-product / smaller number of teams to get some of value |
| - | * Need more lean startup organization to leverage variability. Organization we want is about setting up an environment where an organization establishes hypotheses and validates ideas, and then takes those validated ideas to create business value | + | * Need more lean startup organization to leverage variability. Organization we want is about setting up an environment where an organization establishes hypotheses and validates ideas, and then takes those validated ideas to create business value |
| - | * Sunk cost is a strong cognitive bias | + | * Sunk cost is a strong cognitive bias |
| - | * Move org from "scope driven" | + | * Move org from "scope driven" |
| - | * (Action) Need to think about Kotter in this context. Two operating systems vs change mindset | + | * (Action) Need to think about Kotter in this context. Two operating systems vs change mindset |
| - | * (Action) Need to figure out mental model, feedback loops, benefit / constraint for lean startup style org | + | * (Action) Need to figure out mental model, feedback loops, benefit / constraint for lean startup style org |
| - | * If we don't understand the System Under development we cannot understand the complex system. Start by understanding dependencies within / without | + | * If we don't understand the System Under development we cannot understand the complex system. Start by understanding dependencies within / without |
| - | * (Action) What do I need to understand about storage System Under development? | + | * (Action) What do I need to understand about storage System Under development? |
| - | * Need to help people combat linear thinking. Use Monte Carlo simulation to model and show results. | + | * Need to help people combat linear thinking. Use Monte Carlo simulation to model and show results. |
| - | * There really are 10x people. Need to understand where they are in the dependency of work. | + | * There really are 10x people. Need to understand where they are in the dependency of work. |
| - | * Determine what, if anything to do about Lehmans laws | + | * Determine what, if anything to do about Lehmans laws |
| - | * Idea - develop a " | + | * Idea - develop a " |
| - | * Architecture role - faster, more stable delivery of value. Design flow optimized for responsiveness, | + | * Architecture role - faster, more stable delivery of value. Design flow optimized for responsiveness, |
| - | * Traditionally architecture is way too big and takes way too long. Shrink cycle through slicing | + | * Traditionally architecture is way too big and takes way too long. Shrink cycle through slicing |
| - | * (Blog) " | + | * (Blog) " |
| - | * (Blog) " | + | * (Blog) " |
| - | * Watch being " | + | * Watch being " |
| - | * Watch " | + | * Watch " |
| - | * Sometimes the right answer with a system is to do nothing | + | * Sometimes the right answer with a system is to do nothing |
| - | * (Write Blog) about this | + | * (Write Blog) about this |
| - | * Need to understand side effects of measures as no measure is neutral | + | * Need to understand side effects of measures as no measure is neutral |
| - | * Develop measures based in "what business hypotheses are we trying to validate" | + | * Develop measures based in "what business hypotheses are we trying to validate" |
| - | * (Video) " | + | * (Video) " |
| - | # Thinking | + | ==== Thinking |
| - | * Static - Dynamic mismatch: consider two interacting parts over time - is one side changing, the other not (e.g. Demand and team structure) | + | |
| - | * Tangible - Intangible connections: | + | * Tangible - Intangible connections: |
| - | * Demand - Portfolio - Supply model for organizations | + | * Demand - Portfolio - Supply model for organizations |
| - | * Monte Carlo simulation to help understand system better | + | * Monte Carlo simulation to help understand system better |
| - | # Organization Structure and Flow | + | ==== Organization Structure and Flow ==== |
| Idea - once you see something work, hold onto it, and use it to build something else | Idea - once you see something work, hold onto it, and use it to build something else | ||
| Line 733: | Line 733: | ||
| Perhaps don't have to get too bold | Perhaps don't have to get too bold | ||
| - | ## Organizing to Deliver Value (Definition) | + | ==== Organizing to Deliver Value (Definition) |
| Want to identify flows of value too set up teams / org structure | Want to identify flows of value too set up teams / org structure | ||
| Line 739: | Line 739: | ||
| Problems (or combinations of) | Problems (or combinations of) | ||
| - | * Too big: too many people to reason about the org | + | |
| - | * Too small: too many things to small group of people | + | * Too small: too many things to small group of people |
| - | * Too convoluted: not all value flows left to right, in isolated value streams | + | * Too convoluted: not all value flows left to right, in isolated value streams |
| - | * Variable business demand: value stream looks this way one day, different the next | + | * Variable business demand: value stream looks this way one day, different the next |
| We can abstract flow of work | We can abstract flow of work | ||
| Line 755: | Line 755: | ||
| Number of fallacies about value stream: | Number of fallacies about value stream: | ||
| - | * Product means value stream: may not as may not be incrementing value (e.g. Anyone touching PowerPoint? | + | |
| - | * Functionality that cuts across multiple products, its temporary and therefore just backlog item (e.g. Microsoft move to cloud had no additional features but effected every product for 2 years) | + | * Functionality that cuts across multiple products, its temporary and therefore just backlog item (e.g. Microsoft move to cloud had no additional features but effected every product for 2 years) |
| - | * Business value == customer value and we should organize around customer value (e.g. Customer is input, but business needs to make money) | + | * Business value == customer value and we should organize around customer value (e.g. Customer is input, but business needs to make money) |
| - | * If we organize architecture around value, business demand will stand still (not it will change) | + | * If we organize architecture around value, business demand will stand still (not it will change) |
| Thinking tool | Thinking tool | ||
| Line 769: | Line 769: | ||
| Theory of constraints says have to focus on bottleneck. Right answer might be to stop sending backlog items to " | Theory of constraints says have to focus on bottleneck. Right answer might be to stop sending backlog items to " | ||
| - | ## Organizational Patterns | + | ==== Organizational Patterns |
| Approach | Approach | ||
| Line 788: | Line 789: | ||
| In general patterns of dependency fall into three basic structures (IVA): | In general patterns of dependency fall into three basic structures (IVA): | ||
| - | * I - team a depends on team b | + | |
| - | * V - platform and two consumers | + | * V - platform and two consumers |
| - | * A - two teams supplying one before then can complete work | + | * A - two teams supplying one before then can complete work |
| For V | For V | ||
| Line 807: | Line 808: | ||
| Mental model of Kanban board: | Mental model of Kanban board: | ||
| - | * Left to right | + | |
| - | * Manage WIP | + | * Manage WIP |
| Doesn' | Doesn' | ||
| Line 819: | Line 820: | ||
| {{image File: | {{image File: | ||
| - | ## Choice of Medium | + | ==== Choice of Medium |
| Why do we think pair- / mob-programming work | Why do we think pair- / mob-programming work | ||
| Line 833: | Line 834: | ||
| Message: Understand the effect medium you are working with has on economics - benefit of pair programming is that the medium is not code (tangible, slower, after the fact of being made concrete) but rather communication (intangible, | Message: Understand the effect medium you are working with has on economics - benefit of pair programming is that the medium is not code (tangible, slower, after the fact of being made concrete) but rather communication (intangible, | ||
| - | It is economically good decision to pair | + | It is economically good decision to pair |
| Applies to many things | Applies to many things | ||
| If it takes time to resolve a dependency that you could have picked up in a PI planning event through discussion then wouldn' | If it takes time to resolve a dependency that you could have picked up in a PI planning event through discussion then wouldn' | ||
| - | ## Open / Closed Principle | + | ==== Open / Closed Principle |
| Applied to organizations | Applied to organizations | ||
| - | Ideais | + | Idea is to encapsulate dependencies within " |
| Different types of connections | Different types of connections | ||
| - | * Tangible - Hard: Team A needs something from Team B | + | |
| - | * Tangible - Software: Teams don't need functionality but integrate into same code base | + | * Tangible - Software: Teams don't need functionality but integrate into same code base |
| - | * Intangible - inconsistencies don't lead to delivery issues but increase entropy and misalignment (e.g. Two teams implement "fuzzy search"; | + | * Intangible - inconsistencies don't lead to delivery issues but increase entropy and misalignment (e.g. Two teams implement "fuzzy search"; |
| For org (or any design) keep system open for intangible and closed for tangible connections | For org (or any design) keep system open for intangible and closed for tangible connections | ||
| For intangible want to spread information - actively communicate e.g. Using cop, Yammer, wiki, virtual conference | For intangible want to spread information - actively communicate e.g. Using cop, Yammer, wiki, virtual conference | ||
| - | ## Demand - Portfolio - Supply model | + | ==== Demand - Portfolio - Supply model ==== |
| Thinking tool | Thinking tool | ||
| Line 870: | Line 871: | ||
| {{image File: | {{image File: | ||
| - | ## Defining Value | + | ==== Defining Value ==== |
| Note. Cannot reduce priority to a single number (e.g. CoD). Need more lexigraphical ordering process based on different levers (e.g. Strategic themes) | Note. Cannot reduce priority to a single number (e.g. CoD). Need more lexigraphical ordering process based on different levers (e.g. Strategic themes) | ||
| Line 897: | Line 898: | ||
| Other practices that drive " | Other practices that drive " | ||
| - | * Fixed forecast / fix scope projects | + | |
| - | * promising before we have a capacity discussion | + | * promising before we have a capacity discussion |
| - | * just saying " | + | * just saying " |
| - | * regulatory compliance interpretation | + | * regulatory compliance interpretation |
| - | * capitalization interpretation | + | * capitalization interpretation |
| - | # The System Under Development | + | ==== The System Under Development |
| If we don't understand the System Under development we cannot understand the complex system (as it effects the total system) | If we don't understand the System Under development we cannot understand the complex system (as it effects the total system) | ||
| Line 921: | Line 922: | ||
| What effects " | What effects " | ||
| - | * Unit test | + | |
| - | * Cyclomatic complexity | + | * Cyclomatic complexity |
| - | * Branching | + | * Branching |
| - | * Knowledge sharing (intangible) | + | * Knowledge sharing (intangible) |
| - | * Length of time with branch checked out (more chance of regression) | + | * Length of time with branch checked out (more chance of regression) |
| {{image File: | {{image File: | ||
| Line 937: | Line 938: | ||
| Two problems with this | Two problems with this | ||
| - | * What will happen if low performer at the node of the dependency network | + | |
| - | * Expectation is that high performers try to control what they work on and so won't be on that critical dependent node | + | * Expectation is that high performers try to control what they work on and so won't be on that critical dependent node |
| {{image File: | {{image File: | ||
| Line 944: | Line 945: | ||
| Lehman Laws | Lehman Laws | ||
| - | * The System Under development must be continually adapted or it becomes progressively less satisfactory | + | |
| - | * As a system evolves, its complexity increases unless work is done to maintain or reduce it | + | * As a system evolves, its complexity increases unless work is done to maintain or reduce it |
| - | * As a system LLC associated with it, developers, sales personnel and users, for example, must maintain mastery of content and behavior to achieve satisfactory evolution. Excessive growth diminishes the mastery. Hence the average incremental growth remains invariant as the system evolves. | + | * As a system LLC associated with it, developers, sales personnel and users, for example, must maintain mastery of content and behavior to achieve satisfactory evolution. Excessive growth diminishes the mastery. Hence the average incremental growth remains invariant as the system evolves. |
| - | * The quality of the system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes | + | * The quality of the system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes |
| - | * The system evolution process constitute multi-level, | + | * The system evolution process constitute multi-level, |
| Note - below is another source these are different to the ones quoted by Alex. There is also a more formal version. | Note - below is another source these are different to the ones quoted by Alex. There is also a more formal version. | ||
| - | * The law of continuing change. -- Any software system used in the real-world must change or become less and less useful in that environment. | + | |
| - | * The law of increasing complexity. -- As time flows forwards, entropy increases. That is, as a program evolves, its structure will become more complex. Just as in physics, this effect can, through great cost, be negated in the short term. | + | * The law of increasing complexity. -- As time flows forwards, entropy increases. That is, as a program evolves, its structure will become more complex. Just as in physics, this effect can, through great cost, be negated in the short term. |
| - | * The law of large program evolution. -- Program evolution is a self-regulating process and measurements of system attributes such as size, time between releases, number of reported errors, etc., reveal statistically significant trends and invariances. | + | * The law of large program evolution. -- Program evolution is a self-regulating process and measurements of system attributes such as size, time between releases, number of reported errors, etc., reveal statistically significant trends and invariances. |
| - | * The law of organizational stability. -- Over the lifetime of a program, the rate of development of that program is approximately constant and independent of the resources devoted to system development. | + | * The law of organizational stability. -- Over the lifetime of a program, the rate of development of that program is approximately constant and independent of the resources devoted to system development. |
| - | * The law of conservation of familiarity. -- Over the lifetime of a system, the incremental system change in each release is approximately constant. | + | * The law of conservation of familiarity. -- Over the lifetime of a system, the incremental system change in each release is approximately constant. |
| Idea - develop a " | Idea - develop a " | ||
| Line 965: | Line 966: | ||
| " | " | ||
| - | # Adaptive Economics | + | ==== Adaptive Economics |
| + | |||
| + | |||
| + | ==== Economic prioritization and capacity ==== | ||
| - | ## Economic prioritization and capacity | ||
| Defn - economic prioritization is any form of sequencing of backlog items that produces improved cumulative economic outcomes | Defn - economic prioritization is any form of sequencing of backlog items that produces improved cumulative economic outcomes | ||
| Line 993: | Line 996: | ||
| Sometimes the right answer with a system is to do nothing | Sometimes the right answer with a system is to do nothing | ||
| - | ## Measures | + | ==== Measures |
| No such things as neutral measure | No such things as neutral measure | ||
| Line 1005: | Line 1009: | ||
| Develop measures based in "what business hypotheses are we trying to validate" | Develop measures based in "what business hypotheses are we trying to validate" | ||
| + | {{tag> | ||
| + | |||
| + | ~~LINKBACK~~ | ||
| + | ~~DISCUSSION~~ | ||
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/enterprise_lean-agile_coach_course.txt · Last modified: 2020/06/04 09:03 by hans