The pace of change in business is accelerating, and this is especially true in the world of development. Thanks to new frameworks and tools such as Docker, custom development can now run at a pace unthinkable just a few years ago.
This is also true in the cloud, with Salesforce development, cloud-based development tools such as SAP Web IDE and next-generation integration tools, such as Dell Boomi offering fast and secure development paths. Compare this to packaged software, where complex development tools require setup and configuration followed by heavily governed change processes with complex transport procedures. How could the two possibly coexist, and within an Agile project to boot?
Agile methodologies are not simply about speed - in fact the main benefit of any Agile approach is a focus on delivering value to the business, by dealing with change and delivering the 'right' functionality for end-users. From this perspective, the underlying technology used to deliver the functionality is irrelevant, as the methodology provides the framework to adapt to change and focus on delivering the greatest value to the business.
Having worked on a number of Agile projects that mixed packaged software with either custom development or SaaS deployment, there’s been a few key lessons that I've learned along the way;
Educate the team
If your project utilises multiple technologies (and most do), you will likely have a team with varying levels of experience in each solution component. It is therefore important to educate the team about the capabilities and limitations of your packaged software. This does not mean turning your whole team into experts, but giving everyone a basic grounding in the packaged software will be invaluable as your project progresses.
Understand the constraints of the packaged software
It is critical to fully understand the constraints within which you are operating. This means knowing a release schedule set in stone, understanding the level of support available for the packaged software, recognising the governance processes in place and their impact on your timeline, and appreciating the lead-time needed to move changes through the system landscape (i.e. Development, Test to Production). Once understood, you can plan within these constraints and identify key issues that need to be challenged or require careful planning. This should help avoid running into barriers unexpectedly.
Ensure a unified view of high-level architecture
Everyone in the team needs to have a clear view of the high-level architecture as it evolves over the course of the project – understanding what each element of the solution is responsible for, and when a change to one element will likely impact the others.
Get early agreement on solutions
Within every project lifespan, a number of key decisions will be made on solutions to particular challenges or issues. On each occasion, the decision needs to be identified and then made as early as feasible. This helps to ensure that any work required within the packaged software can be assessed and understood, with any follow-on challenges or limitations raised 'on paper' rather than after development has started.
Remember that packaged software has a purpose
Regardless of which packaged software you are using, it will have been designed to deliver a specific set of functions - which it will do very well. So, be sure to make use of this functionality as much as you can. There is little value in re-developing functionality that your packaged software provides in other platforms, and while that may mean you need to expose this functionality in a more readily consumable manner, it will ensure consistency within your solution.
In my experience, Agile methodologies and packaged software can be a good fit, although it may require slightly more planning, effort and some slight adjustments from a 'normal' Agile project. By following the lessons above (and likely learning more of your own), you will be able to deliver more value, and deal with change within an Agile project that utilises packaged software.