Frosty morning
So as I look out, bleary-eyed, at the huge puffs of steam being vented past our window by the building’s boiler, I’m kind of sorry that moving to a proper office has meant that I can’t just stay at home in the nice warm flat and work from there on frosty days like these. Still, the office itself is warm enough, it’s just the trip to it that means I have to brave the icy conditions.
Just read an interesting article here on longer term planning with the Scrum methodology. Good stuff, but there’s still the big chasm of “how do we get the publisher to sign up to this”. Until the people paying the money are okay with the less detailed milestone definitions that come along with agile planning, there will continue to be issues. It’s all very well running teams on agile internally, but until there is a solid contractual way of satisfying the publisher’s need for security with the developer’s need for flexibility, there will still be problems. At the moment the milestones are defined fully at the start, but it’s a naive producer that doesn’t expect the content of those milestones to change. It’s at the developer’s disadvantage though – the contract states that they are bound to deliver what’s in the milestone list, and if they don’t the publisher is within their rights to cancel the project at their discretion. They generally won’t, but it’s a quick get out if they want it. Even if the publisher and the developer both know that the milestones have become meaningless, when they’re written into the contract it means that there needs to be a re-negotiation to fix them again.
Personally I think it’s far better to start out with a high level statement of intent – that the developer will be working on a particular title for the publisher, and that they will use their best efforts to deliver builds of acceptable quality. The regular delivery of those builds is part of the process, and the method of arbitration as to what is ‘acceptable’ is written into the contract as well. That way the publisher still retains the majority of the power (control over what they deem acceptable), but they can’t use that control to avoid their responsibilities to allow the developer reasonable time to deliver something acceptable.