Agile on the Beach 2016 – Day 1

Sun, sand and Agile methodologies – it can only be Agile on the Beach! Like last year, a few of us here from Manifesto headed down Falmouth in Cornwall for the two day conference dedicated to all things Agile. With talks across a variety of streams, from Software Delivery to Product and Team (as well as the mysterious ‘Bonus Track’), there is something for everyone.

Here are some of the key things we took away at the end of the first day.

1. Is Agile A Placebo?

The day kicked off with a keynote delivered by Linda Rising on the importance of using science to make better decisions. Linda began the session asking how the assembled Agile practitioners and enthusiasts decided to use Agile in their businesses, and if we had come to the decision after looking at scientific studies on the benefits of using Agile. The crux of the talk was about how our brains are wired to be more receptive to stories over science, and that we should make an effort to use data to drive our decisions instead of relying on group think and word of mouth.

2. Continuous Delivery – Commit to Production

Paul Boocock of Codeweavers Ltd gave a talk outlining some tips for using Continuous Delivery to get code from a developer commit, into a production system of a large brand in about 15 minutes. Paul outlined how their developers all commit directly into trunk rather than relying on branches, with tiny commits, which reduce or eliminate the need for merge conflicts, with developers committing on average 20 times a week. He also stated that developers are not able to commit if the build is broken, which ensures the whole team take a collective responsibility to fix it.

 

3. Your Code is your Legacy

The focus of Jo Cranford’s talk was about how to ensure that code quality stays high. Most developers have worked on systems where there is a chunk of ‘Legacy Code’ that no one fully understands or likes to touch for fear of breaking the whole system. Jo pointed out that all code you write could eventually become ‘Legacy’, so its important to build quality, sustainable code – in particular code that is easily readable. As an analogy, Jo reminded us of the ‘Broken Window’ theory, and how vital it is to ensure that quick hacks are not allowed to linger in code, as this can encourage poor quality code in the future.

4. Users Behave Irrationally

That’s according to the very interesting talk Kat Matfield gave us today. When we want to do effective user research we need to keep in mind that:

• People can’t predict the future, not even their own personal future.
• People are quite bad in remembering the past, unless it’s a life-changing event
• People are untrusworthy when they talk about their present

So does this make research a useless tool? Of course not, but when testing the effectiveness of a product or of a service we have to remember some key- guidelines:

• Try to mimic real conditions as much as possible
• Never ask about trivial things and avoid leading questions
• Look at recorded behaviour rather than memories
• Ask scrupulously neutral questions
• Don’t let slips which answers are most popular
• Take account of real conditions when analysing results

6. How do you like them Apples?

Adam Polczyk enlightened us with his analysis on agile performance management. We learned that “bad apples”, namely negative group members, will always have a big impact on the performance of the whole team which is often quite destructive.

So what is Adam’s solution to help team to learn more about themselves and truthfully improve?

• Focusing on enhancing team members competences rather than giving traditional unilateral feedback
• Make sure the team holds responsibility and share anonymous feedback very frequently
• Ensure the team competency view is strictly anonymised and visible only to the team itself
• Adapt non-violent communications rather than negative feedback (recognise, appreciate a team member for their work and suggest or recommend rather than criticise for their flaws)