11 minutes ago, Oberon_Command said:

The designer just wants to be able to do burst fire, to see how it feels, and the engine doesn't support that because, when you were doing the initial implementation, they didn't ask to be able to adjust that.

It is only implementation of ajustable parameters require. Really termodynamics under natural convection conditions is well known process that exactly described by equations. Only that require to make designer happy is to add some control of border conditions air viscosity and other parameters of equations.  For example even commonly used  2D flame hotspot-bloor-shift technique uses integratin same equations but with lowest possible digits precission and Navier-Stocks equatiom stubed by a constant value. Really guys that has bring this technique to gamedev has wery vell know how it scheme works into real scientific software, becouse thay has exactly know in wich conditions low recission  computing sould be stable, and used same stub for flow function  that used into real scientific software during debugin of other stages of algo.

2 hours ago, Oberon_Command said:

And don't just handwave "I ask the designers at the start of the project" or "I make everything tweakble" because, as I have repeatedly said, that isn't generally feasible.

Assume that tweaking interface automatically generated and binded with objects. Only that you have to do for it into source code to make it  tweakable is to mark object properties visually tweakable by placing it definitions to especial section of class definition. Really it is innovations of middle of 90th.

3 hours ago, Oberon_Command said:

There is no constant, universal description of the tank game I just described.

Really? Tank have a turrets that have a weapon that uses a shells. It is enought to make a universal model that is complete data driven regardless of number of turrets, weapon kind firemodes, etc. (turrets, guns etc, just added to tank as to container by a designer together with required constraints of positions e.t.c). Also same model can fit any requirements of battleships, planes, spaceships and ever devil in the mortar that fires a exorcism balls.

2 hours ago, Oberon_Command said:

There simply isn't time

You have no time just becouse using SCRUM/AGILE methodology you have to make and remake a same solution into million variants insteand to make it once by universal way and use million times without any changes of code.

4 hours ago, Oberon_Command said:

But this isn't a scientific-driven software industry. We are neither automating factories nor writing autopilots. This is the video game industry - an artist-driven industry. We don't work the way other software engineers do. 

I can guarantee you this isn't unique to video games. I'm currently working on software for the finance industry, and we get the exact same "hey, it would be really cool if x" spec changes from our customers.

11 minutes ago, ChaosEngine said:

it would be really cool if x" spec changes from our customers

But specs it is not a process description. It is a start point of researching project field common rules. And it is responcebility of developer to find ranges in wich specs may be adjusted by data driven way before begin any coding.

In strict waterfall, spec means 'everything'. If you need changes, you need to change the spec first. You have to strictly adhere to the spec. However, most of the time, if you manage to change the software without updating spec, once it goes to the next state, the person next to you will ask you to put that in the spec. 

And, even if we update the spec to match the software, or create a software to match the spec, it will be somewhat different. Because of the difference, they become multiple sources of truth that create confusions along the way. At one point people will realize that spec is useless, no one read it afterward, yet we have to maintain it somehow.

@ChaosEngine looks like I've got a friend here :). I'm in the financial software industry too.

8 hours ago, Tom Sloper said:

16 hours ago, SillyCow said:

Avoid the 1 hour mandatory daily meeting at all costs.

An HOUR?? It should never be more than 15 minutes.

When I've worked on bad "agile" projects this would be the case. This is the most common sign that you are doing it wrong.

People come with open laptops and cellphones to the meeting and becomes a drawn out waste of time. It usually happens either because you have too many people in the meeting (ie: 9 people). Or people are turning the update into a debug/design session.

If your scrumm master does not stop this abruptly (and many are too nice to do so) than this becomes a major problem. The motto of "people and interactions over processes" does not help. I have really appreciated working under strict managers who rigorously upheld the scrumm process. I find that alot of scrumm masters shy away from doing this (shutting people up and not inviting too many people into the standup) because they don't want to be the "bad guy".

1 hour ago, mr_tawan said:

In strict waterfall, spec means 'everything

