10 ms·

> Blizzard Entertainment spokesperson Andrew Reynolds told The Post, “As you may know, game development in general, and ‘Diablo IV’ specifically, follows an ite

> Blizzard Entertainment spokesperson Andrew Reynolds told The Post, “As you may know, game development in general, and ‘Diablo IV’ specifically, follows an iterative process where the scope evolves over time. Production on the game is going extremely well. Overtime is voluntary and limited to specific teams. We regularly survey the team on their professional well-being, and the latest results are the most positive they’ve been in years.” Replace evolving scope with increasing scope and you've got the most common recipe for development failure being pitched as a good thing.

Retric 4y ago
Alternatively, evolving scope is decreasing scope as they cut ever more critical parts of the game to make the fixed deadline. Either way it isn’t a good sign to be changing scope this late in the development process.
kramerger 4y ago
It's not really an iterative process if you fail at every iteration. Let's call it what it is: a series of waterfalls, all with unreasonable schedules
verdenti 4y ago
barbazoo 4y ago
I love how scope "evolves" as if it was a natural process and not just the result of poor planning.
- Jensson 4y ago
  For a game the scope evolves since you can't know how things play or feel until you test it.
- jay_kyburz 4y ago
  You can't plan for unknown unknowns. If you develop a feature and it turns out the feature is not great, you can choose to ship a game that's not great, or fix it. Once you have committed to a ship date and moving the date is no longer an option, fixing it means working over time. These crunches often come from the team themselves who are identifying that things aren't as good as they could be, want to fix it, but don't have the power to push dates back. Update: One problem is that creative teams are rarely satisfied, and would love to polish things forever. The production team needs to be constantly pushing back on the creative team to leave things alone and call it done. Working out what is "good enough" is really really hard. Update: Also, I wrote this comment before reading the article, and I don't mean to defend 6 months of crunch. That clearly _is_ bad management and exploitative. When you have a few bad features you can take a few weeks or a month to fix them. When you are 6 months out and only now just announcing a release date, there is lots you can do. You can cut the bad bits, you can hire more staff, you can move the date.
- strictnein 4y ago
  All software projects have changes in scope. And yes, that scope evolves. You get new customers (internal or external), new feature ideas, and functionality that is discovered to be unwanted or too complex.
  - otikik 4y ago
    And deadlines are moved or features are cut in order to make them. “Pizza during weekend at the office” is just bad planning.
- brianwawok 4y ago
  So if your plan for the game is not fun when you play it, you should just ship a turd sandwich?
  - moogly 4y ago
    That's what Ubisoft does.
  - falcolas 4y ago
    Like any project, sometimes you have to drop the game and work on something else. Ideally using the assets you have from the failed game. It's not an unusual tack to take even for regular software developers. Not all feature work. Smart folks will cut bait and focus on something that does.
ncallaway 4y ago
An iterative process with an increasing scope is totally fine. Using it as an excuse for crunch is insane, because an iterative process with increasing scope needs to also have a flexible deadline.
- jayd16 4y ago
  Can't change the holiday season timeline.
  - Thiez 4y ago
    That's fine, but then you should aggressively limit scope expansion.
  - hermitdev 4y ago
    If you cant change the time line, don't change the scope. This isn't rocket surgery. This late into the project, the scope should be well defined. I mean, especially in this era of DLC, why the need to increase the scope, anyways? Punt the extra ideas for later release.
    - deleted 4y ago
      [deleted]
    - default_png 4y ago
      That's how you get Half Life 3..
    - jayd16 4y ago
      I don't think crunch works but trying to define game scope 3 years out doesn't work either.
  - jerf 4y ago
    "Activision Blizzard employees developing the upcoming dark fantasy action role-playing game “Diablo IV” say it will be hard to meet a June 6, 2023, release date without working significant overtime, in a process they say has been plagued by mismanagement." Not exactly a holiday release.
throwuwu 4y ago
I’m not in the games industry but all the war stories I’ve heard trend in the opposite direction. They start out with really broad scope and then increasingly drop and cut content and features as the deadline approaches. The only time I’ve heard of features being stuffed in and blowing out the timelines is in the major boondoggle cases where management was a complete shambles and it’s far more than just feature creep that goes wrong in those cases.
musicale 4y ago
It was nearly 12 years from Diablo 2 to Diablo 3, and they didn't have to deal with a pandemic. I don't think waiting another year for Diablo 4 will be the end of the world. Though I'd like to see a WarCraft 4 someday too.
- atoav 4y ago
  > I don't think waiting another year for Diablo 4 will be the end of the world. Exactly. As I see it such things are much more crucial for games that might look/feel dated if they come out too late. The magic within the Diablo games (especially the first two) comes from the world it places us into, the way it is presented, the music, the story. All of these are things that shouldn't break with one year of delay. The worst thing that xould happen with a Diablo 4, would be that fans of the series get the impression it was rushed.
brailsafe 4y ago
I feel like my team lead has forgotten what iterative means, and expects much shorter turnout times in recent months for things that will absolutely not fit into a 2 week sprint. Since he kept going on about tickets that were getting stale due to last-minute unrelated scope expansions and me not being able to reprioritize new commitments on old tickets, I've just started being more strict. No, this ticket intended to literally just fix a typo is not also going to fix this unrelated bug qa discovered while testing.
- MrGilbert 4y ago
  > No, this ticket intended to literally just fix a typo is not also going to fix this unrelated bug qa discovered while testing. That's basically how it is supposed to work. If you need something to get fixed, create an item/bug for it and let it get prioritized.
- wildrhythms 4y ago
  I think this is a top-down issue caused by people in charge who fundamentally do not understand development lifecycles. When the requirements change at all I have to completely reassess the timeline.
- everforward 4y ago
  I've found success in cutting tasks up in things that will fit in a sprint. If I have to write a feature, I commonly split it into a few tickets: - Write the code - Test the code - Documentation changes - Deploy the code If it's a big enough change (or a new app), I might create a few sets of those tickets. E.g. one "write/test/document/deploy" set for the database schema to do Y, another one for the business logic to do Y, another for the HTTP endpoints for Y, etc. The tickets are specific to the implementation, not to the feature, so they can't be expanded. New work can only come through new tickets, which get prioritized. Manager is happy because tickets get cleared. I'm happy because I can fight scope creep by pointing to my sprint and asking which tickets they want to bump for their new scope creep. Tickets like "implement X feature" with a 2 week estimate are a landmine for engineers because it's broad enough for the scope to expand infinitely, and it starts to look like nothing is getting done to management.

Retric 4y ago

Alternatively, evolving scope is decreasing scope as they cut ever more critical parts of the game to make the fixed deadline. Either way it isn’t a good sign to be changing scope this late in the development process.

kramerger 4y ago

It's not really an iterative process if you fail at every iteration. Let's call it what it is: a series of waterfalls, all with unreasonable schedules

verdenti 4y ago

barbazoo 4y ago

I love how scope "evolves" as if it was a natural process and not just the result of poor planning.

Jensson 4y ago
For a game the scope evolves since you can't know how things play or feel until you test it.
jay_kyburz 4y ago
You can't plan for unknown unknowns. If you develop a feature and it turns out the feature is not great, you can choose to ship a game that's not great, or fix it. Once you have committed to a ship date and moving the date is no longer an option, fixing it means working over time. These crunches often come from the team themselves who are identifying that things aren't as good as they could be, want to fix it, but don't have the power to push dates back. Update: One problem is that creative teams are rarely satisfied, and would love to polish things forever. The production team needs to be constantly pushing back on the creative team to leave things alone and call it done. Working out what is "good enough" is really really hard. Update: Also, I wrote this comment before reading the article, and I don't mean to defend 6 months of crunch. That clearly _is_ bad management and exploitative. When you have a few bad features you can take a few weeks or a month to fix them. When you are 6 months out and only now just announcing a release date, there is lots you can do. You can cut the bad bits, you can hire more staff, you can move the date.
strictnein 4y ago
All software projects have changes in scope. And yes, that scope evolves. You get new customers (internal or external), new feature ideas, and functionality that is discovered to be unwanted or too complex.
- otikik 4y ago
  And deadlines are moved or features are cut in order to make them. “Pizza during weekend at the office” is just bad planning.
brianwawok 4y ago
So if your plan for the game is not fun when you play it, you should just ship a turd sandwich?
- moogly 4y ago
  That's what Ubisoft does.
- falcolas 4y ago
  Like any project, sometimes you have to drop the game and work on something else. Ideally using the assets you have from the failed game. It's not an unusual tack to take even for regular software developers. Not all feature work. Smart folks will cut bait and focus on something that does.

ncallaway 4y ago

An iterative process with an increasing scope is totally fine. Using it as an excuse for crunch is insane, because an iterative process with increasing scope needs to also have a flexible deadline.

jayd16 4y ago
Can't change the holiday season timeline.
- Thiez 4y ago
  That's fine, but then you should aggressively limit scope expansion.
- hermitdev 4y ago
  If you cant change the time line, don't change the scope. This isn't rocket surgery. This late into the project, the scope should be well defined. I mean, especially in this era of DLC, why the need to increase the scope, anyways? Punt the extra ideas for later release.
  - deleted 4y ago
    [deleted]
  - default_png 4y ago
    That's how you get Half Life 3..
  - jayd16 4y ago
    I don't think crunch works but trying to define game scope 3 years out doesn't work either.
- jerf 4y ago
  "Activision Blizzard employees developing the upcoming dark fantasy action role-playing game “Diablo IV” say it will be hard to meet a June 6, 2023, release date without working significant overtime, in a process they say has been plagued by mismanagement." Not exactly a holiday release.

throwuwu 4y ago

I’m not in the games industry but all the war stories I’ve heard trend in the opposite direction. They start out with really broad scope and then increasingly drop and cut content and features as the deadline approaches. The only time I’ve heard of features being stuffed in and blowing out the timelines is in the major boondoggle cases where management was a complete shambles and it’s far more than just feature creep that goes wrong in those cases.

musicale 4y ago

It was nearly 12 years from Diablo 2 to Diablo 3, and they didn't have to deal with a pandemic. I don't think waiting another year for Diablo 4 will be the end of the world. Though I'd like to see a WarCraft 4 someday too.

atoav 4y ago
> I don't think waiting another year for Diablo 4 will be the end of the world. Exactly. As I see it such things are much more crucial for games that might look/feel dated if they come out too late. The magic within the Diablo games (especially the first two) comes from the world it places us into, the way it is presented, the music, the story. All of these are things that shouldn't break with one year of delay. The worst thing that xould happen with a Diablo 4, would be that fans of the series get the impression it was rushed.

brailsafe 4y ago

I feel like my team lead has forgotten what iterative means, and expects much shorter turnout times in recent months for things that will absolutely not fit into a 2 week sprint. Since he kept going on about tickets that were getting stale due to last-minute unrelated scope expansions and me not being able to reprioritize new commitments on old tickets, I've just started being more strict. No, this ticket intended to literally just fix a typo is not also going to fix this unrelated bug qa discovered while testing.

MrGilbert 4y ago
> No, this ticket intended to literally just fix a typo is not also going to fix this unrelated bug qa discovered while testing. That's basically how it is supposed to work. If you need something to get fixed, create an item/bug for it and let it get prioritized.
wildrhythms 4y ago
I think this is a top-down issue caused by people in charge who fundamentally do not understand development lifecycles. When the requirements change at all I have to completely reassess the timeline.
everforward 4y ago
I've found success in cutting tasks up in things that will fit in a sprint. If I have to write a feature, I commonly split it into a few tickets: - Write the code - Test the code - Documentation changes - Deploy the code If it's a big enough change (or a new app), I might create a few sets of those tickets. E.g. one "write/test/document/deploy" set for the database schema to do Y, another one for the business logic to do Y, another for the HTTP endpoints for Y, etc. The tickets are specific to the implementation, not to the feature, so they can't be expanded. New work can only come through new tickets, which get prioritized. Manager is happy because tickets get cleared. I'm happy because I can fight scope creep by pointing to my sprint and asking which tickets they want to bump for their new scope creep. Tickets like "implement X feature" with a 2 week estimate are a landmine for engineers because it's broad enough for the scope to expand infinitely, and it starts to look like nothing is getting done to management.