I am part of a project that develops a software with quite a clearly defined in- and output. But the path (a chain of intermediate steps and artefacts) is not yet clear. We start with a toy-ish approach to get a very minimum MVP and want to refine then to finally get going.

Being agile I get that you add features iteratively. But what if you have to reshape your 'ansatz' approach?

I guess we will reach a point (at least once) where we not only have to adjust a detail but change an artefact so that it will have an impact on other artefacts and their creation in the process.

Imagine we are on the green path but we realize we need to get back on track to reach the blue one b/c the peak to reach is set as our goal.

enter image description here (source)

Does this sound weird? - Does agile know this? - Do I miss something?

Every idea and perspective is highly appreciated. :)

(might also be in the direction of exploratory development?)

-------------------- EDIT --------------------

Ok, Doc Brown has a point. Thank you for raising! Let me clarify:

My concern is not changing the code basis (like language or platform). My concern is the abstract production process.

We get text in and produce a diagram.

There are of course several ways to proceed. For short texts one might directly jump from text to xml; an llm can do it. But when the structure gets a little more complicated one might have to add a step in between to disentangle things (like create structured text first).

But the direct easy jump happy path was part of a first sprint. This new and refined step in between forces us to adjust the previous story because maybe debugging is different now.

This feels "wrong" as we change the basis and do not simply add a new story.

  • It would really help if you would add some details about the scale which you have in mind - the time scale, the team size scale, the projects scale. Also, can you give an expressive example of what you have in mind by "changing an artefact"?
    – Doc Brown
    Commented Feb 6 at 21:14
  • I am actually asking rather generally though I get your point. - We design a product that transforms textual input into a graphical representation. To get there we have to extract to structure of interest, clean it up, choose a "language" of interest which is xml and do maybe some auto debugging or manual tweaking. But there are different approaches thinkable. Maybe the textual input can be translated automatically into executable xml for short text, but in the end fails for longer texts. But that might force us to break up the whole chain that "worked" for the first mvp easy example.
    – MaK
    Commented Feb 7 at 8:13
  • "I am actually asking rather generally" is a recipe for collecting close votes ("needs details or clarity" or "needs more focus") and downvotes. Better be specific. In your comment (which you should edit into the question, BTW), you already telling us that the risk of having to change your design decisions is not caused by things like changing the whole programming language ecosystem in the middle of the project. That already can make your question a lot more answerable.
    – Doc Brown
    Commented Feb 7 at 9:10

2 Answers 2


Its hard to understand what is really your question.

But the common issue is that people think about Agile as "chaos". This is not true. Its completely fine even in Agile development to have some high-level goals you want to achieve in 1, 2 or even more years.

Its completely fine to have high-level architecture for more complex services you want to do, to understand high-level requirements.

All this can be done before starting with the development itself (altough you should not overplan early and you should not go in too much details for something you will deliver after long time).

Now the point of Agile is that you do small iterative changes to reach your goal and to fulfill even your non-functional needs and goals. So imagine you have huge service that will take i.e. 6 months to finish with everything you wish for. The point of Agile is that you come up with i.e. 6 phases (1 month each) and each phase implemented will have some visible/measaruable business value.

Even when you start with Phase 1, its good to understand where you want to get in Phase 6, so you do not implement something that is going actualy against the goal you want to achieve.

The point is, that quite often when you reach i.e. Phase 3, you find out that Phase 3 of this project already manages 80% of your business requirements and you deprioritize next phases (and do something else meanwhile with higher business value). Also during implementing of each phase you can find out new requirements, new business values and shape future development based on it.

So Agile does not mean you are going randomly to some direction and dont know what you want to achieve. It means that you are achieving your goals by smaller steps, where at the end of each step is product that brings some new value or functionality.

  • Thank you. - Well my concern is: What if I realize in phase 3 that I have to change sth from phase 1 to make it work? - This should happen regularly, no?
    – MaK
    Commented Feb 7 at 16:16
  • 1
    @MaK - the iterative approach accept any kind of changes. Therefore you just add one more update that changes something you want. The advantage of Agile is that you can find this out during Phase 3, do the update and possibly change also how Phase 4,5,6 to adapt to that change. While with Waterfall-like approach you would find this at Phase 6 and that would be more costy to change. Altough if you find out that everything you built up to Phase 3 is completely wrong, then even Agile does not save you - you can throw it away and start over. But that means that all your goals were wrong already.
    – libik
    Commented Feb 10 at 11:06

Super vague question but I guess the answer is often "You don't"

The "Big rewrite" is always something you need to do, but the cost is always very high and there are always other new things you might be doing instead. So there is a lost opportunity cost.

For example if we take your graph at face value, going back and doing things the blue path way over green gives you an extra 20%? value, but its going to take longer than you have already spent on the green path. You could do another different project and double your total value in the same time. Also there is probably some suboptimal hack you can put in place to get you similar benefits.

Every few years you will hit some barrier where the gains from a rewrite are worth it. Say some new tech comes out that everyone else is using and it gives a significant boost to everything. You adopt the tech, write the "blue path" and switch the product over, decomming green.

Now, if close isn't good enough, for your product and green is a complete fail. Well then you have no choice, hopefully you can reuse some of the work, but the ideal of iterative is that you will have hit that failure point earlier, and hence more cheaply, than you would have with a waterfall, plan everything at the start approach.

  • Thanks. Well we haven't failed yet. I am just mapping out the approaches and your answer first of all tells me that there is no 'magic trick' :) But it does support my pov that we should work in a modular way with an idea of reusability and adaptability and zoom out regularly to keep track.
    – MaK
    Commented Feb 6 at 12:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.