The problem solver ’ s problem Roger Marlow
You choose Pairs of problems Which would you prefer to solve?
Pacify Get past the compiler
Educate Tune
Entertain Find shortest circuit
Quote Reconcile
Explain why his system is down Factorise
Problems, problems. In the software community we think of ourselves, even define ourselves, as problem solvers But only for certain types of problem
People problems? We dismiss people problems: “ politics ”   “ personality clash ”   “ management ” Identify it. Dismiss it.
So what? People... Commission, Design, Plan, Build, Install, Operate, Fix, Support, Choose, Buy, Sell, Use, Manage and Pay For ...Software. But apart from that, they are irrelevant to it.
The right tools for the job Simplification Intuition Holism Abstraction Logic Decomposition Technology People
The trouble is... Simplification Intuition Holism Abstraction Logic Decomp ’ Our preference for these tools Over these And this dividing line
For example How does this work? Two parrots are sitting on a perch. One says to the other  “ Can you smell fish? ” Holism Intuition Simplification Abstraction Logic Decomposition
Reductionism (it ’ s a problem) I.T. suffers from reductionism We have all seen the damage this does to I.T. departments Analyse, categorise, group, standardise, commodatise Leads to siloed roles, hand-offs, lack of feedback, process over people, contracts over collaboration, etc. So why are we doing it to Agile?
We ’ re forgetting what made Agile work Keep the big picture in mind Iteration, not incrementalism Whole team. Collective code ownership Organise for the most important thing - people on the project Simplification rather than decomposition It   is taking us in the wrong direction
For example: stories Hand written. Just a handful. Formal. Hundreds. In a tool De-humanised Human friendly
Another example: iterations Only ever a few days from finished Manageable work load Genuine want to  ‘ go for it ’  at iteration end Too much work to comprehend ‘ Iteration ’  ends ignored Seldom feel done De-humanised Human friendly
Other examples Experience based estimation Human friendly office behaviour Refactoring: tidy-up as you go Simple tools, e.g. cards Ever more elaborate estimation techniques Wearisome stand-ups Multi-week  “ refactorings ”  to switch to an uber-design An plethora of tooling Reductionist, de-humanised Simple, Intuitive, Holistic
Glimmers of hope? InfoQ mailer: July 27th Social data as graphs of objects Database migration at Netflix Craft and engineering in the development process Type checking in dynamic languages New book: Individuals and interactions: An Agile Guide Comparison of automation tooling Example of Oozie workflow server Tools for reverse engineering in .NET and Java Arguments for REST in SOA
Glimmers of hope? New book: Individuals and interactions: An Agile Guide “ The authors present a set of tools and techniques... ” “ The book places a lot of emphasis on knowing yourself, and understanding how you interact with others. ” “ It presents the DISC framework for self- and team-discovery ” “ How does the DISC framework compare to other psychometric tools, such as Myers-Briggs Type Indicator? If someone knows their MBTI profile how does it map to the DISC framework you present? ” “ Our experience is that the majority of the really difficult problems that projects (and even companies) face are not technology related but rather associated in some way to problems with team dynamics, organizational behavior or communication issues. DISC is not the end all-be-all. But it is one component in helping team members get along, understand one another, and modify communication styles to maximize effectiveness. ”
We have seen this before Reductionism made Waterfall ludicrous The tendencies are still there Agile started with a clean slate, but it ’ s starting to look messy It ’ s not the methodology - It ’ s us
And my point is? Agile was successful because it was people friendly, and people are critical to software development. It gave those of us who are not naturally good at  ‘ people friendly ’  stuff, a people friendly process. Agile won ’ t progress unless we remember this It needs to progress because it does n o t always work Emphasis on tools is misplaced. It is of secondary importance People are of primary importance. They make the difference Lets see more interest in that at conferences like this

