>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".
Agile/Scrum don't provide for dependencies management, and when implemented thorough and correctly the Agile/Scrum actively and severely impedes dependencies management.
>The point is that, blaming agile for your failure is about as pointless as saying agile is a saviour.
I'm not blaming 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.
I'm blaming the people who decided to implement the Agile/Scrum in our company when it is an obviously unsuitable process for any minimally complex projects.
Besides the above mentioned dependency management issue, the Agile/Scrum main effort is directed toward dramatically lowering of the latencies in the dev process (which main effect is totally transparent always up-to-date status - management's wet dream, and boy, did we have it!) while promising bandwidth/throughput (productivity) increase at the same cost (i.e. the same developers/teams).
The fallacy of "it is possible to pick all the 3 at the same time" - the lower latency and increased bandwidth/throughput while keeping the same cost/hardware - would be easily recognized by any normal engineer in the context of a normal engineering problem. Yet when it comes to process management, many otherwise reasonable engineers do unexplainably believe in the pixie dust of Agile/Scrum.
When somebody says "we're successful and we're using Agile/Scrum" it has always (until it is 10x dev case described below) been the case in my experience that hey do have significant deviations from a complete thorough Agile/Scrum implementation and those deviations provide the "breathing windows" which allow for their survival.
Another situation of "we're successful and we're using Agile/Scrum" is that the companies employing "10x" developers, like Google, FB and many well-funded hip startups can allow themselves to decimate the engineers' performance/bandwidth/throughput even by say 5 times (by the combination of factors like open floor office, Agile/Scrum process management, etc.) and they would still be left with effectively "2x" performing developers which still allows to be pretty successful. Similar scale decimation of performance/throughput of a typical "1x" developer at a typical BigCo like say ours naturally leaves you with "1x/5" :)
>> 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.
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".
Agile/Scrum don't provide for dependencies management, and when implemented thorough and correctly the Agile/Scrum actively and severely impedes dependencies management.
>The point is that, blaming agile for your failure is about as pointless as saying agile is a saviour.
I'm not blaming 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.
I'm blaming the people who decided to implement the Agile/Scrum in our company when it is an obviously unsuitable process for any minimally complex projects.
Besides the above mentioned dependency management issue, the Agile/Scrum main effort is directed toward dramatically lowering of the latencies in the dev process (which main effect is totally transparent always up-to-date status - management's wet dream, and boy, did we have it!) while promising bandwidth/throughput (productivity) increase at the same cost (i.e. the same developers/teams).
The fallacy of "it is possible to pick all the 3 at the same time" - the lower latency and increased bandwidth/throughput while keeping the same cost/hardware - would be easily recognized by any normal engineer in the context of a normal engineering problem. Yet when it comes to process management, many otherwise reasonable engineers do unexplainably believe in the pixie dust of Agile/Scrum.
When somebody says "we're successful and we're using Agile/Scrum" it has always (until it is 10x dev case described below) been the case in my experience that hey do have significant deviations from a complete thorough Agile/Scrum implementation and those deviations provide the "breathing windows" which allow for their survival.
Another situation of "we're successful and we're using Agile/Scrum" is that the companies employing "10x" developers, like Google, FB and many well-funded hip startups can allow themselves to decimate the engineers' performance/bandwidth/throughput even by say 5 times (by the combination of factors like open floor office, Agile/Scrum process management, etc.) and they would still be left with effectively "2x" performing developers which still allows to be pretty successful. Similar scale decimation of performance/throughput of a typical "1x" developer at a typical BigCo like say ours naturally leaves you with "1x/5" :)