15

I have an existing language that I need to port to a new platform. I'll probably attempt this by changing the backend of the existing compiler.

It is a significant amount of work to re-write the backend. I can't see a way breaking this down into sensible stories without violating INVEST criteria.

I can't see how each story can be Negotiable - they are all required for a working compiler. The stories are all of equal priority and it doesn't matter what order I deliver them. I need to do them all.

There are some parts of the software I'm implementing that are lower priority than others and I can see that we can deliver that incrementally. However, there is a significant core that is Must Have.

I plan on trying to follow Scrum, but am I just going through the motions?

Are there recommended practices for this kind of project?

| improve this question | |
  • 1
    @Sklivvz updated make more sense? – Dave Hillier Aug 28 '13 at 10:44
  • 1
    As an alternative to scrum, take a look at kanban. They're both agile, but AFAIK kanban is better for the type of work you're doing, while scrum is better for work that can be split into different priorities. – Izkata Aug 28 '13 at 12:24
  • @Izkata Kanban still expects a prioritized input queue, either by value or by arrival time. The all-or-nothing value proposition is the fundamental blocker when considering any sort of iterative development model. – CodeGnome Aug 28 '13 at 12:56
  • @CodeGnome Hm.. I admit to not having done kanban, but I understood it to be good for having lots of overarching things, as described in this question: If you do work for each card in its own branch then merge to trunk when it's complete, that's one "iteration"/release. They'd just overlap with each other, unlike sprints in scrum. – Izkata Aug 28 '13 at 13:38
  • 2
    The requirements won't change. You just can't believe that anymore. – JeffO Aug 28 '13 at 15:27
22

