I tried to practice Scrum in my team. But my colleague asks me:
Our software has clearly requirement. So why we should use scrum
How can I persuade him from this case.
There are a number of reasons why agile may be a good thing, assuming that though it's 100% clear what the requirements are, it's unclear what the most valuable sequence of execution is and that delivering a partial product early may already return value early.
Early delivery of some features may already unlock value. One could build an application by first releasing the admin module, then the print module, then the report module and finally the underlying business logic. In that order there would be 0 value, until the business logic is actually implemented. All that time the other modules would be gathering dust and their value would be delayed. By releasing the business logic and a partial report and admin module first, you might be able to take the application into production much earlier and unlock value sooner. You'll have a better ROI that way.
Early delivery allows you to prove your architecture, deployment and infrastructure. By delivering your product in smaller bits (which may allow a small subset of your users to use it early), you can prove your architecture early (thus reduce risk), and you get multiple opportunities to test your deployment scripts, ensuring that once your application is heavily used, you can deploy a fix in a much shorter time and with much lower impact to your end-users.
Early delivery gives feedback. You think (assume) that the requirements are 100% clear. In many cases they rarely are, or by seeing the actual application in one may realize it doesn't actually do exactly what it needs to do. By showing working software regularly, you have a chance to continuously prove that you know the requirements 100%. If you do more traditional waterfall, you gamble that you know the requirements. In the agile way the risk of being wrong is much lower, since you'll know you're wrong early and still have a chance to change direction.
60% features of many applications are never used. Take Microsoft word for example. How many people actually use the extensibility model? embedded XML? and quite a few more of those features that snuck into the product over time. True, there is a market for each of these features, but a lot of people can make do with a slightly more advanced version of WordPad. Unless you have the market reach of Microsoft, building an application that has all the features of word in a waterfall way and then releasing it, is going to be very, very, costly. Doing it agile allows you to stop early, never building the features that were not needed anyway. For many waterfall development projects the requirements are often more than that's actually needed. A lot of the "Business" asks for more than they'll know they'll get in the end, better safe than sorry many will think, and they add all the things they think they might ever need to the requirements specification.
Can you prove that the assumption of 100% known requirements is correct? I assume one can't. Especially since requirements tend to change over time. But for small projects, or for very defined pieces of work (maybe required by law or some kind of certification), one could known exactly what is needed and just build it.
You only mention that the requirements are already known. Does that mean that your developers already know exactly how to build it? And have you figured out exactly how and if you can test it? And do you know what the most useful sequence of delivery is? Is your infrastructure capable of handling the application? All of these questions can easily be answered by building small bits of the actual product and continuously integrating them.
Of course you might be able to work out on paper exactly how all the pieces will fit together, in very rare cases that works, when you know the domain, use proven technologies (usually slightly older technologies) and have already built something that's very similar at least 3 times. In those cases, where you're allowing yourself to create some technical debt by using old stuff, you could probably do without any form of agile.
Now whether you'll need to do a lot of Backlog refinement along the way? Maybe not, if a lot of the requirements are already known. For all the other good reasons, I say that there is a lot to win by working in an agile way, especially if all the requirements are assumed to be known.
If your team buys into these reasons, then by all means go agile. Whether it's scrum or something else. At least deliver regularly and make sure that your work is continuously tested and deployed. If you team doesn't buy it, try structuring your waterfall project in a way that tries to embrace the points mentioned above. Deliver regularly, make sure your work is continuously tested and deployed... Wait... That sounds like agile, if not at least iterative and incremental delivery ;).