Out and About: Agile on the Beach 2014 - Day 1

I spotted this last year and missed out on the early bird so made an extra special effort this year since this is one of the few Agile specific conferences in the UK.

Arriving on the Wednesday night meant a pasty and pint was foisted up on us in the bar, which was very welcome after a 5 hour drive. The subsequent pints chatting with the most excellent Jon Tilt from IBM might have been a slight mistake - but we only really discovered this at the breakfast retrospective. Jon showed us all up at breakfast after a run around Falmouth University campus looking fresh as a daisy.

The keynote this year was J. B. Rainsberger, who gave us a round trip of movements and the future of Agile with specific emphasis on XP. As with any good key note there were points I agreed with and some I didn't but the perspective was most welcome. Obviously a seasoned speaker it was a pleasure to listen to and the hour went fast.

Starting a conference about Agile with talking about the death of the brand i.e. Post Agile might have made some people feel uncomfortable but it embraced the idea that change is good as we learn from our experiences. Also, talking about "confident humility" resonated with me - the attitude we bring with us when we collaborate or pair is all important.

There was some fun too - the simplified planning cards were something I would adopt tomorrow! Can't seem to find a picture of them but there were just 3: Do it, Too F**king Big, No F**king Idea. J.B. wondered if there should be just one more, "I'll do that now"

Agile on the Beach has 4 tracks - Craftmanship, Team, Business and Product (which was a bonus track for this year). Curiously, I did not attend a single Craftmanship session which proved to me how my emphasis has changed over the last few years. People might create but teams deliver.

I started the day listening to Allan Kelly talking about "Does Agile work outside Software". This was more of a decomposition of what value we expect from Agile and if they apply to other types of business. There were some interesting points raised but the examples were the most compelling.

Lonely Planet apparently use SCRUM throughout the organisation - a talk was given at Agile on the Beach 2013 about how their lawyers use it. Pair Programming? Try pair laywering (if that is a word) - a way of building peer review into the creation of legal documents. Same idea applied to different field. They also use stand ups, iterations and retrospectives.

There was more of this throughout the conference - "Agile = consistently identify and seize opportunities" is a concept that can be applied universally. Although some practices are specific to a field, the principles can be applied to many organisations. Interesting stuff.

Next I moved over to the Team track with a talk from Darci Dutcher about fostering collaboration with Designers. This talk resonated with me since I have had challenges getting developers to communicate. It seems that without IM or SMS as a buffer many of them have problems. Even bribes don't seem to work :(

She focused he talk around 3 ideas: Attitude, Skills and Facilitation. I really liked this talk - specifically the point that nobody 'teaches' collaboration. As she pointed out this is not the same as a compromise or what your bosses opinion is. It should be something new, created by the people in the room, each progressing ideas and being creative.

I did manage to ask her about what else we can do with people who just won't dive in. I have an article on some of these thoughts coming up but Jon Tilt had a some insight - "If you can't change the people, change the people" (not something I like to think about since I like the people I work with)

Talking about Jon... I have seen Jon before at Hursley talking about how IBM started to use Agile. The thing like about Jon's talks is that the challenges IBM face are way larger than pretty much anything anyone else is talking about.

Fancy getting about 30,000 developers across 20 countries and 80 locations on the same page? These developers also work on radically different products (through many acquisitions) and have completely different cultures. Where do you start? So, the title "Making the Elephant Dance" is apt.

Jon is also a great speaker, so this was fun too. My take away from this was their use of Confidence Maps to allow quick visual representations of a projects current status - even the attendees could pick out the project in trouble from the example.

So after a quick bit of lunch (nothing special, sadly - I was spoiled at Re:Develop!) I arrived a little late to see Melissa Perri from produxlabs.com talk about Lean Product Management. It was crammed - the Software track had the smallest room by far and this session proved most excellent, even though I was on the floor in the isle with half the room.

Melissa is an awesome speaker - fast but easy to understand. Her point about moving your focus to the problem is something I have long believed in too. I specifically liked the alternative structure to user stories that she suggested:

When <situation>
I want to <action>
So I can <outcome>

The shift of emphasis to make the problem the topic of conversation is similar to other alternative templates suggested for feature injection. I think I prefer this one however, especially when it is backed up with "Explore problems rather than gather requirements". I think that the phrase 'Problems not Features' could be a bumper sticker. Maybe a tattoo?

There was a nice comparison between a 'normal' Product Manager and Lean Product Manager - essentially that they work to a Goal. She put emphasis on experimenting not developing, proving you are moving the right direction and working with the whole team to produce results. She asked us "What does success look like?". It made me wonder if I was doing the wrong job.... this looked much like what I enjoy doing!

There was more (much more). Her take on an alternative to road maps is something I want to look into. She also wins the newly created conference award for most amount of amusing cat slides - well done you :)