The problem solvers problem

  • 1.
    The problem solver’ s problem Roger Marlow
  • 2.
    You choose Pairsof problems Which would you prefer to solve?
  • 3.
    Pacify Get pastthe compiler
  • 4.
  • 5.
  • 6.
  • 7.
    Explain why hissystem is down Factorise
  • 8.
    Problems, problems. Inthe software community we think of ourselves, even define ourselves, as problem solvers But only for certain types of problem
  • 9.
    People problems? Wedismiss people problems: “ politics ” “ personality clash ” “ management ” Identify it. Dismiss it.
  • 10.
    So what? People...Commission, Design, Plan, Build, Install, Operate, Fix, Support, Choose, Buy, Sell, Use, Manage and Pay For ...Software. But apart from that, they are irrelevant to it.
  • 11.
    The right toolsfor the job Simplification Intuition Holism Abstraction Logic Decomposition Technology People
  • 12.
    The trouble is...Simplification Intuition Holism Abstraction Logic Decomp ’ Our preference for these tools Over these And this dividing line
  • 13.
    For example Howdoes this work? Two parrots are sitting on a perch. One says to the other “ Can you smell fish? ” Holism Intuition Simplification Abstraction Logic Decomposition
  • 14.
    Reductionism (it ’s a problem) I.T. suffers from reductionism We have all seen the damage this does to I.T. departments Analyse, categorise, group, standardise, commodatise Leads to siloed roles, hand-offs, lack of feedback, process over people, contracts over collaboration, etc. So why are we doing it to Agile?
  • 15.
    We ’ reforgetting what made Agile work Keep the big picture in mind Iteration, not incrementalism Whole team. Collective code ownership Organise for the most important thing - people on the project Simplification rather than decomposition It is taking us in the wrong direction
  • 16.
    For example: storiesHand written. Just a handful. Formal. Hundreds. In a tool De-humanised Human friendly
  • 17.
    Another example: iterationsOnly ever a few days from finished Manageable work load Genuine want to ‘ go for it ’ at iteration end Too much work to comprehend ‘ Iteration ’ ends ignored Seldom feel done De-humanised Human friendly
  • 18.
    Other examples Experiencebased estimation Human friendly office behaviour Refactoring: tidy-up as you go Simple tools, e.g. cards Ever more elaborate estimation techniques Wearisome stand-ups Multi-week “ refactorings ” to switch to an uber-design An plethora of tooling Reductionist, de-humanised Simple, Intuitive, Holistic
  • 19.
    Glimmers of hope?InfoQ mailer: July 27th Social data as graphs of objects Database migration at Netflix Craft and engineering in the development process Type checking in dynamic languages New book: Individuals and interactions: An Agile Guide Comparison of automation tooling Example of Oozie workflow server Tools for reverse engineering in .NET and Java Arguments for REST in SOA
  • 20.
    Glimmers of hope?New book: Individuals and interactions: An Agile Guide “ The authors present a set of tools and techniques... ” “ The book places a lot of emphasis on knowing yourself, and understanding how you interact with others. ” “ It presents the DISC framework for self- and team-discovery ” “ How does the DISC framework compare to other psychometric tools, such as Myers-Briggs Type Indicator? If someone knows their MBTI profile how does it map to the DISC framework you present? ” “ Our experience is that the majority of the really difficult problems that projects (and even companies) face are not technology related but rather associated in some way to problems with team dynamics, organizational behavior or communication issues. DISC is not the end all-be-all. But it is one component in helping team members get along, understand one another, and modify communication styles to maximize effectiveness. ”
  • 21.
    We have seenthis before Reductionism made Waterfall ludicrous The tendencies are still there Agile started with a clean slate, but it ’ s starting to look messy It ’ s not the methodology - It ’ s us
  • 22.
    And my pointis? Agile was successful because it was people friendly, and people are critical to software development. It gave those of us who are not naturally good at ‘ people friendly ’ stuff, a people friendly process. Agile won ’ t progress unless we remember this It needs to progress because it does n o t always work Emphasis on tools is misplaced. It is of secondary importance People are of primary importance. They make the difference Lets see more interest in that at conferences like this