There are many development methodologies for creating technical products such as software applications. Sometimes practices are given a certain label to meet stakeholder expectations but may differ based on the lifecycle of the project. Given the definitions of more precise methodologies, understanding the true nature of these practices can improve project execution.
Bazaar
The Bazaar methodology is often called "semi-organized chaos" in that many ideas are never part of the final product. Bazaar encourages ideas, innovation, and evolution by taking from distinct, often mutually-exclusive ideas when composing a final solution. It is very common in open source projects.
Spiral
Spiral is iterative development and sequential improvement. It is used to identify solutions, analyze risk, develop, and plan next steps. In exploration of the design space, it adheres to constrains and requirements or helps to define them (but not always all). In the eyes of the stakeholder, the spiral methodology reduces risk.
Agile
The Agile methodology is good for refinement, discovering requirements and developing solutions. It delivers product in small chunks of functionality. It gives visibility to stakeholders by breaking up long lifecycles into short sprints. Providing good visibility avoids building the wrong product.
Combining methods
Before discussing other methods, it is important to notice the flow between methods when furthering the project lifecycle.
The methodology used should apply to the lifecycle segment of the product/project. When planning a project, intentionally articulating this transition in the project plan is referred to as "Design for design". For example, a technical project lifecycle may carry as follows: Planning, Analysis (Bazaar -> Spiral), Design Implementation (Agile), Test and Integration, Maintenance.
Now, continuing on...
Waterfall
Waterfall breaks down a product lifecycle into linear sequential deliverables with defined capabilities. It reduces costs in later stages are errors are found early on. Waterfall is great when requirements and scope are fixed. Due to the longer-term nature of Waterfall, it can produce next to no waste (through minimal iteration) or complete waste when the output delivered is not what the stakeholder desires.
Agilefall
To avoid the possibility of complete waste associated with Waterfall, Agile cycles can be added to make "Agilefall". Agilefall is Waterfall with the ability to pivot. It has more frequent checks than Waterfall and provides incremental delivery. With Agilefall, there is very little waste - or at least no complete waste.
Rapid Application Development (RAD)
RAD is nearly synonymous with Rapid Development Methodology (RDM) and is synonymous with Rapid Application Building (RAB). RAD priorities rapid prototype releases and iterations. With RAD, you make something that works and then polish it later. Functionality is priority over performance and code cleanliness. Because of the intent to iterate, functionality may be added or removed. That which remains is polished for production environments. RAD emphasizes user feedback over strict planning.
Ad-Hoc
Ad-Hoc is a lot like RAD, but is more useful at the feature level vs the prototype level. Work is performed without planning. Ad-Hoc is seen as a non-methodical approach. It is great for products that are only built once, but quickly. Like RAD, requirements met minimally. Ad-Hoc is great when the customer calls and says "I need this tomorrow."
Agile-Hoc
Many refer to Agile-Hoc as "Saying you're doing agile but not following the plan" when in reality, it is adapting to refinement and stakeholder priorities within the Agile sprint cycle. Due to its product focus, Agile-Hoc sees the final product as the requirements, making the code the design. Agile-Hoc is a lot like RAD, and eliminates waste by building once and refactoring later. With each reaction within a sprint, it may seem that "Everything is a prototype" - and this perception is accurate until iteration converges on a final solution.