I attended Day 1 of YOW! Sydney 2013 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.
Jeff Paton (@jeffpaton) is an independent consultant, teacher and Agile coach, and (I believe someone said) the inventor of Story Mapping. He spoke at YOW! about ‘Safety Not Guaranteed: How Successful Teams Ignore the Rules to Create Successful Products’.
Jeff started his talk by announcing that he hated agile development since the moment he first heard of it, but went on to explain that he doesn’t really hate agile now and that an important part of this has been to learn to pay a lot of attention to what he’s doing.
The Origins of Agile’s Arch-enemy: WATERFALL
Jeff talked about how the first description (though not the name) of the ‘Waterfall‘ method of software development came from a paper written by Winston Royce – but the whole point of Royce’s paper was that this method wouldn’t work! Royce actually suggested doing things twice and only delivering the second version to customers.
Is Agile Software Development a Process or a Game?
Jeff conducted an audience exercise where he got us to call out words that we associated with the word ‘Process’, and then words we associated with ‘Game’. The resulting lists of words were not surprising, but Jeff noted that over several years of doing the same exercise, no one has ever mentioned the word “team” as something that comes to mind when they think about “process”.
He then spent some time sharing his own observations of the differences between process and games, in particular noting that games have simple rules, and the skill in achieving success comes from strategies and tactics used to win within the bounds of the rules.
One example of a key difference he gave was that games have ‘positions’, not ‘roles’. In a sports team you have general responsibility for some area of the playing field, but if you’re struggling to control it, other team members are expected to help, and if you leave your position to surge forward and score a goal, no one’s going to criticise your decision to move through someone else’s “patch”. The “roles” assigned to people in software development organisations can often have a more constrictive effect.
He highlighted that process doesn’t equal skill. Following a game plan doesn’t win the game. You need lots of practice to be skillful, and you need to apply that skill to each situation.
He talked about how clear goals were really important. My favourite quote from the talk was:
Finishing on time isn’t success.
We build software, and we’re usually focused on getting it “done”, but the ultimate goal is to please the people who use it. Software is much more like a game than we think. We need to focus on the outcome, not just on staying on the field until the end buzzer.
Process looks good because it seems simpler, manageable and predictable, with clear roles and responsibilities. However, those are not the things that make good teams win.
Examples of Companies Adjusting their Agile and Product Development Approaches
Jeff talked about a company he had worked with (I think it was Liquidnet?) where they had changed their process to get rid of product management as a preparation activity, so that the product design is done together, as a whole team activity, as part of a sprint.
Scrum is an agile strategy, not the “rules” of the game.
Marty Cagan, an internationally renowned expert on product development, once told Jeff: If you’re really good at product development, you’ll be right about a third of the time. Most software fails to achieve its objectives.
Design thinking starts with getting lots of understanding, creating lots of ideas and prototyping lots of them to figure out what works.
Jeff has also assisted or visited Edmunds, a website for pricing information about cars. Almost everyone at Edmunds talks to customers. They do this because piles of data and analytics can tell you heaps about what people do, but it can never tell you WHY they do it. You only way to get to that is to talk to them.
The whole Edmunds team thinks about ideas, creates sketches, shares ideas, build prototypes with paper and scissors, and even does internal trade shows to get feedback from the rest of the company on their new idea prototypes. In short, they are doing heaps of up-front design work and review before diving into implementation. This pulls the design feedback forward to far earlier in the process.
Adding Lean Startup Methods to Agile Development
One approach Jeff suggested for moving away from the chains of “process” is adding the Lean Startup methods pioneered by Eric Ries to your current understanding of agile development.
In 2010 at the Startup Lessons Learned conference, Kent Beck (@KentBeck) one of the originators of the Agile manifesto, suggested the manifesto’s “working software over comprehensive documentation” be replaced with “validated learning over working software (or docs)”. The upshot: working software is not enough. Customers using your software is not enough. To know if you’re succeeding, you need to be able to name what you’ve learnt from each change to your software.
Lean Startup advocates are keen on building fast to get to the “harsh reality” of real data sooner. They want to know if what they’re doing sucks, so that they can move it towards “better” as soon as possible. Again, they’re pulling the feedback forward to earlier in the cycle.
Jeff suggested that when you make learning the primary goal of your iterations, you need to learn about the riskiest assumptions first to get the most critical learning first.
He offered the concept of Post-Agile development, in which “done” doesn’t mean ready to deploy, or deployed, or even “validated to be working”; it means having discussed and concluded what you have learned.
He shared the example of the Nordstrom Innovation Lab and their experiment to shrink the learning loop by putting developers in the store! Worth watching.
However, for some problems, rapid experiments don’t result in the right learnings. And sometimes well-thought out experiments take too much time and money to be commercially viable.
This final slide from Jeff’s talk is a great summary: 
Want to learn more?
The slides from Jeff’s talk are available on the YOW! website.
Image credits: ‘Crash Test Dummies‘ by Tracie Masek
‘12-02 Bsktbll – WCS Crusaders vs Charleston Townies – 159‘ by Gus Estrella
‘Eric Ries – The Lean Startup, London Edition‘ by Betsy Weber
Slide credit: comakers