Lessons in Agile Management by David J. Anderson

Management
1. #1: On Leadership
  1. The industry is aging
    1. We need new management rules for old geeks (who already regret missing their 20s)
    2. These rules mean establishing process that ensures work-life balance
    3. Old geeks want their capability to produce balanced with the demand from the business
  2. Prairie Chickens who survive long enough end up in the middle
    1. Because failure was punished and success could be achieved by sitting back and watching money pour in, the executives that made to to the top were those who avoided mistakes not those who made bold moves.
  3. Managing to the values vs Making the numbers
    1. You cannot sacrifice the values to hit the numbers in the short term
    2. Managers who don't live by the values should be removed. Period.
  4. Lead people, manage things
    1. 2 different roles for 2 different people
      1. Project Manager
      2. oversight of the delivery to the customer
      3. day-to-day issues & problems
      4. removing obstacles and facilitating flow of work
      5. Engineering Manager
      6. oversight of the system of software engineering
      7. lead & motivate people to do good work
      8. build the team into a learning organization
    2. The team reports to the leader, rather than the manager
  5. New line managers need to learn to live vicariously through their staff
    1. Learning to settle for "good enough" rather than "perfec" (as they would do it themselves)
    2. occasionally, hands-on guidance may be needed
    3. Lead to believe through example
  6. Compensate for Uncertainty with Leadership
    1. the discussion around defining how many good or experienced people are required for any given method is a red herring.
    2. the greater the uncertainty in a project, the more leadership is needed (at all levels) to compensate for it
  7. Some Military Lessons
    1. Nobody gets left behind - "drive out fear"
    2. Everyone gets some sleep
    3. Everyone gets to eat sufficiently
  8. Separation of strategy, operations, and tactics are the three basic levels of delegation for any corporation
  9. Failure tolerance
    1. More responsibility means that more people will act on their own initiative, and that inevitably means more mistakes
    2. If leaner, flatter structures are going to work, we have to invest a lot of effort in helping those in the front line to make the right decisions, not punishing them if they make the wrong ones
    3. Asking for help when in doubt must be seen by everyone as a sign of responsibility, not as a symptom of weakness.
    4. If you're trying to build a high-trust culture, but you've got 14 layers of hierarchy, there's a mismatch
  10. Observations on "The Apprentice"
    1. The show appears to have educated us on bad management
      1. mistakes edited out
      2. leaders taking care of their people considered boring
    2. identifying someone to be "sacrificed" for the survival of the others treats the symptom, not the cause
