Agile Adoption Anti Patterns

2,038 views
1,922 views

Published on

Talk I gave at Agile Vancouver 2009

Published in: Technology, Business
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,038
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
0
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide


  • 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 “professional”
    “Oh yes, I’m an AAA-P Blackbelt” etc

    Patterns of Enterprise Application Architecure
    P of EAA

    I reckon theres a book here somewhere…

    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’ve seen repeated
  • Do you like the horrible abbreviation?
    My attempt to make this look “professional”
    “Oh yes, I’m an AAA-P Blackbelt” etc

    Patterns of Enterprise Application Architecure
    P of EAA

    I reckon theres a book here somewhere…

    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’ve seen repeated
  • Do you like the horrible abbreviation?
    My attempt to make this look “professional”
    “Oh yes, I’m an AAA-P Blackbelt” etc

    Patterns of Enterprise Application Architecure
    P of EAA

    I reckon theres a book here somewhere…

    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’ve seen repeated
  • Do you like the horrible abbreviation?
    My attempt to make this look “professional”
    “Oh yes, I’m an AAA-P Blackbelt” etc

    Patterns of Enterprise Application Architecure
    P of EAA

    I reckon theres a book here somewhere…

    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’ve seen repeated
  • Names have been changed
    Mixed up details
    Some may not even have happened…
    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 - “Value chain activities” – the stuff you do to actually meet your customers needs –
    SUPPORTING DOMAINS - “Supporting activities” – the stuff you need to enable you to do that: HR, Payroll etc –
    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 – very important
    Routines
    All the managerial processes, how work is allocated, how work is done.
    Where does the formal decision making authority lie? etc…
    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 - “Value chain activities” – the stuff you do to actually meet your customers needs –
    SUPPORTING DOMAINS - “Supporting activities” – the stuff you need to enable you to do that: HR, Payroll etc –
    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 – very important
    Routines
    All the managerial processes, how work is allocated, how work is done.
    Where does the formal decision making authority lie? etc…
    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 - “Value chain activities” – the stuff you do to actually meet your customers needs –
    SUPPORTING DOMAINS - “Supporting activities” – the stuff you need to enable you to do that: HR, Payroll etc –
    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 – very important
    Routines
    All the managerial processes, how work is allocated, how work is done.
    Where does the formal decision making authority lie? etc…
    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 - “Value chain activities” – the stuff you do to actually meet your customers needs –
    SUPPORTING DOMAINS - “Supporting activities” – the stuff you need to enable you to do that: HR, Payroll etc –
    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 – very important
    Routines
    All the managerial processes, how work is allocated, how work is done.
    Where does the formal decision making authority lie? etc…
    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’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’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’s, Class Diagrams, told people what to do and made all the decisions.
    In the new world, he doesn’t know what to do.
    Example, Publishing house, the technical leads did not know what to do – 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 “that what Agile is?”
    Code base aquires technical debt at a terrifying rate.
  • Context
    The PM has been told to “be agile”, has read a book or two, maybe even seen it done once before, and off we go...
    What
    Knows everything
    Doesn’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 – not allowed to talk to people in them, “we have story huddles for that”
    Completely silent team, terrifying!
    “Go on, self organise!”



  • Context
    Agile ‘expert’
    What
    You’ve seen it once before, maybe even success before - great! Now you are in charge.
    Perfect novice behaviour
    Haven’t seen enough success or failure to know that the answer is always ‘It Depends’
    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…
    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…
    You *will* miss your deadline
  • Context
    Example: User Stories and acceptance criteria – tell someone they need five acceptance criteria, and they *always* have five criteria
    Example: Semantic Diffusion… BDD – 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…

    Consequences
    Anecdote about people consistently overestimating their own level of expertise – 74% of drivers believe they were “better than average”…
    Dreyfus, be careful talking to be people who don’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 – tell someone they need five acceptance criteria, and they *always* have five criteria
    Example: Semantic Diffusion… BDD – 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…

    Consequences
    Anecdote about people consistently overestimating their own level of expertise – 74% of drivers believe they were “better than average”…
    Dreyfus, be careful talking to be people who don’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 “we want coaching”
    Touchy feely – just make suggestions
    End up saying “You didn’t lead us!”

    What
    What they are really saying is:
    As a novice, I haven’t got a clue what I want – I don’t know what I don’t know
    So I will say “just coach me, don’t tell me what to do”
    When they get to advanced beginner, they say – why didn’t you just tell me what to do?

    This is a failure on the coaches part.
    It’s not a coach vs leader thing
    It’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’t forsee
  • Who has worked in an organisation where process changes are imposed every 18 months?

    Smart people getting together and designing the ‘best process”
    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 – not really getting “it”
    “It’s a bunch of processes that you follow, not stuff that you can change”
    A Life without reflection is a life not worth living” – Evelyn Waugh…

    It becomes just another process to be followed.
    When the process starts breaking (and it always will in certain circumstances) then it doesn’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’s what they get,
    If the Enterprise Architecture group wants class diagrams then that’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’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 “Agile” (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’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’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 “Agile” (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’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’t make this linear… BUT

    We can make the dip less dippy.

    All about flattening the cost of change curve

    Virginia Satir – cost of change curve

    Add a person to indicate that it’;s about how people react to change


  • When do most changes fail?
    ‘valley of despair’
  • When do most changes fail?
    ‘valley of despair’
  • When do most changes fail?
    ‘valley of despair’
  • Cost of change

    We can’t make this linear… BUT

    We can make the dip less dippy.

    All about flattening the cost of change curve

    Virginia Satir – cost of change curve

    Add a person to indicate that it’;s about how people react to change


  • Cherry picking doesn’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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’t work - compensating for ignorance with increased control doesn’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’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.
    <strong>The best processes arise from self organising teams</strong>
    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 – 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 — learning fundamentals, techniques, heuristics, proverbs
    Ha breaking with tradition — finding exceptions to traditional wisdom, reflecting on their truth, finding new ways, techniques, and proverbs
    Ri transcendence — there are no techniques or proverbs, all moves are natural

    Dreyfus
    Stuart Dreyfus and Hubert Dreyfus

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

    Dreyfus
    Stuart Dreyfus and Hubert Dreyfus

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

    Dreyfus
    Stuart Dreyfus and Hubert Dreyfus


  • Straw poll on Dreyfus
    Explanation - decision tree -> 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’t give explanations as to *why* just that is *is*
  • Straw poll on Dreyfus
    Stewart Drefus, Systems Analyst
    Hubert Dreyfus, Philosopher

    Explanation - decision tree -> pattern matching...

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

    Explanation - decision tree -> pattern matching...

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

    Explanation - decision tree -> pattern matching...

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

    Explanation - decision tree -> pattern matching...

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

    Explanation - decision tree -> 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

    “If you are a group of 9 people to write you a compiler, you get a 9 pass compiler…”

  • 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

































  • 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 diplomatic.” Anon, www.c2.com
    2. 2. !"#$%&!'()*(+&!+*,)-.%/+0& Agenda What am I going to talk Anti- Introduction Root Causes patterns So what do Questions? Summary we do?
    3. 3. !"#$%&!'()*(+&!+*,)-.%/+0& Introduction
    4. 4. !"#$%&!'()*(+&!+*,)-.%/+0& Who is this James Lewis? Introduction
    5. 5. !"#$%&!'()*(+&!+*,)-.%/+0& Who is this James Lewis? Introduction A developer
    6. 6. !"#$%&!'()*(+&!+*,)-.%/+0& Who is this James Lewis? Introduction A developer I’ve been called an architect but not to my face
    7. 7. !"#$%&!'()*(+&!+*,)-.%/+0& Who is this James Lewis? Introduction A developer I’ve been called an architect but not to my face XP Coach
    8. 8. !"#$%&!'()*(+&!+*,)-.%/+0& Who is this James Lewis? Introduction A developer I’ve been called an architect but not to my face XP Coach Your storyteller today
    9. 9. !"#$%&!'()*(+&!+*,)-.%/+0& AP of AA Introduction
    10. 10. !"#$%&!'()*(+&!+*,)-.%/+0& AP of AA Introduction Don’t make the same mistakes as me
    11. 11. !"#$%&!'()*(+&!+*,)-.%/+0& AP of AA Introduction Don’t make the same mistakes as me What this talk isn’t
    12. 12. !"#$%&!'()*(+&!+*,)-.%/+0& AP of AA Introduction Don’t make the same mistakes as me What this talk isn’t Complete
    13. 13. !"#$%&!'()*(+&!+*,)-.%/+0& AP of AA Introduction Don’t make the same mistakes as me What this talk isn’t Complete The answer
    14. 14. !"#$%&!'()*(+&!+*,)-.%/+0& Representative work Introduction Media Investment Publishing Investment Organisation Bank House Bank Programme Organisational Management Agile Coaching Agile Coaching Change Programme Coaching ~ 60 people > 200 people 30-40 people 10 people All front office 5 teams 4 teams 1 team developers “How do we scale “We need to get 2 year rewrite. “it “we’ve been told to agile to CMMi certified. Is can’t fail if we use ‘Go Agile’” programme size?” Agile ok?” agile?”
    15. 15. !"#$%&!'()*(+&!+*,)-.%/+0& Who is choosing Agile? Introduction
    16. 16. !"#$%&!'()*(+&!+*,)-.%/+0& Who is choosing Agile? Introduction Is it still developers?
    17. 17. !"#$%&!'()*(+&!+*,)-.%/+0& Who is choosing Agile? Introduction Is it still developers? Is it a golf course decision?
    18. 18. !"#$%&!'()*(+&!+*,)-.%/+0& Who is choosing Agile? Introduction Is it still developers? Is it a golf course decision? This brings new challenges
    19. 19. !"#$%&!'()*(+&!+*,)-.%/+0& Who is choosing Agile? Introduction Is it still developers? Is it a golf course decision? This brings new challenges But we like challenges right?
    20. 20. !"#$%&!'()*(+&!+*,)-.%/+0& What is an organisation? Introduction John Roberts. The modern Firm, 2004
    21. 21. !"#$%&!'()*(+&!+*,)-.%/+0& What is an organisation? Introduction People John Roberts. The modern Firm, 2004
    22. 22. !"#$%&!'()*(+&!+*,)-.%/+0& What is an organisation? Introduction People Architecture John Roberts. The modern Firm, 2004
    23. 23. !"#$%&!'()*(+&!+*,)-.%/+0& What is an organisation? Introduction People Architecture Routines John Roberts. The modern Firm, 2004
    24. 24. !"#$%&!'()*(+&!+*,)-.%/+0& What is an organisation? Introduction People Architecture Routines Culture John Roberts. The modern Firm, 2004
    25. 25. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction
    26. 26. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction Structure
    27. 27. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction Structure Strategy
    28. 28. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction Structure Strategy People we hire
    29. 29. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction Structure Strategy People we hire People we fire
    30. 30. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction Structure Strategy People we hire People we fire Routines we follow
    31. 31. !"#$%&!'()*(+&!+*,)-.%/+0& Anti-patterns
    32. 32. !"#$%&!'()*(+&!+*,)-.%/+0& What are they? Anti-patterns
    33. 33. !"#$%&!'()*(+&!+*,)-.%/+0& What are they? Anti-patterns Stuff I see as a practitioner time and time again...
    34. 34. !"#$%&!'()*(+&!+*,)-.%/+0& What are they? Anti-patterns Stuff I see as a practitioner time and time again... ...And wish I didn’t
    35. 35. !"#$%&!'()*(+&!+*,)-.%/+0& Flaccid Technical Lead Anti-patterns
    36. 36. !"#$%&!'()*(+&!+*,)-.%/+0& Flaccid Technical Lead Anti-patterns Just enough design up front is not the same as no design up front
    37. 37. !"#$%&!'()*(+&!+*,)-.%/+0& Inverted Servant Leader Anti-patterns
    38. 38. !"#$%&!'()*(+&!+*,)-.%/+0& Inverted Servant Leader Anti-patterns Can a leopard change its spots?
    39. 39. !"#$%&!'()*(+&!+*,)-.%/+0& Novice in Charge Anti-patterns
    40. 40. !"#$%&!'()*(+&!+*,)-.%/+0& Novice in Charge Anti-patterns “Ahh, but on my last project we...”
    41. 41. !"#$%&!'()*(+&!+*,)-.%/+0& Change everything at once Anti-patterns
    42. 42. !"#$%&!'()*(+&!+*,)-.%/+0& Change everything at once Anti-patterns We are slower than before
    43. 43. !"#$%&!'()*(+&!+*,)-.%/+0& Change everything at once Anti-patterns This Agile thing just doesn’t work! We are slower than before
    44. 44. !"#$%&!'()*(+&!+*,)-.%/+0& Be careful what you wish for Anti-patterns
    45. 45. !"#$%&!'()*(+&!+*,)-.%/+0& Be careful what you wish for Anti-patterns You should give a novice rules...
    46. 46. !"#$%&!'()*(+&!+*,)-.%/+0& Be careful what you wish for Anti-patterns You should give a novice rules... Just make sure they are the right ones.
    47. 47. !"#$%&!'()*(+&!+*,)-.%/+0& Novices don’t know what they want Anti-patterns
    48. 48. !"#$%&!'()*(+&!+*,)-.%/+0& Novices don’t know what they want Anti-patterns Coach #fail
    49. 49. !"#$%&!'()*(+&!+*,)-.%/+0& New Architecture Team Anti-patterns
    50. 50. !"#$%&!'()*(+&!+*,)-.%/+0& New Architecture Team Anti-patterns All the smart people should get together and talk about design right?
    51. 51. !"#$%&!'()*(+&!+*,)-.%/+0& Process Mavens Anti-patterns
    52. 52. !"#$%&!'()*(+&!+*,)-.%/+0& Process Mavens Anti-patterns Lets implement the best process for everyone
    53. 53. !"#$%&!'()*(+&!+*,)-.%/+0& Stagnant Agile Anti-patterns
    54. 54. !"#$%&!'()*(+&!+*,)-.%/+0& Stagnant Agile Anti-patterns One Agile to rule them all and in the darkness bind them
    55. 55. !"#$%&!'()*(+&!+*,)-.%/+0& Agile Adapter Anti-patterns
    56. 56. !"#$%&!'()*(+&!+*,)-.%/+0& Agile Adapter Anti-patterns Is it ok to hammer a square peg into a round hole?
    57. 57. !"#$%&!'()*(+&!+*,)-.%/+0& Hamstrung Scrum Anti-patterns
    58. 58. !"#$%&!'()*(+&!+*,)-.%/+0& Hamstrung Scrum Anti-patterns We have a Scrum master.
    59. 59. !"#$%&!'()*(+&!+*,)-.%/+0& Hamstrung Scrum Anti-patterns We have a Scrum master. We are Agile. Right?
    60. 60. !"#$%&!'()*(+&!+*,)-.%/+0& Root Causes
    61. 61. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes This is about organisations adapting to change in their operating environment.
    62. 62. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes
    63. 63. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes Along comes the World Wide Web...
    64. 64. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes Along comes the World Wide Web... Organisations must track changes to stay competitive
    65. 65. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational 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
    66. 66. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes This is about managing changes to people, and organisations
    67. 67. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes
    68. 68. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes People find change hard
    69. 69. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes People find change hard Often we are not very good at introducing change
    70. 70. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes People find change hard Often we are not very good at introducing change Change takes time and perseverance
    71. 71. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational 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
    72. 72. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes
    73. 73. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes Performance is not a convex function of the choices we make
    74. 74. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes Performance is not a convex function of the choices we make There are local and global optima
    75. 75. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational 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
    76. 76. !"#$%&!'()*(+&!+*,)-.%/+0& Is the organisational design to blame? Root Causes
    77. 77. !"#$%&!'()*(+&!+*,)-.%/+0& Is the organisational design to blame? Root Causes Hamstrung Scrum Architecture Team Process Mavens Stagnant Agile Agile Adapter
    78. 78. !"#$%&!'()*(+&!+*,)-.%/+0& Is the organisational design to blame? Root Causes
    79. 79. !"#$%&!'()*(+&!+*,)-.%/+0& Is the organisational design to blame? Root Causes There is no such thing as the right design
    80. 80. !"#$%&!'()*(+&!+*,)-.%/+0& Is the organisational design to blame? Root Causes There is no such thing as the right design There is no such thing as the right process
    81. 81. !"#$%&!'()*(+&!+*,)-.%/+0& Is the organisational 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
    82. 82. !"#$%&!'()*(+&!+*,)-.%/+0& People break. Deal with it. Root Causes
    83. 83. !"#$%&!'()*(+&!+*,)-.%/+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
    84. 84. !"#$%&!'()*(+&!+*,)-.%/+0& People break. Deal with it. Root Causes
    85. 85. !"#$%&!'()*(+&!+*,)-.%/+0& People break. Deal with it. Root Causes People find change extremely difficult
    86. 86. !"#$%&!'()*(+&!+*,)-.%/+0& People break. Deal with it. Root Causes People find change extremely difficult ...and they always will
    87. 87. !"#$%&!'()*(+&!+*,)-.%/+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
    88. 88. !"#$%&!'()*(+&!+*,)-.%/+0& Individual change
    89. 89. !"#$%&!'()*(+&!+*,)-.%/+0& Managing changes to people So what do we do? Use learning models to flatten the Satir change curve
    90. 90. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus Model of Skill Acquisition So what do we do?
    91. 91. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus Model of Skill Acquisition So what do we do? Novice Context free, determines action based on mechanical application of rules
    92. 92. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus Model of Skill Acquisition 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
    93. 93. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus Model of Skill Acquisition 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
    94. 94. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus Model of Skill Acquisition 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 Expert transcends reliance on rules, guidelines, and maxims. Intuative decsions
    95. 95. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus Model of Skill Acquisition 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
    96. 96. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus model applied to pair So what do we do?
    97. 97. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus model applied to pair So what do we do? Novice Maintains attention while pairing, doesn’t grab mouse or keyboard
    98. 98. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus model applied to pair 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
    99. 99. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus model applied to pair 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…
    100. 100. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus model applied to pair 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…
    101. 101. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus model applied to pair 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…
    102. 102. !"#$%&!'()*(+&!+*,)-.%/+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
    103. 103. !"#$%&!'()*(+&!+*,)-.%/+0& Changes to teams
    104. 104. !"#$%&!'()*(+&!+*,)-.%/+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
    105. 105. !"#$%&!'()*(+&!+*,)-.%/+0& Conway’s Law So what do we do?
    106. 106. !"#$%&!'()*(+&!+*,)-.%/+0& Refactoring (organisations) to So what do we do? Can we use techniques from software engineering to change teams and organisations? Joshua Kerievsky, 2004
    107. 107. !"#$%&!'()*(+&!+*,)-.%/+0& Transitional change So what can we do?
    108. 108. !"#$%&!'()*(+&!+*,)-.%/+0& Transitional change So what can we do? Start where you are
    109. 109. !"#$%&!'()*(+&!+*,)-.%/+0& Transitional change So what can we do? Start where you are Tell people what you are about to do
    110. 110. !"#$%&!'()*(+&!+*,)-.%/+0& Transitional change So what can we do? Start where you are Tell people what you are about to do Track progress visibly
    111. 111. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change
    112. 112. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Requirements pushed ad-hoc to developers
    113. 113. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Requirements pushed ad-hoc to developers Its more efficient that way
    114. 114. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change What if this was an enterprise architecture?
    115. 115. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change What if this was an enterprise architecture?
    116. 116. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Identify a bounded-context
    117. 117. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Implement a coarse- grained interface
    118. 118. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Implement an anti-corruption layer
    119. 119. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Can we apply Conway’s Law?
    120. 120. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Its a real team!
    121. 121. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change
    122. 122. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP board
    123. 123. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP Add a backlog board
    124. 124. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP New requirements Add a backlog board through PM
    125. 125. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP New requirements Add a backlog board through PM Translate requirements
    126. 126. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP New requirements Add a backlog board through PM Queues, Classes of service, WiP limits, Translate Enterprise Service requirements Bus*
    127. 127. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP New requirements Add a backlog board through PM Queues, Classes of service, WiP limits, Translate Profit!! Enterprise Service requirements Bus*
    128. 128. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP New requirements Add a backlog board through PM Queues, Classes of service, WiP limits, Translate Profit!! Enterprise Service requirements Bus* * Ok, not this one
    129. 129. !"#$%&!'()*(+&!+*,)-.%/+0& Breaking the system...
    130. 130. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the Wrong Thing Righter” So what do we do?
    131. 131. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the Wrong Thing Righter” So what do we do? Traditional software development methodologies concentrate on the process and then on the people
    132. 132. !"#$%&!'()*(+&!+*,)-.%/+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
    133. 133. !"#$%&!'()*(+&!+*,)-.%/+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
    134. 134. !"#$%&!'()*(+&!+*,)-.%/+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
    135. 135. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the Wrong Thing Righter” So what do we do?
    136. 136. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the Wrong Thing Righter” So what do we do? Agile software development methodologies concentrate on the people and the customer
    137. 137. !"#$%&!'()*(+&!+*,)-.%/+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
    138. 138. !"#$%&!'()*(+&!+*,)-.%/+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
    139. 139. !"#$%&!'()*(+&!+*,)-.%/+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
    140. 140. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the right thing” So what do we do?
    141. 141. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the right thing” So what do we do? ‘agile’ delivery practices Customer-centric Devolved decision making Organised around demand
    142. 142. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the right thing” So what do we do? How do you do that?
    143. 143. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the right thing” So what do we do? How do you do that? You can’t expect everything for free...
    144. 144. !"#$%&!'()*(+&!+*,)-.%/+0& Summary
    145. 145. !"#$%&!'()*(+&!+*,)-.%/+0& Summary What I just talked about Anti- Introduction Root Causes patterns So what do Questions? Summary we do?
    146. 146. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember one thing Finally...
    147. 147. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember one thing Finally... People will break
    148. 148. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember one thing Finally... People will break and that will mean your project breaking
    149. 149. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember two things Finally...
    150. 150. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember two things Finally... Agile is about more than just iterations
    151. 151. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember two things Finally... Agile is about more than just iterations A set of complementary principles and practices
    152. 152. !"#$%&!'()*(+&!+*,)-.%/+0& and if you remember three Finally...
    153. 153. !"#$%&!'()*(+&!+*,)-.%/+0& and if you remember three Finally... Local optimisation is good
    154. 154. !"#$%&!'()*(+&!+*,)-.%/+0& and if you remember three Finally... Local optimisation is good but systemic optimisation is better
    155. 155. !"#$%&!'()*(+&!+*,)-.%/+0& Questions?
    156. 156. !"#$%&!'()*(+&!+*,)-.%/+0& Obrigado! http://bovon.org @boicy james.lewis@thoughtworks.com

    ×