5 things we learned from Day 2 of Agile on the Beach

The sun has not been shining very much in Falmouth over these last two days of Agile on the Beach but not to worry: the brilliance of the speakers, sessions and fellow attendees has more than made up for it. In keeping with tradition (which we established yesterday) here are the top things we’ve learned from day 2.

1. Cocaine makes us more productive

Well, sort of – not that we’ve ever tried it or would advocate its use. This came from Jenni Jepsen‘s keynote speech that covered the effects of stress on the brain and how, by reducing stress, we allow our prefrontal cortex to operate more effectively.

This is important because it’s in the prefrontal cortex where our rational, reasoned self lives. When we’re stressed, scared or tired then the limbic system takes over. This is where the more base animal instincts live, which don;t really do much for rational thought.

Cocaine can have a similar effect by increasing dopamine levels in the prefrontal cortex. But we wouldn’t recommend it – using agile methodologies to reduce overall stress is a much better idea.

2. Agile is just like cycling… and jazz

This was from a talk by Danny Whear of ShelterBox. He drew parallels between Dave Brailsford’s approach to coaching the Sky cycling team and the incremental improvements sought delivering projects iteratively when using Agile techniques.

He also equated the perception of Agile to the perception of jazz i.e. it’s confusing, just for experts, isn’t really considered mainstream and the lexicon is hard to learn. The session was one of the most fun and engaging of the 2 days here.

3. User stories are not goals

In ‘User story mapping for fun and profit’ Lynne Johnson and Charlotte Philippe made reference to Ron Jeffries three Cs:

• Card
• Conversation
• Confirmation

They reminded us that the goal is not to write a user story, it’s to understand what’s needed. All too often we get tied up in trying to write a backlog instead of trying to promote the conversation which leads to the confirmation. But once you’ve ticked off the three Cs above you could even be so bold as to throw the user story away (though you’d probably want to keep the acceptance criteria).

4. BDD isn’t about testing, it’s about conversations

Yes, conversations again. There’s a lot more talking involved in software development than most people realise.

There were a couple of sessions that touched on this topic: ’10 things about BDD, Cucumber and Specflow’ by Seb Rose and ‘Taking back BDD’ by Konstantin Kurdyashov.

The focus of Konstantin’s talk was primarily that BDD is about design and communication. It’s a way of collaborating with business and non technical people to define clear business requirement examples and minimise the likelihood of ‘translation cost’.

Another key benefit of BDD is the idea that engaging the business in ongoing conversation allows for better overall understanding, both from a technical delivery view point but also by feeding back into the business understanding, enabling them to react to unexpected knowledge gaps.

As someone still trying to get their head around BDD, Seb’s talk was most interesting and finally gave me that ‘Eureka!’ moment I’ve been searching for. And hey, guess what? BDD is not just for testers but a collaboration between different roles within the development team!

For a long time, I thought it was a job for the testers to write the scripts and run them. How wrong I was! In fact, it begins with a conversation between 3 key roles in the dev team (the three amigos meeting) which will determine exactly how something will work before any development has even begun.

BDD demands collaboration before tests are written and the development can begin. So, now you know.

5. Google only work from trunk

This, from Chris Oldwood‘s session ‘Waltzing with Branches’, was fascinating and goes against the ‘received wisdom’ that we all need to work on branches and then merge into trunk/integration branches later. Of course, what people fail to realise is that Google have over 100 million automated test cases that they can run against the code to check that that last check-in didn’t break the build. It’s a perfectly valid approach – but your tests need to be up to the job.

Well, that’s it from #Agileotb this year. Looking forward to 2016 already…