Clicking the diagram opens the interactive DA Browser where you can learn more about all goals, decision points and options of DA.
The process decision points that you need to consider for asset management are:
- Obtain assets. There are several ways that you can obtain potential assets. The least effective is to try to build them to be reusable from the very beginning but this strategy often proves problematic in practice because it’s hard to predict what other teams will actually want and as a result you tend to overbuild the asset. A better approach is to obtain an asset from external sources, either free (as in the case of open source assets) or through purchase. In this case the assets are often both under and over built – some features you want are missing and many that you do not want are there. The most effective strategy, in general, is to harvest an existing asset that is already in use within your organization and to generalize it so that others will want to reuse it.
- Publish assets. An asset won’t be (re)used if people don’t know that it exists. When a new intangible assets are made available they must put into your organizational reuse repository, described appropriately, and announced to any interested parties. When tangible assets are made available for use a similar process is followed where assets are made available to the appropriate people and people are informed about how to obtain them.
- Support asset usage. When it comes to tangible assets, this is mostly a matter of supporting usage – how do we convince people to take advantage of the organization’s existing assets, when we have them and when appropriate, rather than procuring new ones? When it comes to intangible assets, it’s a matter of reuse. There are many ways for an asset management team, and better yet the reuse engineers if they exist, to support Disciplined Agile (DA) teams. Training, educating, coaching, and mentoring team members in reuse are fairly straightforward to understand. Some of the more interesting strategies include working with a delivery team to configure and even integrate an asset into their work. Reuse engineers, often working with a team’s architecture owner , will identify potentially reusable assets that can be harvested and generalized for reuse.
- Evolve assets. Your assets will need to be evolved or replaced over time. For tangible assets this could include regular maintenance of the asset, repairs to the asset, or upgrades to it. For intangible assets this includes any work required to generalize the asset to make it reusable, configuration management of the asset’s constituent parts, to update an existing asset to support its evolving purpose, to tailor an asset so that it can be reused in a new situation, and to eventually retire the asset when it is no longer needed.
- Fund usage. There are several ways fund asset usage efforts, as you can see in Figure 1. The least effective, and often debilitating, strategy is to put a chargeback strategy in place. The basic idea is that if someone reuses an asset then they should pay for it (some organizations will even charge a team for downloading intangible assets from their reuse repository, regardless of whether they use it or not). The problem with this approach is that it in effect punishes teams for reusing things, thereby motivating them to buy or build things from scratch in the future. In some organizations it proves better to not fund the usage effort at all, which typically results in ad-hoc reuse at best, than it is to put a chargeback scheme in place. The most effective approach that we’ve seen is to directly fund the usage support/reuse team, thereby taking cost considerations out of the equation when people choose to (re)use an asset.
- Govern assets. The asset management effort, as with all other efforts, should be governed in a streamlined, collaborative manner. This is part of your overall organizational governance/oversight efforts.