Agile (Adaptive) model
Contents |
Abstract
The agile (Adaptive) model is known from software development, where technology and customer demands change continually [1] . 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 [2].
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. [1]
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. [1]
Big Idea
Short intro to Agile framework...
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: [3]
"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan" [3]
Besides the manifesto the Agile Alliance agreed upon twelve principles of agile software which they would follow:[3]
- 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.
Agile (Adaptive) vs. Waterfall (Predictive)
When to use what
Hybrid product development process
Software vs. Hardware Development
Application
There are several different agile methodologies such as: Feature-Driven Development, DSDM, Extreme Programming, Adaptive Software Development, Pragmatic Programming, and Crystal [3]. 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.
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 [1]. The Sprint is fixed to a certain length at events not exceeding one month [6]. 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.
Three different aspects have to be addressed in the planning:
- 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.
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.“(6)
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.
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.
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.
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).
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.
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.[6]
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:
- 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:
- 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:[6]
- Creating the sprint backlog.
- Evaluate when a task is done.
- Adapting and adjusting the plan each day to reach the sprint goal.
Limitations
Big organization
-Need of documentation
References
- ↑ 1.0 1.1 1.2 1.3 Darrell K. Rigby, Steve Berez, Greg Caimi and Andrew Noble. (2016). Agile Innovation. Bain & Company. URL:https://www.bain.com/insights/agile-innovation/
- ↑ Nicola Garzaniti, Clément Fortin, Alessandro Golkar. (2019). Toward a Hybrid Agile Product Development Process. Product Lifecycle Management in the Digital Twin Era
- ↑ 3.0 3.1 3.2 3.3 https://agilemanifesto.org/
- ↑ 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.
- ↑ 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.
- ↑ 6.0 6.1 6.2 6.3 https://scrumguides.org/scrum-guide.html
- ↑ 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.