Back on the business track was Frances Bonnington with a talk about the application of SCRUM is a non-engineering industry. Frances was a newly qualified ScrumMaster at this time and this was almost a trial of fire as she took us through a very honest look at what worked and did not work. It all had a happy ending, however when she took charge of some geeks as ScrumMaster. I like happy endings.

Having learned that Melissa's talks are usually rammed, I was early for her last session called "Beyond Pretty: Creating Measurable Designs". I even had a desk so I could write a bit more legibly, go me!

She kicked off with decomposing 'design' - being a mix of Visual Design (What it looks like), Information Architecture (How information is composed on the page), UI Design (How we interact with the design), UX Design (Can users achieve their goal?) and finally Marketing Design (Does it sell the message?).

She posed the question if any one person can achieve all these things, using the phrase 'the unicorn designer'..... makes me think of how I feel about the phrase 'Full Stack Developers' for exactly the same reason.

The talk was about measuring design, which started with a quote:

What cannot be defined, cannot be measured;
When cannot be measured cannot be managed.
- Paul Lillrank

The 'normal' linear approach (IDEA -> Research -> Wireframe -> Build -> Launch!) makes to many assumptions on what is a set of decision. Instead, treat the design as a hypothesis and treat this as a cycle allowing you to test the hypothesis. We only launch once we have solved the customers problem.

She explained there are 2 types of measurement: Quantitive and Qualitiative.

Quantitive is useful for spotting trends and we can measure them against KPIs but it won't tell you why. Lots of tools to do this for you!
Qualitative is about observing behaviour and finding meaning.

Measurable design calls on both of these to prove if your solution is working.

There was a bit of cross over with her previous talk and that was a good thing. The ideas of iterative learning makes a lot of sense and she made a good point that you should only make small changes so you can monitor the outcome. If the change is too large, how do you know what delivered the impact you are looking for?

And there were more cats.

Finally, we ended the day with some flash talks. The highlight for me was a 5 minute talk on certifications and if they are good or bad. The suggestion was for a new certification, a CSSTWP:

Certified Stealing Sh*t That Works Practitioner

Awesome! The stickers were late apparently, which is a shame because I think I would prefer this one over anything else I have seen.

Also of interest was mutation testing. How do you know if your unit tests are working or any good? Well, how about injecting errors and running your unit tests again? Didn't sound like there was much in the way of tooling but I do like the idea.

A conference would not have been a conference without a bit of a party, hosted by IBM. At 6pm we all tottered off to the local beach for a few drinks and some food. They don't call it Agile on the Beach for nothing - by the way, organisers pay attention, it would be much easier to get corporate sponsorship if the name was different :)

No UX for you!

A few years ago, a designer friend said that we should load a different UI for older browsers. He wanted to make it look horrible and have the bare minimum functionality that we could get away with.

At the time, we basically ignored him and put it down to too much beer the night before. It turns out he might have been on to something, if this is anything to go by:

http://www.theregister.co.uk/2014/08/31/google_search_browser_support/

Guess this just goes to prove how important the user experience is. His notion that a terrible user experience would force people to move or upgrade might have been a stroke of genius. Lets face it, nothing else seems to have worked!

What do your customers know anyway?

Agile undoubtedly changes how we engage with our customer. The customer is centre stage to all our efforts.

For any organisation that has kept their customers at arms length, this is a scary prospect. It is highly likely that customers are more hostile than helpful in this scenario.

Involving customers in the development process is not an easy thing to achieve. I have even heard it said that it cannot be done for various reasons. This typically reduces customer involvement to demands made during sale or contract renewal - which are both driven by sales people.

At this point, we are clearly in panic mode as our number one concern is to protect revenue. This is typically where good product design is the last consideration and the product is polluted with some pretty badly designed features.

This is not the customer engagement we need. If it were left to the customer they would have the 'Do It' button that basically performs their specific function. The customer does not know best when it comes to product design - you do. That is what you bring to the party.

Just because your existing customers will put up with a naff experience don't forget that new customers might not be so forgiving. A poor user experience will ultimately affect your ability to attract new customers - they have zero investment in you and will simply move on.

Getting involvement with your customer as a standard part of your development process will radically shake up how you work as a business. Listening to your customer is where the agility that you are looking for will come from.

Our engagement with the customer should focus on one thing - what is the problem we are trying to solve for them. By concentrating on the high level behaviours they are looking for, we get to solve that problem for them. That uses our formidable skills as software developers to their full extent.

The customer does not know what they want. They know what problem they need solving. Once we know that, we can create software that is truly useful.

Just like you would not trust anyone to pass on a really important message, getting the customer to explain the problem to the people who will do the work is the holy grail. The more people you have in the way, the less likely we will solve the customers problem. Diluting their message through a chain of dialogues that are each biased is a waste of everyone's time.

If you can do all this, then you only need a team who can guide conversations with your customer to fully appreciate what problem the customer wants to solve.... and we all have one of those, right?