The development method will say nothing about the organization.
Do not expect method descriptions to provide any details. Rather, you will find details in literature on individual practices.
Organizational designers usually base the organization's development method on the method that the organization will operate under. Often, this is not even a complete development method, but only the practices that the organization will engage in. For example, only practices for system manufacturing, but not for its design. Or vice versa — only design practices, but not manufacturing. Unlike engineers of the target system, who are trained to think about complete development methods (all creation and evolution throughout all projects! Considering what has already happened with the system and its descriptions, and what will happen in the future, including attempts to predict this future!), organizational designers, as well as managers in their conversations with engineers, usually take into account only those parts of the development method practices that are handled by their entrusted organizational unit, which is their "engineered system."
Do not expect development method descriptions to indicate any organizational structure (organigram: who reports to whom, decisions by the organizational designer) or management structure (centralized, decentralized, matrix, functional, etc., decisions by the organizational architect). In other words, the development method will not specify departments or teams. Deadlines will not be specified. However, practices will be specified (primarily disciplines, but also technology will be mentioned).
A development method is the behavior of creators, so it is represented over time: a couple of decades ago, it was a diagram of work stages in physical time, the modern version is a functional diagram linking practices in logical time, and the most modern version is executable options in some tabular modelers, often linked with an issue tracker, which allows to connect process/method/practice development management in real life (lifecycle management) with work management.
When discussing the development method, the question of "who does this" usually remains beyond the scope of the discussion, and resource allocation only arises when discussing work management/operational management. For example, we discuss the choice of the system concept creation practice (practices that will change the states of the system concept alpha), and then we assign tasks for the chosen practice to the organizational unit that has the capability to perform the selected practice (meaning they have people with the necessary skills, modelers with the necessary templates, or from whom these templates can be obtained, as well as authority to spend time and other resources on performing this practice, and all other resources are available). These are two different questions: 1. How will we work and 2. Who will do the work. The work itself only comes after answering both questions!
Physical time cannot be found in development method descriptions, as "practices are performed when circumstances arise." Physical time needs to be observed in work management models (plans-schedules in project management systems, timestamps in issue tracker outputs) of relevant projects, and you won't see this in lifecycle diagrams or practice descriptions.
And if you look at the gradual transition to product line development methods (product lines, sometimes product families, where different system configurations for different needs are assembled from standard modules, and this occurs at several levels of platforms of these product lines), the life cycles of different such platforms as parts of systems or systems in the environment may be intricately intertwined. It is important to always remember that systems are abstracted from the surrounding world subjectively (though this is well-organized subjectivity! Everyone agrees, system thinking is for that!), depending on the concern and preferences in important characteristics of these systems for activity/role/labor/practical areas of interest, thus the selection of a development method as an object from the surrounding world is also subjective. Different people with different experiences will suggest different development methods for the same system and describe ongoing practices in various ways, recognizing different development methods/life cycle models in them.
It is also important to remember that the development method may significantly drift during the project. There will be constant improvement, technologies will be replaced, but at any moment, a transition to new work practices may be initiated — an organization involved in system creation and development will continuously evolve. Organization's development — is primarily changing the development method.
Always remember that there must be the capability to manage the development method: someone::role with tools for modeling methods and skills to do so should design the development method and turn it into a capability (often the responsibility of CTO or CIO), agreeing with all involved. The person responsible for the development method should have the authority to remove employees from the project (or even dismiss them from the company) who do not want or simply cannot work according to the practices of the chosen development method. If an engineer considers that they are working in a "waterfall" approach in a team that adheres to some flexible development methods, then they either conform and also work according to the proposed flexible development practices, or simply resigns (convincing may take longer and be more expensive: they will have already caused a lot of harm with their seemingly good work, as there will be many configuration clashes that will require many other engineers to spend time dealing with their stubbornness and incompetence. It's easier to fire them, and it's the right thing to do: let them improve their qualifications on time).
Make sure to understand not only the development method of the target system, your system somewhere in the creation chain, but also of their supra systems, and of the creators systems (that is, the development methods applied by external project roles in projects creating all these systems). Both the target system, neighboring systems, and systems in long chains of creation should be in focus. Coherence in maintaining this attention, including coherence provided by documenting models of all these mentioned systems, including modeling of development methods and included practices. Do not rely on system thinking "in the mind," rely on thinking through modeling and writing!