19 minutes ago, Oberon_Command said:

I'm afraid that again, speaking from experience as a gameplay programmer,

If you speaking as expirienced programmer you have to know that computer is universal digit mill. Computer able to mill digits only. Illusion that computer able to do something else, comes from properly orginized process of digits milling. It is imposible to mill digits properly without exactly knowledge of mathematical background of process. Also it is what you can hear on your first day on any computing related university course.

4 minutes ago, Avalander said:

not which bits they need to shift.

Exactly. He have to take care how to make a UI elements self-positioned and anchored together. But he have to involve computation of positions for it. And it require to know a mathematical background of it.

6 minutes ago, Avalander said:

If we had to go that low level for any programming task

 Really than higher level, than more complexive math involved. 

17 minutes ago, Avalander said:

At most, they need to think about where to draw a box and which color to use for the text.

17 minutes ago, Avalander said:

no amount of math will tell you whether the players will like the dialog system or hate it.

It is 2 kind of dialogue systems survive today - placed by mouse and anchored UIs with manual visual databinding and complete self generated UIs with automated reflexion info driven data-binding with human designed styles. Only about what UI programmer have take care - is how to implement tools for human designer or how to implement unmanned designer. Both cases he have to implement self position of elements, that usualy using very simplified CAD technicues. UI designing tools can be considired as UI CADs. Really UIs described by human-written text has been outdatet at early 90th. Also non-ajustable by end-user UIs has gone at later 90th.

Regarding SCRUM ... or maybe Agile Methodology in general (these two words are used interchangebly incorrectly most of the time :)), I think there's a session in GDC last year regarding Resident Evil VII that has a mention about it. Capcom's team use Agile (not really sure how, presumably SCRUM) during prototyping state and later switch to Waterfall once everything is settled. 

Agile does not really suit well when there's tight time/budget constraints, as the process involve with 'iteration'. In enterprise, Agile is quite fit as the needs of users keeps changing as time goes by. For game, once the details is set, you don't really touch it unless absolute needs araise. We don't change the details once the game is released, don't we (with exceptions of bug fixes) ? Of course, some aspect of the Agile methodology can play a huge role in the later state, like shorter iteration loops and retrospective. 

Actually, Agile Manifesto only have a few statements in there. The method we use nowadays are kind of interpretion of these statements.

Quote

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

(source: http://agilemanifesto.org/)

SCRUM is one way to archive this, but not the only way. 

39 minutes ago, mr_tawan said:

Individuals and interactions over processes and tools

Any software intended to simulate/control some kind of  process (bussines/industrial/informational). So really key is determining of target process rules and required tools, of course by contacting of individuals that making process himself currently and individuals that have to implement process automation.

57 minutes ago, mr_tawan said:

Working software over comprehensive documentation

Working software can not be implemented without complete description of target process rules in form of mathematical/logical description or/and information schemes.

59 minutes ago, mr_tawan said:

Customer collaboration over contract negotiation

Customer is not able to determine rules of target process himself and have no ideas how to implement automation of process. It is just not his field of competence. Otherwice he just don't need to involve third parties for software creation.

1 hour ago, mr_tawan said:

Responding to change over following a plan

Professionaly made software do not require any changes until task field universal rules changed. Changes that fit into field rules, have to be implemented by a data-driven, end-user ajustable way. It is must have option for any algo.

Consumtion : AGILE violates any basic requirment of software development. Looks like it "metodology" has been created with only mind to pump more money from customers by tiny scamers companies that pretend to be a professionaly software development companies.

If you have 9 people (8 devs and one manager?) I would probably split them into 2 groups (manager + 4 devs). having daily stand-ups with 9 people will  wreck your work schedule. Maybe have a big company meeting at "end of iteration" or something.

Agile can work if you really make sure you stick to the agile process. (contrary to the emphasis on people)

It doesn't have to be any specific agile process, it just needs to be followed.

Otherwise "Agile" just turns into anarchy.

Some key points:

Stand-ups should be short: (less than 5 minutes per developer). Do not let your stand-ups turn into architecture/debugging meetings.If a lengthy subject needs to be discussed, end the meeting and start a new one. Do not hold 2 people hostage for an hour if only 7 people needs to be in the room. If someone starts debugging/architecting in a standup tell them to stop! Have the actual stand-up standing up so that people are uncomfortable wasting other people's time. Set an alarm clock or something if you can. A daily stand-up that takes more than 15-20 minutes is a demotivational disaster. Make sure your team is committed to keeping it short. If someone is late, they should lose their "right" to talk at the stand-up. Avoid the 1 hour mandatory daily meeting at all costs. It will suck the life out of your developers.

Try to minimise the amount of people in a meeting. In my opinion meetings with more than 5 people have a high chance of turning into lectures. 

That said, while the "standup" is a "holy time" that should be respected and revered by all participants, people should be enabled and encouraged to talk to each other.  (They just don't need everyone in the room to do so [and if they do, they can invite them] )

Have a clear "definition of done": Something is not done unless it has been integrated into "master" and preferably tested by someone other than the developer that implemented it.

Make sure you reduce your "truck factor" buy forcing people to work outside their comfort zone: Very important to have at least 2 people working on every code base. This will also increase teamwork and team cohesion.

Have a well organised task tracking tool: Whether it's a bunch of post-its on  a board, or a fully fledged task management S/W.:

• Tasks should not get lost (forgotten or closed before they are finished just to meet an EOI)
• People should be able to easily build a backlog (save for later)
• At any time each developer should know exactly what he is supposed to be working on
  • There should also be a "next task" ready to go. Even if they get stuck

One thing about the standup meeting: it's not about 'status update', at least not for the management. It's more like a discussion with your team mate with specific agenda: "what you did yesterday", "what is the obstrucle", and " what are you going to do next". Some time discussion can lead into another deeper discussion, which is good, but should be discussed later after the stand up.

Also it does not have to be a formal standup meeting. A coffee time meeting at pentry can work as well.