Successfully reported this slideshow.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Agile Adoption Anti Patterns

  1. 1. !"#$%&!'()*(+&!+*,)-.%/+0& “In  the  old  days,  we  used  to  just  call  these  ‘bad  ideas’.  The  new  name   is  much  more  diploma<c.”   Anon,  www.c2.com
  2. 2. !"#$%&!'()*(+&!+*,)-.%/+0& Agenda What  am  I  going  to  talk  about? Introduc<on An<-­‐paEerns Root  Causes So  what  do  we   Ques<ons? Summary do?
  3. 3. !"#$%&!'()*(+&!+*,)-.%/+0& Introduction
  4. 4. !"#$%&!'()*(+&!+*,)-.%/+0& Who  is  this  James  Lewis? Introduc<on A developer I’ve been called an architect but not to my face XP Coach Your storyteller today
  5. 5. !"#$%&!'()*(+&!+*,)-.%/+0& AP  of  AA Introduc<on Don’t make the same mistakes as me What this talk isn’t Complete The answer
  6. 6. !"#$%&!'()*(+&!+*,)-.%/+0& Representa<ve  work Introduc<on Media  Organisa,on Investment  Bank Publishing  House Investment  Bank Programme   Organisa<onal  Change   Agile  Coaching Agile  Coaching Management  Coaching Programme ~  60  people >  200  people 30-­‐40  people 10  people All  front  office   5  teams 4  teams 1  team developers “How  do  we  scale  agile   “We  need  to  get  CMMi   2  year  rewrite.  “it  can’t   “we’ve  been  told  to   to  programme  size?” cer<fied.  Is  Agile  ok?” fail  if  we  use  agile?” ‘Go  Agile’”
  7. 7. !"#$%&!'()*(+&!+*,)-.%/+0& Who  is  choosing  Agile? Introduc<on Is it still developers? Is it a golf course decision? This brings new challenges But we like challenges right?
  8. 8. !"#$%&!'()*(+&!+*,)-.%/+0& What  is  an  organisa<on? Introduc<on People Architecture Routines Culture John Roberts. The modern Firm, 2004
  9. 9. !"#$%&!'()*(+&!+*,)-.%/+0& Performance  as  a  func<on   of  the  choices  we  make Introduc<on Structure Strategy People we hire People we fire Routines we follow
  10. 10. !"#$%&!'()*(+&!+*,)-.%/+0& Anti-patterns
  11. 11. !"#$%&!'()*(+&!+*,)-.%/+0& What  are  they? An<-­‐paEerns Stuff I see as a practitioner time and time again... ...And wish I didn’t
  12. 12. !"#$%&!'()*(+&!+*,)-.%/+0& Flaccid  Technical  Lead An<-­‐paEerns Just enough design up front is not the same as no design up front
  13. 13. !"#$%&!'()*(+&!+*,)-.%/+0& Inverted  Servant  Leader An<-­‐paEerns Can a leopard change its spots?
  14. 14. !"#$%&!'()*(+&!+*,)-.%/+0& Novice  in  Charge An<-­‐paEerns “Ahh, but on my last project we...”
  15. 15. !"#$%&!'()*(+&!+*,)-.%/+0& Change  everything  at  once An<-­‐paEerns This Agile thing just doesn’t work! We are slower than before
  16. 16. !"#$%&!'()*(+&!+*,)-.%/+0& Be  careful  what  you  wish   for An<-­‐paEerns You should give a novice rules... Just make sure they are the right ones.
  17. 17. !"#$%&!'()*(+&!+*,)-.%/+0& Novices  don’t  know  what   they  want An<-­‐paEerns Coach #fail
  18. 18. !"#$%&!'()*(+&!+*,)-.%/+0& New  Architecture  Team An<-­‐paEerns All the smart people should get together and talk about design right?
  19. 19. !"#$%&!'()*(+&!+*,)-.%/+0& Process  Mavens An<-­‐paEerns Lets implement the best process for everyone
  20. 20. !"#$%&!'()*(+&!+*,)-.%/+0& Stagnant  Agile An<-­‐paEerns One Agile to rule them all and in the darkness bind them
  21. 21. !"#$%&!'()*(+&!+*,)-.%/+0& Agile  Adapter An<-­‐paEerns Is it ok to hammer a square peg into a round hole?
  22. 22. !"#$%&!'()*(+&!+*,)-.%/+0& Hamstrung  Scrum An<-­‐paEerns We have a Scrum master. We are Agile. Right?
  23. 23. !"#$%&!'()*(+&!+*,)-.%/+0& Root Causes
  24. 24. !"#$%&!'()*(+&!+*,)-.%/+0& Organisa<onal  Change Root  Causes This is about organisations adapting to change in their operating environment.
  25. 25. !"#$%&!'()*(+&!+*,)-.%/+0& Organisa<onal  Change Root  Causes Along comes the World Wide Web... Organisations must track changes to stay competitive Command and control style organisations favour changing everything at once
  26. 26. !"#$%&!'()*(+&!+*,)-.%/+0& Organisa<onal  Change Root  Causes This is about managing changes to people, and organisations
  27. 27. !"#$%&!'()*(+&!+*,)-.%/+0& Organisa<onal  Change Root  Causes People find change hard Often we are not very good at introducing change Change takes time and perseverance
  28. 28. !"#$%&!'()*(+&!+*,)-.%/+0& Organisa<onal  Change Root  Causes This is about systemic optimisations over local optimisations “When it comes to changing the system, most people concentrate on doing the wrong thing righter” John Seddon, Freedom from Command and Control
  29. 29. !"#$%&!'()*(+&!+*,)-.%/+0& Organisa<onal  Change Root  Causes Performance is not a convex function of the choices we make There are local and global optima Sometimes incremental change is not enough
  30. 30. !"#$%&!'()*(+&!+*,)-.%/+0& Is  the  organisa<onal  design   to  blame? Root  Causes Hamstrung Scrum Architecture Team Process Mavens Stagnant Agile Agile Adapter
  31. 31. !"#$%&!'()*(+&!+*,)-.%/+0& Is  the  organisa<onal  design   to  blame? Root  Causes There is no such thing as the right design There is no such thing as the right process But there are combinations that are better than others
  32. 32. !"#$%&!'()*(+&!+*,)-.%/+0& People  break.  Deal  with  it. Root  Causes Flaccid Technical Lead Inverted Servant Leader Change everything at once Be careful what you wish for Novices don’t know what they want
  33. 33. !"#$%&!'()*(+&!+*,)-.%/+0& People  break.  Deal  with  it. Root  Causes People find change extremely difficult ...and they always will But there are techniques you can use to help
  34. 34. !"#$%&!'()*(+&!+*,)-.%/+0& Individual change
  35. 35. !"#$%&!'()*(+&!+*,)-.%/+0& Managing  changes  to   people So  what  do  we  do? Use learning models to flatten the Satir change curve
  36. 36. !"#$%&!'()*(+&!+*,)-.%/+0& The  Dreyfus  Model  of  Skill   Acquisi<on So  what  do  we  do? Novice Context free, determines action based on mechanical application of rules Advanced Beginner More context, rules organised into success and failure patterns Compentent Goal focussed, applies patterns to achieve successful goals, plan formulation Proficient Seeks wider experiences, holistic view of situation. More intuative Expert transcends reliance on rules, guidelines, and maxims. Intuative decsions
  37. 37. !"#$%&!'()*(+&!+*,)-.%/+0& The  Dreyfus  model  applied   to  pair  programming So  what  do  we  do? Novice Maintains attention while pairing, doesn’t grab mouse or keyboard Advanced Beginner Asks more experienced people to let them drive, tries to maintain a fair split between driving and navigating Competent Prefers pairing to working alone, ensures code is reviewed when no pair is available… Proficient Encourages pair to drive most of the time if pair is less experienced, swaps role frequently, does not interrupt driver's train of thought, gives driver a chance to correct himself before pointing out mistakes, encourages pair to follow good coding practices while driving… Expert Seeks time to pair with less experienced developers, spots smaller oversights such as missed warnings, uses pairing as an opportunity to train or mentor…
  38. 38. !"#$%&!'()*(+&!+*,)-.%/+0& The  Dreyfus  model  applied   to... So  what  do  we  do? Updating a Story Wall Continuous Integration Agile Estimation Using User Stories Retrospective participation Retrospective facilitation http://www.thekua.com/atwork/presentations-and-papers/xp2009/ Pat Kua, Agile 2009
  39. 39. !"#$%&!'()*(+&!+*,)-.%/+0& Changes to teams
  40. 40. !"#$%&!'()*(+&!+*,)-.%/+0& Conway’s  Law So  what  do  we  do? “Organizations which design systems... are constrained to produce designs which are copies of the communication structure of those organizations” Melvin Conway, 1968
  41. 41. !"#$%&!'()*(+&!+*,)-.%/+0& Conway’s  Law So  what  do  we  do?
  42. 42. !"#$%&!'()*(+&!+*,)-.%/+0& Refactoring  (organisa<ons)   to  paEerns So  what  do  we  do? Can we use techniques from software engineering to change teams and organisations? Joshua Kerievsky, 2004
  43. 43. !"#$%&!'()*(+&!+*,)-.%/+0& Transi<onal  change So  what  can  we  do? Start where you are Tell people what you are about to do Track progress visibly
  44. 44. !"#$%&!'()*(+&!+*,)-.%/+0& Groups  aren’t  Teams Transi<onal  change Requirements pushed ad-hoc to developers Its more efficient that way
  45. 45. !"#$%&!'()*(+&!+*,)-.%/+0& Groups  aren’t  Teams Transi<onal  change What if this was an enterprise architecture?
  46. 46. !"#$%&!'()*(+&!+*,)-.%/+0& Groups  aren’t  Teams Transi<onal  change Identify a bounded-context
  47. 47. !"#$%&!'()*(+&!+*,)-.%/+0& Groups  aren’t  Teams Transi<onal  change Implement  a  coarse-­‐grained   interface
  48. 48. !"#$%&!'()*(+&!+*,)-.%/+0& Groups  aren’t  Teams Transi<onal  change Implement an anti-corruption layer
  49. 49. !"#$%&!'()*(+&!+*,)-.%/+0& Groups  aren’t  Teams Transi<onal  change Can we apply Conway’s Law?
  50. 50. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated  Team Transi<onal  change Its a real team!
  51. 51. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated  Team Transi<onal  change New  requirements   Introduce  a  WiP  board Add  a  backlog through  PM Queues,  Classes  of   service,  WiP  limits,   Translate   Profit!! Enterprise  Service   requirements Bus* * Ok, not this one
  52. 52. !"#$%&!'()*(+&!+*,)-.%/+0& Breaking the system...
  53. 53. !"#$%&!'()*(+&!+*,)-.%/+0& “Do  the  Wrong  Thing   Righter” So  what  do  we  do? Traditional software development methodologies concentrate on the process and then on the people Process Mavens decide which process you should follow Architecture teams decide which technology you should use Targets decide how well you are doing
  54. 54. !"#$%&!'()*(+&!+*,)-.%/+0& “Do  the  Wrong  Thing   Righter” So  what  do  we  do? Agile software development methodologies concentrate on the people and the customer The team decides the process and technology The customer decides what is built Measures are used to understand flow
  55. 55. !"#$%&!'()*(+&!+*,)-.%/+0& “Do  the  right  thing” So  what  do  we  do? ‘agile’ delivery practices Customer-centric Devolved decision making Organised around demand
  56. 56. !"#$%&!'()*(+&!+*,)-.%/+0& “Do  the  right  thing” So  what  do  we  do? How do you do that? You can’t expect everything for free...
  57. 57. !"#$%&!'()*(+&!+*,)-.%/+0& Summary
  58. 58. !"#$%&!'()*(+&!+*,)-.%/+0& Summary What  I  just  talked  about Introduc<on An<-­‐paEerns Root  Causes So  what  do  we   Ques<ons? Summary do?
  59. 59. !"#$%&!'()*(+&!+*,)-.%/+0& If  you  remember  one  thing Finally... People will break and that will mean your project breaking
  60. 60. !"#$%&!'()*(+&!+*,)-.%/+0& If  you  remember  two  things Finally... Agile is about more than just iterations A set of complementary principles and practices
  61. 61. !"#$%&!'()*(+&!+*,)-.%/+0& and  if  you  remember  three Finally... Local optimisation is good but systemic optimisation is better
  62. 62. !"#$%&!'()*(+&!+*,)-.%/+0& Questions?
  63. 63. !"#$%&!'()*(+&!+*,)-.%/+0& Obrigado! hEp://bovon.org @boicy james.lewis@thoughtworks.com

