Process for handling multiple types of work
Hi all,
I work for an organisation that provides B2B SaaS products - the products are not just 'plug and play', they require configuration and customisation for each individual customer.
The same teams configure new products as well as provide updates and improvements to existing customers. We are getting to a point where trying to handle both the new customer work and work for existing customers is becoming problematic in terms of scheduling, knock-on effect if/where work is delayed etc. and wanted to know if anyone else had encountered the same issues and how they went about resolving this? Were new ways of working introduced, splitting teams up, other??
It sounds as though you have technical debt due to the lack of that plug-and-play capability. A pain point is now felt and is likely to increase because of impeded scalability.
Is the remedial work to achieve plug-and-play accounted for yet on a Product Backlog anywhere?
If customers of your "SaaS" product can't configure it themselves, then it seems that you're offering services other than the software. In addition to the services associated with developing, deploying, operating, and maintaining the software system, you're also offering services regarding configuration and customization.
It seems like there is work to be done. This would allow your customers to perform their configurations and customizations when completed. This would shift the burden from the development team to the customers, allowing the team to focus on the system rather than each customer.
Another option would be to have a second part of the organization handle configuration, customization, and other types of support work. Creating a customer service or client service organization can allow you to segment the work. This could be advantageous since the work for configuration and customization is, in my experience, more likely to be fundamentally different than building the software system.
Even if you choose to form a team or teams to handle onboarding, configuration, and customization, these teams should be able to work without deploying the software product. Having a software architecture where configurations and customizations require deployment often increases complexity, which adds risks to the development of new features and functionality.
The decision rests with broader organizational goals and objectives.
@Ian and @Thomas have given you good advice and it is advice that I have found useful. Although I will give you something to think about.
Does your organization actually have a software product or is the work to customize each solution to the customer the actual product? Honestly, from your short description, it sounds like you offer B2B SaaS customizations rather than products. I worked in a similar company many years ago. It was a small company that had found a niche that made some decent profits. But there was very little consistency between customers and most of them worked in different industries. The way we dealt with the work was to limit the number of customers we had and were happy being a small niche provider. That company survived for years but it never got bigger. It was big enough to keep the people working there happy until the owner decided to retire.
I offered that story because it sounds like your organization is at a point where they need to decide what it is they really want to be. If they want to keep growing, then they need to take a long hard look at their product offering and decide what it is going to be. For that I refer you back to @Ian's and @Thomas' suggestions. Because until you make those kind of decisions, there isn't much that the Scrum framework alone can do to help you out. The Scrum framework is theocratically based upon having a single team work on single product. (Or at least that is how I interpret it.) Since each one of your product solutions is custom made for the client, it seems like you would need quite a few teams to deal with this.