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?

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.

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*