Refectoring Understanding

It is nice when understanding starts to fall into place...

Today, we had a meeting discussing the initiation of a project. One of the items raised is that we need a Technical Discussion White paper to explore the technical issues involved in the development.

I'm an XP novice, but that just didn't sit well with me. The meeting wasn't focusing on this only and basically I just disagreed with the need for this and declared that I'd take the discussion off line.

The person I needed to talk to wasn't available after the meeting, but that didn't stop me from mulling over this and discussing it with others.

My main and first point was that I felt that we didn't need the document. This was countered by several points:

1. Communications - After further investigation, this appeared to be for the benefit of the technical team. My counter - If it is only for the tech team and the tech team is doing this together, why the need for further communication of things that are already known.
2. Commitment / Clarity - What two people may say one day will not be repeated the next. My counter - what we say tomorrow is a reflection of our growing understanding of the domain/problem/issue. Our understanding (and communication?) is dynamic. The document is a snapshot. Countered by the document can be updated to reflect this understand to which I said I've never seen a document be updated in this way. Documents will only ever be an artifact of something that occurred in the past.
   

There were probably a few other points, which I don't remember off the top of my head. But in the end, I took the position of questioning what value the document was giving to the project. I'm happy if there is good value and not happy if it is bloated or redundant. I'm learning barely sufficient. If it is needed, I'm happy writing the document.

Anyway, after this as the ideas collided in my head and came to a rest in new and better ways, it dawned on me that questioning value was important, not just in this particular point, but in all points within the process. Sounds obvious to me on restating the thought, but at the time if felt like the clouds had parted and the sun was shining down on me. 8)

The point is we, as a company, should only be doing just those things that return a value and not those things that are routine or comfortable or because that's what we've always done. XP is about delivering value as quick as possible, it's not about living in a comfort zone. I think I'm now ready to get uncomfortable, and maybe that is my real realization.

We're Going XP!

Well, after Steve came and talked to our company for a day, it seems everyone here really does think that XP is something that we could benefit from. There wasn't even any overt resistance to Pair Programming! Which means that we have picked out a project to apply the XP practices to. (We start before the end of the month.)

Gee, I'm scared! And excited, but mostly scared. Honestly, I'm now responsible for implementing a methodology that is a highly disciplined and very intense. Very opposite to how things currently get done here. And I've tried some of the practices on my own over the last few years without being able to sustain the practice. The worst bit is that I know that there will be failures. I'm not talking catastrophic project ending failures. I'm talking lots of small failures. Not getting things the way they should be failures. It may be more fair to call them mishaps.

The flip side is that we get all the problems, via the mishaps, out into the open early and often. I intellectually know that this is a good thing. Not sure how I'm going to cope with this emotionally though. Now we can deal with the problems sooner and they should be smaller and easier to cope with.

Of course, this is all theoretical to me at the moment. But it is about time I start putting all of this theory to the practical test.

Simple things in life...

I was fortunate enough to catch up with Steve Hayes recently. I've always valued his opinion on XP and would love to work on a project he was coaching...

Anyway, I've always felt that XP was a good idea, but have never been able to find a project to work on with others and every time I've tried some of the practices, I haven't been consistent and lose steam after a short while. Two things came out of our time together.

1. Change of mental state is not a simple transition. As Steve wrote on the whiteboard, transition goes through 3 state (old state, chaos, new state) and not two states. An obvious observation, but something I think I have been suffering from, wondering why the chaotic state isn't the new state I had been looking for and reverting back to the old state. I flashed back to when I first starting teaching myself Java and can quite clearly see the chaos before the new state was reached. I was very enthusiastic about learning Java at the time, so I just keep pushing through all the bad stuff until things started to click. I haven't done this quite yet with XP.
2. XP is about Simple Design. Nothing new here, but what happened is that I think I finally get what this means. I've been trying to do XP with a big up front design model and fit the process around that. Let me tell you now, that doesn't work.

Simple Design is the one bit that has really thrown me off any personal success (or so I now believe) with XP. That coupled with not really pushing through with the methodology has left me feeling that XP is the better road to travel but with no direct evidence that this is so.

These insight have re-ignited my passion for adopting XP practices. I'm hoping this will get me through the chaos ahead...