Wednesday, May 10, 2006

Adoption of XP

I'm always happy to talk about how to make things better and I'm mostly of the opinion that XP is the best way to make development of software more satisfying for all those involved. With this belief, my focus has become, "Where is the value it what is being done?" What value is there is BDUF? What value is there in TDD? What value is there in what we are proposing to add/remove from our processes? Everything has boiled down to the simple question of what value does X provide. I don't think this is an XP specific, or even an agile specific, practice, but I find myself constantly asking this question internally and very often now those around me are probably getting used to hearing this query.

Which leads me to how we are currently adopting XP. We had a detailed discussion yesterday discussing what we have been doing and what we thought we were doing and what we really should be doing. During this conversation, I realized that we were sort of sneaking up on implementing XP within the organization. Not so much getting ready to ambush the company with XP, but rather ambushing ourselves (sort of). Almost a death by a thousand cuts, but instead of death, we get agile development and instead of cuts we have practices. The placement of the cuts are important, but I think I'll bail on this analogy now, before it gets uglier.

Initially, I was asked to identify what I thought should be the development teams focus to be more agile. The first step was to mandate that all development would be TDD. After that, we started pair programmer, but we started "soft" (but spontaneously went "hard" just last week). The interesting bit is where we just started grabbing at practices without much thought. Next cab off the rank was planning game, but this failed horribly. Partially because the customer was out of the office for an extended length of time, but even if this hadn't happened, the planning game wasn't going to give us the most value. We sort of discovered this during our discussion.

Out came the value query. What practices would deliver the most value for the team to adopt next. With this in mind, it was obvious to us that planning game was not the answer (though it might have looked like it previously). Customer tests won out in the end. We found that we were a bit rudderless and even though planning would provide this, acceptance tests really look to be the right answer. To be fair, we sort of are doing planning already, user stories with priorities, but no out right planning game. On inspection from where I was sitting, planning game looked like something valuable, but needed some infrastructure to really work probably. Also, there was a short discussion about how the planning game could help lift the team by providing a psychology boost by completing things. I argued against this from the point that it might very well add negative pressure as well if the team isn't quite ready for it. There is nothing worse than setting goals and continually falling short. Once we've got some acceptance tests and we are estimating and passing the acceptance tests, then the next step would be to get that boost. It sounds a bit conservative to me, but it makes sense. I'm not willing to introduce negative feedback loops to the process…

So, my overall generalizing conclusion from this small experience is that the best way to approach introducing XP to a team of developers depends a bit on history. If there is a legacy codebase, like what we currently have, then sneak up on it by constantly examining what could be done and prioritize these by what value you believe they will give to the process. We started with TDD. Next added pair programming. Failed miserably with planning game (but only because we forgot to look for value) and now are focusing on acceptance tests first before working on a story. Implied in this is that we are taking the time to reflect, which we have decided to explicitly do (even without a planning game, ironic, eh? 8)). BTW, to me, reflection is where you look at your values, i.e. communication, simplicity, etc.

The corollary to this generalization is that if you are on a greenfield project, grab as many practices as you can find and go for your life!

2 Comments:

At 16 May, 2006 21:59, Blogger Myrdhrin said...

Hi Doug,

Very interesting insights on the value of XP and value of processes in general.

It seems from your blog that you already have your management backing you on this... letting you experiment without too much interference (I'm probably making a big assumption here). How did you get them to do this? I've been able to do "some" XP and Agile attemps with my very little team (4 peoples) but I have to justify each every small step and move I want to try.

Your insights would be appreciated!

Thanks!

Mydhrin

 
At 05 June, 2006 12:13, Anonymous Brett Henderson said...

Hi Mydhrin,

It appears Doug's been a bit slow lately in replying so I thought I jump on in for him, especially as I can lend some insight into this particular question. You see, I'm Doug's manager.

How did he convince me to experiment and ultimately adopt XP? Well it probably helps that until recently I was a full time developer. That said, Doug did explain what the aims/benefits where to me when he started and they fit with what we needed to do in the team. We discussed XP as a team, including the Product Manager (client) before all "signing on".

The way we got upper management and even other parts of the business in on it was three fold. Firstly I spent time discussing how this helped us as a business with each of the departments and how it would help engineering meet their needs. Secondly, we had a particularly difficult and complex feature of our product to develop and we adopted XP practices of TDD and Pair Programming in undertaking it. Finally, we developed a demo for the marketing team run entirely as an XP project and exceeded their expectations plus involved them heavily in the process. All of these things were really about communication which as you know is one of the tenants of XP.

Oh, and I still interfere, but mostly by posing the questions Doug has been asking and answering in this post. You see, I want us to keep moving forward with this process, and so ask the "what next" question.

Not sure if this helps in your particular situation. It may simply be that we are a small company working on the front of technology so are willing to try new things. Good luck with your attempts to introduce XP. You'll find the benefits are not only in delivering what the client wants and delivering quality products but in the knowledge sharing are worth the effort.

Cheers,
Brett

 

Post a Comment

Links to this post:

Create a Link

<< Home