Outside–in software development
Of all the agile software development methodologies, outside–in software development takes a different approach to optimizing the software development process. Unlike other approaches, outside–in development focuses on satisfying the needs of stakeholders. The underlying theory is that to create successful software, the team must have a clear understanding of the goals and motivations of the stakeholders. The ultimate goal is to produce software that is highly consumable and meets or exceeds the needs of the intended client.
Outside–in software development is meant to primarily supplement existing software development methodologies. While it is suited for agile software development, it is possible to fit outside-in development into waterfall-based methodologies.
The four stakeholder groups
What sets outside-in software development apart from other stakeholder-based approaches is the categorization of the four types of stakeholders. While the following four groups are unique however there can be and is usually a lot of interaction between them:
- Principals: The people who buy your software—the most important stakeholder to appease.
- End users: The people who interact with your product. They experience how your software works in the real world.
- Partners: The people who make your product work in real life, such as operations teams and also business partners and system integrators.
- Insiders: The people within your company that have some impact on how your team develops software.
It is crucial to speak with all stakeholders, even if they are not the primary audience of your software.
Implementing outside–in software development
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 lean-based software 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.
See also
References
- Carl Kessler and John Sweitzer. Outside-in Software Development: A Practical Approach to Building Successful Stakeholder-based Products, IBM Press.
- First Edition, 2008. ISBN 0-13-157551-1. Pp. 1–3, 23–31, 183–195
- Craig Larman and Victor R. Basili. Iterative and Incremental Development:A Brief History IEEE Computer, June 2003