I've been working as a programmer on a project designed for generic software for gas stations (to be redistributed for many customers) for 18 months. The project is big. Today we have around 150 tables. We haven't used a specifc approuch, it was not well managed.The person table has today around 70 columns, but 15 months ago it had around 30 columns. These new fields emerged in order to integrate with other modules such as sales, financial and accounting. Also many fields were created then deleted.As a result, we had many refactoring and rework. The project never gets ready because there are always new requirements emerging.Here's my doubt: if we had used a usual approach of specification, we would had interviews, a requirements document, activity, sequence and class diagrams, so we would know since the begin that the person table would need 70 fields, then we had avoided a lot of refactoring.Could scrum help in this project? I have a feeling that in this case scrum would end up in a lot of refactoring as well.I'm only a programmer, not a project manager. I'm wondering how it should have been done: with scrum or with big design up front.EditJust to complement the end of this story.Eight months later I asked this question, after put the project in production in some test costumers the project officialy failed. The product owner decided to abandon the project. It got hard to fix problems and a lot of perfomance problems occured.
Should I use scrum for big projects?
scrum;requirements management
It looks like you have churned your way in an uncontrolled development process to create a never-ending development system. This occurs in agile systems too.The root problem is a lack of requirements, and while your solution might seem to be to use an agile methodology to fix this (as agile is designed around changing requirements) it would not solve the problem. Even agile methods require a fairly firm starting point. They respond well to changing requirements, but they are just as useless as any other methodology if you start with no requirements. You still have to have a plan that you're heading towards before you start. Agile helps when that goal drifts, it does not help you define that goal.Now its true that a fixed up-front design is too rigid if you do not know exactly what you are building. So, I think you're going to have to move from your current 'chaos' methodology to something more organised and will have to implement a fair amount of design and planning. You can try to do this in one go with a heavy methodology, or you can be more flexible with an agile one. What you cannot do is expect any methodology to fix your lack of initial planning.Incidentally, Kanban sounds more appropriate for your needs. Scrum works best with small teams and projects. Kanban can work with larger projects but it also works with a throughput of work approach, so design changes are continual and not chunked into sprints. I think you'd have more success with that.