The Staggered Development extra time fallacy

[FZD]

Firstly, it's commendable that CIG is trying different things to improve the development process.

However, staggered development is not a magical incantation that turns 30,000 man-hours into 60,000 man-hours, which might be the idea you'd get reading through Staggered Development FAQ:

Staggering the teams like this means 6-month cycles for development instead of 3, which means more time to ensure features are more complete with fewer bugs - all while still delivering quarterly patches.

What it actually means, is each person working on a feature has a longer period to do so, but their workload is doubled. That is, you got exactly as much time to complete the same work as before.

It in on itself does nothing to solve CIGs signature move of over committing each cycle. That is, as long as they remain too optimistic with their velocity estimates for each update cycle, underestimate the amount of work needed and over promise, they will continue to underdeliver patches, the patches will be late, there will be x.x.1 and x.x.2 feature patches outside of the regular cycle, etc. If anything, I'd say 6-month cycles make it harder to estimate the work than 3-month cycles.

Now, it is possible that staggering the development helps CIG to optimize the resource usage, which is the only way you can get more results out of the same resources, but I wouldn't jump on the staggered development hype train just yet.

 

[NaffNaffBobFace]

I got the feeling that it frees up teams that are waiting for work to be done by other teams so they can start / have completed early and can go do something else rather than sit around and await the rest of the teams to catch up with them...

Maybe I got the wrong end of the stick on that one?

 

[Lorddarthvik]

I don't know if you noticed, but they didn't say this would make anything faster. They only said it would be delivered at a later date and thus it would be better polished and less buggy.
Currently whenever they make a feature, like mining, they release an early implementation one quarter, then work on it some more and release a reworked version later. This is mostly beneficial to us, the player, as we can give them an input on what we would like them to change. This is a strain on their resources that is unnecessary if the feature is delivered at a more refined and stable working state.
That's what the staggered development is for.
It won't make anything faster, they never said it would, but in the long run they hope that they get enough of these features right the first time around, thanks to the longer dev cycle, so they can get some things done faster then if they deployed a new version 3-4 times a year.

Personally, I don't care. It won't change much if anything. Ppl will keep bitching about features no matter what, and unless someone at CiG puts a stop to this "" development by mass whining" they do, it will still take ages to get anything even close to "done" .

 

[Shadow Reaper]

"What it actually means, is each person working on a feature has a longer period to do so, but their workload is doubled. That is, you got exactly as much time to complete the same work as before."

Personally I think there is wisdom in this approach, since it allows the testers more time and every person in the process is available to fix bugs and polish stuff. I think it is certainly harder than only having one thing to do, but I always plan employees work schedules such that if one task hits a roadblock they have another to jump to. I think this is just good time management. If you don't have a second thing to do and something stops you working, you really stop working and that is very poor management.

I have never seen anything that made me think CIG has a management problem.

 

[maynard]

managing a software development project as complex as Star Citizen is a challenge, to say the least

to stay on top of it all and introduce architectural and process improvements along the way, even more so

IMHO Chris Roberts is a genius

 

[FZD]

I got the feeling that it frees up teams that are waiting for work to be done by other teams so they can start / have completed early and can go do something else rather than sit around and await the rest of the teams to catch up with them...

Maybe I got the wrong end of the stick on that one?

Well, it could be that, but it's equally as likely that this will lead to some other people waiting on 3.8 resources before they can continue their work on 3.9. Or they can't plan features that are built-upon in the next patch, i.e. 3.8 features (or thinking smaller, methods, technologies, etc.) can only be further utilized in 3.10 or later, 3.9 features can only be further utilized in 3.11, etc.

I don't know if you noticed, but they didn't say this would make anything faster.

And I didn't say it either. They did, however, say they'd have more time. They don't. It's still the same amount of people doing the same amount of work in the same amount of time.

They only said it would be delivered at a later date and thus it would be better polished and less buggy.

Which would mean they'd need to do more work. However, that then would require more people working on it, or reducing the amount of features planned for each update. Halving the team and doubling the cycle does not produce more man-hours. That's the point.

