I’ve been seeing a lot of references to continual development methodologies lately (ie references to agile, DevOps, CI/CD, etc). Quotes like focus on projects rather than the mission statement, focus on products rather than projects, etc. The core principle is in chunking workload down into modular pieces that can be implemented to give flexibility and agility to meet evolving customer demands. These approaches are claimed to improve customer-centricity as well as improving our ability to deliver.
This is great thinking, but we aren’t quite there yet. Do you notice that these measures have a tendency to be introspective (ie the service provider’s business goals, usually product delivery-related goals)? A customer’s experience isn’t directly related to mission statements, projects, epics or even products. It relates to their end-to-end experience with the service provider’s brand, which means all the components that make up their service. It’s the whole pyramid of pain (as opposed to the service provider’s product definition) and all the disparate business units that contribute to the customer experience.
Continual development is about the slicing and dicing into manageable chunks. The next step is the ability to slice those chunks smaller still, into chunks per service instance, and stitch all of these together to give a service stream. Not just orchestration, but omni-experience orchestration that traverses the entire pyramid experienced by every individual customer.
This is probably too atomic to be managable for a service provider and their current OSS. However, improvements in AI / ML have the potential to have a huge part to play in the next methodology evolution, taking feeds from dev data sources as well as ops data sources. It has the ability to guide customer-driven development rather than product-driven development.
Not just marketing to the segment of one, but development driven by the experiences of one.Read the Passionate About OSS blog for more.