Instead of inventing my own system, I would go with the (rather new) GROWS Method[1], which is designed to be adapted to suit your needs (but only after a certain level of experience is gained).
GROWS splits its components into stages, through which your team progresses as they become experienced with the various practices. The stages are:
Stage 1 is very simple and easy and about getting your team setup on good practices (eg source control). At this stage, you should be following it rigidly.
Stage 2 is about making sure the right people are working on the right things at the right time. A rigid but simple agile-development system.
Stage 3 is about applying judgement and critical thinking to stage 2, adding release planning, retrospectives and other plan-and-feedback practices
Stage 4 is the stage where your team is experienced enough to tune and alter the practices so that they work best for your unique situation
Stage 5 is when you're ready to replicate your teams practices for other teams or environments.
I like it because it acknowledges that no one-size-fits-all system can be perfect for everyone and provides a framework that allows itself to be changed, but does so around a "skills model" to prevent premature change.
"This requires a lot of skill though"
Exactly. Which, in my experience, most teams do not have. All too often have I been in a team practicing some form of agile, but they don't like X and would prefer Y and so they change the framework to suit their needs and then it fails and they blame the framework, saying it doesn't work, when in reality what happened is they changed and broke it, because they are not (yet!) experienced enough in that framework to actually tweak it to their needs. GROWS is designed with this in mind.
[1] growsmethod.com
