Stealth agile and agile contracts

I attended tonight's Agile Denver meeting, which was a presentation by Richard Lawrence from Avenade entitled Stealth Agile - how to implement agile techniques when you don't have full -- or any -- buy-in from management. It was a short preso, and the discussion after the formal part was informative. One audience member asked how to introduce agile practices on a project which is architecture-centric and project leaders tend organize developers' work around components or layers, rather than features that provide end-user value. The suggestion from the audience was to build a small feature as a proof-of-concept designed to expose risk. Architects generally favor proofs of concept, and they also generally like the idea of finding and reducing risk. Note that you can present this idea without even using the word agile or any of it's practices. Sneaky, eh? One caution though - when people see that your POC works, it'll likely end up in production, so built it with production quality, including automated tests.

One of the most interesting questions, I thought, had to do with a decidedly non-stealth agile issue, which is, how do you write a contract to be agile from the beginning? Richard's response was that traditional contracts are typical very scope-centric; they focus on fairly low-level details about what software features will be built. For an agile contract, he advocates one that focuses on the product vision, and just enough scope to specify who will own the intellectual property of different parts that get built - something the Avenade legal team insisted on for their consulting contracts. The agile contract specifies the vision, a team size, and a time frame in which the contractor will endeavor to achieve the product/project vision, allowing customer and supplier to collaborate on refining the specific features which best achieve that vision - through iterative development of working software and the feedback that results. I suppose this requires a fair amount of trust between the parties, but if enables success, I'd say a little trust is a small price to pay.