Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I work for a small product based company. We are about to re-write our existing product from scratch. We are planing to adopt Agile methodology for our development. Now my question is as we have all the requirements even before start of project (as we are re-writing the existing product), is it worth to dive into Agile world? Isn't agile more useful when you don't have all the requirement upfront and you get your requirement in phases?

Secondly, let's say if we jump into Agile, whats the best practice to design database? Let's say in our first iteration we just create a login system (user can login, logout etc). Do we just need to create Users table without worrying about other tables? And other tables would be evolved as our product would progress?

share|improve this question

migrated from stackoverflow.com Sep 19 '11 at 20:48

This question came from our site for professional and enthusiast programmers.

9  
You lost me at "we are about to re-write our existing product from scratch." Please read this old gem before proceding "Things you should never do, part 1": joelonsoftware.com/articles/fog0000000069.html –  JohnFx Sep 19 '11 at 20:19
2  
Using a methodology you don't know for no compelling reason is unjustifiable risk. It is good that you are finding about Agile, make sure you come up with good reasons why you choose it over other techniques. –  Emmad Kareem Sep 19 '11 at 20:55
2  
One of Agile's major benefits is responding to change. Presumably rewriting your existing product will take considerable time. Do you honestly believe that the requirements will not change during that time? –  TrueWill Sep 19 '11 at 21:09
1  
@TrueWill - How can a software methodology 'respond to change'? That doesn't make any sense. It's not AI...? Lol. –  Anonymous Sep 19 '11 at 21:59
    
My workplace is a good example for adopting Agile methods without rewriting, but taking small incremental steps. –  Yam Marcovic Sep 19 '11 at 22:27

9 Answers 9

The most important that the scrum process will be usefull to you. I mean if your work will be better , just take it. Buy you will never know unless you try it. Another point is that no need to take scrum process by the book. Just take things that will work for your. Our team for example do not have a scrum board. Because we do not need it. As for desing , you should try to desing in such manner that future change will not take a lot of time . Your system must be robust. Sorry for my english.

share|improve this answer

Agile is applicable for any development project, and not specifically for complete greenfield projects that do not yet have any requirements specified. Agile project management makes your project self-learning, and self-improving by taking small steps, reviewing your steps often and improving your next steps. There are a lot of blogs on Agile around. Google is your friend ...

Regarding your specific question on Agile database development, you are sort of on the right track. You can develop user management without caring about the rest at first. That will probably end up in some rework when you get further in the project, but that can be considered a cost of doing small focussed iteration. Some middle-of-the-road approach would investigate your database model a bit more upfront and make some design that could work a few sprints ahead. That way, you'll have less rework.

share|improve this answer

is it worth to dive into Agile world?

Yes.

Isn't agile more useful when you don't have all the requirement upfront and you get your requirement in phases??

False.

When you don't have all the requirements it's the only way to make progress. Anything else requires fanciful assumptions that will eventually be proven false. Agile simply makes fewer fanciful assumptions.

When you have all the requirements, you must still follow all the Agile principles.

Read this before proceeding any further: http://agilemanifesto.org/

All of these points are true no matter how much you know of the requirements.

You still benefit from using an Agile method like Scrum, because you'll have more realistic expectations.

whats the best practice to design database? Let's say in our first iteration we just create a login system (user can login, logout etc).

What a terrible first iteration.

Do we just need to create Users table without worrying about other tables? And other tables would be evolved as our product would progress?

Yes. You create the database incrementally.

You do everything incrementally.

You prioritize based on what creates the most value to users. Not fanciful (and silly) technical considerations.

share|improve this answer
2  
I think that your statement "it's the only way to make progress" is an assumption not a true fact. –  Emmad Kareem Sep 19 '11 at 20:52
    
@Emmad Kareem: "Anything else requires fanciful assumptions". You can call that "progress" if you want to. However, I submit that fanciful assumptions are not really progress. Random assumptions as a way to make "progress" are just random dithering. It's not forward progress toward a definite conclusion. It's just random activity, some percentage of which is in the proper direction. The rest of the activity is just assumptions being invalidated as the requirements are gathered. –  S.Lott Sep 19 '11 at 22:41
    
@Emmad Kareem: It helps to provide the correction you'd like to see. "not a true fact" doesn't tell me how to fix it, does it? –  S.Lott Sep 19 '11 at 23:08
2  
Thanks for the clarification. My point was Agile is only one methodology among many others, and saying that "it is the only way" sounds to me like an assumption. Your personal view is of course respected. –  Emmad Kareem Sep 20 '11 at 7:30
    
@Emmad Kareem: "Agile is only one methodology among many others". Agile is not a single methodology. It is an approach which leads to a variety of methodologies. There are "many other" methodologies which cannot and do not work with incomplete requirements. There are many Agile methodologies, all of which do work with incomplete requirements. –  S.Lott Sep 20 '11 at 9:39

Now my question is as we have all the requirements even before start of project (as we are re-writing the existing product), is it worth to dive into Agile world?

