My XP Journey

I have quite a few blogs - my main one being WorshipJunky. So - why anoter one? This one (like all my secondary blogs) is to blog some specific aspect of my life - whether it be recipes I've written or experimented with, my mission trip to Costa Rica, or my short life as Jarill.

Quite some time ago I heard of Agile programming and XP. I originally stumbled across the first Wiki a number of years ago. Based on that we (the Sheriff Infrastructure team at MCI) started using the wiki (and also IRC along with logs) as a way to do more collaborative development. We were already very collaborative and pretty iterative, but in mostly a mini-waterfall sort of way. With the wiki, we became more collabortive, because instead of a "write a 100 page document", "review it for a week", "discuss it for a day" and then "update it for a week" sort of cycle, we went to a "write it for a few days (or maybe even 30 minutes"), "review it for 10 minutes", "discuss it for 5 minutes" and "update it for 5 minutes" sort of cycle. This let us iterate much quicker and provided us with the benefits of

• knowing if the author was off-track,
• team verification (Feedback as an XP term) very quickly, and
• to some extent let us finish the design quicker, because at some point we knew we were "done enough"

The great thing about an entire team stating that we are "done enough" and can move on is that the author doesn't spend tons of time in a vacume trying to decide how much to add to the design. Anyway, I digress (as normal).

So - we were doing this "wiki thing" and disucssing things on IRC - because some of us work every different hours than everyone else - and we say improvement. Then we picked up on TDD (Test Driven Development) and we started applying that. I don't remember how we first came upon it, but from my point of view it was probably a number of things.

• I ran across it on the Wiki
• Team members probably read about it
• I saw/heard about it in seminars - Seeing Martin Fowler do a quick refactoring... well you just know it is "right". Even if you think "Man, I don't see how we could do that on our project"... Seeing him change code, test it, have it go green, then change, test, etc. etc., all in a minute. Well its just beautiful.
• And very importantly - we HAD to do it. We got to a state where we had a complex set of functionality, being developed by multiple team members, and we were never sure how "done" we were. Eventually the manager insisted what we write a bunch of tests and start running them, to see where we were at.

This was the beginning of us actually implementing some "Test First" methodoligies.

So - we were doing some short (for us) iterations, doing some TDD and being very collaborative and iterative. To us, this felt like we were doing "Agile" and "XP" - although we knew to someone who was truely doing it, we might seem like we were a long ways away. But at least it was moving towards it.

Recently, I went to a talk hosted by cosAgile in which Ron Jeffries spoke. That was sort of a turning point. It did a couple of things:

Confirmed that some of the things I and some team members thought were "right", were actually viewed as "right" by... the gurus.
• introduced me to cosAgile - and from there I started doing weekly pair programming in Java (which I don't know) using Eclipse (which I don't know). But it gave me a chance to see some of this in practice. It aslo caused me to
• join the xp mail list - which caused me to spend much time reading and thinking about Agile/XP - and caused me to
• buy XPE2 (XP Explained V2) and the XP Installed (the pink book). Both of which caused me to think about things in a different way and move me from thinking about that "Agile/XP" to having a better understanding of what it is. Well the books and the mailing list.

Luckily, at this point in time, I also got the oppurtuinty to work on a new project. The group I'm in (Sheriff) builds a system (which I've discussed on my main blog here and there) that is primarily composed of two layers. The Infrastructure (which provides a common framework, transport, layer, etc. - written in C++) and customer specific Implementations (which build upon that framework and are primarily written in CLIPS). About a year ago I transitioned from being the Infrastructure Architect to being the Chief Architect over both the Infrastructure and the Implementation. This has meet with some successs (mostly technical) and some failures (mostly process and people based) as I try and move some "Agile/XP like" practices into the implementation teams. Much of my failures could have probably been avoided if I had actually read the XP books first, and taken some advice on how to do this... but oh well. Live and learn. In any case, I'm at the point where I might actually be working on a new implementation.

This is very good from an XP point of view - because archtiects should actually *write* code. They should sign up for tasks, etc. This is also good from my own point (before I read it in an XP book) - because recently it has become very apparent that I need to "get in the trenches" to actually experience some of the issues. And also to prove that some of the techniques I'm pushing/suggesting (pushing is probably a very bad XP word) will actually work. Saying that we can do TDD is one thing. Using TDD on a successful implementation then having that as an example, is a much better way. As our many of the techniques.

So - this implementation is currently in the "we need to talk to the customer and agree this is the right thing to do" phase. But we have high hopes it is. Assuming we can achieve some benefit for the customer, then we'll probably do a new implementation and I'll probably be on the team. This will be brand new, from scratch (although we have a lot of code, experience, patterns, etc. in other implementations). So some framework will be set - BUT we might be able to approach this in a whole new way, using a new development process.

To me - this seems like the perfect place to "get in the trenches" and also to try and bring in some new XP practices. We probably won't do them all. We might not use an exact practice, but might try a principle, etc. But I believe it will be a step forward. And in thinking about this - I decided to start this blog, for a few reasons:

• Blogging sometimes helps me with my thoughts. First, because in writting stuff down, I sometimes have to think about it a little harder, and Secondly, in assuming that someone (even if it turns out is no-one) is going to read it - it also helps me think things through a little bit more
  
• I've noticed a number of people on the XP mailing list have blogs where they put ideas out, w/o just posting them all to the list - so it seemed like a good thing to do, and
• It occured to me that there are a number of "how do I start doing this" type questions out there... and that somehow, in documenting how I do this, it might not only help myself, but help others.

So - having said all that, the purpose of this blog is to jounal my journey of "Starting down the road to XP". Why we pick the principles/practices we pick. Why and how we carry some of those out. Up-front, how we think those will work and hopefully in hindsight whether or not we were right. What we learned, etc.

And a final note - this may be a bit premature. I'm not sure of the implementation or that I'll be on it yet... But I'm pretty sure. And so I'm approaching this somewhat iteratively. Here is where I think I'm going and how I want to get there... So let me put these thoughts down now. If it turns out I don't go that direction, nothing but a little time lost. If I do go that way, then I'm already a bit ahead (because I've already started this blog) and it always helps me to write things down as I think of them, rather than after the fact.