1

First of all, I found it a bit strange because technically, iterative means something that is done as a recurring series of steps - so how can one be purely incremental, when each increment will be implemented through the same series of steps?

Anyway, my main confusion stems from the word "iterative" - if the meaning is enahnced to mean "refining and revising work", where does it fit in the classical story development scenario: you develop story B, and once it passes the tests and meets your DoD and Acceptance criteria, it is Done. You added it on the top of the existing baseline. In the mean time, some other stories are finished, ideally Done and hence certainly not meant to be refined or reworked... Where is the iterativeness?

So, to me it does not seem different from the decades old incremental models (which some claim are examples of Agile models, some say they are not). Just developing features one by one, with early testing and frequent delivery of working increments.

Another interesting point: Agile is apparently said to be "one of the incremental models". However, incremental models are defined by quite a comprehensive upfront documentation...

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
JCerm
  • 37
  • 2
  • 2
    `However, incremental models are defined by quite a comprehensive upfront documentation...` -- Can you clarify this statement, please, perhaps with an example or description of the documentation you're talking about? – Robert Harvey May 02 '21 at 17:27
  • 2
    I find your question hard to understand. You ask about the meaning of certain terms, but you don't give us a lot of context where they are used. E.g. "Agile is said to be iterative-incremental". Who says that and what is the exact phrase? – Helena May 02 '21 at 18:27
  • 1
    Oh come on, he's not asking a complicated point. He simply asks, how does the jargon of something being "done", and a picture of accretion, reconcile with an iterative principle in which a system is (potentially) never finalised and always subject to revision? – Steve May 02 '21 at 18:44
  • 1
    Your question would be a better one if it were more about the SDLC and less about word definitions. – Robert Harvey May 02 '21 at 19:30
  • @RobertHarvey, it seems reasonable to ask clarifying questions about the language that is used to describe and discuss the SDLC, in order to clarify what the development process actually involves. I don't think this question is asking about spurious distinctions between words, but fundamental questions such as how Agile differs from predecessor methods, or how the Agile tenet of iterativeness and capacity to review progress and 'change course', is reconciled with the finality implied by things being "done". – Steve May 02 '21 at 20:11
  • `but fundamental questions such as how Agile differs from predecessor methods, or how the Agile tenet of iterativeness and capacity to review progress and 'change course', is reconciled with the finality implied by things being "done"` -- Those are fair questions. Why don't you ask them instead? You can get really good answers to questions like that without quibbling over the finer points of word definitions. – Robert Harvey May 02 '21 at 20:16
  • If it is so many questions, it should probably be split into multiple posts. If the question is mainly about comparison to a previous methodology, I think it would be good to explicitly name the methodology. – Helena May 02 '21 at 20:35
  • @RobertHarvey, I thought it was just paraphrasing what he had *already* asked in his second paragraph. That's why I interjected to say "come on!". – Steve May 02 '21 at 22:17
  • @Steve: Sorry, I though you were the OP. In all fairness, if that's what the OP wanted to ask, that's what they would have asked. But they didn't ask that; instead, they got stuck on word definitions, some of which they don't understand, others which don't actually exist. – Robert Harvey May 02 '21 at 22:56
  • 1
    @RobertHarvey Sorry, but what definitions used don't actually exist? I can agree with all of them. The incremental model is an SDLC variant of splitting requirements, it has nothing to do with agile per se(https://www.javatpoint.com/software-engineering-incremental-model) – John V May 03 '21 at 06:08
  • @JohnV: I still think you're spending too much time on terminology, and not enough time understanding what that terminology is trying to tell you. – Robert Harvey May 03 '21 at 14:38

6 Answers6

6

It seems like you are mixing several things together, which is why you're confused.

Iterative and incremental development refers to how the system as a whole is built. Contrast typical methods that are associated with Agile Software Development and associated techniques and principles like incremental design, YAGNI, and refactoring with "waterfall" techniques that embrace getting all of the requirements upfront, then spending time architecting and designing for all the requirements, then spending time turning the design models into code, then integrating and testing the system. Instead of trying to do everything for the whole system up front, you'll be repeating the activities for each slice of the system.

