agile alistair or how to do agile software project management
Fri, Feb 25, 2011
I’ve recently had to tear myself away from the compiler and do some software project management, in a rather different fashion than has been seen lately round these parts. I took the decision to jump in, lock stock and barrel, to a cross between XP and Scrum. There are too many flavours of Agile around to actually choose one and as it’s basically common sense, it makes even more sense to follow one’s nose in these things.
I’ve seen enough projects turn into train wrecks to know what not to do but what to do? The project is a small, three person team, short timescale web application development to allow teaching staff to upload lecture videos for QuickTime streaming. The process is manual at the moment, so we’ve been tasked to automate it and we have an intern to help us. The application is also sandwiched between two larger frameworks, the streaming server upon which it depends for the streaming functionality and the wider repository initiatives that are going on, so we need to be aware of the wider landscape when designing the application. The repository stuff was fairly easy to deal with. We decided early on to produce a Dublin Core metadata file for each uploaded video, which would provide an extension point for ingesting the streaming content into, for example, a Fedora repository at a later stage.
I decided at the start, to use User Stories and keep the iterations weekly, with one or two stories per iteration. The issue was, we hadn’t worked like this before and I had no idea how our new chap would perform with Java and Spring, so the first week was basically a “shake down” week where we learned our strengths and weaknesses, became comfortable with the workflow and generally found out what would and wouldn’t work, while still producing a measurable output. I use the term “shake down” as in my other persona, as a mountain guide, the first day of a week’s guiding is usually a “shake down” day to find out who’s comfy on what terrain and how fast everyone moves and when they like to stop for cakes etc. The analogy works well in Agile too.
So I need Agile tools to deal with one of the hurdles to smooth progress, a distributed development team. We’re all in different places throughout the Highlands but meet up face to face every two weeks or so and as we’re only three strong, I decided on the Atlassian Starter Pack:
- JIRA for basic project management
- GreenHopper for Agile project management within JIRA
- Fisheye for version control reports
- Bamboo for Continuous Integration
- Crucible for code reviews
As we learn more about the environment around us, we can move stories from version to version, bring them forward, move them back a version and so on. As I mentioned, we kept stories to a minimum at the start and iterations to one per week to get a good flow going and to “feel our way” as we are basically working in uncharted territory. One major story is Auto Hinting, where we have to automatically add a hinting track to an uploaded movie. This was my story to deal with and it was a Spike, which means I had to go off and do some research into auto hinting. A couple of days later and I had the solution, or so I thought. OS X Server 10.5 has a nifty little commandline tool, /usr/bin/qtmedia, which lets you programmatically hint movies but it’s missing in 10.6. We have two servers we rely on as developers, the dev machine, which is 10.5 and the production machine, which the sysadmin has upgraded to 10.6. So we’re in a bit of a kerfuffle about what to do.
Being Agile though, means we can shift the auto hinting to a later release while we deal with the problem by either finding out how to auto hint in the absence of auto hinting functionality or write an Objective-C service using QTKit, or rollback to 10.5 or bin auto hinting altogether. We have three options we don’t have to worry about just now as we have plenty to get on with for the next iteration which will provide full logging and localisation.
Another issue we came up against early on, during our “shake down” week, was the release day for an iteration. I’d initially set it as a Monday but worrying about a release over the weekend isn’t good for you. Plus one of us only works Monday - Wednesday so they would be out of the loop for two days of the week, missing lots of important communications about where we are and what we need to do to get a release ready. So I decided to shift releasing to a Wednesday afternoon, when we’d all be available and also easy to do face to face for a big release if need be. It also lets the other developer get on with stuff that doesn’t require interaction with the absent developer and we can bootstrap on the Monday to flag up any problems with the next release.
The first week was a big surprise for the team velocity. We raced through the first iteration! So there’s still an optimum story number vs iteration length to work out.
I’ve been guided on the way by a superb book, The Agile Samurai, which I can thoroughly recommend and I’ve completed the Agile Inception Deck which you can download here. The deck was a real help in focussing my mind on the project at the start. There’s also an Agile Lean Europe initiative started up on LinkedIn, where the big hitters are starting to line up. But that’s a bit over my head at the moment. They’re currently beating their chests and generally sorting out the pecking order but it looks to be a good resource of Agile information.
So we’re all learning as we go and hence the title of the post, **alistair. That’s a pointer to a pointer. Two levels of indirection. I’m having to learn Agile in an Agile way as I go along!