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 behind outside–in software is that to create successful software, you must have a clear understanding of the goals and motivations of your stakeholders. Your ultimate goal is to produce software that is highly consumable and meets/exceeds the needs of your client.

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.

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. 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 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 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.

See also

References

This article is issued from Wikipedia - version of the Saturday, April 20, 2013. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.