Few techniques for better product agility
Product Road-Map – One Road-Map for One Product serving multi Clients
Building a product usually requires a lot of different road-maps like development, design for web and design for mobile, sales, and other stakeholders.
As a supplier or service provider like to see a single road-map that shows these together in the same view, giving high level overview of the entire product progression. It can get a bit messy when multiple client and multiple product versions in production and multiple teams managing their road-maps.
Multiple road-maps should be merged into a single view called a master road map, making sure teams have the ability to work on the road map and easily change things around.
Road-maps can change every day or every week. Managing multiple road-maps at once should not be a daunting task but an exciting one that allows you to quickly view the holistic business strategy from a bird’s eye view.
One Code Base – Single Source of Truth
One of the biggest hurdles is merging the code and this may make or break the team not just the code. In typical waterfall projects, this event usually comes at fag end of the project as part of build and integration. In Agile this is one of the key areas where “check in often” concept comes in and “Continuous Build and Integration”. This comes as a savior, only if one understands the right way of doing “check in often”. Agile consultant or the coach can help. But the underlining point is having one code base. Merge all the changes, hot fixes into the mainline. And branch out releases to customers. But never do the changes in the customer release branches. Make the changes in the Mainline by branching out for the development.
On / Off Product Feature Specifications
Apart from the standard customer environmental conditions, get the product configurations, the on / off feature conditions as part of the environmental changes. To deliver the releases to a particular customer, branch out by applying the environmental changes, product configurations to the main code. Deliver it as a new release or version to the intended customer. Ensure the environment and customer configurations are managed through the traceability. You can better implement the application level switches ( UI display controls ) and the static switches (in the application )
Minimize Test Environments
It is highly unlikely that production like environment will be available for the developers. Complexity increases if the product is used by multiple unique customers Challenge for getting the environments and the test data both. Hence minimize at least by combining system, integration, and regression and performance test environments. You may have multiple environments, but common configuration and common test data across all. This ensures you find the defects as early as possible and don’t have to wait for the regression. Even if the build passes in system testing and fails in integration testing, it becomes much easier to debug the failure and give right fix.
Conventional practice is doing testing and if more defects found, do the defect analysis, do the RCA, add more test cases and do more testing. To support this we may have separate test environments for each type of testing to have focused testing. Now with multiple teams like development, patch, hot fixes and maintenance changes by the support team, team could be well organized to manage the testing, but probability of one fix breaking other fixes or breaking the old fixes is more. Probability of fix in integration, breaking the system testing defect are more
Better Deployments, Push to Customer Servers and Pull by the End Systems
Considering the example of deployments in the media domain, first push the working-build to the media data center or the private clouds or to the server at customer site. Now the next step is to, trigger the pull in end systems when they are ready to go down for the new patch installation. Deployment should be automated with rollback built into it.
Engineers may have to do manual sanity post the automated sanity test. If an issue is discovered in any step during the deployment or during the sanity test, roll back the changes immediately. This again from same customer server or the cloud data center to the end systems.
Route the requirements from multiple clients through the common backlog management team who add the details on impact to the different customers and changes needed in the product with mindset to ensure the common code for all the customers. Requirement Traceability may come handy here.
Free Patches: So proactively providing the free patch upgrade with no changes to the customer functionality will increase the confidence and will result in win-win eventually. As part of free patch upgrade, ensure you help with managing server and end system environment upgrade also.
This not only increases the stability of the product. Also defects reported by one client, is fixed for all clients, which the others may not have encountered but this surely this gesture will be appreciated for increased quality product and thus improved and stronger relationship.
Paid Patches :For new features added in the product, send the new proposal, with details of warranty and expiry for the old release. This is an opportunity to value add and customer decides to go for it of no. If yes, free patches also to continue until next paid patch. Old release shelf life has to be ended similar way to OS / ERP.