When you choose an agile SDLC, it changes, to some degree, the meaning of “Done”. In a perfect Agile environment, when your code is complete, you should be able to release it to a production environment. In agile, for a period of work, you select a feature that is consistent within itself. This means, if it depends on another feature that does not fit in your current work cycle, them the other feature must be done first, even if releasing it has no impact on the current production system.
When you pick up a new feature to implement for the current cycle, you follow the process of estimation of tasks,
development, review, QA, and prepare to release. For a database, this means you develop the master object definitions, and the migrations need to deploy your database change, all at one time. In this fashion, when you check in your database modifications, only implemented in your own personal database sandbox, other developers update their personal sandbox by executing your database migrations.
You can implement your database change incrementally. That means, you can do something like change a table, and create migration scripts to populate the new columns with appropriate values. A later check in might include changes to some stored procedures, views, or functions based on the new table design. When your code is complete, meaning all of the changes necessary for the new or modified feature are checked in, the developers may complete their code as well, and a review with the customer can be performed.
Much as you may incrementally make change, so also, the developers may incrementally be making changes. Sometimes you may even create a stub for some SQL code until such time as you can fully implement it. This way, the developer can work on their consumer, and fully test when your code is completed.
Work on being done, and your teammates will love you for it.
Cheers,
Ben