Agile Adoption Anti Patterns

  • 1,514 views
Uploaded on

Talk I gave at Agile Vancouver 2009

Talk I gave at Agile Vancouver 2009

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,514
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
0
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

































Transcript

  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& Agenda What am I going to talk Anti- Introduction Root Causes patterns So what do Questions? Summary we do?
  • 3. !"#$%&!'()*(+&!+*,)-.%/+0& Introduction
  • 4. !"#$%&!'()*(+&!+*,)-.%/+0& Who is this James Lewis? Introduction
  • 5. !"#$%&!'()*(+&!+*,)-.%/+0& Who is this James Lewis? Introduction A developer
  • 6. !"#$%&!'()*(+&!+*,)-.%/+0& Who is this James Lewis? Introduction A developer I’ve been called an architect but not to my face
  • 7. !"#$%&!'()*(+&!+*,)-.%/+0& Who is this James Lewis? Introduction A developer I’ve been called an architect but not to my face XP Coach
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& AP of AA Introduction
  • 10. !"#$%&!'()*(+&!+*,)-.%/+0& AP of AA Introduction Don’t make the same mistakes as me
  • 11. !"#$%&!'()*(+&!+*,)-.%/+0& AP of AA Introduction Don’t make the same mistakes as me What this talk isn’t
  • 12. !"#$%&!'()*(+&!+*,)-.%/+0& AP of AA Introduction Don’t make the same mistakes as me What this talk isn’t Complete
  • 13. !"#$%&!'()*(+&!+*,)-.%/+0& AP of AA Introduction Don’t make the same mistakes as me What this talk isn’t Complete The answer
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& Who is choosing Agile? Introduction
  • 16. !"#$%&!'()*(+&!+*,)-.%/+0& Who is choosing Agile? Introduction Is it still developers?
  • 17. !"#$%&!'()*(+&!+*,)-.%/+0& Who is choosing Agile? Introduction Is it still developers? Is it a golf course decision?
  • 18. !"#$%&!'()*(+&!+*,)-.%/+0& Who is choosing Agile? Introduction Is it still developers? Is it a golf course decision? This brings new challenges
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& What is an organisation? Introduction John Roberts. The modern Firm, 2004
  • 21. !"#$%&!'()*(+&!+*,)-.%/+0& What is an organisation? Introduction People John Roberts. The modern Firm, 2004
  • 22. !"#$%&!'()*(+&!+*,)-.%/+0& What is an organisation? Introduction People Architecture John Roberts. The modern Firm, 2004
  • 23. !"#$%&!'()*(+&!+*,)-.%/+0& What is an organisation? Introduction People Architecture Routines John Roberts. The modern Firm, 2004
  • 24. !"#$%&!'()*(+&!+*,)-.%/+0& What is an organisation? Introduction People Architecture Routines Culture John Roberts. The modern Firm, 2004
  • 25. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction
  • 26. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction Structure
  • 27. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction Structure Strategy
  • 28. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction Structure Strategy People we hire
  • 29. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction Structure Strategy People we hire People we fire
  • 30. !"#$%&!'()*(+&!+*,)-.%/+0& Performance as a function of the choices Introduction Structure Strategy People we hire People we fire Routines we follow
  • 31. !"#$%&!'()*(+&!+*,)-.%/+0& Anti-patterns
  • 32. !"#$%&!'()*(+&!+*,)-.%/+0& What are they? Anti-patterns
  • 33. !"#$%&!'()*(+&!+*,)-.%/+0& What are they? Anti-patterns Stuff I see as a practitioner time and time again...
  • 34. !"#$%&!'()*(+&!+*,)-.%/+0& What are they? Anti-patterns Stuff I see as a practitioner time and time again... ...And wish I didn’t
  • 35. !"#$%&!'()*(+&!+*,)-.%/+0& Flaccid Technical Lead Anti-patterns
  • 36. !"#$%&!'()*(+&!+*,)-.%/+0& Flaccid Technical Lead Anti-patterns Just enough design up front is not the same as no design up front
  • 37. !"#$%&!'()*(+&!+*,)-.%/+0& Inverted Servant Leader Anti-patterns
  • 38. !"#$%&!'()*(+&!+*,)-.%/+0& Inverted Servant Leader Anti-patterns Can a leopard change its spots?
  • 39. !"#$%&!'()*(+&!+*,)-.%/+0& Novice in Charge Anti-patterns
  • 40. !"#$%&!'()*(+&!+*,)-.%/+0& Novice in Charge Anti-patterns “Ahh, but on my last project we...”
  • 41. !"#$%&!'()*(+&!+*,)-.%/+0& Change everything at once Anti-patterns
  • 42. !"#$%&!'()*(+&!+*,)-.%/+0& Change everything at once Anti-patterns We are slower than before
  • 43. !"#$%&!'()*(+&!+*,)-.%/+0& Change everything at once Anti-patterns This Agile thing just doesn’t work! We are slower than before
  • 44. !"#$%&!'()*(+&!+*,)-.%/+0& Be careful what you wish for Anti-patterns
  • 45. !"#$%&!'()*(+&!+*,)-.%/+0& Be careful what you wish for Anti-patterns You should give a novice rules...
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& Novices don’t know what they want Anti-patterns
  • 48. !"#$%&!'()*(+&!+*,)-.%/+0& Novices don’t know what they want Anti-patterns Coach #fail
  • 49. !"#$%&!'()*(+&!+*,)-.%/+0& New Architecture Team Anti-patterns
  • 50. !"#$%&!'()*(+&!+*,)-.%/+0& New Architecture Team Anti-patterns All the smart people should get together and talk about design right?
  • 51. !"#$%&!'()*(+&!+*,)-.%/+0& Process Mavens Anti-patterns
  • 52. !"#$%&!'()*(+&!+*,)-.%/+0& Process Mavens Anti-patterns Lets implement the best process for everyone
  • 53. !"#$%&!'()*(+&!+*,)-.%/+0& Stagnant Agile Anti-patterns
  • 54. !"#$%&!'()*(+&!+*,)-.%/+0& Stagnant Agile Anti-patterns One Agile to rule them all and in the darkness bind them
  • 55. !"#$%&!'()*(+&!+*,)-.%/+0& Agile Adapter Anti-patterns
  • 56. !"#$%&!'()*(+&!+*,)-.%/+0& Agile Adapter Anti-patterns Is it ok to hammer a square peg into a round hole?
  • 57. !"#$%&!'()*(+&!+*,)-.%/+0& Hamstrung Scrum Anti-patterns
  • 58. !"#$%&!'()*(+&!+*,)-.%/+0& Hamstrung Scrum Anti-patterns We have a Scrum master.
  • 59. !"#$%&!'()*(+&!+*,)-.%/+0& Hamstrung Scrum Anti-patterns We have a Scrum master. We are Agile. Right?
  • 60. !"#$%&!'()*(+&!+*,)-.%/+0& Root Causes
  • 61. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes This is about organisations adapting to change in their operating environment.
  • 62. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes
  • 63. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes Along comes the World Wide Web...
  • 64. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes Along comes the World Wide Web... Organisations must track changes to stay competitive
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes This is about managing changes to people, and organisations
  • 67. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes
  • 68. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes People find change hard
  • 69. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes People find change hard Often we are not very good at introducing change
  • 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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes
  • 73. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes Performance is not a convex function of the choices we make
  • 74. !"#$%&!'()*(+&!+*,)-.%/+0& Organisational Change Root Causes Performance is not a convex function of the choices we make There are local and global optima
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& Is the organisational design to blame? Root Causes
  • 77. !"#$%&!'()*(+&!+*,)-.%/+0& Is the organisational design to blame? Root Causes Hamstrung Scrum Architecture Team Process Mavens Stagnant Agile Agile Adapter
  • 78. !"#$%&!'()*(+&!+*,)-.%/+0& Is the organisational design to blame? Root Causes
  • 79. !"#$%&!'()*(+&!+*,)-.%/+0& Is the organisational design to blame? Root Causes There is no such thing as the right design
  • 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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+0& People break. Deal with it. Root Causes
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& People break. Deal with it. Root Causes
  • 85. !"#$%&!'()*(+&!+*,)-.%/+0& People break. Deal with it. Root Causes People find change extremely difficult
  • 86. !"#$%&!'()*(+&!+*,)-.%/+0& People break. Deal with it. Root Causes People find change extremely difficult ...and they always will
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& Individual change
  • 89. !"#$%&!'()*(+&!+*,)-.%/+0& Managing changes to people So what do we do? Use learning models to flatten the Satir change curve
  • 90. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus Model of Skill Acquisition So what do we do?
  • 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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+0& The Dreyfus model applied to pair So what do we do?
  • 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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+0& Changes to teams
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& Conway’s Law So what do we do?
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& Transitional change So what can we do?
  • 108. !"#$%&!'()*(+&!+*,)-.%/+0& Transitional change So what can we do? Start where you are
  • 109. !"#$%&!'()*(+&!+*,)-.%/+0& Transitional change So what can we do? Start where you are Tell people what you are about to do
  • 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. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change
  • 112. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Requirements pushed ad-hoc to developers
  • 113. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Requirements pushed ad-hoc to developers Its more efficient that way
  • 114. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change What if this was an enterprise architecture?
  • 115. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change What if this was an enterprise architecture?
  • 116. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Identify a bounded-context
  • 117. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Implement a coarse- grained interface
  • 118. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Implement an anti-corruption layer
  • 119. !"#$%&!'()*(+&!+*,)-.%/+0& Groups aren’t Teams Transitional change Can we apply Conway’s Law?
  • 120. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Its a real team!
  • 121. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change
  • 122. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP board
  • 123. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP Add a backlog board
  • 124. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP New requirements Add a backlog board through PM
  • 125. !"#$%&!'()*(+&!+*,)-.%/+0& Encapsulated Team Transitional change Introduce a WiP New requirements Add a backlog board through PM Translate requirements
  • 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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+0& Breaking the system...
  • 130. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the Wrong Thing Righter” So what do we do?
  • 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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the Wrong Thing Righter” So what do we do?
  • 136. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the Wrong Thing Righter” So what do we do? Agile software development methodologies concentrate on the people and the customer
  • 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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+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. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the right thing” So what do we do?
  • 141. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the right thing” So what do we do? ‘agile’ delivery practices Customer-centric Devolved decision making Organised around demand
  • 142. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the right thing” So what do we do? How do you do that?
  • 143. !"#$%&!'()*(+&!+*,)-.%/+0& “Do the right thing” So what do we do? How do you do that? You can’t expect everything for free...
  • 144. !"#$%&!'()*(+&!+*,)-.%/+0& Summary
  • 145. !"#$%&!'()*(+&!+*,)-.%/+0& Summary What I just talked about Anti- Introduction Root Causes patterns So what do Questions? Summary we do?
  • 146. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember one thing Finally...
  • 147. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember one thing Finally... People will break
  • 148. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember one thing Finally... People will break and that will mean your project breaking
  • 149. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember two things Finally...
  • 150. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember two things Finally... Agile is about more than just iterations
  • 151. !"#$%&!'()*(+&!+*,)-.%/+0& If you remember two things Finally... Agile is about more than just iterations A set of complementary principles and practices
  • 152. !"#$%&!'()*(+&!+*,)-.%/+0& and if you remember three Finally...
  • 153. !"#$%&!'()*(+&!+*,)-.%/+0& and if you remember three Finally... Local optimisation is good
  • 154. !"#$%&!'()*(+&!+*,)-.%/+0& and if you remember three Finally... Local optimisation is good but systemic optimisation is better
  • 155. !"#$%&!'()*(+&!+*,)-.%/+0& Questions?
  • 156. !"#$%&!'()*(+&!+*,)-.%/+0& Obrigado! http://bovon.org @boicy james.lewis@thoughtworks.com