This week Paul, Dan and I officially started our four-week project together. The three of us signed up to be the canaries in the Code Academy coal mine and see what a three person team of alumni will produce on a four week “contract”. The three of us are going to build the best possible product we can and hope it gets heavily used- but of course the deployment is entirely up to Neal and Mike and whether they think it’s good enough.

I can’t go into too many of the project details, but over the next few weeks I’ll be posting about the process and our growing pains. Part of the deal in committing full time (40 hours a week) to the project is that we’re getting a lot of support and JC Grubbs has volunteered to be our project mentor. Before we even got started he assigned us homework and told us to read The Agile Samurai and The Rspec Book. The three of us were pretty pumped to get experience with both the Agile process and testing.

We’ve adhered to Agile pretty strictly thus far. Our loosely defined roles are that Dan is the designer, Paul is the developer and I’m the “sweeper” (tip of the hat to “Getting Real” on the nomenclature)— but we all help each other and literally work side-by-side at our space in Design Cloud. An important part of the Agile process is to have a team that works closely together both literally and figuratively and we couldn’t get much closer than sharing the same table for eight or nine hours a day. Since Paul is the strongest technical member of the team he even shares screens all day as he and I pair program writing the back-end and tests, and then he’ll switch over in the later half of the day to work with Dan on the front-end HTML, CSS, ERB and JavaScript.

When those two start cranking on those things I find myself using a lot of my project management experience from the ABD days, and blending that experience with what we’re learning about Agile to review where we’re at in our iterations, how accurate we’ve been in our estimations and then checking in with the “customer”. Mike McGee was designated as the official “customer” so that we’re working with one main person, and so far things have been pretty smooth. Ideally we’d like to work side by side with him too, but since that’s not possible I’ve tried to keep him as involved as we can. Last Monday (our official first day) we had our brain dump meeting where he outlined his vision of the project and the three of us had the opportunity to ask him questions and clarifications. That went pretty quickly since Mike and Neal have been working on this project for a long time so he was already prepared with different personas, workflows and validations— plus we’d already had a handful of informal meetings so we were able to prepare a lot of questions ahead of time.

After we established a firm starting point we spent a few hours covering the white boards with sketches and user stories, and after that we started our estimations and planning for iterations. Keeping Mike in the loop and getting his stamp of approval has actually been really easy thanks to some valuable tools. We’ve been throwing all of our notes, whiteboard photos and screenshots into a project on Basecamp, and then JC has let us use Crew to manage our user stories, chores and bugs through the five phases of Icebox, Backlog, Current, Done and Attic. Mike has access to both our Basecamp and Crew accounts so whenever we touch base he has the ability to log in and see exactly where we’re at (as well as review our code on Github). Crew is actually a product that JC’s company DevMynd developed and I’ll unabashedly admit I’m in love with it. Despite all of the cycling events and teams I’ve managed over the years I’ve never actually used any formal project management system before, and even with a small team it’s great to be able to log in whenever we take a break just take a glance at the forest instead of the trees. From a programming standpoint it’s been a help too because it helps me think about the edges cases that we definitely need to be sure that we write tests for.

Testing has been the other big new thing for us on this project, and since the post is getting a bit long I’ll talk about that in the next round. Suffice it to say that we are by no means fluent in test driven development, but we’re slowly getting the hang of it. When we deployed our first iteration on Friday afternoon we were pretty pumped to see green tests across the board- which of course if we’re adhering to Agile standards, is as it should be.