Agile on the Beach 2014 – My 3 take aways
What is Agile on the beach?
Agile on the Beach is a leading annual conference on the Cornish coast that explores the latest Agile and lean thinking in software craftsmanship, teams and business.
Why did I want to go?
I joined a company that uses Agile about 4 months ago and although I had heard of the concept before, had never worked in an Agile environment and therefore didn’t know much about it.
Was it worthwhile?
In a nutshell, yes. With varied speakers covering 4 tracks, there was something to keep my over-active mind engaged at all times. I feel I have a much better understanding of Agile as a concept, even though there are many different flavours of Agile.
My 3 takeaways from Agile on the Beach
Although I learnt lots of smaller things, here are the 3 main concepts that I chose to pick out from across the sessions.
1) What does it mean to be Agile?
The first key theme I picked up on was that “Agile is something you are, not something you do”. I previously thought that working in an Agile way, just meant following a certain set of practices and doing a certain thing. However, I learnt that this is probably not the case.
For example, doing an ineffective stand-up is not Agile was raised by Frances – Just saying “Yesterday I did Card #2546 and today I am doing card #2347” is not the point of stand-up. You should be highlighting which areas of the code base you have changed and any potential issues. This approach is no more Agile that not doing stand-ups at all and add no value.
In fact, you can not do stand-ups, and still be Agile – Being Agile isn’t just going through the motions, it’s not just doing stand ups and retros. If you’re not embracing change and don’t focus on continuous improvement and technical excellence, and you’re not proactive and brave, don’t work on proper communication and not aim for simplicity, than you aren’t Agile.
You don’t need to ‘do Agile’ if you are Agile.
2) How to add value quickly and in a measured way
There were several talks about how to estimate delivery times and how to make sure that you are delivering the right features for your customer, not just building for the sake of it.
When writing a card, it’s often easily to misunderstand requirements. Talking in examples helps to clarify the feature that you are trying to deliver. For example, the person who wrote the card might want X to happen when you click Y, but this is not what the developer implements. Using examples helps to define the specifics of the task.
An alternative to this is writing Job Stories instead of User Stories. Instead of writing, “As a user, I want to save items to a wish list so I can buy them later”, expand on this and instead write “When I find a product I like but I am not ready to buy yet, I want to save the product for later, so I can quickly come back and purchase it without searching again”. This allows more scope for development of the correct solution, instead of just dictating one way to deliver the feature. The “Job Story” method also makes the feature seem more real and easier to imagine, allowing the developer to think of possible edge cases.
Another thing raised was to consider how you estimate your stories. Instead of estimating that a story is worth 4 story points or will take a week, the suggestion was to have only 4 categories:
- I’ll do it now
- It will take me a day
- It’s too fucking big
- I have no fucking clue.
This granularity of “now” or “1 day” encourages focus on the particular task at hand. Any tasks in “too big” should be broken down to fit “now” or “1 day” and tasks in “no clue” should be investigated until they fit into another category.
Melissa gave an example of testing out a new feature on a page, to try to increase purchase rate of an e-commerce site. However, after implementing the feature, they realised that actually most users didn’t go through the index page which hosted all the products (the one where they made the change) but instead clicked through directly from an email into the individual product. They should have worked this part out first *before* making the change.
If you are trying to release lots of different pieces of functionality at once that are all dependant on each other and simply don’t have the time, then try breaking down the tasks into the smallest viable chunks of each feature – image from J B Rainsberger.
3) Thoughts on pairing
I went to a talk by Kev and Georgie about cross functional pairing. This really opened my eyes – previously I thought pairing was only for developers. However, when I considered it a bit more, I thought about how we have been writing cards in my day job. We have recently been writing cards as a pair with direct developer input. This helps us to flag any areas that might be particularly difficult to implement, even when a task might seem simple from a non-developer viewpoint.
They also offered tips on which pairings might work well and how the pairing relationship may be different depending on who is in the pair. For example, pairing 2 experienced developers, where one of these doesn’t know the code base very well, is a great way to increase the knowledge of the newer developer allowing him to go and pair with a less experienced developer.
They also offered some simple tips on pairing, these were:
Some other more serious tips were raised too:
- If the person typing makes a mistake, give them 15 seconds to fix it themselves before pointing it out.
- If your partner is getting bored or falling asleep, pass them the keyboard.
- If your partner is getting tired or frustrated, ask for the keyboard.
- Talk a lot. Talk about what you’re doing. It helps your partner understand what you’re doing.
For me the conference as a whole was very beneficial as a crash course on Agile. It left me considering a lot of the points raised and I have already started to implement some of the ideas that I was inspired by at the conference. (The scones were great too)