Of course Scrum is useful. It's a methodology that does two things for you:
- It allows your project to adapt to change and
- It allows you to track progress, and get an idea on when it will be finished
So, there's some value in using it.
I think some of your preconditions are not correct and that's where you are getting lost.
I can't see how each story can be Negotiable - they are all required for a working compiler
This is not true. You can support a subset of the language and still have a compiler that works under certain conditions. Surely less valuable than a full compiler, but still valuable.
Also, you misunderstand what "Negotiable" means: it does not necessarily mean "Optional" and there is no requirement that stories are optional in INVEST. A story is a valuable objective and the negotiation is on how to reach that objective. Surely there's going to be more than way of implementing the backend of each language feature. There's where you need negotiation.
The stories are all of equal priority and it doesn't matter what order I deliver them.
This is not correct, as you say below that some stories are not "must have", so certainly some are less valuable. But even in the "must have" category: some language features are much more fundamental than others, and measurably so.
One way to measure this is "how much more lines of code we can compile on an existing codebase" or "how many more tests pass" if you have a predefined suite of tests.
There are also other options. If you were compiling a C-like language, strictly speaking you only need a if
and goto
loop to have a (barely) functional language and you can implement while
, for
and repeat
as macros. Assuming it's easy enough to write a use a precompiler, you can have a cheap stopgap solution (hey, are we negotiating? :-)
Regarding, adaptability, supporting a language is a fairly static set of requirements, but languages also change and also your knowledge of your needs change. Do you need to implement everything? Are there things you don't need specifically for your aims? One of the basic tenants of agile is the knowledge of having incomplete knowledge, can you leverage it?
In conclusion, to answer your question more directly: do you need agile processes when your requirements are unchangeable? Definitely not! Are they usable? Probably yes! Are they worth your time? Probably not - but are your requirements unchangeable? In my past experiences, "unchangeable requirements" => "lazy product owner" - not a rule, but worth keeping in mind.