Yes, though I'd imagine there are likely more than a few possible changes to how the application is currently designed as this would be the time to clean up various technical debt in having a cleaner design given the information known now.

Isn't agile more useful when you don't have all the requirement upfront and you get your requirement in phases??

How confident are you that those requirements will not change as you build the application again? Are you sure that the design being taken will never be refactored?

Secondly, let's say if we jump into Agile, whats the best practice to design database? Let's say in our first iteration we just create a login system (user can login, logout etc). Do we just need to create Users table without worrying about other tables? And other tables would be evolved as our product would progress?

There are plenty of different options here. Do just enough to make it work. If the Users table is all that is needed, great. If there are a few other tables someone wants to have so the DB is in a more normalized form, then that may make it better to do that. You won't be perfect the first time and Agile is all about a try and fix kind of methodology as once you show what you have the user will often have feedback that is what keeps Agile going and going... (Also where the new requirements will come as people may then start asking for stuff too)

share|improve this answer

Secondly, let's say if we jump into Agile, whats the best practice to design database? Let's say in our first iteration we just create a login system (user can login, logout etc). Do we just need to create Users table without worrying about other tables? And other tables would be evolved as our product would progress?

Be careful about overdoing this approach. It can be like building a house and trying to finish one bathroom completely while the foundation is still setting. Odds are you'll have to completely redo significant portions of your work if your application's foundation, the database and underlying object model, aren't mature or stable enough to support the structure.

Also, remember that saying you're using Agile/Scrum doesn't excuse you from using good software engineering practices like proper unit testing and solid database and object design. When Agile is misapplied it can easily fall into a code and fix death spiral project that can be very painful or even impossible to recover from.

share|improve this answer

Agile is all about more productivity and flexibility. Why are you rewriting your applications? Reasons could be:

  1. Changing the platform (from Windows to Linux for example)
  2. Changing the language (e.g. from ASP.NET to PHP)
  3. Refactoring amount is so high, that makes the re-writing a cost-saving option
  4. Business has changed a lot, so, you're actually creating a new application (a new song, based on the same theme, if you wish)

In any of these reasons, you won't deliver your product overnight, and of course it'll take time.

Having a product backlog is only one of the items agile recommends. What you say about knowing the whole business means that you already have lot's of PBIs in your product backlog.

But isn't it better that you deliver parts of your new product at the end of every sprint? Won't it make you more agile and responsive to changes. For example, imagine that you're trying to make the new application beautiful. Isn't it just bad to know after 10 months that your new design is not acceptable? Won't it be a good practice if you're told after 2-3 weeks about that?

My answer to your question is:

Agile development definitely has many things to offer, even for re-written applications.

share|improve this answer

is it worth to dive into Agile world?

Maybe. Trying anything new can be risky, especially if it's new to everyone. I personally find Agile to be useful when done right.

Isn't agile more useful when you don't have all the requirement upfront and you get your requirement in phases??

It may be useful in helping to drive requirements if you don't yet have them. However, that doesn't mean it's utility is limited to only driving requirements.

whats the best practice to design database?

Iteratively. Use database migrations.

Suggestions

  • If you do want to do Agile that's great. I would try and get someone who has done it before to help you through the process.

  • People often ignore the refactoring step when they first try Agile. Do NOT. It will kill the project.

  • Think in vertical slices (features) instead of layers. Implement vertical slices so you have a working system after the first feature card is done. Once it's working, keep it working and just add with each feature card.

share|improve this answer

I work for a small product based company. We are about to re-write our existing product from scratch. We are planing to adopt Agile methodology for our development. Now my question is as we have all the requirements even before start of project (as we are re-writing the existing product), is it worth to dive into Agile world?

A small company (management) that is planning to use agile practices is in a great starting position since its typically developers who drive adoption. I would recommend that you identify leaders willing to continue driving adoption at the team level (Training, institutionalization, etc.)

With requirements in hand, ask your users what they would want to see in one iteration. Then, deliver it. Do it again the next iteration and again. Users who are able to touch your work early will help refine the requirements as you go. If you do not have automated processes in place now or the team does not understand continuous development then schedule time to make sure they do.

share|improve this answer

We've been using Agile on a project that entails moving from an old application to a new set of applications and a new architecture. Our situation is a little different in that we are trying to not only redo the existing application (used internally by our sales, finance, sourcing and warehouse departments), but we are trying to improve each department's experience along the way. One challenge that we've seen using agile is that the business value for moving parts of the functionality for a given business unit is high, but other parts is low. We therefore find ourselves making new applications and keeping the old application running while we transition. We are having trouble getting the business to see the value in concentrating on moving one "customer" to a completely new application. We are however getting a lot of high value stories into our sprints. I think soon we are going to come to a pint soon, when we have to convince the business that we need to focus on one unit at a time.

So, to answer the original question, yes agile is a good way to go. Be prepared for some dependencies to crop up and guid some of the teams decisions along the way.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.