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

Efficiency in a Development Environment by Sarah Nicholson and Leo Gopal

37f274629153f05557130c427935b8fd?s=47 Leo Gopal
November 18, 2015

Efficiency in a Development Environment by Sarah Nicholson and Leo Gopal

Fusing Ideas from Agile, Physics, Biology, Experimentation Science, Psychology, Philosophy, with a hint of common sense - we present some interesting ideas and concepts that could improve the general happiness and efficiency within an organisation - not just the development team.

37f274629153f05557130c427935b8fd?s=128

Leo Gopal

November 18, 2015
Tweet

Transcript

  1. Efficiency in a Development Environment. Is there a better way?

  2. A Tale of Two Struggles.

  3. The Dawn of Realisation.

  4. Our Aims. Ultimately, all we want to do is reduce

    the stress for teams, clients, and the business (and be happier)
  5. Why Should We Work Together?

  6. $history = ‘Knowledge’; $knowledge = ‘Power’;

  7. Adapt to Survive.* *Hat tip to Darwin.

  8. To agile or not to agile.

  9. None
  10. The First Mistake. “It is a fallacy born from the

    failure to study culture is the assumption you can take a practice from one organization and jam it into another and get the same results”
  11. Do not copy practices. Do copy principles.

  12. $Agile != $agility;

  13. Agile Manifesto Individuals and interactions over processes and tools Working

    software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
  14. agile Agile Manifesto 1. Continuous improvement 2. Iterative development 3.

    Simplicity 4. Trust 5. Servant leadership
  15. Continuous improvement Each individuals role is to look for ways

    to continuously improve, both personally and in the wider organisation. This becomes a shared endeavour, a shared mission. We also help each other improve.
  16. Iterative development Organisations should have short learning cycles, so that

    we can validate our assumptions/hypotheses as quickly and as often as possible.
  17. Simplicity Scaling what we do is key to an organisations’s

    success. Simplicity should be your guidance during scaling. This is as true for our technical solutions, as for our methods of working and organising the organisation.
  18. Trust An organisation should trust their people and teams to

    make informed decisions about the way they work and what they work on.
  19. Servant leadership An organisations leadership should be focused on coaching,

    mentorship, and solving impediments rather than telling people what to do.
  20. The First Reflection.

  21. None
  22. Newton’s Laws of Motion 1. Inertia 2. Force 3. Friction

  23. Applying Science.

  24. None
  25. None
  26. I.P.A. The simplest system for problem solving Identify. Plan. Act.

  27. The Second Mistake.

  28. Slow Down, Go Further.

  29. Start with what you’re doing now.

  30. 7 steps of change

  31. 1. Shock or Disbelief “We’re not going to have a

    plan before we start”?
  32. 2. Denial “The way we work is fine, we don’t

    need to change”, “ We’re perfect as we are”
  33. 3. Anger “The reason we aren't understanding is because you’re

    an awful teacher”, “When you stop me talking in a stand up it’s unprofessional of you and it makes me upset”
  34. 4. Bargaining “We’ll try it for four weeks and if

    it doesn't work we’ll go back to the way things were before”
  35. 5. Guilt “I'm getting it wrong and letting everyone down”

  36. 6. Depression “I don’t think I can do this, it’s

    too difficult”, “I don’t want to work in this way any more”, “I'm quitting the project”
  37. 7. Acceptance and Hope “This is much better than before,

    but we have a lot to improve on”, “I didn't think we could do this, but we can”
  38. Onboarding & Adoption.

  39. - Gab Scali

  40. There is No Failure…. …just Feedback

  41. Finding the Balance.

  42. Lets Slack.

  43. None
  44. None
  45. Using a Razor. Specifically, Ockham's Razor: Among competing hypotheses, the

    one with the fewest assumptions should be selected.
  46. Think Big, Act Small Prioritise. Refine. Reduce. Reflect. Adapt.

  47. 1. Do Immediately & Personally 2. Defer Until Later, Do

    Personally 3. Delegate. 4. Disregard.
  48. Seeing is Doing.

  49. Kanban

  50. None
  51. None
  52. Deliver Fast, Deliver Often

  53. None
  54. None
  55. Side Effects Adopting this approach to business can affect: Contracts:

    Fixed Bids vs. Pay Per Sprint Improved Scoping and Client Education Improved Continuous Delivery and Feedback Loops Happier Clients with more refined and focused finished products. Happier Developers with less scope creep and angry A.M’s and P.O’s Happier Product Owners and Account managers (‘coz clients and customers are happy) Better Delivery Times and More Accurate Estimates.
  56. Thank You sarahleighw@gmail.com & leo@leogopal.com Sarah Nicholson & Leo Gopal