With waterfall, sure you can get a lot done with a beaming goal post in the distance, but is work done on the wrong things considered throughput? Agile should help resolve issues that crop up along the way, and as such throughput might be a bit less, but the idea is that you can change focus and direction as programs get tested, whereas with waterfall you’ll finish a product fast, only to realize that you have to undo a lot of the work done to get back to a place where you can change it. This grossly oversimplifies the whole process, but that is the ups and downs. The agile upside is better direction and “correct” throughput, at the cost of project visibility into the future.
Depends on how you do waterfall, just like it depends on how you do agile.
With waterfall you can still have all those things agile does, weekly meetings, burndown charts, even sprints. The important thing behind waterfall is that right at the very beginning you have a complete description of everything the program will be doing. When you do the programming, you do all the programming. Once it’s done you test it and make little adjustments where things are going wrong. Once you did the testing, you hand over to the customer and do the next project.
In comparison, Agile asks you to regularly interact with the customer and see if the requirements evolved or changed, things that might happen when the customer sees the application evolve. You don’t do that in Waterfall.
Waterfall can be immensely powerful when deployed under the right circumstances. As does Agile.
I would also disagree that agile gives you more correct throughput, Waterfall can be just as good if your customer gives you a good handover. But this depends entirely on the customer.
Mini-waterfall is agile in the large, and I think mini-waterfall is kinda underrated, especially in teams where the same people work together frequently over a long period:
“We all understand what this is, it’s going to take us 3-5 weeks, we might have a few questions along the way, but it should be done by about October”.
I think we are pretty much in agreement. Waterfall puts a lot of responsibility on the customer knowing exactly what they want and how they want it, and some good architects that can create a specification that matches this. If all that is in order, waterfall should win hands down, and the testing at the end should be minor (some graphical design, a few discrepancies, etc.)
Where agile wins is if this is not the case, which unfortunately often happens. In cases where you are not producing for a customer (such as internal product development), it can also be hard to know in advance how a feature works out and you want feedback early and often. Agile then is better, to avoid working in the wrong direction and “correct the course” often, since there is no “X marks the spot” for crossing the finish line.
I found the analogy to manufacturing kind of amusing in light of the fact that Lean and the Toyota Production System achieved huge improvements by focusing on small batches/single piece flow instead of trying to micro-optimize the efficiency of large batches.
In the industry, you can optimize througput over latency because you produce the same thing over and over again. But in software development, you usually develop something new. If the software you need already exists, you just use it. You need an agile process because you develop something new, and you cannot plan everything ahead of time. Some issues are discovered along the road. Because of this, I don’t think the latency versus throughput trade-off is really relevant here.
And yet, we do reinvent the wheel very often in software development. Sure, nobody writes the same program a million times but there are plenty of programmers who pump out CRUD web apps.
But those CRUD apps are customized, and the customer paying for them may change the requirements. “Develop something new” doesn’t have to mean “develop something revolutionary” or even “develop something novel”, it just means something that doesn’t already exist.
To the extent that most CRUD apps share certain design characteristics, that’s why we’ve got LEGO programming or whatever people are calling it now. But even if you use a bunch of off-the-shelf components the customer can make decisions that result in the need to put the pieces together somewhat differently.
I’m not quite I agree with the assembly-line analogy for non-agile development (waterfall). Because when it comes to development, waterfall is so wasteful. Requirements are written, without ever knowing whether they are useful, complex architectures drawn, without ever knowing whether there are actually scaling issues with the simpler approach,complex implementations pursued over months, without just finding out whether a naive implementation that can be done in 3 weeks might do a good-enough job already. Instead, Waterfall development piles up requirements libraries, architecture drawings, to be implemented later.
The situation you describe may describe the situation for developing the n-th generation of an industrial product. You know the product and its users, you have an idea about the requirements and the technical challenges and then you can map out how a process-efficient implementation can happen. Otherwise waterfall leads to working on suspicion a lot of times. Also, your throughput is zero, as long as you cannot show that your product is working.
So, I think we would need to discuss this while looking at a stacey matrix http://www.barryovereem.com/wp-content/uploads/stacey-matrix-agile.png . In the corner of known requirements and known technology waterfall might be more process efficient, with unclear requirements already, I feel that agile will be more efficient, the situation known requirements with challenging technology I don’t see as clearly in favour of agility, yet there most waterfall process have trouble deriving low-level requirements from their known high-level requirements, which again makes agile the more efficient choice.
Maybe process efficiency needs a closer definition and we aren’t talking about the same thing?
With waterfall, sure you can get a lot done with a beaming goal post in the distance, but is work done on the wrong things considered throughput? Agile should help resolve issues that crop up along the way, and as such throughput might be a bit less, but the idea is that you can change focus and direction as programs get tested, whereas with waterfall you’ll finish a product fast, only to realize that you have to undo a lot of the work done to get back to a place where you can change it. This grossly oversimplifies the whole process, but that is the ups and downs. The agile upside is better direction and “correct” throughput, at the cost of project visibility into the future.
Depends on how you do waterfall, just like it depends on how you do agile.
With waterfall you can still have all those things agile does, weekly meetings, burndown charts, even sprints. The important thing behind waterfall is that right at the very beginning you have a complete description of everything the program will be doing. When you do the programming, you do all the programming. Once it’s done you test it and make little adjustments where things are going wrong. Once you did the testing, you hand over to the customer and do the next project.
In comparison, Agile asks you to regularly interact with the customer and see if the requirements evolved or changed, things that might happen when the customer sees the application evolve. You don’t do that in Waterfall.
Waterfall can be immensely powerful when deployed under the right circumstances. As does Agile.
I would also disagree that agile gives you more correct throughput, Waterfall can be just as good if your customer gives you a good handover. But this depends entirely on the customer.
Mini-waterfall is agile in the large, and I think mini-waterfall is kinda underrated, especially in teams where the same people work together frequently over a long period:
“We all understand what this is, it’s going to take us 3-5 weeks, we might have a few questions along the way, but it should be done by about October”.
That can actually work out pretty well.
I think we are pretty much in agreement. Waterfall puts a lot of responsibility on the customer knowing exactly what they want and how they want it, and some good architects that can create a specification that matches this. If all that is in order, waterfall should win hands down, and the testing at the end should be minor (some graphical design, a few discrepancies, etc.)
Where agile wins is if this is not the case, which unfortunately often happens. In cases where you are not producing for a customer (such as internal product development), it can also be hard to know in advance how a feature works out and you want feedback early and often. Agile then is better, to avoid working in the wrong direction and “correct the course” often, since there is no “X marks the spot” for crossing the finish line.
The irony of his manufacturing analogy is delicious.
I found the analogy to manufacturing kind of amusing in light of the fact that Lean and the Toyota Production System achieved huge improvements by focusing on small batches/single piece flow instead of trying to micro-optimize the efficiency of large batches.
In the industry, you can optimize througput over latency because you produce the same thing over and over again. But in software development, you usually develop something new. If the software you need already exists, you just use it. You need an agile process because you develop something new, and you cannot plan everything ahead of time. Some issues are discovered along the road. Because of this, I don’t think the latency versus throughput trade-off is really relevant here.
And yet, we do reinvent the wheel very often in software development. Sure, nobody writes the same program a million times but there are plenty of programmers who pump out CRUD web apps.
But those CRUD apps are customized, and the customer paying for them may change the requirements. “Develop something new” doesn’t have to mean “develop something revolutionary” or even “develop something novel”, it just means something that doesn’t already exist.
To the extent that most CRUD apps share certain design characteristics, that’s why we’ve got LEGO programming or whatever people are calling it now. But even if you use a bunch of off-the-shelf components the customer can make decisions that result in the need to put the pieces together somewhat differently.
I’m not quite I agree with the assembly-line analogy for non-agile development (waterfall). Because when it comes to development, waterfall is so wasteful. Requirements are written, without ever knowing whether they are useful, complex architectures drawn, without ever knowing whether there are actually scaling issues with the simpler approach,complex implementations pursued over months, without just finding out whether a naive implementation that can be done in 3 weeks might do a good-enough job already. Instead, Waterfall development piles up requirements libraries, architecture drawings, to be implemented later.
The situation you describe may describe the situation for developing the n-th generation of an industrial product. You know the product and its users, you have an idea about the requirements and the technical challenges and then you can map out how a process-efficient implementation can happen. Otherwise waterfall leads to working on suspicion a lot of times. Also, your throughput is zero, as long as you cannot show that your product is working.
So, I think we would need to discuss this while looking at a stacey matrix http://www.barryovereem.com/wp-content/uploads/stacey-matrix-agile.png . In the corner of known requirements and known technology waterfall might be more process efficient, with unclear requirements already, I feel that agile will be more efficient, the situation known requirements with challenging technology I don’t see as clearly in favour of agility, yet there most waterfall process have trouble deriving low-level requirements from their known high-level requirements, which again makes agile the more efficient choice.
Maybe process efficiency needs a closer definition and we aren’t talking about the same thing?