Specs meaning starting point of researching and nothing alse regardless of metodology used. Also any specs can be approached by different ways.  It is responsebility of developer to find a most flexible way. For example let research some flexible ways for previously discussed hipotetical story. Of couse we can imediately start to code a some garbage code that would  be trown to  trash at first minor changes. And it is called a woodoo-programming. But by any canonical development requirements we have first to determine entities of task field, their responsebilities and relationships. Following this way wi shortly have solution to make tanks and turrets a composite objects and angular actuators with constrined angles to drive a turret left-right and gun up-down. Gun fire and reload cycle can be approached as state machine where each stage have a own delay and flag is it processed automatically or by user keypress. By this way wi will have a wery tiny code of implementation and 100% data driven tweaks of any object behavior. Realy to implement any proposed specs changes (and anything else what can be required into any whechicle shooter) it require to add/remove stages to gun machine and remap some input keys that anycase have to be 100% data driven,and add a additional guns/turrets slots and angle costraints into modeling software (anycase it involves changes of 3D model geometry)   It is called a software engineering.

My wife works in a heavy agile environment and what i heard about is not that bad, but not great either - because it does not work for all customers. There are customers which always think in the waterfall method and does not want to get involved in the development process at all -> They want a fixed price, a fixed feature set based on a hard specification book.

Other customers misuse the system to get features for free - using the blaiming scheme -> "It does not work as intended" > "Change it!", even though its 100% implemented as descriped in the product/backlog.

But there are definitly customers which seems to be happy with the system as well.

I personally dont work in a agile environment, i just had two professional trainings for SCRUM and know the basics - so i can at least apply for jobs which requires it.

2 hours ago, Fulcrum.013 said:

Specs meaning starting point of researching and nothing alse regardless of metodology used. Also any specs can be approached by different ways.  It is responsebility of developer to find a most flexible way. For example let research some flexible ways for previously discussed hipotetical story. Of couse we can imediately start to code a some garbage code that would  be trown to  trash at first minor changes. And it is called a woodoo-programming. But by any canonical development requirements we have first to determine entities of task field, their responsebilities and relationships. Following this way wi shortly have solution to make tanks and turrets a composite objects and angular actuators with constrined angles to drive a turret left-right and gun up-down. Gun fire and reload cycle can be approached as state machine where each stage have a own delay and flag is it processed automatically or by user keypress. By this way wi will have a wery tiny code of implementation and 100% data driven tweaks of any object behavior. Realy to implement any proposed specs changes (and anything else what can be required into any whechicle shooter) it require to add/remove stages to gun machine and remap some input keys that anycase have to be 100% data driven,and add a additional guns/turrets slots and angle costraints into modeling software (anycase it involves changes of 3D model geometry)   It is called a software engineering.

Spec is the alpha (the starting point) and the omega (the end results) in classics software development process. Of course the actual outcome of the process is the 'software', but specification get evolved along the way. The main reason is the specs will act as an reference for another project. If the spec does not matches with the software, either one of them has to be amended.

In larger organization, there are number of people get involved with some piece of software. Sometime you need a sign-off from the head of different business units before it can be delivered to the client (which happens to be one of these business units). So what would these heads check before they sign-off ? Of course, not the source code. They read the specification, or some other kind or document. (My latest work is about the processing, but it affects registration, so I have to ask the registration BU head to sign-off as well. for example). 

I personally view Agile as a recommendation, not the 'only correct way'. In fact in the manifesto, it says prefer A over B (but keep B in the consideration too). It's not strictly enforced rule.

However, there are people misuse it. Many people (in the 'certification camp', for example ) dictate what to do and what not. Agile is not a universal rule,  let alone SCRUM. I remember listening to an interview with one of the CMM inventors. He said CMM is just a guideline, the implementation does not really need all of them to be implemented. However, later some other people put those guideline together and create CMMI, which dictate thing to do and what not. This is something happening in the Agile world.

But I believe that in a few years, the word Agile will fade away. People will take some of it suggestions. It will become the norm and a basis of other methodology to come (DevOps ?).