I'm mostly following AGILE, but it's the only software development methodology I know. Do we know what methodologies are used by the AAA guys like EA and Ubisoft? Which ones are popular among indie devs?

Me: solo indie dev with ~20 years of programming experience

I don't have a formal or highly regimented process, but I also work alone so it's less necessary because I don't have to communicate with other team members. The process I use is very similar to 'agile', but I don't really even bother to follow or know exactly what the agile processes are. I just use what works for me. So, here's how I usually do it:

1. Visualize what I want to build and how it should work.
2. Write it down in notepad++ with as much detail as possible.
3. Think about it really hard.
4. Plan out how I'm going to attack the problem. What data structures will I use? What classes will I create? How will they relate to each other?
   4a: I *don't* spend any time drawing class diagrams or any sort of schematics. My philosophy is that if I have to do that, then the problem I'm working on is too big and I need to attack it in smaller chunks.
5. Implement it in code, but cycle between coding and QA very rapidly.
6. QA pass. Does it work? Does it fit the vision? Does it fit the design intent? Is the design good? Is it fun?
7. Completion. Lots of play testing. The play testing will generally reveal some areas to polish, fix or add onto. That returns us to step #1.

These usually happen in relatively short, focused sprint cycles. I think game development is a highly iterative process where you're finding your way through a maze. You can do "big design up front" (BDUF) but it generally doesn't work as well for games? Maybe it does for other more experienced designers and bigger games, but for the smaller indie games, it is hard to design 'fun' and get it right the first time. With larger teams though, you'll need to have a much more focused design effort up front because it is the way you coordinate efforts and communication between team members.

There's agile/scrum, and waterfall, and iterative. Most devs either use one of those, or combine aspects of two or all. If agile is working well for you, just stay with it.

It's not uncommon for different teams in the same company to follow widely different development methodologies (although the many variants of "agile" are definitely among the most popular).

Software development methodologies are a bit like design patterns. Everyone has their own opinions about which ones to use and how closely one should follow them

(I can't play it now for some reason, hopefully I put the right clip on.)

From this session, the team at Capcom mentioned that they started with Agile first in the pre-production/prototype stage. They switch to Waterfall in the full production mode.

In my experience, I don't think I've been on a project that's strictly followed a formal model. Typically it's some iterative stuff during pre-production. Then to actually budget the project you pretend it will be waterfall and draw out the Gantt charts. Then month to month / week to week you do some stuff that riffs off scrum, agile, kanban, etc. And then occasionally a producer reconciles actual progress with that fictional waterfall plan. Each team will usually have a lead directing them in their own style, and a producer overseeing and coordinating the leads.

The project will usually be split up into many milestones (which are tied to payments if the game is being externally funded, to reduce investor risk). 

Planning / communication styles may change depending. On which milestone you're up to, whether you're behind schedule, and whether you're focussed on features, bug fixing, polishing, etc...

I suppose every project I've been on has been true Agile, but only because Agile mostly follows the mentality of "wherever you go, there you are."  The first relationship in the Agile Manifesto is that whatever you are doing that works for you by definition is the right process. If something isn't working for you then you change it, and whatever you change to becomes your new right process.

Different phases of software have different life cycles.  Every major project I've been on since about '93 has followed the model of sprints, usually two or three week iterations. Within that time frame generally developers follow a mini-waterfall: Commitments are made up front, the design for those weeks is made concrete, and implementations are done.  However, due to lack of strict definitions that may not be what some people consider waterfall; if you mean that waterfall requires the full specification of functional interfaces before writing implementation then no, it doesn't follow it. But if you mean a firm commitment to implementing a specific feature set in a fixed time frame, then yes, individual sprints are a waterfall.

Double-checking on the Wikipedia as the fount of all truth, the simplified form of the original Waterfall papers closely models what a single sprint does in most Agile models. The requirements for the iteration are fixed, they're designed, they're implemented, and they're verified. When each requirement is verified the sprint is complete.

It is somewhat ironic that even your original question countermands what Agile means.  You aren't alone with that, it is quite common:

On 9/14/2018 at 3:50 PM, chimchooree said:

I'm mostly following AGILE, but it's the only software development methodology I know.

The Agile Manifesto has four simple relationships. People over processes, products over documentation, the spirit over the letter of the law, and the destination is the goal rather than the path.

Any time someone declares that a process is THE process for agile, they have violated the first relationship.  The process is whatever works for the people, and different people like different processes. Different projects have different needs, different difficulties, different people. 

When describing Agile to people who have had bad experiences or who haven't done it at all, I typically explain it like a large event calendar.  First, people over processes. The organization doesn't care how individual processes take place, if someone uses the writing process described by a specific literature professor for writing the keynote talk, or if catering recipes are cooked in exactly the process specified in a cook book; Instead,the organization cares that people can get their job done.  Second, the organization doesn't care how much documentation or paper-trail is generated, the end result is the large event; if you need lots of paperwork to build the event, do it; if you need very little paperwork to build the event, do it; the same applies for paperwork on software. The third is about ensuring you've got the right solution; everyone knows comic strips and stories where people meticulously followed a specification and implemented the wrong solution; focus on the right solution rather than the specification.  And fourth, the destination is the goal; writing up a path that says the travel time is seven minutes, drive east on center street, then turn north on 7th avenue only works if you're going from one specific place to another and there are no detours; instead state where the destination is and allow everyone to make their own plans and account for detours they encounter; you may point out known concerns like construction taking place on Broadway, but instructions for driving from the west side of the city make no sense for those coming from the north, and neither makes sense for someone taking a taxi from the airport; don't specify how people should write their software, but do specify all the requirements of the final product.

Literature has an enormous body of ideas for processes that work for some people, for some groups, for some projects.  If they work for you, use them. If they don't work for you, use something else.

I'd like to add that, using SCRUM or any other Agile practice does not necessary mean you're using Agile methodology :).

