Last weekend I had the opportunity to drive down to Columbus to participate in the second annual Columbus Give Camp. It was the first Give Camp experience for me, and I’m looking forward to the next one. I keep hearing rumors about having one in Cleveland, and I hope to see that happen soon as well.

The Team

My team was dynamite. I got to work with Cleveland’s own “Day of .NET” organizer Sarah Dutkiewicz, lawyer and Arch Linux hacker Chris Bumgarner and Rubyist Kenny Drobnack. At various times we had additional help from others, like Steve Andrews (who was our acting Photoshop maven) and Paul, whose last name, alas, I don’t know, but who works for Quick Solutions.

The Project

Our project was to create a consistent look and feel across multiple web sites owned and operated by Tech Corps Ohio, a Columbus-based charity which provides IT-related training for kids (for some reason this makes me think about my son beating me at Halo). The kids, in turn, provide web development help for local businesses and charities—a Peace Corps-inspired model.

Tech Corps Ohio (can I just call them TCO hereafter?) had 4-5 websites based on different frameworks and applications, such as Joomla, Moodle and WordPressMU. Each site had stock, off-the-shelf templates, and so they didn’t look like the all belonged to the same organization. Furthermore, none of the sites had navigation pointing to the others. Each site was an island.

During the week before Give Camp, Aero313’s creative directory Erin Corrigan put together a splendid graphic design for the TCO suite of websites. And on Friday afternoon, we got down to the business of making her vision a reality.

This project wasn’t deeply technical: next to the Ruby and .NET hotrods scattered around the Quick Solutions office, our project looked technologically tame: predominantly HTML/CSS with a pinch of PHP. But I was concerned about the complexity of the system we were trying to address. Unless the sites could share CSS resources, any changes to one site would be arduous to implement in the others. In order to tame this complexity, there were two major tools I hoped we could use: some kind of version control and Kanban.

Use Git For Committed Relationships

Version control turned out to be crucial. The objective of having various template types share CSS and PHP resources meant that there would be consolidation of code and attention on a relatively small collection of files. Furthermore, the division of tasks could not always mean division of resources: work on different story cards would inevitably lead to changes in the same files. We needed a version control system which could facilitate a fast-paced, ad-hoc workflow; we settled on Git, and Chris set us up a github repository. It turned out to be an awesome choice. I think about half of us had worked with Git before, and half of us had not. You couldn’t have guessed that by late Friday night: everybody took to it like the awesome geeks that they are.

Even with version control, there were times when weird stuff happened. Suddenly your changes get overwritten, and the plain fact is that a) you don’t know how it happened, and b) you don’t necessarily have time to figure out who did what. But Git rocks: despite a couple of occasions when code got regressed, we never lost code. And I’ve worked on enough projects to how seriously cool that is. Believe it or not, there are many, many projects which get bogged down in revision-related chaos. Git saved our commits and that makes everybody happy.

Kanban For Starters

We snagged a stray whiteboard, started writing stories on post-it’s and soon had a nifty, impromptu KanBan board going. Some on our team had heard about Kanban, some hadn’t. I think I explained it for about two minutes. We didn’t try to do a deeply detailed Kanban board. Frankly, for a weekend project like this, there were just some analytics we were never going to try to pull out of a really disciplined Kanban process. But things that scale well ought to scale in both directions; and Kanban scales down really nicely.

Our board was really dead simple—it had only four columns: “backlog”, WIP, test and done. We had no buffer queues, and the only queue with strict limits was WIP (we decided on pair programming, thus two developer units). Eventually I added an additional “queue” down in the lower-left corner called “decomposed” which was for general, high-level cards which had subsequently been broken down into smaller cards.

I am absolutely certain there are Kanban gurus who will insist what we did was not even really Kanban. And they’re probably right, but so what. It was helpful, nonetheless. The beautiful thing about our Kanban board is how much bang we got for the planning buck. We didn’t have to focus on an intricate minuet of process and procedure. There was no 15 minute discussion about how to organize our board. We wrote new cards on the fly, as they came into our heads. We improved our stories and our board on the fly, as we went along. In this way our relaxed Kanban board helped us to self organize, and to adapt to the high degree of discovery inherent in our project: our predominant activity was not to write new code, but to hack existing code which was found in the wilds of the PHP Game Preserve we call the Intarwebs.

Is That Your Final Answer?

I noticed that few of the projects last weekend reached a point that the developers or product owners would call “done.” And that’s ok. It is in the nature of scoping and estimation, that the shorter the timeframe, the more volatile will be the scope. Beyond a certain point this phenomenon cannot be mitigated by extra programmers. That is why an Agile mindset is absolutely critical: you have to focus on delivering the most important things first, so that when the bell rings on Sunday afternoon, and you push to the server one last time, you know you’ve given your client the absolute best value possible as defined in his or her terms.

Our lightly expressed Kanban board helped us keep TCO’s priorities front and center throughout the whole weekend. We didn’t get everything done. But we do know that the parts of the project which we did deliver are the parts that TCO said they wanted the most.

A Word About Our Client

If you ever get the chance to work with TCO’s Director of Programs Aung Nay, take it. First off, Aung spoiled us, bringing in fresh fruit, candy, and loads of positive encouragement. But beyond any of that, Aung did a great job of helping himself by helping us to help him. Aung had a clear objective, and a well defined scope which he communicated to us. He was also very savvy about when to remove himself from the process. For example, once he had described the look he wanted for the website, he pulled himself out of design loop completely. This isn’t something that every client could or would do, but it was one of the ways that Aung streamlined the project for us. I look forward to seeing him in Give Camp circles in the future, and I’d work with him again any time.

A Word About Our Sponsors

Huge thanks to Quick Solutions for providing the bandwidth and office space for Give Camp. You did a really good thing. Massive accolades to Carey Payette [twitter], our organizer, also to James Bender [twitter] (the guy who brought us food) and all the others who put in extreme hours, suffering sleep deprivation, all to create an excellent environment for getting projects done. I know there are others I should thank whose names I do not know: forgive my omission and thank-you all. You guys are an inspiration.

A Word To The Campers

I also have to say what a profound experience it was to work along side 40-50 smart, motivated people. Not only did you come out to volunteer for charity work, but over the course of an exhausting weekend, you did it with style and grace. Good humor and courtesy prevailed where one might have anticipated frayed nerves and irritation as you navigated everything from C# to flat files, from network outages to ninja dinosaurs. In my book you folks are the best of the best, and frankly it makes me proud to be part of the software racket.