Outside-in software development is meant to primarily supplement your existing software development methodology. While it does ideally work in more agile environments, it is possible to fit outside-in development into waterfall-based or six sigma methodologies. Outside-in software development is not a catchall solution, but a way to better your existing methodology.
What sets outside-in software development apart from other stakeholder-based approaches is the categorization of the four types of stakeholders. The following four groups are unique, but there is a lot of interaction between all four:
It is crucial to speak with all stakeholders, even if they aren't the primary audience of your software.
The outside-in approach does not require your entire development methodology to change. Outside-in development can supplement the existing tools of developers.
Outside-in development works particularly well in the context of agile/lean development. One of the major tenets of agile development is to program with the least amount of waste. Outside-in methodologies promote only developing according to stakeholder requirements. By identifying your stakeholders properly and soliciting helpful feedback early on in the development process, agile and outside-in methodologies can mesh together seamlessly.
Kessler and Sweitzer recommend that, no matter what kind of development methodology you employ, you incrementally introduce outside-in development to your team. They cite the lack of enthusiasm by developers as the main reason to not implement sweeping, large scale change.
Outside-in software development should not be introduced as a holistic development process. It is meant to supplement your current software development methodology.