Alan Stevens - Manage Complexity with Agility

This session rocked!

Alan started out by pointing out that he is not an expert, just an enthusiast. His enthusiasm was self-evident and contagious.

He said that this session is about what has worked for him and encouraged us to avoid dogma and take what works for each of us.

The following are my key take-aways from Alan's session:

Iterations
Iterations are about putting a heartbeat to your practice and about creating a constant velocity. (Don’t push out a whole bunch of stuff one month and nothing the next. ) These are great things to keep in mind. Here I am writing this weeks later realizing just how much I need to put this into practice.

Alan's Law
“Heroism is Failure” If you have to be a hero on a regular basis, something else is broken.

Short Horizon
If you're working with regular 2 or 4 week iterations, you have an emotional advantage: You know what you’re dealing with. If you're coding for months on end with no iterations, you can feel lost. Also, it gives you the chance for Frequent Course Corrections. Two to four weeks worth of “wrong work” is easier to correct than 6-9 months.

User Stories
Alan emphasized two points. First, user stories are Users' Goals in Users' Terms. They are not technical requirements. They are not about software or technology. They are the essence of the value they need us to deliver.

For developers, it is a reminder of a future conversation – a to-do list.

Alan also suggested the following user stories template:
As a : (Role)
I want (something)
So that (benefit)

User stories allow us to avoid BDUF – Big Design Up Front.

The Last Responsible Moment
Defer decisions until the last responsible moment because that is when we have the most information. Don’t pretend you know things you don’t.

The next portion of Alan's session covered testing and dependency injection and he showed FoxUnit and FoxMock. I saw Alan cover these topics in very good detail last year at Southwest Fox and FoxForward.

Refactoring
Alan started his discussion of refactoring by asking "if" we refactor and what we do when we refactor. It seemed that the audience had a pretty good handle on refactoring. Alan reviewed some common elements of refactoring such as Code Smells. (a hint that something might be wrong in the code)

Alan made the point that you should Enable Change – if you’re afraid to change a piece of code, that’s a smell.

I jotted down a few additional quotes that I thought were worth sharing:

Work on your business not just in your business. - Michael Gerber
Value Developer Cycles over CPU cycles
Eliminate Waste
Prevention is the best cure.
Avoid Complacency

Finally Alan recommended a couple books that I need to add to my reading list:
The Pragmatic Programmer – Andrew Hunt and Dave Thomas
The Goal – Eliyahu M. Goldratt and Jeff Cox

This was one of the best sessions at Southwest Fox this year. I mentioned to Alan that I didn't think he needed to show any code and he countered that it is really important to show people how to test - that talking about it isn't enough. He's probably right about that.

What this session did for me was to help me focus on the bigger picture of best practices. There was a communal enthusiasm in this session - we all wanted to go out and code better, immediately.