The way we work

Good ideas

"Agile" is the enterprise software buzzword of the minute, so we don't mind if it makes you a little nervous. In fact, that's a good sign.

But if we get away from the excited hullabaloo that surrounds the so-called Agile Methodology—if we find a quiet space to look at it objectively—we notice that there's a bunch of just plain good ideas about how to make great software on a budget. These good ideas pre-date all the hype, and have been thought up not by theorists or managers, but by those of us who have been trying to make great software for years.

At Inventive Labs, we're less about the methodology, less about the buzz, and more about the good ideas. So here's how we like to work with you.

Being agile

At the start of any software project, everybody has an imperfect understanding of how it's going to work. Sure, if you click that button you should go to that page, but what if the user input is invalid? What if there's a thousand items in the list, instead of ten? With any piece of software, there's many bits of functionality that can only be thought of once the bulk of it is in place.

If your focus is on a really usable piece of software—software that gets used because it doesn't get in the user's way—you just can't know what is going to make it optimally usable until you've tried it. Ergonomics invariably begins with someone sitting down on an uncomfortable chair.

But most software development is still conducted against fixed price contracts. This means that when you suddenly realise there's a feature missing, or the interface isn't as usable as you thought it would be, you discover that your developers say it can't be done, or insist on a contract renegotiation before continuing work. In this situation, clients and contractors often become antagonists, and the result is generally as bad as you might expect.

Two weeks

The alternative is an iterative development cycle. At Inventive Labs, it all happens in a fortnight.

Every two weeks, for the duration of the project, we deliver you working software. Not complete (until the final delivery, of course), but working software that you can try out and begin to use in earnest.

Every two weeks you get to decide whether the project is progressing the way you'd like it to. If you decide it isn't, you can talk to us and we can begin to address your concerns, well before they have any significant budgetary impact. If for whatever reason you think the project is untenable, you can pay us to that point and walk away with working software.

While that can happen, it doesn't happen very often. Instead, every two weeks, we sit down with you and review a feature list. We jointly created and agreed on this feature list at the start of the project, but there's nothing set in stone about it. If you realise there's a feature missing, just add it. If you decide an unimplemented feature is no longer required, just cross it out. Everything is flexible.

Every two weeks, having reviewed the current functionality of the project, you go through each feature on the list and rank it by its importance to you right now. We take the top-ranked features on the list, and make them the priority for the next fortnightly iteration.

This is the best of both worlds: you have low risks and plenty of flexibility to get exactly the software you want on budget, while we still have firm targets to develop against.

We think this is a good idea, and we've found that good software comes from it. If you have any questions about iterative development and what it means for your project, please don't hesitate get in touch with us.

Photo of the Madrese Chahar-bagh used under a Creative Commons licence courtesy of Abbas.