...you keep treating it like we are in maintenance mode! [All Development is Maintenance Development]

One of my team said recently "This is a new product. You keep treating it like we are in maintenance mode!". He was right.

Eventually every product gets released. Once it is released you need to be in maintenance mode. Agile development focuses on getting this feedback from running software as soon as possible in by releasing early and often.

As soon as the first release is being used by real people (typically within weeks of starting the project) you are in maintenance mode, whether you like it or not. So all development is done in maintenance mode.

Because of this... You have valuable data you need to migrate with each release. You have users that need to be informed of changes to UI or behavior. You will have to prioritize between bug fixes and new features. You also gain valuable feedback from real users about the usability of your solution.

Here are some rules I have found useful for maintenance development:-

Every developer has their own database instance.

This sandboxes your changes from everyone else's. You wouldn't share the same copy of the code on a shared drive for development, would you?

Every change to the schema is done through scripts.

This allows you to share your db changes with the rest of the team (allowing you to make them more frequently) and handle migration of existing data. Like code, other's don't get your changes until they choose to. You must test these scripts to ensure the data remains intact. I used to have copies of a few big customer databases which I used to verify this. [I'll be releasing a .Net tool to help with this process soon]

Every schema change should have a number.

Every database needs a 'sysinfo' table with one row in it that tells you which version the database is. Every script is numbered in the order they are to be run. Running a script updates the database version number. This makes working out what script to run next simple, allows you to skip steps that don't need running, and unlike scripts that check if a change is needed before doing it, run fast and allow you to put re-do changes you have undone in a previous version.

Stored Procedures are code and should be versioned along with the codebase.

Your process of getting latest should be 1/ get latest. 2/ run the database schema migration scripts on your personal db instance 3/ update any changed stored procedures

Every check in should be atomic.

In other words every check in should contain all code, stored procedure and schema changes to leave you in a state you could get latest, build from scratch, generate a database from the scripts, run all the tests and everything will work.

Have no more than one branch (the version in production) and a trunk (the version in development).

Branches mean duplicated effort. If you release every week, you don't need one at all.

If you work out a good way to seamlessly keep the user trained on the latest version, let me know. I have a feeling the correct solution will involve the app automatically training people on how to user it, which would work for new users too. See Basecamp for an example of this.