5 things we learned from Day 1 of Agile on the Beach
Agile on the Beach is a two-day event where Agile practitioners, trainers, theorists and beginners convene to share their experiences, tips and strategies while having a generally nice time on the English coast. This year four of us Manifestonians headed down to Falmouth, Cornwall to soak up the latest in Agile thinking and some sun(ny intervals).
Day 1’s schedule was jam-packed with talks and sessions. Here are five things we picked up that we thought were particularly valuable.
1. People are crap
This was from a talk from Dave Farley – the author of Continuous Delivery (a pretty important book in agile circles). The talk essentially centred around the idea that we’re all pretty flawed and have our limitations. He talked about some fairly wide ranging concepts to help us understand and deal with those limitations, from the hierarchy of needs (bring nice biscuits to a meeting and it’ll be more successful) through to cognitive bias and optical illusions.
2. Google commit 60 times per minute
A talk by Steve Smith called ‘The Death of Continuous Integration’ highlighted the benefits of trunk based integration over using feature branches to integrate developers’ code when building software. He used the example of HP who went from a 1 week build, 6 week testing cycle in 2008 to a 3 hour build, 24hr test cycle with 10-15 builds a day in 2012. Interestingly, Google (with 15,000 developers) commit 60 times a minute!
3. “It’s better to be roughly right than precisely wrong”
Estimating is just that. An estimate. Our clients understandably want to know how much it’s going to cost and how long will it take. So we try to tell them. But it’s always just an estimate. This gem came from David Lowe in a talk called ‘Can Guinness help you estimate?’
A session by Allan Kelly suggested that the project model doesn’t really fit software development. Project thinking is too temporary and doesn’t allow for needs which unfold as the work progresses. He said we should instead be focusing on building and developing continuous teams who deliver benefit. Then you feed them work. Don’t manage projects.
5. Feedback loops are important
This is a thematic takeaway rather than one which results from a single session. One of the key things I saw emerge from today’s set of talks is the importance of having and responding to feedback loops.
This principle appears across every level of the agile process: from granular concepts such as TDD, where feedback can drive the design of the software; to higher level concepts like continuous development, which allow companies to more effectively assess and respond to the impact of their decisions and the value these bring to their users.
Of great importance in the iterative process is the ability for the team itself to communicate and receive feedback, adapting as and when necessary. Effective communication leads to a greater sense of ownership of decisions and goals amongst the team, which in turn provides a greater drive for excellence.
Day 1 complete. More from #AgileOTB coming soon…