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

Rainer Züst and Peter Troxler describe the importance of considering time-related changes in planning. As they describe it, systems and their environment change over time. It can influence the product's design and force the development team to make changes. One of R. Züst and P. Troxler’s suggestions to time-related changes is: “Recognise future changes in the system and environment and account for them in the planning process: Analyses of the past, the present and the future have to be integrated in the planning process.”<ref name="No more"> Rainer Züst, Peter Troxler (2006), NO MORE MUDDLING THROUGH: Mastering Complex Projects in Engineering and Management </ref>

Another suggestion could be to use an agile approach. Instead of analyzing the past, present and the future, and using a lot of time to make plans for it, the team could use a framework that is ready to adapt to changes. For this, agile methods would be a great match.

===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"> Kent Beck et al. (2001), The Agile 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:<ref name="manifesto"/>


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

===Product development===
Today agile methods are commonly used in the development of physical products as well as in software development. An agile model is often valuable for a development process with many uncertainties because of its flexibility. In a development process, there can be both external uncertainties as changes in customer needs, or internal as if the team, e.g. discovers a better technical solution. <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>

A lot more of the development processes today have a need for the flexibility that the agile models can provide. The two main reasons for this are how the market and the products have transformed. Today’s products acquire a lot more functions than back in the day. It can be difficult for a design team to determine all functions at the start of the development process. And the difficulty of forecasting the requirements for a product is only increasing. This leaves the design team with a lot of uncertainty and the need to be flexible. Furthermore, the market changes all the time, e.g. due to the fast development of new technology and the change of customer needs. Thereby, it can be challenging to forecast long-term market needs, too. Besides being flexible in the development phase, shortening the development cycle can be a good solution. <ref name="agile"/>

Some of the benefits an organization can achieve by using an agile method are that the product can tolerate a much higher risk of changes in the design. It can both be to avoid that the team must start all over if it happens that there is a new design requirement late in the process. But it can also be beneficial if the design team sees an opportunity in changes the design solution late in the process to make a better solution. Could, e.g. be if a new technology was introduced to the market. <ref name="agile"/>

===Agile (Adaptive) vs. Waterfall/Stage-gate (Predictive)===

Waterfall or stage-gate has been designed to select the right project or problem for the development team. Once selected, the team will map out and plan the whole process delegate roles and responsibilities to make structure in the development process. The idea is that the team cannot proceed to a new stage without being able to pass the requirements set for the gate. Once the team enter a gate, the stage before is done. One major advantage of waterfall or stage-gate is that they provide a lot of structure early in the process. Therefore, it is a good choice if the market conditions are stable and if the organization has done similar projects before. (Toward a Hybrid Agile Product Development Process)

One of the significant differences between agile and stage-gate is in agile methods, the team are only supposed to look at one feature of the product at the time in a short sprint. In a traditional stage-gate, the team would have a more holistic view of the product and work on all features simultaneously within the stage they happen to be in (agile innovation).

In Stage-gate/Waterfall, the organization is divided into big functional teams. They have a lot of interaction with the customers in the first couple of stages, where the development team are trying to understand the problem and where they are setting the design requirements. The team builds all features at once to meet the design requirements decided at the beginning of the process (agile innovation).

In Agile, the organization is divided into small cross functional teams. They have constant collaboration and interaction with the customer throughout the entire process. As the development team only are working on one feature at the time in Sprints and the most important features first, they will only build what is proven valuable (agile innovation).

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

