Pursuing systematicis fraught with risks – hence the motivation to take a pragmatic, approach. What exactly does that entail? This post will introduce four key ingredients when pursuing agile software reuse:
You can keep building one-off components and services and hope they all fit together nicely. But, that would be wishing for something that is extremely unlikely. Hence the need for a roadmap. The reuse roadmap is your guiding compass that provides business vision/objectives, a set of phases that transform the way you build software, and planned high-level milestones. Why is this roadmap important? Because you need to make sure that your reuse objectives are aligned with tangible business goals. Reuse pursued as a technology-focused objective will yield only minimal benefits. This shouldn’t be vaporware or slideware but based on ground realities in your organization. My recommendation: start small and keep things simple by pursuing reuse within a pilot project or two, get traction, and build on it. Start firmwide and your chances of success will dwindle very rapidly.
You need to ensure that every iteration is aligned with your reuse roadmap. Your iteration has tangible features that are being implemented. They become much more effective if they are aligned with your overall vision. This isn’t meant to make every feature reusable or every iteration produce reusable assets. Just the opposite. Continuous alignment accepts that building reusable software is hard, takes time, and is . You can fight that and stand firm on producing perfect assets. That will not only add needless complexity but increase schedule risk for your iterations. Instead the idea here is to align assets towards reuse. This could be refactoring existing code, wrapping legacy service capabilities, or building a sub-set of a new asset’s features. Make your best efforts to align project backlog and refactorings with reuse objectives. This won’t always be possible and that is okay. Agile practices advocate exploration and alignment rather than prediction and certainty. Continuous alignment simply extends these ideas towards systematic reuse.
Agile practices espouse simple design and avoiding big design upfront (BDUF). Iterative design is to build a reusable asset in successive iterations. Too many systematic reuse initiatives have failed in pursuit of the perfectly reusable software component or service. Business requirements, motivations, and goals change continuously and trying to implement the perfect asset only makes design risky. Iterative design also is about building for your immediate requirement and nothing more. Have a very cool idea to extend an asset? Add it to your project lists of tasks or refactorings and align them with iterations as appropriate. Just design what you must. There are times when you know future requirements and you can build towards that but those are still predictions. When in doubt, go back to the basics: understand your domain, clarify existing domain models/relationships, refactor the design, and build towards reuse. Never hesitate to delay commitment.
Systematic reuse isn’t about technology or software techniques alone. It is a rich-interaction activity that involves every member of your team. Teamwork is key and foundational in achieving reuse objectives. Your daily standup meetings, iteration retrospectives, and are all opportunities for your team to examine work in light of your reuse roadmap. Collective code ownership, continuous refactoring, and integration are practices that require your team’s contribution. Simply put – without constructive dialogue, reuse-friendly conversations, and passion, reuse will remain a dream. Your team is practicing iterative design, pursuing continuous alignment when planning iterations, and ensuring your codebase is in the accordance with the systematic reuse roadmap. No teamwork, no reuse!