View source for Agile (Adaptive) model

__TOC__
==Abstract==

The agile (Adaptive) model is known from software development, where technology and customer demands change continually <ref name="agile innovation"> Darrell K. Rigby, Steve Berez, Greg Caimi and Andrew Noble. (2016). Agile Innovation. Bain & Company. URL:https://www.bain.com/insights/agile-innovation/ </ref> . The agile way of thinking is slowly gaining a foothold in physical product development, especially in projects where the customer needs changes frequently, and there is a need for fast and adaptive response <ref name="towards">  Nicola Garzaniti, Clément Fortin, Alessandro Golkar. (2019). Toward a Hybrid Agile Product Development Process. Product Lifecycle Management in the Digital Twin Era </ref>.

Agile methodologies differ in many ways from traditional methods like waterfall. The main difference is that instead of dividing the process into phases, the agile model works in sprints. Instead of focusing on all aspects of the project at once, every sprint deal with one only feature. A sprint is usually a couple of weeks long, and every sprint goes through design, develop, integrate, test, and deploy phases, and ends up with a minimum viable product (MVP). Ideally, an agile team should be small and cross-functional to minimize communication delays. The team must constantly collaborate with the customers to understand their needs and eventually changes of needs. <ref name="agile innovation"/>

It is important to point out that agile methods are not better than traditional methods and the other way around. But it is important as a product developer to understand when to use which kind. An agile way of thinking is ideal when the market frequently changes, where a more traditional workflow should be preferred if market conditions are stable. If it is a complex problem where the scope is unclear agile would be a good solution, but if the scope is clear and the team has done something similar before, traditional methods are a good choice. Therefore, it should be discussed before starting every new project whether to use an agile or a traditional workflow. <ref name="agile innovation"/>

==Big Idea==
===The Agile Manifesto===
Back in February 2001 seventeen people gathered at The Lodge at Snowbird ski resort in Utah over three days to get mutual understanding and to uncover a better way to develop software. The people gathered was independent thinkers about software development, and they named themselves “The Agile Alliance”.  The result of the conference was the Agile “Software Development” Manifesto: <ref name="manifesto"> https://agilemanifesto.org/ </ref>


<blockquote>"'''''Individuals and interactions''''' ''over processes and tools''</blockquote>

<blockquote>'''''Working software''''' ''over comprehensive documentation''</blockquote>

<blockquote>'''''Customer collaboration''''' ''over contract negotiation''</blockquote>

<blockquote>'''''Responding to change''''' ''over following a plan''" <ref name="manifesto"/> </blockquote>


Besides the manifesto the Agile Alliance agreed upon twelve principles of agile software which they would follow:


*Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

*Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

*Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

*Business people and developers must work together daily throughout the project.

*Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

*The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

*Working software is the primary measure of progress.

*Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

*Continuous attention to technical excellence and good design enhances agility.

*Simplicity--the art of maximizing the amount of work not done--is essential.

*The best architectures, requirements, and designs emerge from self-organizing teams.

*At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.<ref name="manifesto"/>

===Agile (Adaptive) vs. Waterfall (Predictive)===
<ref name="agile"> Thomke, S. and Reinertsen, D. (1998) ‘Agile Product Development: MANAGING DEVELOPMENT FLEXIBILITY IN UNCERTAIN ENVIRONMENTS’, California Management Review, 41(1), pp. 8–30. doi: 10.2307/41165973.</ref>
====When to use what====
====Hybrid product development process====

===Software vs. Hardware Development===
<ref name="soft vs. hard"> P. M. Huang, A. G. Darrin and A. A. Knuth, "Agile hardware and software system engineering for innovation," 2012 IEEE Aerospace Conference, 2012, pp. 1-10, doi: 10.1109/AERO.2012.6187425. </ref>
==Application==
There are several different agile methodologies such as: Feature-Driven Development, DSDM, Extreme Programming, Adaptive Software Development, Pragmatic Programming, and Crystal <ref name="manifesto"/>. But one of the most commonly used agile methodologies is SCRUM.
===Scrum===
<ref name="scrum guide"> https://scrumguides.org/scrum-guide.html </ref>
<ref name="scrum 2"> N. Garzaniti, S. Briatore, C. Fortin and A. Golkar, "Effectiveness of the Scrum Methodology for Agile Development of Space Hardware," 2019 IEEE Aerospace Conference, 2019, pp. 1-8, doi: 10.1109/AERO.2019.8741892. </ref>
====Sprints====
====The Scrum Team====
In each Scrum Team, there should be one Project Owner, one Scrum Master, and several Developers. When using the Scrum framework, it is important to have a small cross functional team. Meaning that the team members together should have all the skills necessary to complete the work in each sprint. The team should be small enough to manoeuvre quickly and have good communication, but big enough to complete the job in each sprint. A rule of thumb is that the team should not exceed the number of 10 people. If the number exceeds 10 people, it is possible to divide the team into two Scrum Teams working on the same project but sharing Project Owner and Project Backlog to ensure that they are not doing the same work twice.<ref name="scrum guide"/>
=====Scrum Master=====
=====The Project Owner=====
=====Developers=====
====Project Backlog====
====Sprint Backlog====
====Daily Stand up====
====MVP====

==Limitations==
==References==
<references/>