· xp2010

XP2010: General thoughts

I had the chance to attend the XP2010 conference in Trondheim, Norway for a couple of days last week as I was presenting a lightening talk based on a blog post I wrote last year titled 'Tough projects and the Kubler Ross Grief Cycle'.

It was interesting to see the way another conference was organised as the only other conference I’ve attended was QCon which is a much more technical conference.

It seemed that a lot of people I spoke to were coming to the same types of conclusions around different software development issues.

Notably that it only makes sense to refactor code mercilessly if we’re actually working around a specific piece of code and that having a target velocity is fairly pointless but seems to be necessary when working with stakeholders who aren’t used to an agile approach.

David Anderson did the day’s keynote which was titled 'Catalyzing Lean: Building a Limited WIP Society in Your Organization'.

There were a couple of standout points from this talk for me:

  • He talked about using a Work in Progress limit with respect to the number of stories that we can have in each swim lane of the story wall and how it can be used to provoke conversation in the team. For example if we notice that there are no items currently being tested then we need to look back to the place just before that i.e. in development to see where the bottleneck in our process is. We can then have a conversation about what we can do to fix that. David pointed out that it still takes leadership to make the conversation happen - just using a WIP limit won’t fix all our problems.

  • He also showed the idea of using opportunity cost of delay diagrams showing what happens if deliver something late so that we can see which features really are a priority. This is linked with the idea of each story having a class of service. If the client loses a lot of money if a story isn’t completed by a certain date then this would become a very high priority story for us to complete and it would have a high class of service. This seems like a much more useful way of working out the priority of stories as we now understand exactly why something is high priority rather than it just being because someone said it is.

Another interesting session that I attended was one run as a series of Pecha Kucha’s where several high profile agilists described their 'Agile Suitcase' - a list of items that they would take around with them whenever they have to coach the agile approach to software development.

There were lots of cool ideas but the most interesting to me was Joshua Kerievsky’s where he mentioned that running an agile readiness assessment as something that he likes to do with new clients.

I’ve not come across the idea before but it strikes me at least as an approach that would help to get some data on what level agile coaches should start at when working in this type of role.

I don’t know much more about what it entails but found the following on twitter from Kerievsky:

An Agile Readiness Assessment is a time to demonstrate your agility, assess their resistance, explore their future and gain mutual trust.

Another interesting idea from a 'Learning and Improvement' lightning talk about 'Agile teams and rescue dogs' was that of selecting the team member with the least experience as the team leader.

In the rescue dogs organisation the goal of the leader would be to ensure that the right leader was leading the team depending on the situation.

The leader would vary depending on the situation and the expertise required which seems like it should fit quite well in agile teams.

I’ve not worked in a team where this approach was taken but it seems like something interesting to try out.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket