Micro-Funding (Part Two)
DQ reader Stephen Saunders, internationally known as "The Guillotine of Wit," has some interesting thoughts to share concerning the micro-funding discussion from last week:It's not a new concept by a long shot, but agile methodologies are typically considered best practice in enterprise software development circles (or, at least, the enterprise development circles I travel in). That's my area of expertise at the moment - I've worked in several different agile shops, and can advocate certain practices to one team over another based on real-world experience.
In most of the formal agile methodologies (like extreme programming, scrum, crystal methods, etc), they advocate doing fast, short cycle iterations that prove business value or ROI as soon as humanly possible, as well as keeping all the stakeholders - especially the customer - on the change review committee during the entire duration of the project. At any point in the development cycle, someone who cares about the success of the project can say, "Hey, that thing we thought was important? It is, but less so. What we really need is THIS..." and the impact of that change is minimized. Customers, sales, marketing, CTO/visionaries all collaborate on priorities and are all empowered because they are helping decide on what makes the most ROI for the business.
It's not terribly different from the micro-funding you describe, or the Sid Meier approach. Produce something with some minimal business value, ask the stakeholders what is the next most important thing to add, and incrementally give them a product that stays on target with business need.
It strikes me as insane that enterprise software shops have known about this class of methodologies with a good track record of success, and yet the gaming industry seems to be stuck in the rut of traditional, risk- inherent "waterfall" software process.
So micro-funding, even though it sort of organically emerged from need, actually mirrors an already-successful approached used for developing business-oriented applications.
I've been on large software projects that used both of the methodologies that Stephen mentions. What I like about the agile approach is that if the project has effective leadership, it will almost always, by the nature of the methodology, deliver a useful product. With the waterfall approach (what we called the "throw it over the wall" approach), though, even when a project does get completed, it often no longer addresses the needs of the customer, because the needs have changed during the development cycle.
<< Home