Do the merits of Agile as a build approach for software development equally apply when implementing standard software?
For many years Agile has been successfully used in software development projects. Its merits are most obvious when having to build something that hasn’t been done before and when the user or client is unable to picture the desired end result with all requirements specified at a sufficient level of detail.
The iterative approach in the Agile methodology addresses that fundamental problem by parallelising the phases of design, develop, and test that are distinctly separated in the classical, incremental Waterfall approach into a series of iterative Sprints. This allows for the user to understand what they really need while the developer learns how to best build it. The very same concept also provides for much more flexibility when having to deal with frequent changes on the way. More so, Agile is able to facilitate frequent changes in scope and/or requirements whereas Waterfall avoids the same once the design is signed off.
The below picture shows the fundamental difference between the incremental approach in Waterfall versus the iterative nature in Agile:
Given the obvious advantages of Agile in software development it is no wonder that projects implementing standard software like SAP started to look at Agile some 10 years ago. But then, the very benefit of deploying standard solutions is that there should not be a lot of developments to be done in such projects in the first place.
And there is the challenge. For too many years customers implementing standard software have spent a lot of time and money to make their solution as specific as possible, often with lots of add-on developments and even modifications. This has contributed to a perception that SAP implementations are complicated, take long, and are expensive. Interesting to note that I never heard any customer complaining about Waterfall being so resistant towards change whilst scope control discussions are a constant in any given project.
Today’s organisations want fast implementations with tangible business impact. They are looking for cloud solutions which naturally come with more restrictions for custom-build enhancements or even modifications. At the same time many prefer sticking to an incremental approach towards deploying their solution in order to remain in control of the expected and predicted outcome. No need to say that every customer also needs flexibility in terms of responding to changing business conditions. The latter has not been more prevalent than now.
All of that requires a specific approach when looking at the implementation of standard software solutions like SAP. On the one hand clients like the fact that Agile produces useable solutions quicker and the flexibility it provides. On the other hand, clients often don’t like the notion of Agile being so tied to software development when they just want to leverage the benefits of a standard software solution. Also, not every organisation is ready for an Agile approach as they feel they have less control over the final outcome or key individuals cannot be dedicated to the project as needed.
Fortunately, the best of both worlds can be blended to successfully deliver implementation projects leveraging standard software solution be it on premise or in the cloud.
I have used the following approach when discussing the best way to achieve both speed, user acceptance, minimal enhancements and add-ons whilst allowing for flexibility when having to adopt changing circumstances.
- Assess the general Agile readiness of the organisation
- Understand Agile specific roles and responsibilities, ground rules, and success factors
- Agile project governance and project setup
- Lean Blueprint approach to create the Product Backlog
- Breaking down the Product Backlog into User Stories
- Story Mapping from a first feature set of a walking skeleton to full functionality
- Definition of Done
- High level estimation and release planning
- Organise realisation of the first release in Sprint Cycles
- Final preparation and Go-Live of Release 1
Obviously, the first point is critical in understanding whether or not Agile can work and be beneficial for a given project in a specific organisation. If this check shows more No’s than Yes’ or if the score is below 50% than a Waterfall approach is likely to be the better option. Where the scores indicate a better general readiness, it is prudent to ensure the client understands how Agile can be used successfully. Going through points 2 – 10 of the above with various key stakeholders will do exactly that.
In my own experience I have seen Agile working very well in standard software implementation projects. This is particularly so when there are many unknowns like new technologies or new (business) solutions at play. If an organisation is ready for Agile, I would always recommend going for it. The benefits of better-quality results, early visibility into what the project is in fact building, and the ability to cope with change in the project are simply too valuable to be missed.
Let me know what you think and what your experiences are in using Agile in standard software implementation projects. I am also keen to hear about how your Agile projects have fared in times where most if not all work is done remotely.