Agile and SaaS is an animated relationship
Agile is marketed as a fun, stress free and productive way of working. It has some of those things, some of the time. Just as any other methodology also has some of those things some of the time.
With any tech implementation you’ve got massive odds stacked against you up front.
First is the cost, a huge investment which at some point someone will go “my gosh, this is costing way too much”. Second is the activity, bumps, stress and issues that is related with any complex project. Third is the incredible complexity of going from an old state to a new state that is still largely undefined and all the cultural issues that entails. And finally, fourth is the reality of the software & hardware stack you’ve chosen, it does some things well, others not.
This is what you need to blend together effectively to have an outcome that is measurably successful.
SaaS complicates this because it’s a shared resource, and has been built to have a standardised infrastructure that can then be utilised by multiple parties. There are benefits to the parties here in that it limits their responsibility to what one could call the ‘value layer’, the part of the application where business process happens, and not worrying about back end infrastructure (in theory).
There is a cost to this benefit though, limitation. SaaS is typically built for speed to value, with a compromise on pixel perfect UI and automation options. What further complicates this is the ongoing maintenance requirement and the skillset required for that. Yes you may be able to build something in SaaS platform that it doesn’t natively do well, but then it will need to be maintained and tested ongoing requiring specialist skillsets that is hard and expensive to find.
Because of this, the relationship between agile and SaaS is more complex. If there isn’t enough value in doing something in a SaaS application, you shouldn’t do it, even if it’s easy to do. Agile is also centred on the end user, as it should be. With SaaS it’s not as simple as that as the core application already has prebuilt processes and a user interface. This is one of the benefits, but most companies struggle to adopt this and still want to bend the application to their existing often outdated processes. The I.T team want something that scales and is easy to maintain, each business unit wants something that is bespoke to them, usually catering to plugging existing gaps instead of building for the future. eg “Jenny send Joe a spreadsheet over email, can they send the spreadsheet over the CRM instead”.
The typical response to this argument is that this should all be worked through, groomed and prioritised. The issue with this is that the next sprint is just days away and you’re still dealing with the speed bumps in the current sprint. Time is against you and these things are important and take time to flesh out.
I don’t offer any silver bullets for this other than making sure there is recognition that what you’re embarking on is difficult and all parties respect this. It won’t be pretty, you’re reinventing to a future unclear (but better) state whilst still operating the current one, with some people who only live in the future, and others who only live in the past.
Some simple advice to get through would be spending much more time than you think on detailed process design and thinking full releases, not sprints ahead and having a dedicated group only focusing on way in the future.
Agile falls flat once the key focus is on stories, estimation, ceremonies and points. It should always simply be focused on higher level principles such as value creation and response to change.