When you look at individual units of work, just because you've developed, tested, and shipped something doesn't mean that you won't revisit it. There are a few different reasons why you may need to. One would be that you get feedback that what you built is no longer quite right and you need to revise that feature. Or perhaps you are building a related feature and need to revisit your design decisions to support both, yet keep a maintainable system. Maybe the team's technical maturity grows and an evolving Definition of Done means that there's now technical debt to be resolved.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • Thanks, yes it could be because I look at the low level only. But then how is that different from incremental waterfall? Even in that case, with clearly defined scope and just delivering in pieces, I will be repating the steps for individual slices (though not really for requirements). – JCerm May 02 '21 at 17:52
  • 3
    There's no such thing as "incremental waterfall." – Robert Harvey May 02 '21 at 19:29
  • 3
    @JCerm I have never heard of "incremental waterfall". I'm aware of a few "modified waterfall" structures, like the sashimi model where the phases overlap slightly (such as starting design before requirements are finished), waterfall with subprojects (where you collect the system requirements, but allocate more detailed requirements as well as all downstream work to subprojects, until integration). Incremental seems to be the exact opposite of waterfall. – Thomas Owens May 02 '21 at 20:08
  • @RobertHarvey Of course the Incremental Waterfall exists. Please do some research before stating such claims. From the book Beginning of Software Engineering (Stephens, 2015): "The incremental waterfall model (also called the l multi‐waterfall model) uses a series of separate l waterfall cascades. Each cascade ends with the delivery of a usable application called an increment." – John V May 03 '21 at 06:14
  • @ThomasOwens Pls search for "incremental waterfall", there are many mentions also in the books available online. Why would it be the exact opposite - you still have a complete set of requirements, the only difference is that you repeat the cycle for a few increments, instead just once. – John V May 03 '21 at 06:20
  • @RobertHarvey Some more detailed info about the Incremental waterfall and other alternate models: https://doit.maryland.gov/SDLC/Pages/archives/altMethods.aspx – John V May 03 '21 at 06:42
  • @JohnV It looks like "incremental waterfall" is just "waterfall with subprojects", but the subprojects don't happen concurrently. I wouldn't call this "incremental" because it's not incremental at all phases/activities. The Maryland page, for example, says that the first three to four phases are done sequentially, which seems to go much deeper than just requirements before splitting off to subprojects. I'm not sure how you can justify calling a model "incremental" when so much of the requirements and design are done up-front. Only the construction is incremental. – Thomas Owens May 03 '21 at 09:17
  • @ThomasOwens I think it is slightly different in that there is no integration at the end. In the end, what they call the incremental waterfall actually matches the simple incremental model - if you know exactly what needs to be built (proper requirements...), you can simply plan all the work, assign it to increments and start working. This approach is quite common in large companies delivering against fixed constracts. Some of them call themselves agile...Anyway, I think it truly depends on how you understand incremental. As you say - in this model, only the construction is incremental.. – John V May 03 '21 at 09:58
  • @JohnV: Kudos for finding a reference or two for "incremental waterfall." First time I've heard of it. But it's not a new idea. The technique of taking a large project and breaking it down into smaller steps has been around since people discovered fire and began making stone tools. – Robert Harvey May 03 '21 at 14:37
  • @RobertHarvey No problem, I also learned about incremental waterfall just a few years ago. And honestly to me it seems a reasonable "hybrid" - in fixed contracts, you at least internally develop in smaller increments to maintain the feedback loop with your testers and hopefully some customer representative, even though you deliver all later on a release date. At least, that is how we leveraged that, and IMHO it is just common sense of derisking. Add standups to improve communicatio... – John V May 10 '21 at 08:13
2

You're right that agile software development is not necessarily radically different from other software development approaches. The “radical” idea in agile is to Do Things That Work, which usually means adapting the process to make it work better, and to listen to the people doing the work (“people over processes”).

Under the agile umbrella, we have specific process methodologies such as Scrum. Scrum is definitely iterative and incremental, and suggests feedback loops of various levels. In a typical instantiation of a Scrum process, you'd see feedback loops like the following:

  • retrospectives
  • sprints
  • standups
  • TDD red/green/refactor cycles