Thank you for all the replies. I guess the main split is between iterative and waterfall lifecycles, and it's popular to adopt Agile's principles. People vary process based on what stage of production or which team they are in.

I guess it's more descriptive to say my process is iterative with week-long sprints. My husband is my project manager, since he has experience. On Saturday, I have a little meeting with him to explain what I accomplished over the week, what went well, and what I struggled with. Then we decide on what I should do next, write them as specific, testable technical requirements and rate them by difficulty. Then, keeping the difficulties in mind, we choose which points I should do over the next week. I'll work on them until Saturday. If the process isn't working for me, I adjust it as part of the meeting in-line with Agile just like frob describes. I've only used this process for a month. On past smaller C# and flash games, I did waterfall.

On 9/16/2018 at 12:50 PM, mr_tawan said:

I'd like to add that, using SCRUM or any other Agile practice does not necessary mean you're using Agile methodology :).

I've been in a couple of industries now, doing Software Development for 20 years, and I've only ever seen an Agile process done properly twice (and as a contractor for most of my career, I've seen a lot of projects in companies big and small).

The most common bits that are dropped are having Use Cases / Use Case Prioritization by Uers and User Testing at the end of each sprint. As it so happens, this is what makes the most difference when it comes to delivering something that actually serves user needs and/or business process needs which in turn is what helps the most to spare everybody the time wasting and all-around frustration of "finishing development and delivering" only to find out you actually haven't and need to hack stuff in, often core stuff.

Meanwhile, ever since Agile became fashionable, pretty much everybody who thinks they "do Agile" does Stand Up Meetings, usually without understanding what they are meant to deliver to the whole process and thus going at it wrong.

Most people don't know what they want until they see it (I've worked in drafting Business Requirements too, and that's my experience) and one - maybe even THE - core benefit of Agile versus Waterfall is that in the former (when done properly) you're quickly iterating with the Users or User Representatives (often Marketing) and converging toward the point that balances what they want, with what they need and with what can be done given the time and technology constraints, whilst in the latter you only find out just how badly mismatched the result is with what it should be at the end of the project.

*sigh*