In this post I am going to mention several talks from Agile on the Beach. You can get a summary of the talks by reading my notes here. You can also watch the full videos here.

*

A couple of weeks ago I went to Agile on the Beach and I did my best to live-blog my notes from the sessions. In most cases I was able to publish my notes before the speaker had finished answering questions.

I’ve never been big on note-taking but I found this exercise really useful. I’ve often found that by explaining a concept to someone else it helps you to comprehend it yourself and this was no different. While the speakers were talking I was actively putting the concepts into my own words and by making my notes public I was motivated to ensure that they were clear and accurate.

However, when one of the other attendees asked me which my favourite session was, I drew a blank. I had made the rookie mistake of attending every session and I had written over 7,000 words in two days. At the end of it all, call it information overload, I could barely remember most of it.

This made me think of what Marcin Florean (@mfloryan) told us at the beginning of his talk.

“I’m really sorry you came to the conference. You will not learn anything today.”

His talk told us that in order to truly learn something our learning must be primed, deliberate and validated.

He finished with a quote:

“If you’ve done something with something you’ve learned, then perhaps you have learned it.”

It was probably someone very wise and intelligent that spoke those words but I didn’t catch who it was because my head was buried in my laptop.

It occurred to me that the notes I had taken were a great starting point, but due to the sheer amount of stuff I needed dedicate more time to actively process all the information. Then finally I needed to do something with the information to validate that I understand it properly.

That brings me to this post.

My first objective: Define “agile”

There was a moment in Nick McKenna’s (@nickmckenna’s) “There is no agile” talk (in the afternoon on the second day of an agile themed conference) where he asked anyone in the room to define ‘agile’. He was met with silence. I think that demonstrates an uneasy truth that many of us use the word a lot – but not many of us are confident to stand up and define it.

Stop reading for a moment and try to define agile yourself in your mind. (Don’t use Google.) Would you be confident to stand up in front of your peers and tell them your definition?

Simon Brown (@simonbrown) discussed how it was important for teams to have a common language in order to work together productively. So if agile is so hard to define, perhaps we are in trouble?

It’s very easy to list a bunch of processes that feel very agile: KanBan, stand-up, retrospectives, frequent releases. But doesn’t the hallowed agile manifesto tell us that individuals and interactions are more important than processes and tools? So defining agile as a bunch of processes feels wrong.

That’s because agile is a feeling isn’t it. We know in our gut if something is or isn’t agile. If someone disagrees they just don’t get agile. Hmmm, this line of thought makes me feel uncomfortable. If we can’t put into words why the other person “doesn’t get” agile then maybe we should think about our own understanding before making judgements about others? Perhaps Simon Brown was on to something?

So if we can’t define agile as a process or a feeling we talk about what agile does or doesn’t do. It promotes delivering value early. It is about iterating and learning. It is about evolving our designs or requirements as we go. It’s about self-organising teams communicating and working together efficiently. It isn’t waterfall. But what something does is not the same as what it is. A good manager probably does all of those things, but agile is not a human being.

So what on earth is it?

I think that the closest thing to a definition came in the day one keynote by JB Rainsberger (@jbrains). Although I don’t think he attempted a one line definition at all. He talked about how agile probably is some ethereal feeling or understanding that can’t be easily defined after all, but that describing it as such makes us look foolish and doesn’t help people to understand it better.

He quoted Chip Heath and told us that if we can learn, understand and then script out the critical moves (the processes) we are able to think about problems in a smarter way and make better decisions. He promoted the idea that by starting out by following the familiar agile processes we can take our own journeys to understanding agile. (For more detailed notes on what those processes are read my notes from his session or watch the video).

Nick McKenna took this a step further (to the point of thought-provoking controversy to be fair) by saying that once a team is comfortable with the process they should be trying to iterate through the processes more quickly.

Start with a four week sprint. Move to a two week sprint. Move to a one week or a one day or an hourly sprint. Start with a monthly one hour retrospective. Eventually retrospectives will be a five minute chat at the end of each day.

In time, all the processes become so ingrained and familiar that we are doing them habitually, unconsciously and continuously. At that point the regular one hour meetings become a waste of time. We don’t need the processes any more.

Perhaps when we get there we have achieved enlightenment? (Then again, perhaps now I’m being guilty, as JB Rainsberger put it, of sounding like a “utopian nut”?)

In my next post…

This post is more than long enough now but I’ve only completed half the task I set out to achieve. In my next post I’m going to write about what I learned when I applied some of the agile processes and other lessons from Agile on the Beach to an unlikely real world project.