Personally I think there is wisdom in this approach, since it allows the testers more time and every person in the process is available to fix bugs and polish stuff. I think it is certainly harder than only having one thing to do, but I always plan employees work schedules such that if one task hits a roadblock they have another to jump to. I think this is just good time management. If you don't have a second thing to do and something stops you working, you really stop working and that is very poor management.

I have never seen anything that made me think CIG has a management problem.

Well, my whole point is that there isn't any additional time. If you double the cycle and the workload, it's still exactly the same amount of time per feature, now the work is just shifted around.

So if you wanted more time per feature, you'd reduce the amount of features being worked on. Or hire more people. Or if you had a problem with time management, fixing that would then also help. But if you didn't have a problem with time management, well, can't fix what isn't broken.

 

[Sraika]

I heard there was some fallacy in this thread

 

[Lorddarthvik]

Well, it could be that, but it's equally as likely that this will lead to some other people waiting on 3.8 resources before they can continue their work on 3.9. Or they can't plan features that are built-upon in the next patch, i.e. 3.8 features (or thinking smaller, methods, technologies, etc.) can only be further utilized in 3.10 or later, 3.9 features can only be further utilized in 3.11, etc.


And I didn't say it either. They did, however, say they'd have more time. They don't. It's still the same amount of people doing the same amount of work in the same amount of time.



Which would mean they'd need to do more work. However, that then would require more people working on it, or reducing the amount of features planned for each update. Halving the team and doubling the cycle does not produce more man-hours. That's the point.



Well, my whole point is that there isn't any additional time. If you double the cycle and the workload, it's still exactly the same amount of time per feature, now the work is just shifted around.

So if you wanted more time per feature, you'd reduce the amount of features being worked on. Or hire more people. Or if you had a problem with time management, fixing that would then also help. But if you didn't have a problem with time management, well, can't fix what isn't broken.

