Dave Thomas kicked off proceedings with some Lady Java:
Keynote: Top 10 JVM Erroneous Zones
Cameron Purdy from Oracle presented this session. Whilst it is good to see management levels talking about and understanding the core business, I found this keynote rather average. The presentation is available here.
Getting the opportunity to see Mary Poppendieck speak is always a pleasure, for this conference she delivered her talk on Continuous Design. As the program host for the Lean and Agile track, I also had the pleasure of introducing Mary. Her presentation is available here.
avoid vanity metrics, need actionable metrics, use innovation accounting – start with a hypothesis, build MVP, target initiatives at improving a growth metric in your hypothesis, measure done as adding value
use A/B tests to change your conversion rate
test early – don’t waste your time arguing
cohort metrics – operate on data, as people run into my product how do they behave
feature toggles – switch features on/off on demand, wrap entrance to feature with toggle code, control via configuration file – customers love it
canary releasing – take a small amount of users and give them a new version, need to be able to tell a good change from a bad change very fast – monitor key thresholds and roll back fast if required – make sure when something goes wrong it never goes wrong again
Apple – ” it’s not about money” – understand customer problem and the revenue will turn up
Google – “it’s best to do one thing really, really well” – stay focussed
Amazon – “think long term” – you don’t want make a lot of money off your best customers, some things don’t always make financial sense
3M – “hire good people and leave them get on with it”
I also had a great half hour chat with Mary on the second day of the conference where we talked in-depth about continuous design as well as size of the product team. She believes the key is to enable the complete development cycle and discover good engineering products. We should stop using software words, including Agile, and start using system level engineering. As for the team size debate, we should use system engineering and break our teams into appropriate sub-components.
60 Years of Innovative and Agile Work Practices
Nigel Dalton led this entertaining and informative trip down memory lane, and as the program host for the Lean and Agile track I also had the pleasure of introducing him. The presentation is available here.
people who pay your wages don’t know your stuff, this is a heavy duty approach that has been used for the last 100 years
1930’s Cabinet War Room – as close to an agile room design as you can get, war is a fairly big project!, agile does scale (WWII), lucky it did or this presentation would have been in German!, military and politicians were in the same room, no battle plan survives contact with the enemy
1950’s U2 and SR71 – if you do good engineering, you will be amazed how long it lasts
1960’s moon race – iteratively learning through doing, working rockets are the primary measure of focus
1970’s Luna Tractor – Russians were striving for a different question, what is on the moon?, different question and cost a lot less money, Apollo 13 is the greatest example of an agile project, ask the right question…
1980’s cold war fears – madness of strategic parity, Russians learnt a space shuttle program cost a lot of money after duplicating it, took the USA 30 years to learn it
no scientific experiments that show agile is any better
we need sleep – but average time is dropping, naps are good too…
we are hardwired to look at the horizon, so lift your eyes and look around and blink
lying down improves your cognitive performance
research from University of Queensland – the longer you sit the sooner you will die
the startling ideas come at a time when you are doing nothing
eat before you’re hungry, drink before you’re thirsty – when the brain is lacking energy, the default is to say no
we are hardwired to be close to nature – we do better with natural light and real plants around us, take 5 minutes outside in a natural environment
explain the problem to your dog or a stuffed toy
in meetings, when at an impasse, get each person to explain each others version of the problem
fearless change experiments – test the waters, reflect, small success, step by step
I also had the opportunity to sit in on a very interesting interview with Linda Rising on the Coding By Numbers podcast with Craig Aspinall and Steve Dalton.
Domain-Driven Design for RESTful Systems
Jim Webber delivered this entertaining session, perhaps the most entertaining part was when he tried to explain a cassette tape to a young audience member (I remember loading Commodore 64 games off tape…). His slides are available here.