Can Agile work with client projects? Gravity Jack’s Way

Posted by Jon Friedman on Wed, Apr 06, 2011 @ 08:32 PM

Agile methods and custom projects don’t mix, according to conventional wisdom. Clients expect fixed deliverables on a fixed date. How do we unhook them from a fixed specification and get them closer to what they really need? We wrote about this in using agile methods to deliver on a fixed price, fixed time commitment, and now we have proven results from an Assembla customer.

Gravity Jack, a software design studio based in Washington State, eliminates the “I know that’s what we said, but it’s not what we want” conversations by offering a fixed effort/flexible requirements business model.

Gravity Jack screens small Gravity Jack creates web sites, designs mobile applications for iPhones, Android phones, and other devices, and produces “Augmented Reality” software. Clients include Boeing, NASA, Nasdaq, MTV and Showtime Networks.

At previous companies Gravity Jack’s leaders had suffered through fixed price, fixed schedule client projects. Delivered software never met the client’s real needs, clients were unhappy, the firms often lost money, and everyone was stressed.

Gravity Jack’s brainstorm: Let clients hire a fixed amount of effort (for example, two developers per month for three months) and give them the tools to observe progress and adjust requirements each month.

This was essentially applying the core tenants of the Agile development methodology: short iterations, regular input from product owners, and the flexibility to reprioritize tasks quickly.

Now, “We never fight with clients,” says Terry Hoy, Vice President at Gravity Jack. “They have a realistic view of what is being accomplished. Every month they can change their priorities. They never feel like we are nickel-and-diming them. Most importantly, they get the web site or application that they really wanted, even if they didn’t know what that was when they started.”

But there are prerequisites to implementing this type of business model. First, you have to be very good at estimating the effort required for each requirement or feature. Second, you need really good communication with the client.

Gravity Jack sets up an Assembla project workspace for each client. All code is checked into a Subversion repository. All requirements files and design documents are stored in the workspace. Key information is kept in a Wiki. And clients receive email alerts whenever code or a document is checked in or some other significant event occurs. The client sees work being competed each day, and can access key documents at any time. Regular communication builds a sense of trust and encourages clients to keep their requirements current.

A big bonus: clients perceive lower risk. If for some reason one wants to walk away from Gravity Jack at the end of a month, they can take over the Assembla project workspace with all of the code, documents, wikis and emails.

Finally, “We never have to say ‘that’s not in the spec.’” says Hoy. “Everything is in the spec. Customers can see the trade-offs and revise their priorities every month based on realistic options. At first we didn’t know if this approach would work, but customers have really jumped on board. The stress level is much lower and everyone is much happier.”

You can find more information about Gravity Jack at http://gravityjack.com/

Check out their unique Augmented Reality concept: http://gravityjack.com/augmented-reality-application-development

Tags: agile, software business, project management, case studies

COMMENTS

I read your Blog because you happen onto important topics deserving serious discussion. But I am disappointed that sometimes the blog turns into thinly-veiled promotional material for assembla and their customers.

Aside from that, I have a few problems with the current post. Gravity Jack's "brainstorm" is not innovative and fresh. It ıs an old story. You miss the opportunity to point out some key problems with the approach. Gravity Jack proposes shifting a fixed price contract to a time & materials engagement. In this case, all of the project risk shifts also to the customer. But what the customer typically buys is functionality. They also want their partner to adopt some of the project risk. Fixed-price contracts require specific deliverables. Most often, these are the basis for progress payments. It is not a viable business model for all project risk (both technical and business) to swing entirely in favor of the client. So, incremental payments are essential. Where there are fixed deliverables tied to payments there are acceptance tests to ensure the goals have been met. Where there are acceptance tests there is a specification somewhere. Operating in the absence of a specification is a disaster under the fixed-price engagement model. If the customer wants it, it is surely OK for Gravity to operate under a time & materials basis. But then, Gravity becomes a head shop, surely not in line with their stated mission.

I thınk a good model will be to fund the creation of the spec, to ferret out what the customer really wants, on a time & materials basis. Then, the execution of the development can be conducted as a fixed-price project. I agree with Joel Spolsky's prescription that a spec up front is in all cases necessary. Also necessary, is an agreed-upon and orderly way to modify the spec as the situation dicatates during the execution phase of the project.

If "agile" in your meaning is always bound up in "figuring out what needs to be done while you are doing it", then you will always see a conflict between agile methods and the so-called "custom projects". But, as stated above, the solutıon is not to "unhook" from specifications. The solution may very well be to conform agile development practices to a world where functional specifications have real value and to focus these practices on detailed planning and execution within the boundaries set by the spec and the plan, allowing orderly change when you realize you did not get it right at the beginning.

posted @ Friday, April 08, 2011 4:31 AM by Michael Motta

Comments have been closed for this article.