In Scrum, the main feedback loop is the sprint. Each sprint has a defined duration and defined scope. At the beginning, we determine some tasks that should be Done during the sprint. At the end, we see what was Done. Did some things fail to get Done? During the retrospective, there's opportunity to understand why and adapt as necessary for the next sprint. Then we repeat. Since we might adapt between each Sprint – and in particular, the Product Owner may change priorities based on the experiences – it is not appropriate to plan in advance multiple sprints. One step at a time.

You are entirely correct that individual tasks (backlog items) in Scrum are not handled in an iterative manner. A task is either Done or it's not. This is considered important in order to manage clear expectations with the Product Owner, but also to demonstrate clear progress to the PO.

The entire point of Scrum is that many projects do not make clear progress because a lot of tasks are only mostly done. This delays value, and makes it difficult to close feedback loops. The idea is that with Scrum, there will be something Done each Sprint, thus delivering clear and predictable value to the PO. And since the PO can re-prioritize between Sprints, this maximizes the value delivered across the project duration.

When you say “incremental models are defined by a comprehensive upfront documentation” then this is wrong. There are processes without a focus on documentation that are clearly incremental, such as Scrum. It's also perfectly OK to prepare lots of upfront documentation in an agile project, if that documentation has value (though in many cases, a Spike is more useful to find a good design than to do lots of upfront analysis). This circles back to my original point: agile is about finding a process that works. In this viewpoint, being agile is about values that inform how you select and implement processes, and are not an inherent attribute of processes themselves. (Indeed, most Scrum instantiations are probably not agile in any meaningful way…)

Iterative/incremental processes were pioneered in environments with very high integrity requirements and thus a focus on documentation and testing. In particular, some incremental processes involve an entire Waterfall-like process per increment, including analysis and design phases. This isn't wrong, but this also isn't the defining feature of iterative/incremental. The defining feature is that functionality of the project is split across two or more increments, thus de-risking the project and allowing for early feedback to be integrated. This is broad enough to cover both defense projects that start with a 1000-page requirements document and a three-person web consultancy doing Scrumban.

