Making the right decisions in the middle of an iteration or release cycle is risky and needs good judgment. Investing in a reusable asset is no exception.
What can help you take decisions on whether it is worth investing the time and effort for making a software capability reusable? The single most important factor is business relevance. Is the capability a priority for your business? Even if it is not a priority, is it one for the medium or long term? If the answer to these questions is no, you shouldn’t invest valuable resources into making your capability reusable. Yes, if it isn’t relevant, it needn’t be reusable. Assuming a capability is business relevant, there are several considerations you can think about:
- Do you have user stories that either directly or indirectly requires this capability? For instance, if you have a login customer user story, and you don’t have a customer component, this is an opportunity to create one. In the same vein, the login customer story itself might have variations. What are the different kinds of login that you need to support? Username/password, username/password/special verification text, email/password, username/random set of questions, username/defined set of questions etc.
- Do you understand the extent of variability that is required for the asset? Consider the ratio of the features that vary a lot vs. the overall functionality. Even if you end up with a gross, high-level percentage it will help you during design.
- Consider specifically the aspects that vary and the number of variations you need to support. This is very critical to plan for the reusable asset. Remember, you are pursuing iteration not perfection! Draw a distinction between the variations that are an absolute must vs. ones that can be built over time. If you look back at the first point, maybe your business only needs the simple login using username and password. In that case don’t rush into building in variation support. On the other hand, if they come back and ask for multiple kinds of login you can always refactor to support variability.
- Will the capability add significant schedule or technical risks? If so, you need to make this transparent and get clarity from your sponsors. You can explain the rationale for investing in a reusable capability if there is business relevance. Similarly, if schedule risk is unacceptable or you have other higher priority assets to build, refactor, etc. then add this asset to the refactoring list and revisit later.
- Will the capability introduce deployment changes? Does it need an additional resource such as a database, a configuration file, or is dependent on an external service provider? In that case you will want to run it by your production support and operations partners and get their buy-in.