Disciplined Agile Reuse: Harvesting Potentially Reusable Assets

 

Agile development teams build new things every day, and some of these things can be generalized into robust assets for reuse by other teams. This is particularly true for teams that are working with new technologies and techniques: for example, your first few C# teams are likely to develop useful micro services, or the first few agile teams to write personas will develop a potentially reusable template. The downside is that the first people to work with a technique or technology are most likely to make “beginner mistakes,” so their work may not be something you want to share with others. The implication is that you either need to wait to harvest a higher quality asset later or be willing to invest more effort into generalizing the asset.  We’ve found that it’s usually best to wait, giving you more time to gain experience with the technology or technique and discover if there is actually a need for the asset on other teams.

One of the key activities performed by a reuse engineering team is to harvest potentially reusable assets so that they may be generalized for reuse on other teams.  There are five steps to the harvesting process:

1. Find a potentially reusable asset.  Reuse engineers will be constantly on the look out for potentially reusable assets.  They find out about them via word of mouth, through internal online discussions, during enterprise architecture coordination meetings, and from suggestions made by members of development teams.
2. Assess the viability of the asset.  Just because someone thinks that an asset is potentially reusable doesn’t mean that it is.  The reuse engineers must determine whether there is a likely demand for the asset.  When other several other development teams have something similar, or are at least thinking about developing such an asset soon, then this is a fairly straightforward decision.  If there isn’t any immediate customers for the asset then that’s an indication that you are likely better to wait until it’s clear that other teams will be able to leverage the asset before you invest in generalizing it.
3. Generalize the asset. It takes much more effort to generalize an asset to make it reusable than it does to develop it for single-purpose usage. For example, studies showing that development of reusable code costs 111% to 480% of the development cost of single-purpose code.  Generalizing an asset requires great skill because the person doing this needs to be familiar with not only the technology or technique behind the asset but also with how it will potentially be used in practice. Part of generalization is to ensure that the asset conforms to appropriate guidance and making it easy to understand by its intended audience. You also want to validate the asset. You’ll need to unit test code-based assets and review templates and non-code artifacts with their target audiences. Concise overview documentation is important, but far more important are one or two good examples showing how to use the robust artifact properly. In the case of code, your unit tests may be sufficient. For templates, you should capture an actual example of the document for which it is a template (for example, to support a use case template, you should harvest one or two well-written use cases from a project team).
4. Reintegrate the asset into the source. The reuse engineers do this “extra” integration work so that the source team gets the advantage of working with the improved asset without taking on the cost of having to refactor their solution to do so.
5. Publish the asset.  The asset needs to be made available to the teams who could actually reuse it.  The publishing effort typically entails putting the asset into a reuse repository (which could be anything from a folder to a configuration management system to a commercial asset management product) and announcing the availability of the asset to potential customers of it.

There are four basic timing strategies for when to harvest an asset:

1. Harvest in-progress. You generalize an asset developed by a team before it has been released into production.  The reuse engineers do this by working closely with the development team, often joining them for a period of time so that they can generalize the asset and do the work to reintegrate the new version into whatever the team is building.
2. Harvest after production release. With this strategy the reuse engineers wait until the source development team has finished building the asset.   As with the first strategy they do the work to generalize reintegrate the asset.   In cases where the team isn’t working on a new release they do a “patch” release of the solution into production, but this obviously isn’t a desirable situation to be in (it’s far better to have stable development teams).
3. Harvest a legacy asset. In rare situations it is possible to harvest an existing asset currently deployed in production by encapsulating access to it. Although this strategy is often talked about it is rarely used in practice because it requires the asset being harvested to be well architected in that it must be loosely coupled and highly cohesive.  Most legacy assets tend to be the exact opposite, which is the primary reason why they’re not already being reused by other teams.
4. Harvest for a new project. You wait until a project team needs an asset previously developed by another team and then decide to either reuse the asset as-is or to generalize it.  This strategy has the advantage that you know there is a customer for the reusable asset before you invest in it.  However, the team may not be able to wait for the asset to be generalized.  Furthermore, unless the asset was developed recently people are likely to have forgotten about it, implying that this strategy has a short viability time frame.