The Mandate
Submitted by John on Wed, 02/03/2010 - 14:03
Having discussed some of our options for enlisting a developer, I'd like to follow on and expand on the process by which that developer will take our collective wishes and translate them into a final product. This mechanism needs to be responsive to what the community wants, and specific about what the community expects; but it also needs to be general enough not to cripple a designer's initiative, and flexible enough to adapt features to the final architecture. The consolidated tool with which we can carry all this out? The Mandate.
Let me first clarify what the Mandate (I feel compelled to capitalize it, for some reason) is not: it is not a design document, at least not a formal one. Trying to have the community create a full design document directly is exactly the kind of "design by committee" situation we want to steer clear of. What the Mandate is, instead, is a concise statement of the community's expectations; a dynamic document which communicates to the developer what we want most out of the game.
The Mandate would be structured in two parts: Principles, and Features. (Savvy readers might note that I've been categorizing design articles the same way.) The first part, the Principles section, would be absolute, but very general. In other words, the principles behind the game would constitute our minimum basic requirements for its design, and would not be open to negotiation. However, they would not spell out any particular implementation; the developer would be free to propose their own vision on that score. I've already explained in some detail what I think the fundamental principles in this section should be, but if there is strong support in the community for additional ones, more could certainly be added.
The second part, the Features section, would be a dynamic summary of the features voting board I described in my article on community integration. It would show the features suggested by the community, ranked by their popularity. This section of the Mandate would be more mutable than the Principles; the features, rather than being contractual line-items, would provide guidelines for developers, and a way of organizing their proposals to the community or the executive board. To put it in terms of agile design methodology, the Features board is a collection of user stories: discrete items of functionality originating with the project stakeholders (us).
How will the Mandate be used? The Mandate acts as a common point of reference for developers and the community. By proposing and voting on feature items, the community will be able to express concisely what it wants from a next-generation game. Furthermore, newcomers to the community will have at their fingertips a summary of what the game they are potentially investing in will be like. For developers, it will provide a basis on which to both propose a design to the community, and to develop that design throughout the project's life. Let me elaborate on the first of those a bit more: when we are ready to accept proposals from developers, we can organize them into a standard format, part of which will be a response to items in the Mandate: which features they will definitely include, which will be possibly included but secondary priorities, and which they will not implement. Based on this, both the developers and the community will have a clear mutual understanding of what is expected and what will be done.
One further point about the Mandate is what is absent from it: The space between the abstract principles and the specific features is the space for developers to exercise their expertise and their vision for the game. No designer would want to work on a project where their every move is dictated by a crowd of fans, most of whom aren't game industry professionals, or even developers. They must have freedom to create and develop their own vision for the game. That is the strength of having a single project lead: We give them the principles they must follow, and the results we most want; then we must step back and let them do what we are paying them to do, and what they are best qualified to do: design and build a game that meets those criteria.
I am hoping to have a preliminary version of the Mandate in place as soon as we set up the infrastructure for feature voting. In the meantime, suggestions on improving the concept are always welcome!
5 reponses to "The Mandate"
1. http://games.slashdot.org/sto
http://games.slashdot.org/story/10/02/09/0551202/Game-Development-In-a-P...
An implication against the aforementioned Agile style of coding.
2. Good catch, I read Slashdot
Good catch, I read Slashdot pretty often but I didn't see that; The article (and the comments) bring up some interesting points, but a lot of what he mentions assumes a story-driven game, or one being developed for sale; Agile might be a good approach for something more iterative like a city sim, although for the core engine there might be better methodologies.
3. First some comments about the
First some comments about the main article.
Normally, it's recommended to keep the design as high-level as possible, without going into too many details. This also allows changes much easier.
Now we probably have a huge amount of people willing to design for this project. So the features could actually be quite detailed, without being worred about running out of design manpower. But it's not necessary, we could mix them as we want.
When we choose to work on something, I recommend that we split it up in, to borrow from Kanban terminology "Minimum marketable features(MMF)". That is the minimal thing that would bring some additional value to the game. Note the word minimum, it's very important that we don't push too big features to the developers. This way we can make sure that it's much more likely to get done, and also that we get it in a timely manner. This MMF should be quite detailed, and at least include the "definition of done". So that both we and the developers know when the feature is done, and can move on to the next one.
Note that this splitting can cause a lot of additional work, so it would be good to keep them at that level in the mandate as well. When can group many MMF's into a bigger features if we want though. And then prioritize the MMF's inside that feature. However prioritizing is according to lean principles, and also agile principles better be done at the last possible moment.
4. Now some comments about the
Now some comments about the agile blog
http://games.slashdot.org/story/10/02/09/0551202/Game-Development-In-a-P...
An implication against the aforementioned Agile style of coding.
First before you read on, I assume that you know some things about scrum and kanban. If not, you can still read my post, but you probably won't understand everything. Otherwise you can download the minibook Kanban and Scrum - making the most of both. Registering is needed, but it's free.
I have read that article several times now, including the comments and I'm still not sure what that guy is on about. First of all if we are living in a post-agile world, why do we have the following presentations on the game developers conference next month?
Beyond Scrum: Agile Project Management for Games
Building Global Bridges: the Benefits of Cross-Border Agile Game Development
Agile: No Silver Bullet
The last one needs the description
The goal of this panel is to discuss the good and the bad of agile development. Let's not sugar coat it, agile development is hard and does not fit all production paradigms. We'll discuss where the dogmatic approach to agile fails and where to apply practices from other areas, such as waterfall and lean. The panel will also answer audience questions directly and help diagnose how and why Agile projects went wrong, and methods teams and companies can use to get their processes back on track
So it's not that about that agile doesn't work. It's about how to make it work. Yes a huge part of agile is about to adapt the process to work for you.
Secondly he says that he likes the agile manifesto and that's really all what agile is. You don't need to use scrum to be agile for example, nowhere in the manifesto does it say that you have to use scrum.
Here it is
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
First he goes one to rant about "Individuals and interactions over processes and tools", however it seems like he didn't read the fine print "That is, while there is value in the items on
the right, we value the items on the left more." So agile is not against processes, it's only against processes that doesn't value individuals and interactions as much as the process itself.
Then he rants about extreme programming practices, that are in no way part of agile. They can help you archive agile goes but are not a requirement. What's worse as can be read from the comments, he doesn't account for all facts.
Then he goes on to rant about that you cannot always have the most skilled people, and that agile will fail in those cases. Google is probably his base for this. Google only hires the most talented people, and they have almost no processes, and it works really well. However many agile projects has come up with methods to overcome theese problems, they encourage communications, to make sure that the people that are skilled enough have all the information needed. They usually use the extreme programming practice, pair programming, where they team up inexperienced people with experienced, thus the inexperienced people will learn new things.
Creativity vs production. I don't know how this relateds to agile at all. In fact agile is all about "Responding to change over following a plan", with the principle "Welcome changing requirements, even late in
development. Agile processes harness change for the customer's competitive advantage". Isn't that just exactly what's needed to allow creativity? Scrum on the other hand helps with productivity, there's countless examples of that. So agile lets you do both.
Phases of production. Nothing against or pro-agile. Agile let's you do this.
Skill-set - No idea what he is talking about in the context of the article
Client - From the agile principles "Business people and developers must work together daily throughout the project". If the business people only are interested in schedules, then agile is exactly for you, since scrum for example let's you predict when things are getting done much more accurately than any other methods. And as he says, if the business people wants constant changes, agile allows that.
I would have understand him, if he took another approach for this article. Here are some examples
Kanban would work much better than scrum, for the last two items. That's why I propose Kanban for game developement instead of scrum. Note that kanban is not aniti-agile in any way.
5. Exactly. The whole process
Exactly. The whole process of breaking down the game experience into discrete features and prioritizing them is where community input can really shine (and take a significant amount of work off the developer's hands). Conversely, since we own the project we also need to be deciding the very highest principles. It's only that in-between where community input becomes more a nuisance than a help, the dreaded "design-by-committee." That's the area where we need a centralized vision and centralized decision-making. If we balance it right I think it can be a really powerful combination.
About mqs's link: I must admit that, in true Slashdot fashion, I only skimmed the article briefly before skipping to the comments :) But yeah, I did think the tone was a bit histrionic and overly general. The comments had some interesting points though; one guy was making the case that spiral development was better suited to a game project than agile. Anyone have experience with that?
Post new comment