Bear in mind that the main reason Agile processes were created was to cope with shifting requirements. If requirements are set in stone (truly fixed requirements are rare but I'll take you at your word here!) then some of the best practices for dealing with changing requirements - e.g. Negotiable stories - become somewhat irrelevant. That said, following a Scrum workflow still has a lot of potential value in terms of scheduling and providing deliverables. Even if your deliverables won't constitute a fully usable product for a while, there's still something to be said for being able to demonstrate progress to your customer (and the team!).

Consider that all those 'must have' stories comprise a single epic: "Be able to compile on platform X". In this case the whole epic needs to be completed before any value is delivered to the user, but this is often the case at the start of large projects. Start with a story to compile the simplest possible program, then create further stories to support more and more language features.

Above all, don't get too hung up on trying to force every situation to fit into a highly generalised approach. Agile is supposed to work for you, not the other way around!

| improve this answer | |
  • 1
    Requirements always shift and to think they won't until the code is written and approved (assuming those in charge follow the rules)is just being in denile. – JeffO Aug 28 '13 at 15:26
  • @JeffO I agree: changing requirement are a sought after feature of agile, for example that's why we have demos. – Sklivvz Aug 28 '13 at 15:47
  • 1
    @JeffO If you want to nitpick, requirements do not always change, they almost always do. I'll change my wording regardless. – vaughandroid Aug 29 '13 at 7:55
  • 1
    I find this answer to be distasteful. "Start with a story to compile the simplest possible program, then create further stories to support more and more language features." But it is likely to require 6 months of work to build a framework before even the smallest program can be built! This is not a realistic answer describing the use of an agile approach for a backend system. – Dan Nissenbaum Dec 8 '13 at 8:07
10

Of course Scrum is useful. It's a methodology that does two things for you:

  1. It allows your project to adapt to change and
  2. 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.

| improve this answer | |
  • 3
    +1 for "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." Because that creates a testable and usable unit before the end of development. – Ross Patterson Aug 28 '13 at 10:50
  • 2
    And also "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." - I think its important to be able to demonstrate progress. – Dave Hillier Aug 28 '13 at 10:52
  • +1, though one point I am missing here is that requirements for a compiler can also be cut "horizontally" instead of by "supports language feature X". The compiler may need to optimize things (own requirement), may output debugging information (own requirement), may fulfill some performance requirements, and so on. – Doc Brown Aug 28 '13 at 11:32
  • @DocBrown requirements can certainly be horizontal, but stories need to be vertical. – Sklivvz Aug 28 '13 at 11:36
  • "As a user of the compiler, I want to enter DavesCompiler -O9 program.c, and the output should be a highly-optimized version of program.c (more formal definition of what highly-optimized means follows)" - sounds like a reasonable user story for me. – Doc Brown Aug 28 '13 at 11:50
4

TL;DR

All project management controls add overhead. Don't add overhead you don't need.

Scrum is the Wrong Hammer Here (Don't Be a Nail)

Scrum is a project management framework rather than a set of development practices suitable for an individual developer. Unless you are doing project management, Scrum is probably the wrong choice.

In addition, when you say:

The stories are all of equal priority and it doesn't matter what order I deliver them. I need to do them all.

you are implying a couple of things:

  1. The project has zero value unless all stories are 100% complete.
  2. The stories are not dependent on one another.

If both of these statements are true, then there's really no point in using a framework or practice designed to prioritize work by value or dependency-order.

Suggested Alternatives

Any development project could potentially benefit from some agile practices. In particular, in your specific case I would recommend:

  1. Ensure all your stories have a "definition of done" that includes unit- and acceptance-testing.
  2. Integrate and refactor often; don't leave yourself with a giant integration task at the end of the project.

Additionally, even if your product truly has zero value unless all stories are done, I'd spend some time grouping the stories into themes that you can treat as completed milestones. Being able to say "I've completed the foo feature" is often more useful than saying "I've got 23/117 random stories done." YMMV.

| improve this answer | |
  • 1
    I didn't claim to be an individual developer. – Dave Hillier Aug 28 '13 at 11:42
  • @DaveHillier "I have an existing language...I'll probably attempt this by...I plan on trying to follow Scrum." None of that says anything about teams, other people, or the need for formal project management. Even if there are 347 of you working on the project, the answer is still valid if your premise is valid. If not, update your question and I'll do my best to update the answer as appropriate. – CodeGnome Aug 28 '13 at 11:51
  • 1
    No one else has made such an assumption. I agree with some of what you've written. – Dave Hillier Aug 28 '13 at 12:11
  • 4
    @DaveHillier I read your question the same way as CodeGnome, that you'd be a solo developer on this project. The overuse of I instead of We is probably why. – Izkata Aug 28 '13 at 12:41
  • Wrong tool, not wrong hammer. A hammer is a hammer, not all problems are nails :-) – Sklivvz Aug 28 '13 at 21:19
2

I understand your concerns, but I believe there is still value for you in using scrum.

Admittedly, the user stories are much more fixed than in a consumer facing application. So that aspect of scrum will provide less value.

Where I think you will get value is from the iterative and frequent releases. Having a potentially releasable product at the end of every sprint compels you to keep code quality high and technical debt low. It is also a great way to find defects early.

I think you would also benefit from knowing your velocity. After several sprints, you can see how many effort points your team is finishing each sprint. This gives you an objective metric to help determine your ship date.

Above all, remember that agile is adjective. At the end of every sprint, you ought to be holding a retrospective meeting and then tailoring your process to your needs. If there is a part of the scrum process that doesn't apply to compiler development, remove it. If there is some other process element that would benefit you, add it. The most important part of agile in my opinion is to be cognizant of your process and be constantly improving for your specific situation.

(Please note, I've never done scrum on a compiler project; take my advice with a grain of salt.)

| improve this answer | |
0

Yes it does, as long as you remember that Scrum is not a set of strict rules to follow. You can adjust it to your project. Sprints, standups, weekly scrums will still be useful in order to foster better communication between team members and to make sure the project continues in the direction that was intended.

All stories might seem to have an equal priority, but you need to take into account the relative difficulty of implementing them. You don't want to keep your most difficult items until the end of the project. You will want to start working on them as soon as possible.

| improve this answer | |
  • Scrum is not a set of strict rules to follow - i thought it is exact the other way round. Isn't it like it has only a few rules, but you have to stick to them (e.g. Daily Standups, Definition of Done, Story Points)? – Uooo Aug 28 '13 at 10:34
  • Are you advocating ScrumBut? – Dave Hillier Aug 28 '13 at 10:36
  • @Uooo only the first of the three you mention is Scrum, the rest are just good practices, but not strictly fundamental. – Sklivvz Aug 28 '13 at 10:36
  • @Sklivvz Is this why many project managers think "we are doing daily standups, so we are doing scrum"? Scrum is more than only daily standups. – Uooo Aug 28 '13 at 10:39
  • 1
    @Sklivvz okay, now I get what you mean with it :-) I thought you meant only doing standups is already scrum. – Uooo Aug 28 '13 at 10:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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