2. #2: On Management
  1. Improving managers would have the greatest economic impact on software development
    1. "Poor management can increase software costs more rapidly than any other factor" (Barry Boehm)
    2. Managers are responsible for the system
      1. people performing activities
      2. policies that govern, regulate and coordinate those activities
  2. Management
    1. Goal setting
    2. decision making
    3. measurement
    4. analysis of feedback
    5. actions
    6. interventions
    7. investment strategy
  3. Managers as Permission Giver
    1. People can tip the balance and cause a cascade of behavioural changes by either leading by example or giving permission
    2. "I give you permission to take the time to do designs"
  4. Management misdirection: mechanisms to deflect blame / elude responsibility
    1. Individual measurement is management misdirection
      1. Bad managers use it to know who's to blame
      2. Bad managers do not see it as their own failing that they don't develop their people
      3. Flipping the metric around: interpret the metric as the measuring the manager's ability
      4. individuals are almost never responsible for their own performance, but rather victims of the variation in the tasks that they had to perform (Deming)
      5. When you start measuring developers, you incentivize them to start hoarding, rather than sharing information
      6. individual measurement is also demotivational, as it is seen as invasion to privacy
    2. trading off quality in exchange for fast hacking sets the team for failure
    3. Line manager squeeze: setting an impossible tasks for line managers to accomplish: senior management diverts attention and deflects blame and criticism onto junior managers
  5. Much of your team's performance is being constrained by policies
    1. Policies are under your control (or your boss' control)
    2. Just change the policies!
  6. Two types of underperformers
    1. Performace is the manager's responsibility
    2. Managers are responsible for the "can't do the job" employee
      1. The manager should never have hired them in the first place
      2. The employee is still trying to do their best, even when it isn't nearly good enough
      3. Managing the "gardener" out of the team is the manager's responsibility
    3. For those who "won't do the job", the manager's responsibility is to deal with the "attitude" by making plain why and how they need to change
      1. Treat the person as bench slack, out of the critical path
      2. The person will either change their attitude and re-integrate into the team, or self-select out of the organization
    4. Learn to deal with dysfunction as a separate management problem, and focus on improving capability
3. #9: On Human Resources
  1. HR Myth #1: Merit-based pay
  2. HR Myth #2: Divide & Conquer
  3. HR Myth #3: Performance Buckets
  4. HR Myth #4: Tribal Markings
  5. HR Myth #5: More thoughts on Pay-for-Performance
  6. HR Myth #6: Where comparative pay scales came unstuck
Systems Thinking
1. #3: What Would Drucker Do?
  1. Drucker told us to lead people and manage things
  2. The next great challenge: manage the knowledge worker for productivity
    1. Invisible work is impossible to manage
    2. Invisible work is easy to hoard and stockpile
    3. Excessive demand and invisible work result in overburdening
  3. Effectiveness is a habit, a complex set of practices. Practices can be learnt
    1. Drucker leaves us hope: if we teach, coach, mentor, and instill the correct set of practices, effectiveness will follow
  4. Workmanship must be encouraged, but it must always be related to the needs of the whole
    1. "I'm making a living" (just getting what I need out of the job)
    2. "I'm doing the best job of stonecutting in the country" (this is the problem)
    3. "I'm building a cathedral" (the true manager)
  5. Developer as Executive
    1. Every line of code affects performance (functional or non-functional) of the product
    2. Every design decision potentially affects the ability of the business to respond to market demands
    3. if developers are simply left to design, develop, and test without supervision, individual developers are making "executive decisions" in their own, every day.
    4. Understand that each knowledge decision is an executive decision and put processes in place to control the quality of those decisions and ensure that they are aligned with the strategic direction of the business.
2. #4: Inspired by Deming
  1. Demings teachings
    1. capability must be viewed in light of it variation, and that it isn't constant (or average)
    2. to truly respect people, managers must design a system that sets them up for success. To do so, one must understand the capabilities of the system, and the demands set upon that system
    3. 95/5 rule: 95% of the observed capability of the system is determined by its design, only 5% is affected by the capability of individual workers
    4. 2 management mistakes
      1. #1: Interfering when everything is normal (tampering - behaving in the way it is designed to work)
      2. #2: failure to intervene when a process is out of control (behaving differently from what is designed to do)
  2. Choose to be inspired by Deming rather than dogmatically following his methods
    1. A narrow focus on reducing variation may not be optimal from a customer-service perspective
    2. Calculating control limits based on +/- 3 sigma may not be relevant in our world
  3. Deming's thinking is very well aligned wkth Agile
    1. Quality is defined by the Customer, and not the spec
    2. Quality is conformance to process and not to spec
    3. Management is about managing the process
    4. By embracing variation and accepting it as inherent to the work, the people aspect of "individuals and interactions over processes and tools" is embraced
  4. Kanban training is management training (in the Deming's sense)
    1. promotes understanding the system, explicitly defining its policies
    2. makes managers take ownership of system design
  5. Variation
    1. Knowledge work has high level of uniqueness to it. Variation is then inevitable.
      1. We need a probabilistic approach to managing software development rather than the predominantly 20th-century deterministic approach
    2. To meet project promises and deliver on time, schedules must be buffered against common-cause variation
      1. This requires understanding an understanding of the team's historical capabilities and a prediction of their future capability
    3. To buffer for special-cause events may allow for face-saving, on time delivery, but it's very expensive
    4. Any reasonable senior manager should expect line managers to buffer common-cause variation appropriately, while accepting that unforeseeable special-causes can still make a delivery late. They should accept the outcome as a consequence of an appropriate risk-management choice and avoid attributing blame or fault
    5. Understanding variation is the vital ingredient in driving out fear
      1. There will be fear at the staff level only if assignable-cause variation has been inadequately addressed through risk-management planning.
      2. The only fear should be on the impact of the event, and not the repercussions from managers
      3. There is no point in assigning blame for assignable-cause variation that is beyond the control of the team, the managers, or the organization. And there's never a basis for assigning blame for excessive chance-cause variation
      4. Large amounts of chance-cause variation are the norm in software development. If we can teach managers to see it for what it is, we can teach them to act appropriately. The result will be less fear in the workplace.
  6. Quality as a competitive Weapon
    1. The Four States of Control helps us understand how to reduce fear in the org
    2. Conformant quality means that customer expectations were delivered
      1. We can be there just by luck (in spite of lots of assignable-cause variation) - Brink of Chaos
      2. We can get stay there (Ideal State) by getting eliminating assignable-cause variation, and reducing chance-cause variation, or understanding it sufficiently to set proper expectations
    3. If you can reduce your chance-cause variation, that moves the Spec Line to the right, essentially pushing your competitors into the Threshold State
      1. To do this, you need to change your process
      2. you need better technical practices and better, more consistent implementation of those practices
3. #5: Goldratt and His Theory of Constraints
  1. ToC gave us the model to look for explanations of why Agile works
  2. Lesson #1: Small Batches
    1. instituting small batches (coupled with a focus on quailty) is often enough to bring big results (D. Reinertsen)
    2. it is the size of the iteration or project that represents the amplitude of the control signal (the size of the feedback loop).
      1. The longer the amplitude, the more difficult the process is to control
    3. Small batches enable "conformant quality == on time, on budget, with required scope", because they reduce the likelihood that requirements will change (pg 108)
  3. Lesson #2: Resistance to Change
    1. A hero is the master of chaos
      1. Heros are heros because they delivery
      2. A hero measures their self-esteem by their prowess at putting out fires
      3. A hero doesn't want to be under control because their self-esteem will drop when they are no longer praised for being a hero
    2. The organization wants to be under control and to deliver predictably, but some staff members thrive on chaos and their status in the organization depends on it
    3. Senior management must start to reward people for behaviours that are congruent with controlled performance, and they must build self-esteem around that behaviour
  4. Lesson #3: Don't assign blame
    1. Describe your challenges as system problems
    2. "I can't deliver to expectations because my inputs suffer from [this] excessive common-cause variation and [these] specific special-cause variances"
  5. Socratic Method considered dangerous
    1. The person being questioned feels manipulated
    2. The method works when the relationship is a coaching relationship (the coachee is treated as an expert)
    3. The Socratic Method is considered dangerous when the inquisitor is an expert and the inquisition is designed to educate the other party.
    4. I think that using the Socratic Method as a teaching tool is best avoided altogether
    5. Kanban system design is about mapping the current practice and exposing it in such way that system effects are revealed for everyone to see, and in a way that connects with them emotionally as well as logically. A purely logical analysis, based on expert knowledge and experience and using the Socratic Method to reveal common system effects, is still likely to invoke a negative response.
  6. When Policies move the bottleneck
    1. Introducing a new policy can move the bottleneck, suddenly causing people downstream from it to become idle
      1. If this is not planned and understood in advance, it can lead to accusations, blame, and loss of trust
    2. The introduction of new policies should not be made locally; local benefit could be outweighed by negative system-wide effects
  7. Variability & Drum-Buffer-Rope
    1. The production rate can increase in a stable fashion only if you either
      1. increase the size of the buffer
      2. decrease the variability at the constraint (while avoiding moving the constraint to other part of the system)
  8. Geeks don't like to be idle
    1. "I've been under-utilized in this project" == "I had slack time" == you weren't the bottleneck
      1. Developers like the idea that success lives and dies with them: if they work more, software is done earlier
      2. Intellectual efficiency: the preference for bigger batches that allow for longer, focused period of work
    2. The solution is to provide for planned "bench" activities
    3. Intangible CoS improves overall capability
      1. Reduces likelihood of overproducing customer work through large batches, leading to longer delivery times, and the cost of perishable knowledge
      2. It helps putting "slack time" to good use and reduces emotional resistance
  9. Improving a Constraint
    1. Measuring Capability
      1. To measure capability, simply observe the throughput of units of value over a period of time
      2. then, define capability in terms of a mean and a reasonable range around it (per unit of time)
    2. Subordinating to Capability: this is how you identify the constraint
      1. The average capability of the whole system, shown at the output, is the average capability of the constraint
      2. I.e. if we observe throughput at the output, we don't really need to know where the constraint is
      3. We then need agreement from the upstream process to supply us with work at the same rate we can consume
      4. The constraint now will be revealed: all the other stages will have slack time
      5. Devs will start putting this slack time to good use, because they don't like to be idle
      6. Now we can apply the 5 Focusing Steps
  10. Stop Estimating
    1. Estimates are inaccurate at best, pure fantasy at worst
    2. The logical argument that is psychologically unacceptable
      1. Plan based on observed throughput capability and embrace the concept of natural variation
      2. The problem is that the spread of variation can be so great that customers are unwilling to accept plans that are based on such wide spread of variation
    3. The pragmatic alterative: offer a package of classes of service
  11. Drive Variability out of the Bottleneck
    1. The original thinking
      1. Driving variability out of the bottleneck is required for predictable delivery, since the bottleneck determines the performance of the system
      2. Also, if your bottleneck capability fluctuates significantly, the bottleneck might move somewhere else in the workflow, and now you don't know where it is again.
    2. What was learnt since then
      1. large amounts of chance-cause variation are normal in knowledge-work
      2. shifting bottlenecks are a fact of life, and therefore attempting to contain variation at the bottleneck so it remains at a constant and predictable position is not practical
    3. Evolution of TOC & Kanban
      1. Goldratt identified that the real constraint in change is emotional resistance. As a reaction, he developed the Thinking Process, which defines an outcome known as the Future Reality Tree (FRT)
      2. DJA chose to develop an evolutionary approach that doesn't define an outcome or prescribes a transition plan. It pursues a guided-evolution approach based on scientific understanding of the flow of work and the implementation of safe-to-fail experiments that guide the existing process in a series of steps
      3. Both the Thinking Process and the Kanban Method can be seen as evolving from a common ancestor (the Five Focusing Steps). The Thinking Process took the route of a planned transition, whereas the Kanban Method continued the evolutionary approach inherent in 5FS.
  12. Process Batch & Transfer Batch: How long should the iteration be?
    1. Process batch
      1. a batch of work that is done by a person, group, or system.
      2. they are grouped together for efficiency, or for reasons of constraints
      3. Every batch has a setup and cleanup cost
    2. Transfer batch
      1. a batch that is transferred down the value chain and passes to another set of workers or to the end customer
      2. they tend to be optimized for the costs incurred by the next stage in the value chain
      3. the transaction costs associated with transfer batch can mean that the transfer batches have to be significantly bigger than the process batches
    3. Iteration and release sizes need to take all these costs into account, and that means they are different in every domain, ad potentially for every customer
4. #6: On Constraints and Transportation Systems
  1. Good Systems Thinking examples
Tribalism
1. #7: Recognizing Tribal Behaviour
  1. Sense of belonging
    1. Identity marks within a larger organization are divisive
    2. Emotional resistance should be trumped by a stronger emotion.
      1. people must be motivated by emotion in order to change behaviour
      2. logic doesn't motivate, but emotions will
      3. fear is the most common choice, but it comes with negative side effects
      4. Pride is strong, largely positive
      5. Hope is also strong
  2. Tribalism
    1. Sense of belonging goes too far when it becomes tribalism rather than affinity and shared experience
    2. Your tribe will make enemies by exclusion
    3. We need to recognize tribalism as inevitable, genetically wired. Denying tribalism leads to dysfunction
    4. When tribes are warring,, the way to unify them is not to appeal to their intellect, but to create a super-tribe to which they can all affiliate
2. #8: Managing Tribes
  1. Change is the norm! There's really no TS+, it's an illusion
  2. Great leadership ensures just enough insecurity to keep innovation and risk taking at the fore while it controls the comfort that leads to backstabbing and infighting
  3. Understand your Tribe
Agile Development
1. #10: Understanding Agile
  1. Good, Fast, Cheap -- pick three!
    1. Companies that are built to last do not accept the "tyranny of OR"; instead, they embrace the "genious of AND"
    2. Agile is really about having it all
      1. A core focus on quality and workmanship results in less escaping defects, freeing capacity to use it in more valuable work
      2. face-to-face communication & less bureaucracy produces faster lead times
      3. small, self-organizing teams reduce cost
  2. Trust is the essence of agile
    1. What is Agile?
      1. two schools of thought
      2. short feedback loops
      3. treating people as humans
      4. psychology has been acknowledged as important in software development since the 60s, but inclusion of sociology and an understanding that the interactions between people are a vital part of successful knowledge work is the novelty Agile introduced
      5. Trust is what makes Agile unique
    2. Where there's trust, there's less waste, less extra work, less verification, less auditing, less paperwork, less meetings, less finger-pointing, less blame storming
    3. The first goal of an Agile manager is to build trust between the engineering team and their customers, and within the team
    4. Various aspects of Agile are about building trust
      1. frequent delivery
      2. focus on working code rather than documents
      3. face-to-face communication
      4. pair programming and peer reviews
      5. stand-up meetings
      6. shared responsibility & joint accountability
      7. direct collaboration with Customers
      8. tracking and reporting based on customer-valued functionality
      9. information radiators, big visible charts & complete transparency
  3. Agile Litmus Test
    1. How much trust is there in the room?
    2. The more trust there is, the fewer transaction costs there will be
      1. Less overhead for transaction costs means less waste
      2. Less waste means better economic outcome
    3. A better economic outcome should ultimately be the reason we adopt Agile
  4. Instilling Discipline
    1. Traditional heavyweight methods replace professional discipline with process; they don't trust the discipline of workers
    2. When you have discipline, you don't need hierarchy
    3. Discipline is not a pre-requisite to Agile, but it's a necessary component (both at team and individual levels) for successful Agile adoption
  5. Making progress with imperfect information
    1. while Trust is the key differenciator for Agile, the true essence of Agile is the concept of moving forward with imperfect information and being prepared to rework later
    2. The core mistake was to assume that acquiring perfect information is possible in a complex endevour like software development
      1. Boehm's 1976 findings on cost of change favoured the pursuit of perfect information early in the lifecycle, leading to analysis-heavy processes
      2. But software development is too complex for that to work
      3. Kent Beck's intuitively refuted Boehm when framing XP
    3. What is required is to probe for more information with partial or approximate solutions, and implement feedback loops to iteratively pursue the answer
      1. Boehm's later work on the Spiral Model during the 80s shows that he understood this; the rest of the industry didn't
      2. Rework is not "waste" in the traditional sense; rather, it's a mechanism for further information discovery
    4. Real-options analysis
      1. the option we're buying is to deliver working code sooner
      2. the cost of the option is having a developer start work before the final spec is ready, which carries the risk of incurring rework that will make the whole effort longer than waiting for the full spec
      3. if all this rework is performed by a non-bottleneck resource, then it doesn't cost anything extra (non-bottlenecks have idle capacity)
      4. Developers can use that slack to perform required refactoring
  6. What are the right conditions for Agile adoption?
    1. high social capital (trust)
    2. liberal thinking (open to new ideas, new thinking, and influence from outsiders)
2. #11: Agile Practices
  1. Why we lost focus on Development Practices?
    1. Programming and programmers are not the constraining factor on improved performance
    2. with immature teams having sloppy development practices and poor initial quality (high defect insertion rates), development is the constraint. Agile has successfully fixed that!
    3. The rest of the community has moved its focus to other areas, most notably project management and business analysis, where the constraints are occurring
    4. As the wider community fixes the issues there, and improves flow of value, the focus will swing back to engineering and development practices
    5. In the meantime, it's a compliment not to be the focus of attention :-P
  2. Agile Estimating & Why it is "muda"
    1. traditional forms of estimation are a waste of capability
      1. When we spend time estimating something, and we use a capacity-constrained resource, we lower our capability
      2. Doing the estimate in advance before the work is actually done means that anything learnt from the estimating process is lost
      3. Often we estimate work that gets cut or doesn't get done at all because the estimate was too large!
    2. Analysis is value-added work
      1. analysis creates knowledge that is used to deliver customer-valued functionality
    3. replace estimation with a lightweight estimation method: a model and some data to develop a probabilistic view of the future
      1. Data about the throughput by unit of time
      2. an idea of the mean rate
      3. an idea of the spread of variation
      4. a buffer to account for variability
      5. Caution: don't use velocity data for short term planning !
    4. replace estimation with analysis [just-in-time] to do the work
      1. Estimation is about quantification of cost; analysis is about decomposition and integration of a set of parts
      2. Analysis reduces variation and makes plans more accurate
3. #12: Defining Agile Leadership
  1. Declaration of Interdependence
    1. We need to treat project as flow problems
      1. The value chain creates consumer value by transforming ideas into working knowledge through a series of transformative steps
      2. Once you have a flow model, you can look for bottlenecks in the flow, and know where to focus to maximize ROI
      3. The primary role of the Agile Manager is to focus on what's obstructing flow
      4. the role of the Scrum Master
    2. close partnership with customers
      1. "partner" means to align the supply chain's interests and focus on the end consumer
      2. putting the customer's skin in the game through inter-active partnership and frequent contact is what gives us the ability to deliver reliable results
    3. we expect uncertainty and manage for it
      1. variation, change, unknowns, chaos
      2. Anticipation should enable swift, more agile reaction
    4. we view individuals as assets in a business, encouraged to take risks, make a difference, and innovate
    5. optimal performance through group accountability and shared responsibility
      1. optimal performance is reached when everyone in the value chain partners together and has a vested interest in the success of the whole chain (as opposed of by focusing on individual efficiency)
      2. group accountability = "we are all in this together"
      3. We succeed together
      4. we accept responsibility for our failures
      5. by creating an environment of personal safety individuals as motivated to do the right thing for the whole system, since they don't need to make local decisions to protect themselves
      6. No need to ask for "courage" when we provide "personal safety"
    6. effectiveness and reliability come from situationally specific strategy, processes, and practices
      1. it's OK to customize techniques, methods, practices, IF you can show it leads to more economically effective solutions
      2. unique processes evolved for fitness in their own environment
  2. Kanban fully implements the DoI
    1. Increase ROI though focusing on continuous flow
      1. by visualizing the workflow, limiting WIP, managing flow, measuring lead times, and optimizing value delivery with classes of service based on the economics of delay
    2. Reliable results by engaging customers in frequent interactions
      1. Customer engaged through visualization
      2. By asking Customers to take shared ownership of the system and it's effectiveness, and to throttle their demand to the rate at which the system can deliver
    3. managing uncertainty through iteration, anticipation, and adaptation
      1. Classes of service demonstrate anticipation of demand
      2. quantitative measurement, using statistical observation of capability, manages for uncertainty
      3. WIP limits and social interactions encourage adaptation
      4. Time-boxed increments are replaced with cadence
    4. unleash creativity and innovation by recognizing individuals
      1. Limiting WIP creates slack, which creates space for creativity and innovation
      2. Making policies explicit empowers people to make their own decisions, and be creative about their process, and optimize the economic outcome
    5. boost performance through group accountability and shared responsibility
      1. operations review allows a wider group of stakeholders to take shared responsibility for the effectiveness of the whole system
    6. improve effectiveness & reliability through situationally specific solutions
      1. Start from where you are now and evolve from there
4. #15: On Roles, Responsibility, and Organizational Structure
  1. ARCI (rather than RACI) is firmly a facet of the command-and-control management style
    1. In a command-and-control world, if no one is assigned as accountable (to give out orders) the work never gets done
  2. Committed-Involved (pigs-and-chickens) removes the problem by merging doing with giving orders
    1. Those in the team doing the work (committed) are jointly accountable & responsible
    2. Those in the team not doing the work (involved) are simply consulted or informed
  3. Line managers are "Chiglets"
    1. When an assignable-cause event happens and escalation is needed in order to remove the impediment and get work moving again, suddenly the line manager is a pig.
    2. Line managers live in a world that oscillates between two states, neer quite stable as either chicken or pig
  4. The chicken/pig division is a direct impediment to successful enterprise Agile transformation
    1. Negotiation vs collaboration
      1. Governing policies should be agreed upon collaboratively
      2. You must get everyone committed to delivering on business goals
      3. Then, everyone must be a pig
    2. Transparency and Inclussion in Policy Making
      1. Giving stakeholders a say in setting policies and day-to-day transparency makes everyone a pig, and changes the relationship
      2. If stakeholders are kept "chicken", they will feel they can't really get a sense of what's going on and they will start intruding, eroding the relatioship
    3. Lack of inclusion coupled with lack of transparency breeds fear in managers, often causing them to react with inaction and immobility.
    4. Conclusion: there are no chickens.
#13: Lean
1. Inventory is more than Documentation
  1. Early use the Lean Manufacturing metaphor led to interpret that inventory is documentation, and needs to be eliminated
  2. Inventory is all the work flowing through the system but not yet sold
    1. Documentation is only part of inventory
    2. WIP is inventory
    3. Unfinished goods are inventory
2. Waste elimination is a tertiary concern
  1. Waste should not be reduced to the detriment of flow, and smooth flow can be sacrificed to improve value delivery
  2. Lean Decision Filter
    1. Value trumps flow
    2. Flow trumps waste elimination
    3. Eliminate waste to improve efficiency, do not pursue economy of scale
3. Use of Cumulative Flow Diagrams (CFD)
  1. Burn up charts are not sufficient for managing a project
    1. they have no concept of WIP
    2. projects tend to follow an S-Curve
      1. projecting the anticipated end-date is problematic if you just draw a linear trend
  2. WIP is knowledge inventory, and is perishable
    1. (1993) Marvin Patternson: design as an information discovery process
    2. (2003) Mary Poppendieck: all software development is design
      1. We can model the flow of value through a software engineering system as the gradual reduction of uncertainty and the discovery or more and more detailed information until working code is produced
    3. (1997) Donald Reinertsen: the value of information depreciates over time
      1. To have real value, a design must be appropriate for its time, and come to market within its window of appropriateness
      2. knowledge and information are perishable
      3. the faster requrements can be realized as working code and brought to market, the more value will be delivered
      4. Lead time for turning an idea into working software is then critical for the financial success of any software activity
  3. WIP is a leading measure
    1. The size of the inventory is directly proportional to the average lead time (Little's Law)
    2. WIP can be used to predict lead time and delivery date
4. Dark Matter
  1. Project dark matter is unrecognized , client-valued functionality
    1. Requirements that your customer knows to be there, but couldn't see when defining the requirements
    2. It will look like scope-creep, but the customer denies having asked for any changes
  2. Is always there, embrace it!
    1. If part of the essence of agile development is to make progress with imperfect information, dark matter is inevitable. Attempts to prevent it destroy the very agility you're trying to achieve.
    2. Analysis can never be perfect. When you can accept that, and accept the probabilistic paradigm, you can move forward earlier and complete sooner
    3. Use two questions to calculate a scope buffer
      1. How certain are we about this domain?
      2. How comfortable are we that we caught all the detail while doing the domain modeling and client-valued functionality identification?
    4. Enter a "Dark Matter" line in earlier project plans, and replace it later with new things that are discovered
      1. in the CFD, dark matter should be plot different from "new requirements"
    5. understand Cost of Delay, and recognize that earlier, faster progress to a partial solution is ofteh better than delaying to acquire better information leading to a more solution.
5. The "Standard Work" concept is dangerous when translated to knowledge work
  1. centralized tool decisions is a manifestation of the cost accounting fallacy
    1. There's economy of scale for a larger license purchase
    2. But, what does it do to thorughput
  2. centralized tool standards represent a constraining policy
    1. They disempower development managers and developers, creating a poor environment for optimal productivity
    2. demoralizes workers and constraints performance
  3. Software process choices should be aligned to workflows
    1. the market into which the product is deployed should be well understood
    2. the minor cost-efficient advantage of the whole staff being trained in one method is far outweighed by the problems created, and the cost in ROI, by the use of the wrong process for the job
6. Genchi Gembustsu ("going to the source")
  1. imagination-based techniques deliver a better payback than actually "going to the source"
    1. Lean Startup: Don't just go to the source beforehand; rather, spend very little time and money and go to the source with something that works and gets feedback.
  2. going to the source (sitting with the users) can be misleading if it leads to observing a badly broken system
7. Set-Based Design isn't relevalt in sofware development (Reinertsen)
  1. SBD has made little progress in software development
  2. Perhaps the reason is that sofware is inherently "soft" and the cost of change is generally lower than the cost do developing parllel alternative solutions
  3. Software can be architected to leave options open and defer design decisions, or decisions can be made and then changed at relatively low cost
8. Good vs Bad variation
  1. Organizing for routine work: drive out variation
  2. Organizing for innovative work: encourage variation
#14: Random Thoughts on Risk
1. Two definitions of "risk"
  1. event-driven risk
    1. Common in PMI lierature, but much more narrow
    2. Risk is an event that will hinder or affect the successful completion of a project
      1. it has a likelihood of occurrence, and an impact
      2. it can be managed through efforts to reduce likelihood or mitigate impact
  2. uncertainty-driven risk
    1. much broader meaning
    2. Risk refers to the uncertainty being managed by the enterprise as a whole, rather than specific events
      1. wider economic factors
      2. the competition
      3. the quality of the product
      4. how well prospective customers like the product, and how quickly they adopt it
      5. our ability to understand the market
      6. our capability to deliver against fluctuating demand
      7. ability to react to unfolding events
      8. our propensity to innovation
      9. our strategic and market positioning
    3. Risk management is everything we do to make our business successful
    4. By implication, all knowledge workers are risk managers
2. Risk Planning
  1. how to deal with variation
  2. how to set expectations accordingly (in the presence of variation)
  3. how to accommodate variation as if it were natural (because it is!)
3. Risk: how long?
  1. "Approximately 44 minutes" is variation-aware language
4. Risk: what should we build?
  1. strategic positioning: your business can be (one of)
    1. a cost leader (there can be only one)
    2. a niche player (with market share typically less than 10%)
    3. differentiated (many forms of differentiation)
  2. what features do you need?
    1. If you're a cost leader, all you need is the table-stakes, and possibly Cost Reducers
    2. if you're an innovator
      1. Differentiators
      2. Spoilers
  3. An enumeration of [Table Stakes, Differentiator, Spoiler, Cost Reducer] allows you to align strategic positioning directly with our maketing prodict mix selection choices
    1. works better than "prioritization"
    2. Risks should not be "prioritized"; rather, they should be allocated
5. Risk: future changes in design
  1. We cannot generalize about the cost of change
    1. Both curves are wrong
      1. Traditional guidance (Boehm's cost of change curve) suggests that options for future changes are ALWAYS worth buying (leading to BDUF)
      2. Kent Beck's YAGNI heuristic suggests that options for future change are NEVER worth buying, because changes later in the lifecycle can be made lower
    2. The cost of change depends on the position of the constraint in the workflow, the variability inherent both in the domain and the method, and the skill level of the practitioners performing the work
  2. Getting software developers to think abut early-lifecycle decisions as "options" would be a step forward
6. Risk: building something the market doesn't want (market risk)
  1. what's the likelihood and impact of change on different kinds of requirements?
    1. Table stakes are unlikely to change
    2. Cost savers may suffer change more often than table stakes, but it's still rather unlikely
    3. The risk with spoilers is that they become table stakes by the time they are introdiuced
    4. Differentiators are the most risky because they may turn out to be features customers don't want
  2. We should delay risky items that are likely to suffer change until the last possible moment
    1. commodities first, differenciators later
      1. proper market segmentation will reveal are truly table-stakes, and for whom
    2. developing differentiators early to test them confuses research with product development. These are parallel activities
  3. two reasons NOT to pursue a value-first strategy
    1. value is hard to define, and will have high variability in it
    2. market risk that puts the viability of the feature at risk. It's bad use of option theory to prioritize something before we have enough information to be sure we really want the feature delivered.
7. Banish "priority" and "prioritization"
  1. Priority is a "proxy variable" (Reinertsen)
    1. masks real information, like cost of delay, required skills, technical impact, transaction cost, etc.
  2. find ways to capture and visualize true risk information that the business is managing
  3. "Priority" then becomes something that can be decided dynamically when a pull decision is made
    1. Prioritization is then not needed
    2. Backlogs can remain an unordered list
    3. instead, we can use "selection", "scheduling", "replenishment"
  4. Prioritization is wasteful
    1. It encourages roles/positions for people who do mostly non-value-added coordination work, and they add to the transaction cost of flowing work through the system
#16: On Transition Initiatives
1. The Kanban Method is a truly agile approach to change management
  1. attempts to change towards a defined process is likely to be met with resistance.
  2. the irony of "agile transitions" is that they are based on traditional change management methods
    1. the defined process prescribed in a textbook is to be implemented over a transition period that integrates education, training, practice and coaching
    2. this goes against the agile core concept of making progress with imperfect information, which imply that we cannot know everything in advance, and that predicting the future is a low-leverage activity
2. No mode quality initiatives
  1. The problem with "quality initiatives" is that change does not last
    1. Just say no
  2. Two likely results of a process-led change initiative (in which responsibility for change is seen as delegated to a group)
    1. attitude of "improvement isn't my responsibility"
    2. resistance to changes that are seen as imposed from the outside
  3. The fix: quality and continuous improvement is everyone's business
    1. change must be cultural and that the focus of any management-led initiative must be to drive cultural change towards a culture of continuous improvement
3. Institutionalization of Culture vs Prescribed Process Change
  1. At Corbis, DJA opted for the longer game of cultural change instead of prescibing a method
    1. the J-curve effect would have been too deep and too long
    2. instead, a kaizen culture was encouraged: grassroots, shop-floor improvement suggestions within a structured objective framework of management metrics
    3. monthly all-hands ops reviews
    4. Gradual, sustained improvement, not knowing how it's going to turn out
      1. emergent results
      2. no testable definition of DONE
  2. there was wide recognition of improvements, but not "hyper-productivity"
    1. higher degrees of autonomy, delegation & empowerment, self-organization
    2. a lot of successful software releases
  3. DJA concluded that it takes longer to achieve hyper-productive results with cultural change
  4. The hope was that changes would survive longer, but they started to degrade after DJA left in 2008
    1. Management decided to reduce the frequency in ops reviews, signaling a change in culture
    2. It sent the signal that management didn't care much about process improvement
  5. Corporate culture emerges from the sum of management actions and decisions. It only takes a few decisions and actions to significantly change culture (for better or worse)
4. The relevance of (CMMI) Level 4
  1. Level 4 is often seen as a level to skip (from 3 go to 5)
  2. But organizations want to be predictable, to deliver on business goals within tight financial controls and corporate governance
    1. strong delivery with low variability
    2. proactive
    3. drive down cycle times using quantitative management
    4. Subtopic 4
5. Six-Month Review
  1. Acceptance Tests for an Agile process
    1. Is software being released into production every two weeks or less?
    2. is the quality of the software high?
    3. is the technology organization able to respond to changes in the business rapidly?
  2. The AT does't include the test of doing things that are "recognizable" agile practices
  3. There is more than one way to achieve agility