I recently attended the agile, lean & Kanban exchange in London
(http://skillsmatter.com/event/agile-scrum/agile-lean-kanban-exchange-2010).

Sadly I got snowed in Thursday, and after hiking 2 miles through snow to a station that was closed (people were telling me on the way it was closed!) I decided to turn back and spend the rest of the day with the family.

Friday was different, and through taking 2 busses I managed to get to a peripheral station heading in to London and to conference utopia!

I attended the talks on Retrospectives in the morning ran by Rachel Davies, and got a few extra nuggets to try in future retrospectives. Namely

1. Using a checklist (no I still haven’t sorted that out yet, I usually book a room with a 15 min buffer and then prepare it as I see fit – prime directive, columns on board, old tasks etc… before the team arrives).
2. Not using the Good/Bad columns, this suggestion was made because it tends to polarise the teams and can affect how people contribute to the session.
3. Allowing more time for the actions at the end. Rachel used a diagram to explain that part of the meeting is looking back and part of the meeting is looking forwards to the next sprint/iteration, so 50% of the time for actions is not a bad idea.
4. Actions taken can actually be further broken down into smaller pieces so they can be scheduled into the next sprint/iteration.

The next talk was by Patrick Kua from ThoughtWorks and was on “Making Management work with Agile”. Patrick expertly presented about some of the issues and challenges that are faced by agile teams using a bottom up agile approach. These fell broadly into the following areas:

1. Planning
2. Measurement
3. Direction
4. Problems solving
5. Decision making

Some of the key quotes and points included:

“Tell me how you measure me and I will tell you how I will behave” (Eli Goldratt), this in fact is my favourite point of the whole session, and it took a while to for me to get it! It can be applied in a whole number of different ways. For example, if you measure the number of tasks done, people will create lots of tasks, and then focus on the number done perhaps as opposed to the priority. Another example – if you are recording bugs fixed, then maybe people wont be too careful about preventing them because they can be fixed. Its the difference between delivering value verses ticking a box in a way that value doesn’t have to be delivered.

Other key quotes included:

Genchi Genbutsu (go and see for yourself) – there is only a certain amount you can communicate over the phone, to see the whole picture you need to be present. (Principle of the Toyota Production System.)

Having no problems is the biggest problem of all (Taiichi Ohno)

Management processes with budgeting at their core are not neutral in their management, ie. budget drives decisions not value driving decisions.

A bad system will beat a good person every time (W. Edwards Deming)

You can catch the slides here: http://www.slideshare.net/thekua/making-management-work-with-agile

Lunch

We then had lunch followed by the Open Space Unconference Sessions facilitated by Rachel Davies.

I have never been part of an Unconference before, and to be honest I was a tiny bit unexcited about it. However it turns out that it is based off feedback from previous conferences where attendants reported that the “coffee time” where they networked and spoke to others in the industry was in fact the best time for them as they were able to share and discuss their challenges and find solutions to their individual problems.

Unconference works by interested people placing a “topic” up on the board randomly choosing a time and a location and then attendees examine the board and chose a “topic” from those posted to attend. Its very open, and attendees can be like bumblebees and go from one to another if many are being held at the same time, or they may wish to stay with a particular topic. The only rule is that the originator must stay with their own “topic” for the duration.

The unconference in session, topic setters seen queueing on the right, facilitator Rachel Davies sitting on the left

One of the “topics” I went to involved the playing of a software development “game” using dice to determine software completion and bug introduction and was run by Liz Keogh and Jon Jagger. Good fun to watch!

Stakeholders, analysts, developers and testers with Liz Keogh at the top of the table, behind is the velocity indicator

Overall an excellent day, sadly I had to get back home (weather) so I missed out on the pub. Perhaps next time! For those who have never been its definitely worth a look, and for those who have gone, well the feedback for those I secured tickets for was extremely positive!