Why did they decide to switch to Staggered Development?

For 3.0 they were very feature-driven, where things kept coming in, and the date kept getting pushed back. With 3.1 and 3.2 they were setting up a certain cadence where they were supposed to be more date-driven. This was working for them for 3.1 to 3.4, however some of the features coming in were still rough, and rougher than they'd like. For 3.5 and 3.6 they didn't release on time, and the features kept coming in later and later. For most of their features, it takes longer than 3 Sprints (3 Sprints = 6 weeks) to get it working - to get it to the quality that they want it to be. Their first iteration of Mining, for example, took that team 6 months to deliver everything that needed to be done. That said, smaller teams, or teams working on smaller features, will be able to do their work within a smaller time frame. As they were getting into the cycle, they found themselves questioning whether the work they were putting out was hitting the mark, and both the teams and the directors were feeling frustrated. As a result they started talking internally about how they could adjust things, and "try this out and see how it works". In the middle of each quarter they have what they call a "Go/No-Go" meeting which consists of the directors, including Chris, Erin, and Brian, taking a look at the features and deciding what does and doesn't "hit the quality bar". What should be happening is that all future work of the thing is completed, so that it's just minor bugs at that point in time, and then from there it gets dropped into the stream and it's ready for release. Before they weren't having that - some teams were and some teams weren't, so some of the quality was there and some of it wasn't. So this (seemingly the Go/No-Go meeting) allows them to make sure that there's a gate for their work to pass through, to make sure the quality they're aiming for is met. This also allows the teams a chance to reflect on why they might not have hit their quality target, which could be things like a vacation, someone was sick, or the feature was more complicated. There are a lot of times when they put things together where they have their best estimate of how long a certain piece of development is going to take, and sometimes they meet that estimate and sometimes it takes longer, but the Go/No-Go meeting allows them to look at the feature and make sure that it's hitting the quality level that they want, and then gives them 6 weeks to make sure that they're releasing to the Evocati on time, and then Wave 1 PTU, and they're making sure that the Quality of Life bugs are getting fixed and that features aren't getting dropped in 3 weeks before they're supposed to be going Live. An important point for Brian is that their releases are solid on being date-driven, and that if a feature isn't ready, then it doesn't release for that patch, and that they're not holding up any quarterly releases because a feature isn't ready, because that does everyone a disservice. That is to say, they think it's more important to keep the cadence going for the releases, rather than making sure a feature releases for a certain patch - it means that the team is immediately addressing those issues without working on bugs whilst they're in Live, and this reduces some complexity on their end as well. Jared adds that he thinks that one of the hallmarks of Star Citizen's development is the constant iteration and re-evaluation of their process - that they want to get better at making the game just as much as they want the game itself to get better, so these kinds of changes are inherent to the company. Todd says that what people need to understand is that in normal game development a company would just "run" until they reach Alpha, at which point they'd look at what they've done and realise that they've made a huge mess that the need to clean up before Beta, which is when they have to polish and tune the game, and have an aspect of iteration. In their case, having a Live product since very early on in its development creates challenges that sometimes they're used to and sometimes they're not, so it's a learning process for all of them regardless of how long individual people have been making games for, because Star Citizen is "a very unique beast". Jared says it's a double-edged sword of challenges and opportunities, where there are things that they have to account for but there are also benefits of running a Live Environment, such as the ability to get instant tangible feedback during the development process that can help guide them. Todd agreed, but added that sometimes it feels like they're building a railroad whilst they're on the train.