Cautionary Guidance for Agile With COTS
Cautionary Guidance for Agile With COTS
This article covers 5 points of consideration in evaluating packaged solutions and Agile.
Join the DZone community and get the full member experience.Join For Free
I work for a large systems integrator, and a large part of our business is in the implementation and maintenance of packaged solutions. As such, I’ve received a lot of inquiries in our technology advisory business related to the application of Agile practices to packaged software environments. Below are 5 points of consideration in evaluating packaged solutions and Agile.
Don't Allow the Strategies to Become at Odds
For most organizations, the benefits case for packaged implementations are predicated, in part, on the assumption that these solutions will be implemented “out-of-the-box”, and in doing so these programs include consideration for change management to align the business to the standard process model. In contrast, Agile is designed for the context where we understand the optimal end state can not be known at the onset, and thus optimizes for the ability to exploit emergent opportunities over conformance to plan. Unless a thoughtful strategy is devised to resolve these conflicts the likely outcome, would be increased tendency towards undesired levels of customization of the core product.
Do Apply Agile for Sustainment
Maintenance activities should certainly favor a more Agile approach and would benefit from introducing Kanban methods over traditional ITIL based processes. SCRUM could also be modified to include guard rails for “out-of-the-box” governance. In this case, the Lean Start-up principle could apply—if what we value is validated learning (is the future state OOTB process acceptable to the business?) and we can accomplish the learning without building software at all then the conference room pilot from our ERP playbook might actually be the more Lean concept to apply.
Delivery Ecosystem Readiness
If you’re delivering the solution with teams that are functionally fluent in both Agile and the functional reference architecture of the packaged solution then there is opportunity to architect appropriate guard rails into the approach. I have once attempted in a Systems Integrator role to apply a program level Agile methodology standard to vendor sub-teams specializing in particular packages. In that experience we found that the vendor had an established methodology they were comfortable operating within for the particular package—and as thoughtful as we believed the Agile approach to be at the onset, in hindsight we questioned whether the effort was justified and suspect we might have governed customization more effectively through the partners native approach.
Data and Integration
The world of designing schemas, ETL transformations and data conversions fall into a category of their own that necessitates thoughtful planning ahead of core implementation. This reality really excludes these areas for real consideration of a purist SCRUM/Agile approach (with exception given to UI/reporting components). In the DevOps/custom world, we now have tools to combat these issues with Micro Service patterns (de-coupling/de-normalizing data architectures and building more event-based integration styles). The traditional patterns we are working within packaged product integration styles do not afford us these luxuries, however, at least not yet.
Think Twice If Time to Market Is Critical
Most organizations I’ve observed have de-coupled the release process of customer systems such that they support off cycle (Agile) releases separate from the coordination required for integrated enterprise releases. The challenge comes in the fact that for many organizations the opportunities where time to market is important actually are dependent on back-end systems changes (e.g., publishing new customer offers). In this context, multi-speed falls short of delivering the value the business requires from its technology platforms. For that reason, the question often is not “how to do Agile with packaged solutions”, but rather how to avoid packaged solutions where Agility is important.
Opinions expressed by DZone contributors are their own.