Trying to get what are now called agile practices accepted by management was a big thing. It was transformative to management.

Before about 1995, there was a huge disconnect between what the software development groups wanted to do and what business executives wanted to do. In many (but not all) of the big established businesses, the corporate leadership had roots in older styles of development.

Many business executives in the 1980s and early 1990s watched software development patterns from the 1950s and 1960s. During that era computer time was far more expensive than human time, so it was cheaper to have a system of expert programmers who carefully built the entire design on paper, and only after the paper-based design was completely functional go about the task of encoding the software for the machine.

Of course, systems were much simpler back then. The full design for major operating systems were small books of 200-300 pages. Those few pages documented every function, their parameters and results, and the precise tasks the function would perform.

Since that is what the management was familiar with, that was the process they used. Specify a design, have experts build every detail of the design, re-approve the design, then have the grunts encode the design. It works for building architecture and manufacturing very nicely.

The major methods that management was willing to accept were the full-blown 'waterfall' method and iterative mini-waterfall methods. There were prototypes (basically two waterfalls), spiral development (lots of little waterfalls) and the Big Design Up Front mega-waterfall. Some had more iterations than others, but the methodology was basically the same. Management stated what they wanted, experts built the blueprints that specified everything, management approved the blueprints, then the grunts implemented it.

The ideas covered in the linked-to book and several others were good ideas that were practiced at some places, but the concept that you could continuously change direction mid-project was fought hard by some management groups.

Many of the early ideas have seen modification, but overall each of them persists. Pair programming was thought to give instant feedback, but it was expensive. In some businesses where the risk is high and human costs are relatively low, pair programming makes a lot of sense. Government work in particular, where paperwork and verification plans are often 4x the work than the acutal coding, having two or more people doing the code together works well. For games a much shorter buddy check can also suffice. Automated unit tests are a part of agile, where the unit tests can detect errors within minutes of the error being introduced. When the cost of writing a module is 100%, the cost of writing a module plus unit tests for the module is roughly 180%. The benefit of unit tests comes on the long tail of maintenance and support, so new code and modifications can be instantly regressed against an entire code base. For most games on an annual or bi-annual release cycle the cost of unit tests for game code usually does not quite reach the point of cost effectiveness; it is cheaper to buy a bunch of QA hours rather than the extra roughly 80% cost to co-develop automated tests. For many persistent systems like game servers and engines the unit tests can make sense, and for small libraries they nearly always make strong business sense, but for game code the practice doesn't make economic sense. Some libraries have a long development tail and are shared company wide, bugs can impact many teams, so unit tests for shared corporate libraries makes a lot of economic sense. Scrum meetings, 2-3 week sprints, acceptance tests, owner signoff of specific features as they are completed, they all grew out of a common movement.

It took about ten years or so for most industries to convert. Some industries are still slowly moving over.

The idea that programmers could be given a vague direction and then the software API could naturally emerge can feel very risky in the business-oriented mind that is used to specifying policy and procedure and having the peons follow it. When the management teams were used to building a perfect blueprint to verify the requirements, moving to systems that specify only the verification requirements and not specifying the blueprints feels risky at first. Blueprints encode the implied details that were not specified. It can take a while to learn how to specify all the important details and to leave unspecified the unimportant details. Many management teams still resist the change.

I happen to be a technical-savvy kind of manager (don't misunderstand this as a gifted programmer, which I'm not).

I've applied some Agile methodologies, namely Scrum and Scrum-ban (along with a variety of systems derived from their principles) to over 20 projects. They have led me to the following conclusion, which I've applied as my general rule-of-thumb when preparing a new project:

DO WHAT WORKS.

The upside of agile methodology in a game development environment is that you leverage the latent ownership of some team members to effectively delegate responsibilities to people that are willing to do so. You basically give seasoned and socially-apt veterans a chance to 'change the way it works' and avoid pitfalls that a 'green' manager would obviously step into saying something like 'we'll get through this, trust me'.

Some people have these talents, others don't. If your team has a lot of these 'leaders', agile makes sense, and generally leads to a better work environment.

If your team has a lot of skilled people with no ownership, then you're better off circumventing these methods and fallback into waterfall if you feel you have the better lead.

Also, some project, despite having a team filled with leaders, simply won't work. Agile methodologies attempt to minimize risk in a high risk project. If there are few unknowns (a project that feels like a reskin for example), there's hardly the need to risk-manage at the extreme, and waterfall will do just fine and oftentimes will minimize the amount of meetings required, which the team will also appreciate.

Though I was originally hesitant to break the rules of the agile manifesto, I now fully understand that it is a framework which you need to bend to your will. No one will point fingers if you break the rules and make it work, but everyone will blame you if you can't make agile work, so better off finding something that works.

So, like I said, DO WHAT WORKS. The agile manifesto just brought forwards a few tools you can use which could essentially be summed as 'how much can you trust/rely on your team?

EDIT:

In servicing, specifically, it is very hard to make agile work because the product owner (often internal) must deal with the client (external) which has no idea how agile works and doesn't give a ****. The single most important role in agile (and often forgotten) is the P.O. If the Product Owner can't have his way, or doesn't know how the system works, then all goes to hell very quickly.

Recently, I've been appointed a P.O. that didn't know *** and didn't care. I wouldn't know where to begin to explain the mess that this caused (and obviously, the 'system' (Scrum) got the axe as a result, though that was largely a misguided choice in that specific context).

When I worked at a project with my colleagues back at school we did "agile programming" without knowing it. We basically tried out new things all the time, implemented every new idea, set up weekly meetings and couldn't really decide who is in charge. Now that this procedure actually became a thing people want to encourage and implement worries me.

I worked in an environment that tried to apply agile. So what we got was a huge pile of code with lots of remains of former approaches that (understandingly) nobody dares to touch because it might break something. After every new change some other feature didn't work anymore so we worked a lot on making work what's already there with those new requirement (which came in all the time). Literally nobody in the company knew exactly what this stuff does and there was no documentation or even sane naming of code-components (of course if a feature gets re-branded on a weekly basis it reflects in code and nodody remembers or can make sense of changes of each iteration).

However (not software or even tech-savvy-) management didn't care because they asked for a feature and got it in a short period of time. They didn't know nor understand that this made parts of the codebase unmanagable and that feature x and y didn't work anymore since nobody tests thoroughly (how could they? Deadlines are ridiculously short and once it's "done", there's the next requirement). And if it comes up: oh well, guess I just found another bug. We actually had a lot of inside jokes that came up just by looking closely to all of these functions and that ridiculous amount of unnecessary or even unpurposeful loops.

Deadlines were always set and treated as important yet almost every deadline was exceeded and this became mutually accepted.

So does this mean that agile is bad? Even though it was bad in this case I wouldn't necessarily say it's bad. It worked very well back in the school project. Why? Because back then it was used as a kind of prototyping just to so see what we can do. There was one fixed deadline and once we got closer to the deadline we stopped implementing those crazy ideas and began documenting. However in that company it became a vicious never-ending circle of bad code.