Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How to be an Evil Scientist

How to be an Evil Scientist

Have you ever fancied turning your co-workers into laboratory rats and have them scurry around a maze searching for food whilst you ring a bell and the office cat slavers at the mouth?

No? Okay, well we weren't going to tell you how to do that anyway!

What we will share is how to embed a culture of ongoing experimentation that enables your team to learn and adopt new technologies, techniques, and processes - whilst also achieving current objectives.

No animals were harmed in the creation of this talk.

Benedict Steele

October 29, 2019
Tweet

Other Decks in Technology

Transcript

  1. How to be an Evil Scientist London Continuous Delivery London

    - October 2019 Benedict Steele - @benedictsteele
  2. How to be an Evil Scientist 1. Trick them into

    doing an evil laugh 2. Give them all an evil name
  3. Your first name A The Evil N The Crazy B

    The Mad O The Iron C The Big P The Poison D The Dangerous Q The Bloody E Captain R The Dark F The Ghostly S The Dangerous G Professor T The Rancid H Doctor U The Invisible I Phantom V The Black J The Brutal W The Atomic K The Unstoppable X The Mega L The Vile Y The Grand M The Dark Z The Vicious
  4. Your last name A Shadow N Child B Wizard/Witch O

    Corpse C Tarantula P Slayer D Skull Q Spider E Mastermind R Creature F Wizard S Werewolf G Ninja T Monster H Devil U Vampire I Freak V Mutant J Beast W Robot K Criminal X Claw L Master Y Machine M Lord/Lady Z Clown
  5. How to be an Evil Scientist 1. Trick them into

    doing an evil laugh 2. Give them all an evil name 3. Find out the most evil thing they’ve ever done (you might have to go first)
  6. This is Billie ▪ Consulting Engineer for Armakuni ▪ Quite

    tall ▪ Helps people use best practices ▪ Favourite animal is the capybara ▪ I stole this talk from her, I didn’t even say thank-you
  7. How to be an Evil Scientist 1. Trick them into

    doing an evil laugh 2. Give them all an evil name 3. Find out the most evil thing they’ve ever done (you might have to go first) 4. Tell them about the rules every evil scientist must follow
  8. Evil Scientist Rules Always have lots of evil schemes -

    you never know if there’s going to be a sequel Always start small Always have an arch-enemy Always have an escape plan Always boast, there’s no point in being evil if you don’t boast about it Never wear capes Never get caught monologuing Always measure everything Always splice things together
  9. How to be an Evil Scientist 1. Trick them into

    doing an evil laugh 2. Give them all an evil name 3. Find out the most evil thing they’ve ever done (you might have to go first) 4. Tell them about the rules every evil scientist must follow 5. Describe our arch enemies
  10. Our Arch Enemies The Waiting Around Kid Captain Defect General

    Heroics The Crimson Handoff Gold Plated Features Girl Mr Unneeded process
  11. Our Arch Enemies El Manual Work Awful Comms Boy Knowledge

    Drain Man Constance “Task” Switching The Relearner Rework
  12. Our Arch Enemies Partially Completed Work Woman Dr Overly Complex

    Solutions The Siloed Worker Poor Visibility Man
  13. How to be an Evil Scientist 1. Trick them into

    doing an evil laugh 2. Give them all an evil name 3. Find out the most evil thing they’ve ever done (you might have to go first) 4. Tell them about the rules every evil scientist must follow 5. Describe our arch enemies
  14. How to be an Evil Scientist Lurgy and Continuous Disaster

    London - October 2019 The Mad Werewolf - @benedictsteele
  15. Ladies and gentlemen: the story you are about to hear

    is true. Only the names have been changed to protect the innocent.
  16. “ The future is already here — it's just not

    very evenly distributed William Gibson
  17. Alex and Sam ask Ashley to talk about how she

    decided what to do with her team
  18. What if Alex and Sam took the same approach and

    experimented with their teams?
  19. Empathise Design Thinking Evil Scientist Rules Always have lots of

    evil schemes - you never know if there’s going to be a sequel Always start small Never get caught monologuing Always measure everything Always splice things together Ideate Prototype Test Synthesise
  20. “ A pattern of shared tacit assumptions that was learned

    by a group as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems. Edgar Schein
  21. Westrum typology to measure culture Pathological (power-oriented) Bureaucratic (rule-oriented) Generative

    (performance-oriented) Low co-operation Modest co-operation High co-operation Messengers shot Messengers neglected Messengers trained Responsibilities shirked Narrow responsibilities Risks are shared Bridging discouraged Bridging tolerated Bridging encouraged Failure leads to scapegoating Failure leads to justice Failure leads to enquiry Novelty crushed Novelty leads to problems Novelty implemented
  22. The 5 dysfunctions of a team Inattention to RESULTS Avoidance

    of ACCOUNTABILITY Lack of COMMITMENT Fear of CONFLICT Absence of TRUST To take accountability takes prior commitment Focus on delivering measurable results. Collective and individual accountability, and feedback Commitment follows healthy conflict Healthy conflict implies candid debate Building trust requires vulnerability
  23. Four Key Metrics Lead Time for change Deployment frequency Mean

    time to recovery Change failure percentage Stability Speed
  24. “ The intent of maturity models is usually benign… because

    “maturity” sounds a bit… well…. patronizing. Plus, most of our models don’t involve progressing through different levels, and the primary audience is the team itself rather than management. https:/ /labs.spotify.com/2014/09/16/squad-health-check-model/
  25. Code Quality Code Quality “Absolutely everything is in source control”

    “We automatically test on every commit” “There’s only really the master branch” “I can add as many or as few examples as I need” “It’s in source control except...” “We manually have a look” “Our branches are around forever and there are loads of them” “...but the data wasn’t like that on prod”
  26. Continuous Delivery Continuous Delivery “Deployment is all automatic” “We security

    test git on push” “Commit to VCS and the customers have it in seconds” “Anyone can do a deploy!” “Deployment Joe is the only one who can do that” “That’s the security team’s job” “The customers get it a quarter later” “Only some people can deploy”
  27. Architecture Architecture “We can deploy any bit alone” “Just our

    team maintains this” “We never break backwards compatibility” "We chose our own tools” “We can’t deploy this alone” “Our team and Team X work on this” “Accidentally, we broke our clients code” “We had to use what they told us”
  28. Product and Process Product and Process “We find out direct

    from our users by... “Our kanban board shows all the work, and where it is” “Our stories usually last no than half a sprint” "We weren’t sure so we ran an experiment” “I don’t really know what our users think” “Sometimes work comes from the backlog except...” “Sometimes stories last multiple sprints” “That’s the way we’ve always done it”
  29. Lean Management and Monitoring Lean Management and Monitoring “Rather than

    a sign off process we pair program” “The app gathers metrics and decide what’s next” “Our checks spotted the problem before our customers DID” “We only take on one thing at a time” “We saw the user spike on our dashboard” “Oh we need to wait for CAB before we release” “No idea how the business decides what to do next” “The customer reported it” “We’re constantly doing 7 or 8 things” “It was a week before we even noticed”
  30. Learning Goal ▪ What do we need to learn? ▪

    What is our riskiest assumption? ▪ What is our one priority?
  31. Hypothesis/Assumptions ▪ Is it falsifiable? ▪ Is it specific? ▪

    Is it causal? (eg. If X the Y?) ▪ Is it relevant to the learning goal?
  32. Experiment Idea to Hypothesis We believe <this capability> Will result

    in <this outcome> We will know we have succeeded when <we see a measurable signal>
  33. Time Box Is the experiment timely? Can we get data

    faster? Would less data be sufficient? Metrics Qualitative or quantitative? Is it actionable? Is it Measurable? Fail Condition (If this happens, our hypothesis is clearly false!) Early Stop (If this happens, stop! Experiment is broken, retro!) Plan How will you collect the data? Is it Specific? Is it Achievable? Link to any supporting documents.
  34. x

  35. x

  36. x

  37. x

  38. Formulating it as an experiment made it easy get permission

    to fail (even with a terrifying boss)