Scrum is a framework created to develop software in a faster and more efficient way. The main goal of Scrum is to end up a minimum viable product (MVP) after each Sprint. The overall idea of Scrum is that you and your team have a Product Backlog with all your tasks for reaching the project goal. In the start of a new sprint, some of the tasks are moved into the Sprint Backlog. The team are when working on the task in the Sprint Backlog trying to reach the common Sprint Goal. This is typically done in a one-month long Sprint. Hereafter, the team present the done tasks represented as an MVP in the Sprint review for the PO and other important stakeholders. After the Sprint the team would have a Sprint Retrospective where they discuss the process of the previous Sprint, which they will use to improve their next Sprint.  <ref name="scrum guide"> Ken Schwaber, Jeff Sutherland, (2020), "THE SCRUM GUIDE: The Definitive Guide to Scrum: The Rules of the Game" 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>
====Scrum Events====
Scrum has several different events to structure the process. The different events are designed to make transparency and share knowledge within the Scrum Team. To reduce complexity, the different events should optimally be held at the same time and place each time.
=====Sprints=====
One of the events is the Sprints. The Sprints are only focusing on one feature and typically end up with some MVP <ref name="agile innovation"/>. The Sprint is fixed to a certain length at events not exceeding one month <ref name="scrum guide"/>. Sprint Planning, Daily Scrum/Stand-up, Sprint Review, and Sprint Retrospective are all events happening within the Sprints. A new Sprint starts right after the conclusion of the Sprint beforehand.
======Sprint Planning======

As the topic indicate, this event is a pre-event where the Scrum Team plans out the work that needs to be done within the upcoming Sprint. It is essential that the entire Scrum Team is present and collaborates in this event to make the best plan and forecast for the upcoming Sprint. It is also possible for the Scrum Team to invite people from outside the team to provide advice. The Sprint planning must be fixed to a particular time length. For a month-long sprint, the Sprint Planning event is fixed to a maximum of 8 hours (one day of work). If the Sprint is shorter, so should the Sprint Planning <ref name="scrum guide"/>. 

Three different aspects have to be addressed in the planning <ref name="scrum guide"/>:

*Why is this Sprint valuable?
The PO starts by coming up with a proposal on how the product could increase its value and utility after the upcoming Sprint. Hereafter, the whole Scrum Team collaborates to define a Sprint Goal to ensure that the team works towards a common goal. 

*What can be done this Sprint?
In a collaboration between the PO and the developers, items from the Product Backlog are chosen. It can be challenging to forecast how much can be done within the Sprint. Here it can be a good idea to look back at previous Sprints and the capacity in the upcoming Sprint.

*How will the chosen work get done?
The developers have to figure out how to finish the chosen items from the Product Backlog and how to reach the goal. This is often done by decomposing the items from the Product Backlog into smaller tasks that can be finished in a day or less.


The Sprint goal (why), the chosen items from the Product backlog (what), and the plan for how to deliver them (how) are combined, referred to as the Sprint Backlog.

======Daily Stand up======

Once a day, the Developers meet up for a 15-minutes event. The PO and the Scrum Master can attend if they work on an item from the backlog, but they have to participate as developers. The Daily Scrum should be held at the same spot and time every time to reduce unnecessary complexity. <ref name="scrum guide"/>

The overall goal of the Daily Scrum is to discuss the ongoing process and how well the team is doing toward reaching the Sprint Goal. If necessary, the team may adapt and adjust their upcoming work. Last, the developer team has to develop an actionable plan for the next day of work.
The scrum guide describes the reason for having Daily Scrum as: “Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.“ <ref name="scrum 2"/>

======Sprint Review======

The Sprint Review is the second to last event. Here the Scrum Team meet up with the PO and other potential stakeholders to go through what has been done in the Sprint. The progress toward the end goal is discussed in collaboration, and any changes in the Product Backlog may be adjusted. It is important that the Sprint Review become a working session and not just a presentation from the Scrum Team. For a month-long sprint, the Sprint Review should not exceed four hours. <ref name="scrum guide"/>

======Sprint Retrospective======

The Sprint Retrospective is the last event of the Sprint. Here the team will discuss how well the Sprint went to increase the effectiveness and quality for the next Sprint. The different elements to discuss could be individuals, the interaction between individuals, different processes or tools, etc. It is important to both go through what went well but also problems and how they were solved. The Sprint Retrospective should be the last conclusion of the Sprint, and the time spent should not exceed three hours. <ref name="scrum guide"/>

====Scrum Artifacts====

There are three different Scrum Artifacts: Product Backlog, Sprint Backlog, and Increment. They all represent work.

=====Product Backlog=====

The Product Backlog is a list of items needed to reach the overall product goal. The list should be ordered, with the most important task at the top. The PO creates the tasks, and if the developers want to change or add to the Product Backlog, they have to convince the PO first. The Product Backlog is the only source from which the developers can undertake work. If it is not in the Product Backlog, it is not a task that can be undertaken. <ref name="scrum guide"/>

=====Sprint Backlog=====

The Sprint Backlog is composed of three things: the Sprint goal (why), selected items from the backlog (what), and a plan for reaching the goal (how). <ref name="scrum guide"/>

=====Increment =====

An Increment is a finished task from the Product Backlog. An item from the Product Backlog becomes an Increment when it reaches the Definition of Done. Definition of Done is the quality measurement decided by the organization. First, when the item meets the Definition of Done, it can be presented in the Sprint Review. Otherwise, it will go back into the Product Backlog. <ref name="scrum guide"/>

====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 Scrum Team should be able to manage all types of tasks like research, development, maintenance etc. 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 Scrum Master is one person and is the leader within the team. The Scrum Master is accountable for setting up the Scrum Framework and ensuring that everyone in the team understands the Scrum theory and practice. In addition, the Scrum Master is accountable for: <ref name="scrum guide"/>


*Helping the Scrum Team choose and focus on high-value increments.

*Remove obstacles in the Scrum Team’s process and improve the practices.

*Make sure that all events within the Scrum framework take place and are productive to keep it within the scheduled time.

It is possible for a Scrum Master also to be a developer at the same time.

=====The Project Owner=====
In a project, there can only be one person as the Project Owner. The Project Owner (PO) is, in the end, the person who is responsible for the product and responsible for getting the most value out of the job done. The PO has mainly two tasks to be accountable for, the overall project goal and the Product Backlog. The PO’s task is: <ref name="scrum guide"/>


*Developing a clear project goal.

*Creating and communicating tasks for the Product Backlog.

*Priorities tasks in the Product Backlog.

*Ensure the Product Backlog is well understood.


It is okay for the PO to delegate the tasks above, but it would always be the PO who is responsible for the tasks. If any other person wants to change anything in the Product Backlog, they have to convince the PO.

It is possible for a PO also to be a developer at the same time.

=====Developers=====
The Developers are those who work on reaching the sprint goal in each sprint. There is usually up to 8 Developers in a Scrum Team. A Developer can have a broad variety of tasks depending on the project and on the sprint. But there are some tasks that the Developer always are accountable for:<ref name="scrum guide"/>


*Creating the sprint backlog.

*Evaluate when a task is done.

*Adapting and adjusting the plan each day to reach the sprint goal.

==Limitations==

There are a couple of limitations to implementing an agile workflow, especially for a big, established company. First, it can be pretty challenging to scale up, to fit it to a big company. Agile methods such as Scrum works best in a small team of around ten people. More people can work on the same project, but they should be divided into smaller teams of around ten people. This leads to the next limitation, the lack of documentation. Once more teams work on the same task, documentation is good. But one of the ideas behind agile frameworks is to keep documentation at a minimum. The lack of documentation can also become an issue if someone else has to take over a project, e.g., a firing of an employee. Last, it is a big limitation that a company has to rethink the whole structure of the company and make new cross-functional teams.

==Annotated Bibliography==

====The agile manifesto <ref name="manifesto"/>====
This is a website where it is possible to read about the core values of Agile Development and the 12 principles of agile software. Furthermore, it describes the history behind the Agile Manifesto and how they developed the manifesto. It is also possible to read about the authors of the Agile Manifesto.

====Agile innovation <ref name="agile innovation"/>====
This source is excellent at explaining how Agile operates in general. It has a great description of the differences between traditional frameworks and agile frameworks. It is a good objective source that not only tries to get people to use agile frameworks but explains when to use traditional frameworks and when to use agile frameworks. It also describes the keys to success and how to add value to your innovation by implementing Agile.

====The Scrum guide <ref name="scrum guide"/>====
The Scrum Guide is the official guide on how to implement Scrum to your design process. It explains every step of the process and how to set the process up. It describes the purpose and values behind Scrum. It explains how to set up the team and all the different events throughout the process. After reading this source, you will be able to apply Scrum to your design process.

==References==
<references/>