They did not say it gives them more time overall! They are not trying to bend space-time! They said that they will have more time to work on a feature before we get to play it, making the game more playable. Instead of getting a broken feature, like bounty missions, they will spend the extra 3 months on it (which they are doing right now with that exact feature cos it still doesn't fucking work!) and so they can give us better features from the start!
That doesn't mean they get more time overall for anything, but it also doesn't double the workload, or requires more devs!

What they were trying to say, and not say at the same time, is that the 3 month cycle is unsustainable. They always spend more time then 3 months on the features. The actual time they spend on a feature doesn't really change with raising the self-imposed time limit from 3 months to 6 months, cos they were already spending that time on it anyways!
Did you notice how features constantly got pushed back by weeks and even months, or even into the next quarterly patch? Apparently they did too, and thus they are changing the way they work to accommodate for that.


Okay, lemme try to explain this again.
You have a feature X.
So far, feature X had a 1.0 version after 3 months of work, and because it was shit, they had to do a 2.0 version. But while version 2.0 took only another 3 months of dev time to complete, this time was split up between other tasks and was only deployed later then 3 months. That's still only 6 months spent on feature X in development, but in a messy way.

With staggered dev, feature Y will spend 6 months in development (without breaks or other features breaking up the dev flow) before they deploy the 1.0 version. This time they hope that 1.0 will be as good or most likely better then the 2.0 version of feature X was.

That is the whole point!

You spend the same amount of dev time on the same amount of features with the same amount of devs, but you don't try to make them all at once and hope that one is ready on time. Instead you break up the features into independent groups so they can be worked on for longer and more efficiently.
No, it doesn't not create more time out of nowhere. But they won't be spending as much time fixing and going back to older features as much as they do now, which should improve efficiency, so they will have more time to work on the features, even if just by a little bit.

Tldr.: after a year, CiG saw that the 3 month cycle wasn't enough and they were doing shitty patches and spending lots of time fixing up stuff that was supposed to be ready. So they will try 6 months with two teams staggered, thus minimizing the extra time they currently spend on fixing those features but we do get stuff in 3 month intervals. That's why they do it staggered. Not for them. For us.
This should leave them with more time to actually work on the next feature instead of bug hunting.
At least thats what they hope to achieve, we will have to wait and see if it works out.

 

[FZD]

They did not say it gives them more time overall! They are not trying to bend space-time! They said that they will have more time to work on a feature before we get to play it, making the game more playable. Instead of getting a broken feature, like bounty missions, they will spend the extra 3 months on it (which they are doing right now with that exact feature cos it still doesn't fucking work!) and so they can give us better features from the start!
That doesn't mean they get more time overall for anything, but it also doesn't double the workload, or requires more devs!

They halved the number of devs working on a feature, ie, doubling the workload of the remaining devs. Then doubled the period of which it is worked on, bringing it right back down where they started. There is no more time to work on a feature. It's the exact same amount of man-hours. The only way to get extra work out of this is to bend space-time.

What they were trying to say, and not say at the same time, is that the 3 month cycle is unsustainable. They always spend more time then 3 months on the features. The actual time they spend on a feature doesn't really change with raising the self-imposed time limit from 3 months to 6 months, cos they were already spending that time on it anyways!
Did you notice how features constantly got pushed back by weeks and even months, or even into the next quarterly patch? Apparently they did too, and thus they are changing the way they work to accommodate for that.

I did indeed notice that. This doesn't fix it.

Okay, lemme try to explain this again.
You have a feature X.
So far, feature X had a 1.0 version after 3 months of work, and because it was shit, they had to do a 2.0 version. But while version 2.0 took only another 3 months of dev time to complete, this time was split up between other tasks and was only deployed later then 3 months. That's still only 6 months spent on feature X in development, but in a messy way.

Look, how many months pass between features doesn't tell anything about the amount of work that is put into the feature, as it doesn't address whether there are 1, 2, 20, or 200 people working on it. So lets talk about man-hours and man-months.

If feature X takes 3 months with 10 people, that's about 5k man-hours. If you divide those 10 people to two 5 people teams that then work on features X and Y, but over 6 months instead, that's still 5k man-hours for feature X. You do not get any additional time, if 5k man-hours isn't enough to get that feature done, then it isn't enough just because you spread them over 6 months instead of 3.

You spend the same amount of dev time on the same amount of features with the same amount of devs, but you don't try to make them all at once and hope that one is ready on time. Instead you break up the features into independent groups so they can be worked on for longer and more efficiently.

They're still making the same amount of features over the same period of time. Only before this they made X, then Y, then Z. Now they make X with half the team and Y with the other half, but X gets released 3 months earlier and Z is started. That is, if you considered "all at once" a bad approach, this is then 'even more at once'.

Tldr.: after a year, CiG saw that the 3 month cycle wasn't enough and they were doing shitty patches and spending lots of time fixing up stuff that was supposed to be ready. So they will try 6 months with two teams staggered, thus minimizing the extra time they currently spend on fixing those features but we do get stuff in 3 month intervals. That's why they do it staggered. Not for them. For us.
This should leave them with more time to actually work on the next feature instead of bug hunting.
At least thats what they hope to achieve, we will have to wait and see if it works out.

Spending greater initial effort to reduce the amount of time required to fix a feature has nothing to do with staggered development. To spend greater initial effort, you'd need more man-hours, that is, you either need to hire more people or reduce the amount of work you're doing. Could be CIG is just using this 'staggered development' as a smokescreen to have few months to catch-up, spend greater initial effort for the next update and hope to get that ball rolling, but if they don't start to more accurately estimating the amount of work they can do for each patch and only promise the amount of features they can make with their man-hours, we'll be back here in no-time flat.

 

[Shadow Reaper]

Well, my whole point is that there isn't any additional time.

There isn't more time to work, but there is more time to think.

Wise managers know that their best people work when they're not at work. They think about their jobs at home at dinner, when sitting in a bar or while choking on a cigar. That time--unfunded, private, creative time, is some of the best time any employee has to give. That's when their best ideas come and doubling the time to complete any given task by working two tasks at once gives them double the free time to find creative solutions.

 

[FZD]

There isn't more time to work, but there is more time to think.

Wise managers know that their best people work when they're not at work. They think about their jobs at home at dinner, when sitting in a bar or while choking on a cigar. That time--unfunded, private, creative time, is some of the best time any employee has to give. That's when their best ideas come and doubling the time to complete any given task by working two tasks at once gives them double the free time to find creative solutions.

Hmm, I see your point, but considering you had 10 people spending time home thinking about their jobs at home at dinner, bar, etc. over 3 months, wouldn't that then also be the exactly same as having 5 people thinking about their jobs at home at dinner, bar, etc. but over 6 months?

And I'm not quite sure why you're talking about working on two tasks at once? Everyone is still working on one task at once, it's just you got half the people working on A and the other half on B, or did I missunderstand what you meant?

 

[Vavrik]

There isn't more time to work, but there is more time to think.

Wise managers know that their best people work when they're not at work. They think about their jobs at home at dinner, when sitting in a bar or while choking on a cigar. That time--unfunded, private, creative time, is some of the best time any employee has to give. That's when their best ideas come and doubling the time to complete any given task by working two tasks at once gives them double the free time to find creative solutions.

I wasn't going to say anything in this thread, but @Shadow Reaper has hit something square on here. Creativity can't be put in a box, or a schedule. It happens because people who are creative are always thinking somewhere in the grey matter. What you want to do to leverage that is inspire them, make them want to think.

 

[Vavrik]

Hmm, I see your point, but considering you had 10 people spending time home thinking about their jobs at home at dinner, bar, etc. over 3 months, wouldn't that then also be the exactly same as having 5 people thinking about their jobs at home at dinner, bar, etc. but over 6 months?

And I'm not quite sure why you're talking about working on two tasks at once? Everyone is still working on one task at once, it's just you got half the people working on A and the other half on B, or did I missunderstand what you meant?

I think you misunderstood, productivity is not the same as creativity. You cannot put creativity in a formula or box. You don't get the same creativity from 5 people in 6 months that you get from 10 people in 3 months or 100 people in 1 day or 10 years. That's not how creativity works. It happens because of inspiration, and it's just an idea or a concept. What you're thinking of is productivity. This is something else entirely.

 

[Shadow Reaper]

And I'm not quite sure why you're talking about working on two tasks at once? Everyone is still working on one task at once, it's just you got half the people working on A and the other half on B, or did I missunderstand what you meant?

I'm not sure exactly what CIG is doing, but I don't ever want to give an employee just one thing to do. Any complex task has choke points, bottle necks, places on the critical path outside the control of the person on the task. "Oh, I need Beasley to check the shading because. . ." or whatever. You need a part delievered. You need your manager's okay. You need a piece of critical communication with a customer, etc. Any time an employee can't work, they have to have something urgent and important to do.

I worked ten years for UPS and one thing I came away with is they approach every task with a sense of urgency. If you work that way you get lots done. If instead you don't know what to do because Gimpy didn't send the vrashleflosholovens yet, you can blame Gimpy that you're not working. This is really the fault of the manager though.

Just remember, the best employees who do the job out of sense of pride and accomplishment, do not need managers. Managers are for people who need to be told what to do. All good managers leave employees with instructions what to do if anything stops them from working on whatever is the current task.

BTW, we haven't even considered what happens when you get a truly conciencious employee. Sometimes they'll stay late and work just to accomplish too much and earn that promotion. That's considered old school these days and Millennials try to get ahead by lateral moves in and out of companies, but back in the day the best workers put in time they weren't paid for in order to prove themselves. If CIG had lots of those we'd be in Beta by now.

 

[Montoya]

This is a good discussion taking place here!

What I took from this was that we got a simple answer to a more complicated problem CIG was having.

Im sure if we had another 55min to talk about why this is a better strategy, we would get better answers.

 

[Printimus]

Nothing will look any different from our perspective with the exception of more polish per patch. Had CIG not chosen to share this new development style with us, I highly doubt we as the backers would have taken any notice at all. We still get quarterly releases, and ship concept sales, and etc.

 

[Michael]

There might be one advantage that i see. I'm not a PM nor developer.
But i know one thing, throwing more people on one task doesn't necesseraly speeds up the precess ("too many cooks spoil the porridge").
So if you create smaller teams working on more tasks, for a longer period of time, you might get better end results at a relative faster time. Also less coordination is needed.

But tbh i always had the impression they are doing some kind of staggered development already. Maybe they have improved the whole process, split the teams stronger.

Also i don't think that chris is really involved into PM anymore, mostly seems to be Erins task.

 

[DirectorGunner]

staggered development is not a magical incantation that turns 30,000 man-hours into 60,000 man-hours, which might be the idea you'd get reading through Staggered

Mmm... I didn't get that. I got offsetting different features from each other to have a more trickle-like release of features. Made sense to me, resources are finite and it's not like they're going to magically improve production speed by shifting resources, instead of say some random number of 10 goals hit in a patch, maybe we'll get 5 goals hit. In other words, being very ambitious with a lot of goals isn't working out.. and if that's the case.. the reasons for which I can guess are complex / more than one reason.

What it actually means, is each person working on a feature has a longer period to do so, but their workload is doubled. That is, you got exactly as much time to complete the same work as before.

How is workload doubled for 1 individual but required in the same amount of time when project management wise goal delivery goals are offset to be staggered. This is an overall management approach, I don't see where they said workload is doubled for anyone. Are you familiar with Gantt charts? The typical offsets you see on that is what I gathered they're doing with goals. Assigned resources/labor in that fashion.

It in on itself does nothing to solve CIGs signature move of over committing each cycle. That is, as long as they remain too optimistic with their velocity estimates for each update cycle, underestimate the amount of work needed and over promise, they will continue to underdeliver patches, the patches will be late, there will be x.x.1 and x.x.2 feature patches outside of the regular cycle, etc.

Sure why not, not really much of an argument here other than stating what we know to be obvious in general, no offense intended. Still looking for the evidence to support your conclusion in the subject line.

If anything, I'd say 6-month cycles make it harder to estimate the work than 3-month cycles.

You'd say that but doesn't mean it's going to be the case and that doesn't have much barring on your point about a fallacy of extra time with staggered development.
Estimating goal completion for sprint runs, albeit may or may not be harder depending on cycle size, doesn't mean the management decision to stagger those completion goals is fallacious or in error.

Now, it is possible that staggering the development helps CIG to optimize the resource usage, which is the only way you can get more results out of the same resources, but I wouldn't jump on the staggered development hype train just yet.

Well, I'm not on a hype train about "staggered development" as they say, it means they adjusted again.. and likely to adjust to an issue they're facing.
Agreed optimizing in a work environment is good depending on how. If you optimize at the cost of staff morale, it can detrimentally affect production quality. Or you can optimize by addressing unnecessary roadblocks/inhibitors for the staff and improving leadership/corporate culture to be more conducive to an efficient and productive work environment. Easier said than done of course. If managers had a magic stick they could wave to improve the efficiency of labor/get people to do things happily of their own will... they'd make millions.

But.. again.. not seeing where the fallacy/error in inference is?

 

[NaffNaffBobFace]

Well, it could be that, but it's equally as likely that this will lead to some other people waiting on 3.8 resources before they can continue their work on 3.9. Or they can't plan features that are built-upon in the next patch, i.e. 3.8 features (or thinking smaller, methods, technologies, etc.) can only be further utilized in 3.10 or later, 3.9 features can only be further utilized in 3.11, etc.

As they are now working in the agile framework, that aspect is for the person who prioritizes which team works on what and when, to balance.

I can't tell you exactly how they are running as every implementation of agile process is different in it's own unique ways specific to the project they are working on, but from the video it seemed like some teams got stuff done way fast while others were waiting for other teams to finish doing their thing (just my impression), so to me it seemed the staggering meant once a team has finished their sprint work (say they esitmated 13 points and it ended up being 8) they could go on to other things like testing for other teams while waiting for the end of the sprint or picking up an 8 pointer which may have otherwise been further down the list of priorities...?

Staggering just seems to be an additional tool for the prioritization guy which happened to be implemented at the same time as an agreement to get the patch in as good a shape as it can be came in...?

I don't pretend to be an expert, the place I worked in an agile framework was implementing it experimentally on a non-software based project thats all the experience I've had with it.

 

[Crymsan]

Its quite clear this project has had massive mis-management. If this helps great. They always keep saying what we have is more than most games have and yet the game is many many years from release (this is how much feature creep there has been). I think the ship sales are not driving the cash they need (since they have already spent it), and that's because promising jam tomorrow (is all they ever do and gets a bit like crying wolf).