amon
  • 132,749
  • 27
  • 279
  • 375
  • Well, all definitions of incremental models state they are require detailed upfront analysis because all you do is breaking down the scope to a smaller chunks, which is not exactly what Scrum does, because the traditional incremental model is often referred to as the "incremental waterfall". Also I think you have not addressed how this iterativeness is then reflected in Scrum. – JCerm May 02 '21 at 17:32
  • 2
    @JCerm: Can you provide a citation for this? This is actually the first time I've heard this assertion. Every Agile team I've worked in (including the current one) has started with a simple "wish list," and refined requirements as work progresses. None of them started with a detailed upfront analysis; you're describing *waterfall, not agile.* – Robert Harvey May 02 '21 at 17:35
  • @RobertHarvey Could be found in varous Google books, but this one is the simplest one I could find: https://www.guru99.com/what-is-incremental-model-in-sdlc-advantages-disadvantages.html The incremental model is typically used when requirements are well defined and well known. You then merely de-risk the project by breaking down the scope into increments, which is why I believe those who distinct between incremental model and Agile are right. – JCerm May 02 '21 at 17:39
  • @JCerm: OK, so basically your question is *not* about Agile then, correct? – Robert Harvey May 02 '21 at 17:42
  • @JCerm The opposite of “iterative/incremental” is “linear”, the opposite of “agile” is “prescriptive” or “process-driven”. While specific process models that bill themselves as “iterative” are likely high-ceremony (otherwise they'd call themselves agile), this doesn't imply that agile can't be incremental. There's consensus across the industry incremental approaches are safer in most circumstances since they aid with de-risking. In my answer, I clearly show that Scrum's sprints are an incremental way of doing projects, even though there's no mini-waterfall. – amon May 02 '21 at 17:43
  • 1
    One of the more well-known incremental process frameworks is IBM's rational unified processes. Of course RUP allows for mini-waterfalls and lots of ceremony. After all, IBM is a consulting shop. They don't make money by delivering value, they make money by spending billable time. – amon May 02 '21 at 17:45
  • @RobertHarvey No, it is, because the inconsistency in terminology and understanding is ridiculous - some say agile is the incremental model, but that is not true (at least from engineering perspective). So all the companies that believe they do Scrum (typically with fixed scope contracts), are indeed just using the incremental model with agile practices. – JCerm May 02 '21 at 17:45
  • @JCerm EXACTLY people use terms in an inconsistent manner, which makes such terms less useful. Some people are prescriptive and say incremental process is only when you do X, Y, Z. My answer is more descriptive and says the unifying characteristic of incremental models is when you have increments. – amon May 02 '21 at 17:47
  • @amon I get that, I just do not see where is this iterativeness. The incremetnal part is clear, but there is the same iterativeness as there is to the incremental waterfall: i.e. a you repeat the cycle for each sprint and for each story. – JCerm May 02 '21 at 17:47
  • *"this maximizes the value delivered across the project duration"* - it's not immediately obvious why designing a project schedule in which there are fewer outstanding tasks at once, should "maximise value", particularly given the latitude available to project managers to (a) jig the design and arrangement of all task content to suit the prevailing diktat about how many tasks should be seen to be outstanding at once, or (1/2) – Steve May 02 '21 at 19:11
  • to (b) prematurely treat as complete tasks that are in fact latently outstanding, and whose unresolved subject matter will later be revisited but then presented falsely as a new task (just as the first task was falsely presented as complete). (2/2) – Steve May 02 '21 at 19:12
  • @Steve In my answer I discuss Scrum as defined in the Scrum Guide, not Scrum when it meets reality :) You are right that in reality, a lot of stuff will be less than Done. But the *idea* is that all interesting projects are *uncertain*. Scrum says you shouldn't plan far ahead, but always do the best thing based on the currently available information. So if you're doing a thing that doesn't deliver value, you'll stop at the latest after a sprint – and not continue because the Upfront Plan said so. But gaining new information requires closing the feedback loop, which requires getting stuff Done. – amon May 02 '21 at 20:00
  • Of course, the Sprints are a pretty artificial framework. It's nice to have regular intervals to reflect and adapt, but they're not directly helpful in closing the feedback loop and keeping the feedback loop small. Thus, approaches like Kanban can be systematically superior, since they have a stronger focus on minimizing cycle time and continuously improving the process. Faster cycle time means faster feedback means better decisions means more value in the same time. Constraints like a sprint velocity can be helpful to get started with getting stuff Done, but that's not the goal. – amon May 02 '21 at 20:03
  • *"In my answer I discuss Scrum as defined in the Scrum Guide, not Scrum when it meets reality"* - it must be very confusing for a software outsider to be confronted on the one hand with a description of the development process that doesn't correspond to reality, and on the other hand for the *real* development process to go undescribed. I wonder why and how the two things differ, and what function does the unreal description perform? – Steve May 02 '21 at 21:38
  • *"you shouldn't plan far ahead ... if you're doing a thing that doesn't deliver value, you'll stop at the latest after a sprint"* - doesn't that assume it is always immediately obvious what does and doesn't have value? I would imagine that in most death march projects, it only becomes clear after completion (or at the point of cancellation) that the project yielded no value - there was never a prior point at which managers with the power to cancel the project, actually had zero confidence in the value, and yet marched on, on some silly principle like 'I've started so I'll finish'. – Steve May 02 '21 at 21:53
  • 1
    @JCerm the guru99 article you linked to is not very well written; e.g. the advantages/disadvantages section directly contradicts itself on each line, as well as things previously stated in the text. – Filip Milovanović May 03 '21 at 05:38
  • @FilipMilovanović I do not think so, I can see it is a standard description of the incremental model (which has not changed much during the last 60 years or so). – John V May 03 '21 at 06:24
  • @JohnV There are problems with it. I don't mean so much with the definition, that's mostly OK (although it gives an impression of a structure that's a bit too rigid), it's the sections below that are either too handwavy or questionable. – Filip Milovanović May 03 '21 at 08:17
  • @Steve (1) Re Scrum in theory vs practice: Real-world scrum is messy and full of antipatterns. In the context of this question, sticking to its definition is simpler. (2) You've hinted at one problem with Scrum: it assumes that the Product Owner can accurately judge value. But when PO is also a manager, priorities can get skewed. There is no process against dysfunction. I think closing feedback loops is more important than special processes. [Gitlab recently had a nice blogpost about this](https://about.gitlab.com/blog/2021/04/30/why-its-crucial-to-break-things-down-into-smallest-iterations/). – amon May 05 '21 at 14:02
1

I think your confusion stems from what you associate the word "incremental" with; I get a feeling that you're thinking about rote accretion of features (software simply growing by addition of new things, and piecewise delivery). That's not what's meant - it's about design, about deciding what to build and how.

The problem with waterfall is "big design upfront". This may work when the problem domain is very well-understood (e.g. there are years of research, how things work and interact is known, there are standard time-tested practices, etc.), but it's not iterative or incremental in the sense that pretty much everything is decided upon and specified in one phase. (Now, you could call it incremental in the sense that you're probably building it in multiple steps, in an additive process, but that's not in itself especially interesting.)

Agile recognizes that in many cases for business applications the problem domain is either sufficiently unique or isn't well-understood (in the above sense), and that doing "big design upfront" when you don't know enough about the subtleties of the domain leads to expensive projects that in the end don't do what clients wanted (you build "the wrong thing"), or do it poorly - assuming they weren't overly ambitious and were successfully built at all.

So agile opts for "some design upfront", and then some more design at each iteration, as the developers learn more and get feedback. Agile is trying to hone in on a good solution over time, starting small and retaining design plasticity for longer. Another aspect is that agile tries keep the product useful/usable at every iteration. It also strives to learn what the most important (core) aspects of the system are, and tries to push those to be implemented first (or as early as possible). This combination reduces the risk for clients because they can stop the project when they feel is appropriate (e.g, when they reach the point of diminishing returns, or when they run out of budget), and still get the most value out of it - they still end up with software that is actually useful for them. (Note that there's a business aspect to this as well, you have to have a business model that can support this approach; e.g. you can't have scope, cost and time all fixed, etc.)

The revising aspect is going to come from the the project team developing a growing understanding of the domain, and from frequent feedback - from uncovering new things, or identifying what was misunderstood from (or misspecified in) the requirements, or what was assumed and never explicitly said, etc. It's the moments that make you go: "Oh, so that's what you actually want!", or "Ooooh, this process actually works like this!", or "So, when you say 'shipment' you don't mean the same thing as when your colleague from a this other department says 'shipment'???".

So it's really about incremental delivery of value (clients find product usable/useful in some way after every iteration), and the ability to learn and revise on the go. (Or, if you want to say it differently, it's about being incremental and iterative simultaneously - which then implies that you have to be incremental in the particular way described).

