Agile / Traditional approach- Why not hybrid?

Let’s discuss what are your options if there are some constraints which are preventing you from using agile methodology or simply if your customer does not want to use Agile methodology.
Well, why not use hybrid of Agile and Water fall approach.
Tie your deliverables as required by your customers to water fall steps. Let’s look at the following steps
Requirements Gathering
Designing
Coding
Testing

Go ahead and create requirements and design document and submit it to your customer for sign off.
Take your coding and testing steps and see if you can use some of part of Agile methodology in these steps. Try doing following in 2-4 week iterations:
Create stories from your requirements document
Assign points to your stories
Prioritize your stories
Develop and unit test your stories
Perform automated acceptance tests and deploy

Deploying every 2 week gives your Business Analysts a chance to validate and verify your software. Any resulting issues can be fixed early and will be less expensive to fix. Deploying every 2-week gives your team a short goal which your team can try to achieve and once the team’s goal is achieved, the team will get a sense of achievement and hence this will boost team’s moral. The team will get confident each time an iteration is successful. Not only that, by deploying every 2 week you can measure the development velocity of your team and hence will have more insight in to when the whole software can be delivered. You can take necessary steps if you feel that by this development velocity delivery of the software will be delayed.
Another thing which I want to highlight here is that Agile is less document oriented. No big requirements document, no big design documents, just enough documentation which you feel is necessary. For example, some times we create very detailed design documents explaining how the screens will look, which database tables will be used, what will be the pseudo code , what will be the sql query etc.
Instead of going in so much detail why not a screen design and few words about its functionality. In fact I would prefer to draw the screens with my hand and update the screen when the developer has developed it. Believe me you would save a lot of time and probably be able to code your screen in the time you will be writing your detailed design document. Another reason not to write design documents in so much detail is that no one can be 100% sure about the sql, the database tables and code logic and no one can guarantee that these won’t change. We must welcome change and if we don’t we will fall in our own trap where in the end we will realize that we are running out of time and then these very detailed design documents are left untouched and now suddenly your code and the supportive documents are not in sync. Otherwise also if we know the things will change then why write it. Let coding take its own course, let the development happen with bare minimum documents and in the end produce your documents from your code / software and not the other way around.
All of you who have looked in to RUP and if ever tried to produce those documents will probably realize the pain of doing so much documentation. Sometimes we forget our main goal. Our main goal is to produce working software and not lot of unnecessary documentation just to comply with a methodology. If just by writing few words can convey a software function then please do not write hundreds of lines just to convey the same function in detail. I have seen low level design documents with various sections inside those (For example, Screen Design, Description, Constraints , Database tables, Sql queries, interacting units.) Lets make it simple a screen design ( hand crafted) and just enough detail about its functionality.
Another thing if your customer is not requiring you to submit these low level documents then why make these so much great.

My suggestion lets make our life simple by making things simple, by reducing variables, by not over engineering anything , by being open minded and by welcoming the change. Let’s not make a methodology our religion (be it RUP or Agile or any other) and then keep believe in it for the rest of our life.