7

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?

Improve this question
7
  • 12
    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
    Commented Sep 19, 2011 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.
    – NoChance
    Commented Sep 19, 2011 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
    Commented Sep 19, 2011 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
    Commented Sep 19, 2011 at 21:59
  • My workplace is a good example for adopting Agile methods without rewriting, but taking small incremental steps.
    – Yam Marcovic
    Commented Sep 19, 2011 at 22:27

10 Answers 10

Reset to default
10

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.

Improve this answer
5
  • 2
    I think that your statement "it's the only way to make progress" is an assumption not a true fact.
    – NoChance
    Commented Sep 19, 2011 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
    Commented Sep 19, 2011 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
    Commented Sep 19, 2011 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.
    – NoChance
    Commented Sep 20, 2011 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
    Commented Sep 20, 2011 at 9:39
1

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)

Improve this answer
1

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.

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer
1
  • Yup, you always have to make assumptions on incomplete stuff, and sometimes the foundations you started working with are invalidated by the customer going "and we're also going to need to do this. It's critical it has that. That should be a small change, no?". At that point, you leave the price negotiations to the people you have briefed on what that "small change" entails and start thinking about implementation changes because it will have to be done.
    – mishan
    Commented Jun 16, 2021 at 23:05
0

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.

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer
-1

The most important is that the scrum process will be usefull to you. I mean if your work will be better, just take it. But you will never know unless you try it.

Another point is that there is no need to take scrum process by the book. Just take things that will work for you. Our team for example does not have a scrum board. Because we do not need it.

As for design , you should try to design in such manner that future changes will not take a lot of time. Your system must be robust.

Improve this answer
-1

Yes we should adopt, agile is a methodology used to develop software in an incremental and iterative manner.

As the word agile suggests, the ability to change the direction and speed quickly. This agility sits at the core of agile principles. It leverages quick iterations of the design phases, development, reviews and testing.

It enables businesses to be in a position to continuously improve, evolve and innovate. It does so by breaking down the project into modules and sub-modules which can then be taken on by independent specialised teams. More precisely, it'll results in

  • Better results
  • Maximum flexibility
  • Resilient from the start
  • Better cost handling
  • Identifying and reducing risk
  • Utilising the data and user feedback
Improve this answer