Archive for the ‘xp2010’ tag
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.
I attended an open space hosted by Emily Bache at the XP2010 conference in Trondheim, Norway with several other people who have been organising coding dojos around the world.
It was really interesting to hear about some of the different approaches that people have taken and how a lot of the issues we had with the one we used to run in Sydney were the same as what others had experienced.
These were some of the things that I took from the session:
- We talked about the difficulty of keeping up the enthusiasm/energy for a coding dojo over a long period of time and Emily suggested that one way to reduce this problem was to link the dojo with a group which met up for something else other than just a coding dojo.
For example Emily runs a dojo with the Ruby and Python user groups whereby one week someone would do a presentation on something and the next week they would run a dojo.
The one we ran was generally internal to ThoughtWorks so we had a different problem in that some people preferred a coding dojo and others preferred to hack on problems alone but with others around.
- Another suggestion around this was that rotating the organiser between the group was a way to keep enthusiasm up and made it the whole groups’ responsibility to keep the dojo running rather than placing the responsibility at the feet of one or two people
- An idea suggested by Mariana & Hugo from their experiences running a dojo in Sao Paulo was how to introduce a new language in the dojo environment.
They originally tried just running a randori style dojo but found that this didn’t work out so well if there wasn’t at least one person who had enough experience to at least know how to setup the development environment and write some tests in the language.
The approach they took was to have one person do a prepared kata in the new language at the beginning of the session and then after they’d done that then the rest of the group would participate.
- Another suggestion was to run a retrospective on each dojo session where people would write down what they had learnt from the session and what had hindered their learning.
This strikes me as something which would be quite useful to consider even on a normal project, especially near the beginning, and would help us to at least recognise if there are factors which are preventing us learning as much as we’d like. We could then do something to fix that if necessary.
- Hugo and Emily both suggested the ‘Kake’ format as one which might be better suited in a dojo with people who are quite experienced with the dojo idea.
In this format there would be more than one computer being used and pairs would rotate between the stations.
At each station the same problem could be being solved in a different language or a different problem in the same language.
- I also learnt that we had misunderstood the way we were supposed to pair in a randori dojo.
We somehow had the idea that the driver was supposed to drive for the whole 7 minutes and the navigator would just navigate during that time and then they would be the driver next time around. Emily pointed out that the idea is just to pair normally but have one person rotate after 7 minutes.
This makes much more sense to me and would have made our sessions much more natural than they felt at times while we tried to follow this idea.