Monthly Archives: October 2008

It’s like trying to get home when you’re drunk

I met some friends for lunch the other day and when asked how it was going in my new role, I said to them that it was all a bit like doing the Hokey Cokey at the moment. To put that in context, there are a number of changes that I want to see happen here which are superficially, very simple. In attempting them though, and as anybody else who has attempted to implement any type of change will know, you take a step forward, you take a step sideways and sadly, you even take steps backwards.

One of the friends that was at lunch with me summed this up a little better when he suggested that it was rather like trying to get home when you’re drunk. Let’s face it, getting home is a relatively easy thing to do (I’m assuming that you’ve not ended up in another country here…), you often come a cropper though, you might fall asleep on a bus and go past your stop; You might even just be so wobbly that when you’re walking you actually cover 3 times the amount of distance that is actually necessary. The thing to remember though I suppose, is that you get there in the end. You might even learn something along the way. Like for example, to get a taxi next time.

Having had time to reflect on the time I spent at my last company, one of the things that I’ve realised is that for me personally, it’s important to recognise the small wins. If you don’t and you spend your time just raging against the machine at large, you’re not going to do yourself any favours and really if it’s that bad, take some time away, come up with another plan and approach and start again.


An Agile Adoption Pattern: Wax On, Wax Off

I know I’ve said before that I don’t believe in an Agile Adoption initiative but humour me a little here…

As I rode home dodging in and out of traffic a couple of weeks ago, with the saddle still as low as it would go from the last descent that we did on the bike ride over the Downs that weekend, I realised that it really can be the simple things in life that are most pleasing. It was good to be sat in the saddle cruising down the road on my bike. Then, at a point where I hopped off a kerb back in to a side road and the bag on my back swung round knocking me off balance I quickly realised that it was also the simple things that can catch you out.

Some 5 weeks ago now I set the first team up to use the processes that I want the whole department to be using in time. We did 3 1 week iterations and have recently completed one that ran for 2 weeks. As I took the team through the initial estimation exercise I was reminded of the discussion that has been taking place about whether or not estimation is waste. I agree with all of the points made and I think that once a team has realised it’s velocity it can take the decision to move away from lengthy planning exercises and indeed estimation entirely. Why then have I suggested to them that they estimate their stories? I think they have to start somewhere, the team needs to understand their velocity and in understanding your velocity they can start to look at the things that are slowing them down. One of the things that I have previously said is that it’s important for a team to gain some momentum, to get an idea of their rhythm and this is one way that I think they can do that.

At the same time though, I was advocating keeping the Product Manager away from the team, even when they were saying that this was a hinderance to them in their retrospectives. My reasoning for this was to enable them to get started without interruption. The piece of software that they’re working on was created as a Proof of Concept previously and we’re now looking to take it through to a Private Beta and so I thought the team had enough to go on for a short time without the additional “noise” generated by having a Product Manager involved, on the assumption that whilst the initial requirement was to get a production version of the software shipped once they started seeing the software during the demos, they would then start wanting additional features and distract the team. What has actually happened though is that we’ve ended up having to wait for a few decisions to be made which ultimately have slowed us down. This could have been avoided if I had got the Product Manager involved from the outset.

Ultimately, you have to start somewhere, doing a regular planning meeting allows the Product Manager to give the team the priorities, the stand ups allow the team to plan on a daily basis and to remove any obstacles, the retrospective allows you to inspect and adapt and the demos allow the Product Manager to seethe result of what the team have been working on, it enables them to feel part of the process and to look at how they could extend the product.

How do you introduce new processes to teams? Do the simple things, do them regularly and learn as you go. Wax on, Wax Off.