Another different characteristic between extended-cycle and live short-cycle is planning. In traditional console development the production team is tasked with planning out an entire product over a one to two year development schedule. Even with highly iterative development, the expectation is the general game plan for the project is defined. This changes in two ways for social development:
1. The initial production plan should be targeted at the minimum feature set possible to deliver your product to your users and get user feedback and metrics. This is the quickest, smallest chunk of your project that can be delivered to meet your objectives and go live. You will learn 1000% more about your game and your development when it's live than you knew during those initial stages of development.
Now, this is not to say you need to deliver crap or you can't plan out integrated systems for deployment. You know your game, you just need to evaluate what is necessary to launch, triple guess yourself, ask a friend, and then probably cut down another 10 percent to hit that minimum spec.
2. Once you product is live, trying to forecast and plan for more than three weeks (two weeks even) is wrought with peril. Again, you are now in a mode where you are looking at your data as it comes in and making decisions against your data.
How could you possibly plan the rest of development without knowing your data? That is like crossing a busy intersection with a snapshot of the cars from five minutes earlier (to paraphrase a recent TV ad). The development team should make predictions and outline major feature improvements for a three week period, but set the majority of team to data driven design.
Early on in development, this skews heavily towards reaction as you will likely be dealing with fires and the unexpected. As time progresses it can be a more even split between reaction and planning.. Still, have no ego. If there is a critical choke point with your users push a feature and address it. If players are doing Y when you thought they would being doing X, change your product.
Adam and I were discussing this at length one afternoon. He had some tasks to do detailed designs of features for development for a month or so down the road. Normally, Adam would jump all over these, but he was pushing back.
Essentially he was saying "Why spend the time developing this stuff now? It is just a wasted effort to do it now -- everything is going to change." He was right. Essentially from that point on we adopted a looser system for future designs. We detail out the main components of the feature, but wait until the horizon is closer for the detailed implementation specs.
This last point is short, but is worth calling out. When developing rapidly on a live product, it is massively important to have an automated build system and a test deployment setup that allows you to test against old user data. Chase your tail in test, not out in the wild with your users.
Here I have to make a shout out to Jeff Kesselman (our CTO). We were developing so rapidly I actually drove the product without getting our build process set. We were short an engineer and I wanted to get our main gameplay features online. He pushed back hard, but it still took time to free up the resource. It was a lurch to get the system online and it used up a lot of cycles. In this case, I would say the short and long term gains are high enough to get this right from the get go (even if it does "slow" you down.)
Blue Fang's first mobile game was Lion Pride. This game was developed from kickoff meeting to Apple submission in seven weeks. Primary development came from three people: myself, my art director, and an engineer. This project followed the core principles of short cycle development. We set our objectives and had a very tight information loop. After launching the project, we delivered six updates over a three month period (this was back when Apple approvals were a two week affair).
Key factors to deploying Lion Pride quickly:
Unfortunately, we did not integrate a good analytics system into Lion Pride and as such our live updates were all driven by community feedback. We were active on the forums talking to players and watching our review via iTunes. We always had more content planned, but 50 to 75 percent of our changes were initiated by user feedback.
Turning around regular builds in two week intervals essentially turns into one day of planning, one week of development, a few days of QA and resubmission. This was our team's first taste of the non-stop live development of a Facebook title.
My focus during Lion Pride development was to drive to our core components and execute them. Beyond making fantastic art, I'd have to say Lou's focus was daily suggestions of features, changes, and tweaks which together would blow our schedule. I'd get so many, we ended creating a Lou idea board in my office.
Here is the thing, in most cases (Lou would say "all") the features and ideas being suggested would be awesome additions to the product. Having them all in one place allowed us to consider and contrast them late in development when we actually had time to add them.
Another neat dynamic of Lion Pride development was that our engineer, Lajos Kamocsay, was on a weird time split and essentially developed from 9pm to 4am each night. While I generally prefer the dynamic of being able to bring all developers into the same area for high communication -- the off time was effective. It forced us to define our work clearly and allow uninterrupted development flow.