Label: technique

Content with label technique in KM: Agile Software Release Strategies (See content from all spaces)
There are no related labels.

Page: Accept transition costs
Many of the patterns that are described in this wiki require some up front investment. The cost of the investment can either be direct in terms of added work or indirect through reduced business value in a release. The value of the investment is in reduced risk of failure or rework. Investing ...
Page: Build in stages
One way of reducing release length is to build a limited version of a feature and later make it more comprehensive. This often works best when combined with a limited release. This principle is best explained with examples: Outsourced print In Google Docs the print function ...
Page: Build trust
many projects there is a lack of trust between the business and the development project. The business has seen too many projects that are late and deliver the wrong product. By using the first releases to deliver value to the business the project can build trust that will be essential later ...
Page: Is it necessary?
first thing that one should ask when planning a replacement project is: "Is it really necessary to replace?" Augmenting a legacy system is often better than replacing it. A rule of thumb is that it will be twice as expensive as estimated to replace a legacy system. Many projects decide ...
Page: Learning curve
Knowledge of the tools and frameworks that will be used in a project is often poorest at the outset. The same often goes for the team's knowledge of the legacy system. If it is not possible to identify a reasonably small MRP for the first release one should consider a delaying tactic. Develop a peripheral function ...
Page: Minimize migration
Most people with experience with migration of data from a legacy system to a new one are very cautious when planning a migration effort. Migration is almost always much more complicated and costly than one hopes. It is therefore wise to always look ...
Page: Scope control
Agile approaches such as Scrum emphasize scope control of Sprints(iterations). The scope of a Sprint should not be altered after the Sprint has started. When setting up a release plan based on a MRP with releases longer than one sprint one should ...
Page: Study existing system
common opinion in replacement projects is that you should avoid studying the legacy system so as to not become overly influenced by it. There are a number of reasons this line of thinking is probably wrong: Users are often blinded by the legacy system but they have been working with it for years. Studying ...
Page: The value of Pain
Regardless of how you plan to tackle MRP in a project, the first rule for an optimal MRP is that pain is preferable to a long release. Only include functionality that is absolutely essential. Features that are valuable but not essential should not be in a release that is more than three months ...
Page: Verify patterns
When selecting the patterns that you plan to use in a release you need to verify these carefully. Check strengths and weaknesses Each pattern has a number on intrinsic strengths and weaknesses. Carefully examine the strengths and weaknesses of the patterns being evaluated in the context of your ...