Agile conversations at the dev summit

Much like Chris over at GeoScrum, I’ve been carefully listening for Agile-speak here at the developer summit because I’m keenly interested in what the rest of the industry is going in their development pathways at the same time our team is adopting Scrum and looking for opportunities to exercise our skills.  On Monday night, I had some good informal conversations around the water cooler (read: “beer cooler”) with other developers while we enjoyed the welcome festivities. While standing with Chris and Dave, a couple of questions on a common theme arose:

How, as consultants, do you folks keep the lights on as an agile shop if you don’t do fixed fee, fixed deliverable contracts?

The answer, those of us who work as consultants definitely still do fixed fee, fixed deliverable contracts.  They’re still the most common arrangement in my industry and most clients are most comfortable working in that paradigm so these types of contracts are likely to persist for some time.  For a no-nonsense opinion on these types of contracts and an accurate description of exactly what they accomplish, consider this heroic quote from John Maxwell over at the XP mailing list.

Fixed price, fixed scope contracts are a stupid (but common) way to do business for software development. They’re popular because financial people are comfortable with them, but no one really develops software that way; it’s just that instead of building the unknowns into the the contract (ala optional scope contracts; http://www.jarn.com/about/OptionalScopeContracts.pdf), many organizations prefer to get more or less the same effect via ad-hoc methods involving lots of posturing, raised blood pressures, and “contract amendments”, “follow on contracts”, etc.

So what gives right?  How do agile shops reconcile their process with the fixed-price, fixed deliverable paradigm?  We catch as catch can of course.  Have a gander at the XP mailing list link above or Google “fixed price agile”. The author notes that you still benefit from an agile software approach, you just don’t leverage the full capabilities. It still helps the dev team get the most “work” per unit of time (and by extension, money)…and more importantly, it still catches challenges and missed opportunties early on so that the team can internally make adjustments or go back to the client for a mea culpa as early as possible should it become apparent that targets are not going to be hit.  Also, your financial folks will love you because the incremental sprint paradigm gives them a relatively firm idea of burn rate and utilization for the next month.

So contrary to popular opinion, we’re not contract snobs.  Would I prefer to see language in an RFP that opens the door for my Scrum team to leverage the full capabilities of the process?  Sure I do.  IMHO, much of the agile speak you see in the blogosphere about agile adoption in the GIS industry (at least from me, and I think others would agree) is an optimistic attempt to move the industry toward a little more sanity in the consultant development realm.  While I don’t expect it all to change over to a time and materials world tomorrow, I certainly hope that it garners a few more sane contract arrangements over the next year, building a level of trust with the client that opens the door for future opportunities.