The Freak Parade

One week ago today a small rag tag team of grizzled,  war-weary .NET programmers huddled before a filthy white board clutching a copy of The Art of Agile Development  and a stack of dog eared, grease streaked story cards. An un-built, un-specified software system stretched out endlessly before them like a hole in the fabric of time, a  yawning chasm of unknown depth, and on the other side awaited another unspecified, un-built system, and on the other side of that yet another, and another, and another…

Man, I should have been a novelist. I really missed the boat with this programming gig. Anyway, today marks the end of our small team’s bold foray into Agile development, a one week long XP iteration that took us from a blank Visual Studio 2008 solution to an end-to-end Walking Skeleton of our fledgling system complete with a Domain Model, a fully configured infrastructure incorporating an ORM and an IoC, a living service layer exposing a REST API via WCF  which powers an ASP.NET MVC front end utilizing a custom implementation of the ASP.NET Membership Provider to authenticate users against the API rather than a database local to the MVC app. We didn’t have a whiteboard set up in the team room yet, so story cards migrated from one side of the wall to the other, courtesy of the miraculous substance that is scotch tape. Not all of the task cards made the journey, but 90% of them did, and all of the cards directly related to the operation of the walking skeleton were among the survivors. Tomorrow morning we’ll have our retrospective and plan the next iteration.

The verdict? It was pretty amazing, actually. Our team had made a few false starts in the past, attempting to “ease into Agile”, without much success. This time though we decided to go for the gusto, Pair Programming, TDD and all, and while we probably didn’t follow every XP practice down to the last detail, we did a pretty good job of sticking to the program, and I am here to say that it doesn’t take much acclamation time before the benefits of those techniques make themselves felt. Pair Programming in particular I have always viewed with a skeptical eye. My perception of Pair Programming has historically been a lot like my feelings about most reports of paranormal activity: I am willing to acknowledge the logical possibility that they are valid, but deep down I am pretty sure they are full of the old brown and stinky. Well, no more! Our productivity, despite working with technologies and tools none of us have used before in a production environment for each and every tier of the system, was outstanding.

Pair Programming is one of those things that I don’t think can be truly comprehended by reading about it or talking about it, you have to do it to understand how it focuses your attention and keeps you “in the zone” in a way that is almost impossible to achieve by yourself, especially in today’s environment of the social web, with twitter and e-mail and RSS feeds poking at your attention span all day long. The usual distractions lose almost all of their power when you’re collaborating with another person. For that same reason pair programming was a little exhausting the first couple of days; I wasn’t used to that kind of directed effort for extended periods of time.

In any case, my fears of pair programming halving the productivity of the team are fully vanquished. And the benefits don’t stop at increased focus, either – the knowledge sharing and cooperative learning is also priceless. And here’s another amazing effect that you’d never guess at – you have to see it for yourself: because we were programming in pairs, we were discussing everything we were doing out loud with our partner, externalizing the design thought process and keeping everyone dialed in to the same frequency, allowing us to correct overheard misunderstandings and clarify design decisions across pairs in real time, as the design was taking place, something that was not possible when the design activity was a silent thought process trapped inside each individual programmers brain. It may sound like a little thing, but those miniature misunderstandings and misaligned design decisions end up being big integration woes down the line.

The TDD experience was very pleasant as well. It took us all a few days to get into the rhythm, and I still wouldn’t say it is second nature yet or that we have become expert at it, but the benefits, even in such a short period of time, were tangible. We developed the application tier along with its associated infrastructure and WCF/REST API concurrently with the ASP.NET front end (with a separately configured infrastructure). The front end effort relied on stubbed proxies of the anticipated API being developed for the back end. The combination of a simple, testable, well factored API resulting from the test first approach coupled with a comprehensive test suite made integration of the two halves of the system a truly trivial experience. It was almost like zipping together the two halves of a jacket – integration was a non event.

So it was the first week. I’m hooked. We haven’t been at it long enough to gauge our velocity, or experience the benefits of short iterations, increased business-value, responsiveness to change, etc. etc, so there is still much to work through as well as to look forward to, but so far I’m more than pleased. My expectations have been exceeded.

I’ll continue to post about the experience as it unfolds, but based on this week alone, I can say this: if you are flirting with the idea of trying an Agile process, do it! And don’t play at it, like we did for  months before taking it seriously. I don’t think it is something you can dabble in, I think you need to jump in and start swimming – try all the recommended practices of your chosen flavor of Agile, and discard the ones that don’t work for your team only after experiencing them fail. I can recommend this because I would never have opted to do pair programming. I tried to add it to the back burner for out current project as well, but I was strong armed into it by our designated Agile Coach (well, not really, but I was *very* skeptical) and now I can say that as long as I’m running a team, that team will practice pair programming.

While I have nothing negative to say about the experience, I can say that I feel our successful iteration was at least in part due to a period of preparatory research. While we didn’t do any BDUF, we did do quite a bit of reading into the various components we knew we’d be using, as well as best practices, looking at reference architecture, etc. I don’t know how it would have went if we just dove in with guns-a-blazing. We didn’t know what we were doing exactly, but we had a good idea where to look when we ran into trouble. I think most agile projects must be like this – either experience or preparation heats the metal before you start whacking at it with a hammer, hoping something useful pops out. That being said, once we starting rolling this week, the story cards and associated task cards kept us from veering off into “best practice land” – spinning our wheels on making sure each pattern or tool being put into place was *just right* – a common weakness of mine that an agile methodology makes virtually (and thankfully) impossible.

So mine eyes have seen the glory, and I look forward to the journey ahead as we fumble through (XP > 1 week), invigorated and excited.

I do love this job

P.S.: I’d like to give a shout out to the following technologies and tool-sets that made this week possible: NHibernate, Castle Active Record, Rhino Commons, Rhino Mocks, NUnit, RESTful WCF (a bit complicated, but oh so powerful), ReSharper, ASP.NET MVC and Castle Windsor. And, of course, Visual Studio 2008. I apologize if I’ve forgotten anyone. I love you all!