Editor's Notes



  • What roles do people have here:

    Agile coach?
    Developer/Architect/Lead Techy?
    PM?
    QA?
    CTO/CEO/CIO/ETC?s

  • Straw poll:

    What roles do people have here:

    Agile coach?
    Developer/Architect/Lead Techy?
    PM?
    QA?
    CTO/CEO/CIO/ETC?s

  • Straw poll:

    What roles do people have here:

    Agile coach?
    Developer/Architect/Lead Techy?
    PM?
    QA?
    CTO/CEO/CIO/ETC?s

  • Straw poll:

    What roles do people have here:

    Agile coach?
    Developer/Architect/Lead Techy?
    PM?
    QA?
    CTO/CEO/CIO/ETC?s

  • Straw poll:

    What roles do people have here:

    Agile coach?
    Developer/Architect/Lead Techy?
    PM?
    QA?
    CTO/CEO/CIO/ETC?s

  • Do you like the horrible abbreviation?
    My attempt to make this look &amp;#x201C;professional&amp;#x201D;
    &amp;#x201C;Oh yes, I&amp;#x2019;m an AAA-P Blackbelt&amp;#x201D; etc

    Patterns of Enterprise Application Architecure
    P of EAA

    I reckon theres a book here somewhere&amp;#x2026;

    This is a talk about my experiences introducing agile principles and practices to various organisations.
    I;ve done this a fair bit, not always successfully
    This talk is about some of the things that have stood out for me
    Some of the patterns I&amp;#x2019;ve seen repeated
  • Do you like the horrible abbreviation?
    My attempt to make this look &amp;#x201C;professional&amp;#x201D;
    &amp;#x201C;Oh yes, I&amp;#x2019;m an AAA-P Blackbelt&amp;#x201D; etc

    Patterns of Enterprise Application Architecure
    P of EAA

    I reckon theres a book here somewhere&amp;#x2026;

    This is a talk about my experiences introducing agile principles and practices to various organisations.
    I;ve done this a fair bit, not always successfully
    This talk is about some of the things that have stood out for me
    Some of the patterns I&amp;#x2019;ve seen repeated
  • Do you like the horrible abbreviation?
    My attempt to make this look &amp;#x201C;professional&amp;#x201D;
    &amp;#x201C;Oh yes, I&amp;#x2019;m an AAA-P Blackbelt&amp;#x201D; etc

    Patterns of Enterprise Application Architecure
    P of EAA

    I reckon theres a book here somewhere&amp;#x2026;

    This is a talk about my experiences introducing agile principles and practices to various organisations.
    I;ve done this a fair bit, not always successfully
    This talk is about some of the things that have stood out for me
    Some of the patterns I&amp;#x2019;ve seen repeated
  • Do you like the horrible abbreviation?
    My attempt to make this look &amp;#x201C;professional&amp;#x201D;
    &amp;#x201C;Oh yes, I&amp;#x2019;m an AAA-P Blackbelt&amp;#x201D; etc

    Patterns of Enterprise Application Architecure
    P of EAA

    I reckon theres a book here somewhere&amp;#x2026;

    This is a talk about my experiences introducing agile principles and practices to various organisations.
    I;ve done this a fair bit, not always successfully
    This talk is about some of the things that have stood out for me
    Some of the patterns I&amp;#x2019;ve seen repeated
  • Names have been changed
    Mixed up details
    Some may not even have happened&amp;#x2026;
    Ok, not this last one


  • It used to be the developers who wanted to try out the new cool stuff - who were getting pissed off with heavy weight process and waste.

    Who were looking at groovy stuff like TDD, CI etc. Valuing feedback in their process.
  • It used to be the developers who wanted to try out the new cool stuff - who were getting pissed off with heavy weight process and waste.

    Who were looking at groovy stuff like TDD, CI etc. Valuing feedback in their process.
  • It used to be the developers who wanted to try out the new cool stuff - who were getting pissed off with heavy weight process and waste.

    Who were looking at groovy stuff like TDD, CI etc. Valuing feedback in their process.
  • It used to be the developers who wanted to try out the new cool stuff - who were getting pissed off with heavy weight process and waste.

    Who were looking at groovy stuff like TDD, CI etc. Valuing feedback in their process.
  • CORE DOMAIN - &amp;#x201C;Value chain activities&amp;#x201D; &amp;#x2013; the stuff you do to actually meet your customers needs &amp;#x2013;
    SUPPORTING DOMAINS - &amp;#x201C;Supporting activities&amp;#x201D; &amp;#x2013; the stuff you need to enable you to do that: HR, Payroll etc &amp;#x2013;
    The organisation is the means through which these activities are organised in order to implement strategy.

    People
    The set of people who are part of the organisation, their talents, skills (dreyfus), beliefs, objectives.
    Organisational Architecture
    Is it command and control or is it process oriented/Systems managed?
    The relationships between departments etc.
    Also includes personal networks &amp;#x2013; very important
    Routines
    All the managerial processes, how work is allocated, how work is done.
    Where does the formal decision making authority lie? etc&amp;#x2026;
    Culture
    The mindsets of the members of the firm
    The fundamental shared values of everyone in the firm
    The fundamental beliefs in why the organisation exists
  • CORE DOMAIN - &amp;#x201C;Value chain activities&amp;#x201D; &amp;#x2013; the stuff you do to actually meet your customers needs &amp;#x2013;
    SUPPORTING DOMAINS - &amp;#x201C;Supporting activities&amp;#x201D; &amp;#x2013; the stuff you need to enable you to do that: HR, Payroll etc &amp;#x2013;
    The organisation is the means through which these activities are organised in order to implement strategy.

    People
    The set of people who are part of the organisation, their talents, skills (dreyfus), beliefs, objectives.
    Organisational Architecture
    Is it command and control or is it process oriented/Systems managed?
    The relationships between departments etc.
    Also includes personal networks &amp;#x2013; very important
    Routines
    All the managerial processes, how work is allocated, how work is done.
    Where does the formal decision making authority lie? etc&amp;#x2026;
    Culture
    The mindsets of the members of the firm
    The fundamental shared values of everyone in the firm
    The fundamental beliefs in why the organisation exists
  • CORE DOMAIN - &amp;#x201C;Value chain activities&amp;#x201D; &amp;#x2013; the stuff you do to actually meet your customers needs &amp;#x2013;
    SUPPORTING DOMAINS - &amp;#x201C;Supporting activities&amp;#x201D; &amp;#x2013; the stuff you need to enable you to do that: HR, Payroll etc &amp;#x2013;
    The organisation is the means through which these activities are organised in order to implement strategy.

    People
    The set of people who are part of the organisation, their talents, skills (dreyfus), beliefs, objectives.
    Organisational Architecture
    Is it command and control or is it process oriented/Systems managed?
    The relationships between departments etc.
    Also includes personal networks &amp;#x2013; very important
    Routines
    All the managerial processes, how work is allocated, how work is done.
    Where does the formal decision making authority lie? etc&amp;#x2026;
    Culture
    The mindsets of the members of the firm
    The fundamental shared values of everyone in the firm
    The fundamental beliefs in why the organisation exists
  • CORE DOMAIN - &amp;#x201C;Value chain activities&amp;#x201D; &amp;#x2013; the stuff you do to actually meet your customers needs &amp;#x2013;
    SUPPORTING DOMAINS - &amp;#x201C;Supporting activities&amp;#x201D; &amp;#x2013; the stuff you need to enable you to do that: HR, Payroll etc &amp;#x2013;
    The organisation is the means through which these activities are organised in order to implement strategy.

    People
    The set of people who are part of the organisation, their talents, skills (dreyfus), beliefs, objectives.
    Organisational Architecture
    Is it command and control or is it process oriented/Systems managed?
    The relationships between departments etc.
    Also includes personal networks &amp;#x2013; very important
    Routines
    All the managerial processes, how work is allocated, how work is done.
    Where does the formal decision making authority lie? etc&amp;#x2026;
    Culture
    The mindsets of the members of the firm
    The fundamental shared values of everyone in the firm
    The fundamental beliefs in why the organisation exists
  • Performance or Quality as a convex function of choice

    An organisations design is formed of a vast number of variables, the choices that are made in maximising or minimising those variables affect performance



  • Performance or Quality as a convex function of choice

    An organisations design is formed of a vast number of variables, the choices that are made in maximising or minimising those variables affect performance



  • Performance or Quality as a convex function of choice

    An organisations design is formed of a vast number of variables, the choices that are made in maximising or minimising those variables affect performance



  • Performance or Quality as a convex function of choice

    An organisations design is formed of a vast number of variables, the choices that are made in maximising or minimising those variables affect performance



  • Performance or Quality as a convex function of choice

    An organisations design is formed of a vast number of variables, the choices that are made in maximising or minimising those variables affect performance




  • If you describe it to someone and they find something novel in it, then it isn&amp;#x2019;t a pattern

    Not novel
    Chunked knowledge

    Name
    Context
    Description
    Consequences


  • If you describe it to someone and they find something novel in it, then it isn&amp;#x2019;t a pattern

    Not novel
    Chunked knowledge

    Name
    Context
    Description
    Consequences


  • FlaccidTechnicalLead

    Context
    All of a sudden you go from a team practicing Big Up Front Design to a team using XP and evolutionary design

    What
    This is someone whose world has changed.
    In the old world, he did Design and Architecture ERD&amp;#x2019;s, Class Diagrams, told people what to do and made all the decisions.
    In the new world, he doesn&amp;#x2019;t know what to do.
    Example, Publishing house, the technical leads did not know what to do &amp;#x2013; this is a Dreyfus thing.

    Consequences
    No technical direction for the project or programme. No understanding that when using incremental development practices design is soo important that it happens all the time. Worst case, no design happens because &amp;#x201C;that what Agile is?&amp;#x201D;
    Code base aquires technical debt at a terrifying rate.
  • Context
    The PM has been told to &amp;#x201C;be agile&amp;#x201D;, has read a book or two, maybe even seen it done once before, and off we go...
    What
    Knows everything
    Doesn&amp;#x2019;t understand that now:
    Its about acting on the System
    Not the individual tasks
    Not the individual people
    Consequences
    Worst case, Publishing house where the PM actually made things unbearable
    Core pair hours &amp;#x2013; not allowed to talk to people in them, &amp;#x201C;we have story huddles for that&amp;#x201D;
    Completely silent team, terrifying!
    &amp;#x201C;Go on, self organise!&amp;#x201D;



  • Context
    Agile &amp;#x2018;expert&amp;#x2019;
    What
    You&amp;#x2019;ve seen it once before, maybe even success before - great! Now you are in charge.
    Perfect novice behaviour
    Haven&amp;#x2019;t seen enough success or failure to know that the answer is always &amp;#x2018;It Depends&amp;#x2019;
    Consequences
    Lack of trust, lack of authority, stuff implemented exactly as it was the last time - even though the context is completely different
  • ChangeEverythingAtOnce

    Context
    New project, 1 year rewrite, 40 people

    What
    Same language, but.
    new frameworks and libraries
    new organisational structure
    new management practices
    new analysis
    new skills to be learned (TDD, pairing etc)
    roles change, QA pairing with BA to write tests etc story writing,

    Consequences
    Everything is very very slow. And Agile is then to blame&amp;#x2026;
    You *will* miss your deadline
  • ChangeEverythingAtOnce

    Context
    New project, 1 year rewrite, 40 people

    What
    Same language, but.
    new frameworks and libraries
    new organisational structure
    new management practices
    new analysis
    new skills to be learned (TDD, pairing etc)
    roles change, QA pairing with BA to write tests etc story writing,

    Consequences
    Everything is very very slow. And Agile is then to blame&amp;#x2026;
    You *will* miss your deadline
  • Context
    Example: User Stories and acceptance criteria &amp;#x2013; tell someone they need five acceptance criteria, and they *always* have five criteria
    Example: Semantic Diffusion&amp;#x2026; BDD &amp;#x2013; people basically telling Dan that he was wrong about what BDD means,

    What
    We forget that as Coaches or experienced practitioners we have more exposure to this stuff.
    Quite often we offer a simplification of the real world, an approximation. Lies to children&amp;#x2026;

    Consequences
    Anecdote about people consistently overestimating their own level of expertise &amp;#x2013; 74% of drivers believe they were &amp;#x201C;better than average&amp;#x201D;&amp;#x2026;
    Dreyfus, be careful talking to be people who don&amp;#x2019;t have the same level of expertise as you do
    Much wailing and gnashing of teeth. People actually doing what you said exactly
    Dreyfus novices want rules. So if you give someone rules, make sure they are the right ones!

  • Context
    Example: User Stories and acceptance criteria &amp;#x2013; tell someone they need five acceptance criteria, and they *always* have five criteria
    Example: Semantic Diffusion&amp;#x2026; BDD &amp;#x2013; people basically telling Dan that he was wrong about what BDD means,

    What
    We forget that as Coaches or experienced practitioners we have more exposure to this stuff.
    Quite often we offer a simplification of the real world, an approximation. Lies to children&amp;#x2026;

    Consequences
    Anecdote about people consistently overestimating their own level of expertise &amp;#x2013; 74% of drivers believe they were &amp;#x201C;better than average&amp;#x201D;&amp;#x2026;
    Dreyfus, be careful talking to be people who don&amp;#x2019;t have the same level of expertise as you do
    Much wailing and gnashing of teeth. People actually doing what you said exactly
    Dreyfus novices want rules. So if you give someone rules, make sure they are the right ones!

  • Context
    You are going to be our Agile Coach
    What does that mean? Says I
    Well we want you to be an advisor to us
    Start of saying &amp;#x201C;we want coaching&amp;#x201D;
    Touchy feely &amp;#x2013; just make suggestions
    End up saying &amp;#x201C;You didn&amp;#x2019;t lead us!&amp;#x201D;

    What
    What they are really saying is:
    As a novice, I haven&amp;#x2019;t got a clue what I want &amp;#x2013; I don&amp;#x2019;t know what I don&amp;#x2019;t know
    So I will say &amp;#x201C;just coach me, don&amp;#x2019;t tell me what to do&amp;#x201D;
    When they get to advanced beginner, they say &amp;#x2013; why didn&amp;#x2019;t you just tell me what to do?

    This is a failure on the coaches part.
    It&amp;#x2019;s not a coach vs leader thing
    It&amp;#x2019;s that coaching should take this into account and use the dreyfus model

    Consequences
    Well a loss of trust certainly.
    It will make your job as a coach a lot harder

  • Straw poll on just enough design up front?

    Embarking on a new way of working, losing Design Up Front and moving to using an evolutionary approach to design

    What
    Either people are scared of losing respect/their position (genuine worry)
    Some are genuinely worried about quality
    Believe that quality is a function of design (which it is)
    And that the only way to do design is up front
    Depends on whether they feel threatened by the changes or not

    Consequences
    Lots of thrashing around, meetings which generate nothing but hot air, angst and anger when the team builds something that they didn&amp;#x2019;t forsee
  • Who has worked in an organisation where process changes are imposed every 18 months?

    Smart people getting together and designing the &amp;#x2018;best process&amp;#x201D;
    same process for Nuclear power stations as the web site.

    Management by lowest common denominator

    Consequences: constantly fighting against the process, targets, measures etc
  • Project Manager and some of the team had worked with ThoughtWorks four years previously. Then we arrived, and dared to suggest different things.

    Four years ago you told us to do XXX
    Why are you telling us something different now?
    Why should we use finger charts, burn-up was always good enough for us!
    Excel/Mingle
    Problem with deliberate reflection &amp;#x2013; not really getting &amp;#x201C;it&amp;#x201D;
    &amp;#x201C;It&amp;#x2019;s a bunch of processes that you follow, not stuff that you can change&amp;#x201D;
    A Life without reflection is a life not worth living&amp;#x201D; &amp;#x2013; Evelyn Waugh&amp;#x2026;

    It becomes just another process to be followed.
    When the process starts breaking (and it always will in certain circumstances) then it doesn&amp;#x2019;t adapt as is should
  • Context
    You are on a team that wants to use agile principles and practices.
    The rest of the organisation is waterfall, or six-sigma or CMMi.

    What
    You use the square peg round hole adapter.
    At the boundary use an anti-corruption layer.
    If the PMO wants gant charts then that&amp;#x2019;s what they get,
    If the Enterprise Architecture group wants class diagrams then that&amp;#x2019;s what they get
    The anti-pattern here is that you are trying to force this into a command and control management structure.

    There will always be friction if you are having to do this.
    Your PM will be thrashing trying to produce stuff to satisfy the PMO.
    Governance becomes difficult and will possibly break.
  • You have been told that going Agile is the next big thing and it&amp;#x2019;s all about visibilty and getting software out the door more quickly
    So you tell your PM he is a Scrum master, give him a book and off you go.

    They have looked around and seen that &amp;#x201C;Agile&amp;#x201D; (read Scrum) will help them to produce stuff faster. And so they adopt it.
    Engineering practices, empowering their people, training their people.
    Consequences
    Well, that didn&amp;#x2019;t work out so well did it? Lets do it the old way. At least then we were able to produce some stuff, instead of going to all these Scrums and prioritisation meetings etc.
    So you revert. At the depth of dispair (in the satir change curve) is the likliest place to revert
  • You have been told that going Agile is the next big thing and it&amp;#x2019;s all about visibilty and getting software out the door more quickly
    So you tell your PM he is a Scrum master, give him a book and off you go.

    They have looked around and seen that &amp;#x201C;Agile&amp;#x201D; (read Scrum) will help them to produce stuff faster. And so they adopt it.
    Engineering practices, empowering their people, training their people.
    Consequences
    Well, that didn&amp;#x2019;t work out so well did it? Lets do it the old way. At least then we were able to produce some stuff, instead of going to all these Scrums and prioritisation meetings etc.
    So you revert. At the depth of dispair (in the satir change curve) is the likliest place to revert

  • They have to - process mavens and top down decision making make this inevitable.

    They lurch from one change to another
  • Traditional retailers fail because they are unable to incrementally change
  • Traditional retailers fail because they are unable to incrementally change
  • Traditional retailers fail because they are unable to incrementally change
  • Cost of change

    We can&amp;#x2019;t make this linear&amp;#x2026; BUT

    We can make the dip less dippy.

    All about flattening the cost of change curve

    Virginia Satir &amp;#x2013; cost of change curve

    Add a person to indicate that it&amp;#x2019;;s about how people react to change


  • When do most changes fail?
    &amp;#x2018;valley of despair&amp;#x2019;
  • When do most changes fail?
    &amp;#x2018;valley of despair&amp;#x2019;
  • When do most changes fail?
    &amp;#x2018;valley of despair&amp;#x2019;
  • Cost of change

    We can&amp;#x2019;t make this linear&amp;#x2026; BUT

    We can make the dip less dippy.

    All about flattening the cost of change curve

    Virginia Satir &amp;#x2013; cost of change curve

    Add a person to indicate that it&amp;#x2019;;s about how people react to change


  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.
  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.
  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.
  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.
  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.
  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.
  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.
  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.
  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.
  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.
  • Cherry picking doesn&amp;#x2019;t work - compensating for ignorance with increased control doesn&amp;#x2019;t work
    Hamstrung Scrum
    Complementary Variables They are complementary if doing more of one, increases the returns of doing more of another
    XP Practices
    You can imagine that Continuous Integration, Pairing and TDD are complementary groups of practices.
    That is, doing CI on it&amp;#x2019;s own is good, but when you practice Test (or Behaviour) Driven Development as well you get an an increase in Quality that is greater than just doing one of the other.
    &lt;strong&gt;The best processes arise from self organising teams&lt;/strong&gt;
    Much as ivory tower architecture groups trade adaptability for consistency of approach, process mavens trade effectiveness for efficiency. By mandating the implementation of a particular process pattern for an organisations value chain activities they are coming at it arse backwards. Patterns arise from successful solutions
    Coherent Groups of choices
    Groups of choices can be complementary &amp;#x2013; Systems management/Lean and XP for example

    Substitutes
    You are trying to ensure that a consistent (or in most cases just acceptable) quality of code is checked in
    You can have someone review all the code before check-in, or another option would be to pair program.
    One becomes more attractive the more of it you do (in this case because of economies of scale.





  • Shu traditional wisdom &amp;#x2014; learning fundamentals, techniques, heuristics, proverbs
    Ha breaking with tradition &amp;#x2014; finding exceptions to traditional wisdom, reflecting on their truth, finding new ways, techniques, and proverbs
    Ri transcendence &amp;#x2014; there are no techniques or proverbs, all moves are natural

    Dreyfus
    Stuart Dreyfus and Hubert Dreyfus

  • Shu traditional wisdom &amp;#x2014; learning fundamentals, techniques, heuristics, proverbs
    Ha breaking with tradition &amp;#x2014; finding exceptions to traditional wisdom, reflecting on their truth, finding new ways, techniques, and proverbs
    Ri transcendence &amp;#x2014; there are no techniques or proverbs, all moves are natural

    Dreyfus
    Stuart Dreyfus and Hubert Dreyfus

  • Shu traditional wisdom &amp;#x2014; learning fundamentals, techniques, heuristics, proverbs
    Ha breaking with tradition &amp;#x2014; finding exceptions to traditional wisdom, reflecting on their truth, finding new ways, techniques, and proverbs
    Ri transcendence &amp;#x2014; there are no techniques or proverbs, all moves are natural

    Dreyfus
    Stuart Dreyfus and Hubert Dreyfus


  • Straw poll on Dreyfus
    Explanation - decision tree -&gt; pattern matching...
    Novice - no context, rules
    Advanced Beginner - more context, still rule based
    Competent - more goal focussed, still consciously uses rules
    Proficient - has walked through the door - started to internalise the rules
    Expert - Completely intuative reasoning, can&amp;#x2019;t give explanations as to *why* just that is *is*
  • Straw poll on Dreyfus
    Stewart Drefus, Systems Analyst
    Hubert Dreyfus, Philosopher

    Explanation - decision tree -&gt; pattern matching...

  • Straw poll on Dreyfus
    Stewart Drefus, Systems Analyst
    Hubert Dreyfus, Philosopher

    Explanation - decision tree -&gt; pattern matching...

  • Straw poll on Dreyfus
    Stewart Drefus, Systems Analyst
    Hubert Dreyfus, Philosopher

    Explanation - decision tree -&gt; pattern matching...

  • Straw poll on Dreyfus
    Stewart Drefus, Systems Analyst
    Hubert Dreyfus, Philosopher

    Explanation - decision tree -&gt; pattern matching...

  • Straw poll on Dreyfus
    Stewart Drefus, Systems Analyst
    Hubert Dreyfus, Philosopher

    Explanation - decision tree -&gt; pattern matching...

  • Liz Keogh and Andy Palmer
  • Liz Keogh and Andy Palmer
  • Liz Keogh and Andy Palmer
  • Liz Keogh and Andy Palmer
  • Liz Keogh and Andy Palmer


  • Ipso facto organisations are shite

    &amp;#x201C;If you are a group of 9 people to write you a compiler, you get a 9 pass compiler&amp;#x2026;&amp;#x201D;

  • Most software looks like this:





  • context switching
    always in meetings
    getting requirements in differing formats
    managing constantly changing priorities
  • context switching
    always in meetings
    getting requirements in differing formats
    managing constantly changing priorities
  • What if this was a problem with an enterprise architecture?
  • What if this was a problem with an enterprise architecture?



  • Context switching
    lots of meetings
    ad-hoc requirements
    shifting priorities
  • Single format for requirements
    Developers concentrate on development
    less context switching
    no breaking changes when team practices change

































  • ×