Principles and patterns

There are a multitude of strategies that can be used to reduce the length of a release. These strategies can be described either as principles or patterns. A principle is a rule that you can choose to follow to a greater or lesser degree. Principles are like good advice. You should always take these principles into consideration but sometimes your context will make a principle less relevant. A pattern is usually defined as a solution to a problem in a context. If your context does not match the context of the pattern you will probably not be able to use it. Patterns can be combined. They also have intrinsic strengths and weaknesses that need to be evaluated in the context of your project.

Have you used principles or patterns that are not described here? Please contribute your experiences!

General principles

1. The value of Pain
2. Pain relievers
3. Limited releases
4. Differentiators
5. Scope control and buffer
6. Verify patterns and principles

General patterns

1. Workflow by workflow
2. Follow the workflow
3. Workflow tail first
4. Product by product
5. User by user

Replacement project principles

1. Is it necessary?
2. The value of delaying
3. Minimize migration
4. Facilitate switching

Replacement project patterns

1. Customer by customer
2. New business
3. Umbrella (mask new system)
4. Mediator (throttle)
5. Partial history
6. Input split

Leveraging legacy data patterns

1. Shared database
2. Synchronized database
3. Replicated database
4. Database views
5. Migrate on demand