2016/09/12 Leffingwell Training Day 1 Part 2e

by Gene Kim on

#@deanleffingwell

2016/09/12 Leffingwell Training Day 1 Part 2e

  • @deanleffingwell

  • set based design is the key economic tool for improving outcomes

  • the learning happens in the largest outer loop: like Harley Davidson mules; crop combines; must integrate engine and drivetrain

  • “product development is the process of converting uncertainty to knowledge —Dantar Oosterwal

  • every 2 weeks at Harley Davidson: pull event: demo:

Principle 6: Visualize and limit WIP: reduce batch sizes; manage queue lengths

  • “long queues, all bad”
  • “given average processing speed of 10 features per quarter and committed set of 30 features, a new feature wil. Expected wait time of 30 / 10”
  • backlog is a queue, if they have been committed
  • control wait times by controlling queue lengths
  • we focus on stories, not tasks — if we can achieve the story without a task, great!

  • story by looking at story board: it’s Wednesday, and only 3 of 11 stories even in test; they’re in trouble

  • countermeasure: 3 story WIP limit: Mean Dean

  • WIP limit: dev helps with testing

  • first large scale: inspect and adapt: “we don’t have enough testers”

  • “not enough testers; not enough testers..”. “Wait, no, we have too many developers!” “Wait, I can test!”

  • story of Russian outsourced QA: we doubled tripled quadrupled the number of testers; only solution was throwing developers at testing

  • enterprise: 100% utilization, large queues, huge batch sizes; no wonder we have a problem

  • smaller batch sizes have lower variability over time

  • first penny completed at 15 seconds vs. 2 minutes; 8x improvement

  • time to market is easiest, just by reducing batch size / reducing scope

  • in 1 week sprint, transaction cost seems too high; planning for 1 week doesn’t take 50% of planning for 2 weeks

  • beyond 12 weeks, it’s hopeless, b/c not enough learning; at SAFe, they are at 12 weeks...

Variability

  • validation and verification: not the same, but happens at the same time
  • story: 250 people in $250MM business; PMO plans were crap; we had to plan in once place; led to creation of PI; planning is best done by people doing work; all execs were in middle of room, with sign called “Helpdesk”. There to empower decision makers

Empowering knowledge works: death of Taylorism

  • 1949 experiment: Taylorist scientists: University of Wisconsin: thesis monkeys

Decentralize decision making

  • strategy is the responsibility of the fiduciaries who owe a return to shareholders;
  • move authority to where information is
    • engineer decides when to ship
    • salesperson can close the deal
  • “Dan Pink: Clarity on how to think, without clarity on how to act, leaves people unmoved”

Lesson 4: Experiencing PI Planning

  • team: 15-65 people; common objective
  • often need a lot of people to create value
  • agile teams drive the train
    • scrum master: facilitate, coach
    • product owner: own team backlog
  • “Release Train Engineer: in our last class, 3:1 ratio of women:men”
  • estimation poker: everyone throws down card together, discussion of just the outliers

Role Play / Exercise: PI Planning

Questions

  • what are the units of measure for transaction cost for deployment?

TODO

  • tweetscriber_web: app seems to be crashing because of Tweet returning with failures; maybe too many username GETs coming in from scrapers?
  • would be great to have green/red on tweetstream, on Save Scribe (based on some heartbeat?)
  • When Set Hashtag fails, we need some way to relogin and connect, and get back into normal state
  • to make TweetScriber_web crash, just look for GET /CFEngine, /Salesforce


2017-09-12T20:07:29.817049+00:00 heroku[web.1]: State changed from crashed to starting
2017-09-12T20:07:33.146164+