>> Is it possible to build software successfully with agile processes? Yes. > not really. Until of course your software is simple - ie. 1. doesn't have any sign

>> Is it possible to build software successfully with agile processes? Yes. > not really. Until of course your software is simple - ie. 1. doesn't have any significant internal nor external dependencies being developed as part of the same project/during the same time and 2. any feature can be done by a one "full stack developer". This is false, and I believe you are generalizing your experience far beyond what can can realistically concluded. You experienced a systemic halting of productivity across an organization. That is a very UNIQUE experience. It’s worth discussing, because I don’t think it is clear what happened. your posts are making very broad postulates about agile just not being applicable rather than getting into specifics, and that’s a shame. Software ranging from operating systems, to artificial intelligence, to medical systems, to military systems are being developed with agile software processes. Some of these have higher regulatory documentation and certification requirements than others. Those aren’t incompatible with the agile that I’m familiar with. > Agile/Scrum don't provide for dependencies management, and when implemented thorough and correctly the Agile/Scrum actively and severely impedes dependencies management. Firstly, one team’s use of Scrum might be agile, but Agile is not Scrum. If someone applied Scrum blindly and decided not to include any other processes not in Sutherland’s or Schwaber’s books, or what some coach told your management, that indeed would be risky. Scrum is a rather tepid version of Agile that is incomplete in its description of the practices of successful software development, compared to something like XP, and even XP doesn’t cover everything exhaustively. Secondly, Your point about dependency management is insightful. I think it has more to do with management ignorance about applying Scrum blindly rather than seeing it as a tool in a toolbox. Scrum basically has nothing to say about dependency management. XP has some stuff to say about it, some pretty important insights around continuous integration, but not a ton. This is not to say that dependency management suddenly doesn’t exist or should be banned because an agile author hasn’t said anything about it. Published topics and books need to have boundaries, even though product development itself doesn’t have the same luxury. Various contemporary or follow-on ideas and professional movements such as design structure matrix (DSM), lean product development, API-first design, consumer-driven contracts, continuous delivery, microservices architecture, all have more to say about dependency management. These are not incompatible with agile processes. I don’t think it requires 10x developers to be successful with agile. > The Agile in our case of various mildly to really complex enterprise software projects worked exactly as designed - ie. practically halted down any progress of the projects. The agile in my case is completely foreign to this experience. It involves systems software with millions of lines of code and coordinating across over 80 teams on subsystems, shipping minor updates daily and major updates quarterly. With all shapes and sizes of programming expertise. It is possible, and it is done. If projects halted and weren’t showing progress, there is something systemically wrong in the organization that’s far beyond what’s being discussed here. Sounds like management halted a process that was at least moderately successful and tried to replace it with something incredibly under-baked. Rather than incrementally and iteratively introducing the new process to a set of subsystems, with the ability to use old / proven practices where you had no clear better alternative.