I actually once worked for a place that didn't have this exact process, but they had a heavy process I'm sure nobody would describe as agile. And it worked pretty darn well.
They designed educational games for early elementary education. Every game activity was hashed out with a working committee consisting of an educator, a technical writer, an artist, and a programmer. They'd take a few hours and talk about the concept that the kid playing the game was supposed to learn (say, measures of weight), then they'd brainstorm ideas for potentially entertaining scenarios in which the concept could be explored (say, a flea circus), then they'd start to storyboard various activities and interactions.
Then the tech writer would produce notes, people would review them, and 2-3 weeks later, they'd do it again, refining concepts and interactions.
This process would stretch out over months, and by the time it was finished, the tech writer's notes essentially comprised a complete state machine for the activity described in English on paper. And the artists/media people had the assets for you in the right media formats. Usually sensibly named. Programming was generally pretty straightforward.
You know how a lot of the time that non-technical "idea guys" seem to have this terrible attitude? "Hey, I've already done the hard work of coming up with the idea, all you need to do is translate it into code."
This was one of those rare situations where it was often more or less true. But it was because the people coming up with the concepts were really part of a creative and disciplined process where they had to come to grips with the details in a way that usually only programmers have to.
Oh, and after things were done with programming, they had a QA team compare it against the spec and an educator's review.
They produced a pretty good product. Sometimes I think it's a shame I didn't stay longer.
I think this process would work pretty well for educational games as each game was a self contained thing.
As a teacher myself I do often incorporate a game (computer based or actual paper, dice, pieces), an interactive Web site, a video or other objects into a lesson. I also direct students to Web based interactive content as part of homework along with 'traditional' work.
In effect, my lesson planning is the 'interface' between the (no doubt well coded and engagingly designed) objects your team designed.
I suspect, from my own interactions with the business applications used in the largish educational institutions that I work in, that it might be harder to use this model when the interactions between the individual activities get complex...
They designed educational games for early elementary education. Every game activity was hashed out with a working committee consisting of an educator, a technical writer, an artist, and a programmer. They'd take a few hours and talk about the concept that the kid playing the game was supposed to learn (say, measures of weight), then they'd brainstorm ideas for potentially entertaining scenarios in which the concept could be explored (say, a flea circus), then they'd start to storyboard various activities and interactions.
Then the tech writer would produce notes, people would review them, and 2-3 weeks later, they'd do it again, refining concepts and interactions.
This process would stretch out over months, and by the time it was finished, the tech writer's notes essentially comprised a complete state machine for the activity described in English on paper. And the artists/media people had the assets for you in the right media formats. Usually sensibly named. Programming was generally pretty straightforward.
You know how a lot of the time that non-technical "idea guys" seem to have this terrible attitude? "Hey, I've already done the hard work of coming up with the idea, all you need to do is translate it into code."
This was one of those rare situations where it was often more or less true. But it was because the people coming up with the concepts were really part of a creative and disciplined process where they had to come to grips with the details in a way that usually only programmers have to.
Oh, and after things were done with programming, they had a QA team compare it against the spec and an educator's review.
They produced a pretty good product. Sometimes I think it's a shame I didn't stay longer.