Outside–in software development: Difference between revisions

Revision as of 19:55, 4 July 2017

Revision as of 08:33, 15 November 2017

Line 1:

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, youthe team must have a clear understanding of the goals and motivations of yourthe stakeholders. YourThe ultimate goal is to produce software that is highly [[Consumability|consumable]] and meets/ or exceeds the needs of yourthe intended client.

Outside–in software development is meant to primarily supplement your existing software development methodologymethodologies. While it doesis ideallysuited work in morefor agile environmentssoftware development, it is possible to fit outside-in development into [[waterfall model|waterfall]]-based methodologies.

to fit outside-in development into [[waterfall model|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. TheWhile the following four groups are unique, buthowever there can be and is usually a lot of interaction between all fourthem:

* '''Principals''': The people who buy your software—the most important stakeholder to appease.

Line 19 ⟶ 18:

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