Hey! We have agile boot straps!

The other day, Kevin Morooney made an interesting blog post. I thought it contained a few useful nuggets. Kevin is talking about a podcast where Jon Udell speaks with Greg Elin, chief architect with the Sunlight Foundation:

The notion of agile development, not just as a software development methodology but also as a project management methodology was brought up again and again. I know there are folks in ITS and all over Penn State who are talking about and have embraced both concepts. We’re having lots of discussion about project management in ITS right now — I highly recommend a listen from that perspective too.

That was enough to get me interested.

I gave the podcast a listen and thought this passage was really relevent. In their discussion about development within the Sunlight Foundation, John and Greg are talking about a concept they call bootstrapping in regards to giving the public access to data:

Jon Udell There was always the notion that we would put this stuff out there, but we never really expected anyone would be interested or would want to do anything with it. And, you know, this notion that you can kind of bootstrap this process of getting people engaged with the data. At which point it actually creates a demand. People start to see the stuff — be able to work with it — and then, now we realize that we really did want public to mean something a little more.

Greg Elin John? You can come here and do my job. I mean, I think that’s an excellent articulation of it.

I think that, you know, the Internet also teaches us that you have to bootstrap things. You don’t want to. The big technology projects that fail are the projects where you have a long list of requirements and people are going to work for many years, or you have a very detailed [specification] of what the future is going to be like. And you know, those are the projects that they’re outdated before they launch. Whereas the Internet, where the approach of rough and ready consensus — let’s define the minimal amount of protocol that we need to standardize communication and let everybody have a go at it — and let it iterate really rapidly.

So now, I am interested. I do not want to manage the projects that fail. I want to learn more about agile development, which I had written off as just another fad. It turns out that a set of principles embodies the philosophy of agile development. I will paraphrase a few of them:

• Satisfy the customer through early and continuous delivery of valuable products and services

• Deliver working products and services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

• Continuous attention to technical excellence and good design enhances agility

• Simplicity — the art of maximizing the amount of work not done — is essential

• Working products and services are the primary measure of progress

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

My first reaction (not invented here) was, “Sure. That’s all well and good for you software types, but try that when you have to select a new router platform before you can even begin.” But I gave it a little more thought and realized that — perhaps by accident — we were actually already applying these principles.

Take the ITS Firewall Service as an example. When we initially developed the service, we had a specific application in mind. For that application, we made design assumptions — perfectly valid ones when taken in context — and we developed a service that satisfied that application. It turns out that those same assumptions make it less than suitable for many other applications.

Instead of starting over from scratch, we have been making a series of small changes that each contributes to a more useful service.

• In March, we made a private fiber rate exception. This allowed units to affordably collapse networks in multiple buildings — fed from a common hub — behind a single firewall.

• In May, we made a change to the policy on installation and maintenance of local area networks that added the option for full or hub-only maintenance networks behind a customer maintained firewall, giving units the options to provide their own firewall without losing TNS maintenance.

• In July, we made pricing changes to make the firewalls themselves more affordable.

• Now, we are working on a multi-port firewall service that will allow units to take advantage of more of the capabilities of the TNS maintained firewall.

These are all small steps. Each one designed to make the service more attractive to more people. Early and continuous delivery of valuable products and services. Working products and services, delivered frequently, from a couple of weeks to a couple of months. Well designed and technically excellent. Each kept simple. Showing progress with working products and services.

Wait a moment! We are agile!

If we had compiled a list of all the requirements for the perfect firewall service (we did) and waited until we had the perfect service before making anything available (we didn’t) then all of the people who have benefited from these changes would still be waiting. The project would have failed because it would have been outdated before we finished.

Of course, any time you pick one thing from a list as the thing you are going to do next, someone is going to be frustrated that you have not chosen the thing that they wanted. Perhaps that is where reflecting on how to become more effective comes into play.

Share: Delicious | Facebook