In contrast, a waterfall project might spend a long time in a half-baked, work-in-progress state, and can proceed for a long time before any feedback is provided (or even possible).

Filip Milovanović
  • 8,428
  • 1
  • 13
  • 20
1

Your story meets the acceptance criteria, so it’s done. You will never, ever go back to that story. Absolutely right. That doesn’t mean you never change the code, and you never change the application.

Say your acceptance criteria said there must be a green button on the screen. You do it, QA checks the button is green, story is closed. Next day a customer complains: The button should really be orange. Yes, they said “green” in a meeting, but now they want orange. You don’t re-open the closed story, you don’t re-visit the story. You create a new story “button should be orange, not red”.

You refine stories that are not closed yet. Once the story is closed, it doesn’t get refined anymore, a new story is created or another story is modified.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
0

Incremental

so how can one be purely incremental, when each increment will be implemented through the same series of steps?

A dictionary definition will help here:

Increment - NOUN
An increase or addition, especially one of a series on a fixed scale.
‘all sizes from 4–30 mm in 1 mm increments’

In terms of software development, "incremental" is taken to mean "not all in one go". It is the antithesis of "if you build it, they will come", and it's more akin to "build what you need, don't build for possible future versions".

It means that if your application has a FooService class, that there is no expectation that someone will spend X time making the entire FooService class (let's assume it has features A, B, C, and D), at which point it is considered "finished".

Instead, someone working on task 1 might create a FooService class because they need the A feature, so they develop only the A feature. Then, at some later time, someone working on another task finds themselves in need of a B feature, and FooService is the right place to put it. So now, they develop the B feature. At another point in time, someone might need a D feature, so they add it. Maybe after a while, you notice that B's implementation was very simple but because it is now being heavily used, it needs to be more robust, so you upgrade B to B2.

Little steps, one after the other, as opposed to knowing precisely what you're going to build = incremental development.

If an analogy helps: if you're expecting to hold a blueprint of the entire house before you start building it, you're not doing incremental development.

Iterative

the word "iterative" - if the meaning is enahnced to mean "refining and revising work", where does it fit in the classical story development scenario: you develop story B, and once it passes the tests and meets your DoD and Acceptance criteria, it is Done. You added it on the top of the existing baseline. In the mean time, some other stories are finished, ideally Done and hence certainly not meant to be refined or reworked

If you look at a particular feature in your software (let's call it A), that was probably created because of a story.

But when that story is done, that doesn't mean that you will never touch A again. A new story might be written, which brings some requirements that lead to A needing to be changed, extended, or even made obsolete.

some other stories are finished, ideally Done and hence certainly not meant to be refined or reworked

A story should be finished and then not touched again. But the source code that was related to that story doesn't get that same expectation. Just because these lines of code were related to story A doesn't mean that there isn't (or won't be) a story B which also influences what this code does.

Stories are rigid, and will be finished and done with. The code that was written for that story, however, is a living entity which should gradually be changed/updated to keep adapting to the ever-changing needs of the application.

Agile

So, to me it does not seem different from the decades old incremental models (which some claim are examples of Agile models, some say they are not). Just developing features one by one, with early testing and frequent delivery of working increments.

There is a difference between developing one step at a time, and planning development one step at a time. Agile pushes more towards the latter, more so than older models.

The goal is to not be waterfall, i.e. not trying to immediately build a comprehensive solution. People are notoriously bad at guessing the future, and waterfall specifically asks you to guess what you will need for the foreseeable lifetime of your application.

The odds of you spending time and effort building something that you end up not needing, or needing in a different way than you once anticipated, are so high that it makes the initial effort (and mental load that accompanies it) not worth it. At least, according to Agile.

Keep in mind that what I describe here is how Agile sees the world. Not every model works for every scenario.
I've worked on software projects involving major infrastructure safety, and the waterfall model is paramount to ensure that all involved parties are interacting with each other correctly, down to the strictly versioned chipsets in each PLC controller.
It leads to a more rigid process and severely decreased flexibility in development, e.g. you're not allowed to quickly update the chipset's functionality, but when peoples' lives (and billions of dollars in repair costs) are at stake, flexibility is not the most important priority.

Flater
  • 44,596
  • 8
  • 88
  • 122
  • *"when peoples' lives (and billions of dollars in repair costs) are at stake, flexibility is not the most important priority"* - you seem to be suggesting that Waterfall is still king whenever the stakes are high. But isn't Agile - according to its proponents - also supposed to *reduce* the risk of massive or serious failures? Or is it more along the lines that Waterfall poses the risk of delivering a working system that is no longer required by the time of delivery - Agile reduces the risk of this, but also increases the risk that the system will contain *design faults* for lack of planning? – Steve May 03 '21 at 09:07
  • @Steve: Agile does not reduce risks, it minimizes the size of the issue when one arises **from a software perspective**. Agile makes smaller increments than waterfall, so if an update breaks something, it will on average break in a smaller way. However, very much mind the bolded part. In large infrastructure, a small software change can have a big consequence. My favorite example: fire in tunnel. Fans should direct oxygen away. The direction a fan blows in is decided by a single bit. Wrong bit? You've just aimed an industrial, tunnel-sized flamethrower at the incoming firemen. – Flater May 03 '21 at 10:33
  • @Steve: For more context, because many different companies are involved in a large infrastructure project, this means that everyone must have their (literal and figurative) wires matched up. To ensure that everyone is on the same version, every document must contain the checksum of the version of the analysis which they were relying on. You literally cannot even correct a typo in the analysis without altering the checksum, and thus requiring an entirely new version. Very slow, not flexible at all, but massive in terms of security and clear communication across many channels over the long term – Flater May 03 '21 at 10:37
  • How do you tell the difference between an instance of your "fan control" system that requires Waterfall, and other systems (of lesser importance) that can abide Agile? My experience of most core business systems, is that they are regarded as "fan control systems" that coordinate massive amounts of resources, no part of which can be turned off or operated independently, any disruption to the delicate arrangement of which will haemorrhage cash. Few systems are regarded as low stakes or severable, because making software is far too expensive for things that don't really matter. – Steve May 03 '21 at 11:23
  • @Steve: If a mistake can cause death, grievous bodily harm, litigation, bankrupcy-inducing costs for a company (which is "corporate death"), ... they must be safeguarded against. Those safeguard come at the cost of rigidity. In essence it's a matter of **business priorities**. But this is a very subjective scale. I've seen _tons_ of managers think of their project as "essential", making broad-sweeping rigid frameworks to ensure them, and end up hemorrhaging budgets left, right and center because they overestimate the importance of their project. [..] – Flater May 03 '21 at 11:27
  • @Steve: [..] Conversely, there are also those who undervalue the importance of a project, leading to no real quality control, which also hemorrhages budgets with never-ending bugfixing. There is no objective measure or one-size-fits-all solution to this. All business ventures have some degree of risk to them. Both risks and risk preventions tend to cost money and effort (which is salary, which is money). The key is figuring out which is going to cost you less money overall (and of course additional ethics such as not killing people, where applicable) – Flater May 03 '21 at 11:30
  • @Steve: For example: should cars be built with bulletproof glass? It increases the cost of production, and adds some value, but will the added value increase sales enough to offset the cost of production? If you're making small city cars, probably not. If you're making trucks for the military, probably yes. – Flater May 03 '21 at 11:32
  • Would you agree then that most businesses are virtually incapable of assessing whether a particular project is crucial, or estimating what sort of budget is necessary to ensure that a crucial project succeeds, and therefore are incapable of choosing systematically amongst various processes and frameworks which have different tradeoffs? Essentially, it is all just a case of digging for gold in the hills - maybe you win today, maybe you fold, and everyone peddles his own astrology and superstitions about what promotes success? – Steve May 03 '21 at 12:00
  • @Steve: You're breaking open a massive discussion which strikes at the core of how to run a business - this is not a development-related topic anymore. From a development perspective, the business priorities are set in stone, which in turn sets the stage for considering whether agile or waterfall is the better approach. Anything beyond that point is purely contextual (business case) _and_ subjective (risk strategy). – Flater May 03 '21 at 12:04
  • Well I'm trying to clarify what the comparative benefits are of each development process. It doesn't seem to me that the business would have any hope of deciding, if it doesn't know what the features of each process actually are, and *how* to decide - what advantages and disadvantages each actually provides. That's why I found it interesting when you said that an Agile process is found to be intolerably unreliable for systems that actually matter. – Steve May 03 '21 at 15:11
  • @Steve: _"Well I'm trying to clarify what the comparative benefits are of each development process."_ This is (a) not the question being asked here and (b) has been asked and answered before on this site. (c) _"when you said that an Agile process is found to be intolerably unreliable"_ I said no such thing, I just said that its benefits (flexbility) aren't always the main priority in every scenario. – Flater May 03 '21 at 15:14
  • (I thought I'd replied to this earlier?) Your answer does in fact set out development processes (because the OP asked about them), and the latter paragraph of your answer does in fact allude to the superior reliability of waterfall. – Steve May 03 '21 at 18:19
0

The iterative process isn't iterative over a single story, it's iterating over a series of sprints. We do a sprint, we evaluate how the sprint worked, we make adjustments, we do another sprint, we evaluate how the sprint worked, we make adjustments, and so on.

From the perspective of the customer, they have a list of product requirements. We break those requirements down into small chunks (epics, stories), we organize these chunks into a backlog of work, and then we iterate over those stories, delivinering incremental functionality with each iterations.

Bryan Oakley
  • 25,192
  • 5
  • 64
  • 89