Agile model

Latest revision as of 12:36, 20 March 2022

Written by Berta Viñas Redondo (s202256)

[edit] Abstract

Recently, the world has become much more complex and unpredictable, a special acronym has appeared to describe it, “VUCA”, which states for volatile, unpredictable, complex and ambiguous. ^[1]

The fast pace of changing technology and evolving markets, leads to the need of adaptative and flexible project management approaches. Agile model is an iterative project management approach, that consists of breaking down the development process into small iterations. It also emphasizes the importance of collaborating with the customer and having their feedback throughout the process. Therefore, requirements and solutions evolve through collaboration between cross-functional teams. It encourages frequent inspection and adaptation for rapid delivery of high-quality solutions that are aligned with customer needs.

Agile first appeared in the early 1990s within the software development industry and is based on the Agile Manifesto and its 12 principles. Since then, many agile frameworks have emerged such as Scrum and Extreme Programming (XP). Nowadays, agile has become very popular within many organizations.

This article introduces the agile concept and presents the main values and principles defined in the Agile Manifesto. Next, it compares agile over the traditional project management methods and then describes the different agile frameworks, Scrum and Extreme Programming and its applications. The article concludes by analyzing possible limitations of agile.

[edit] Big idea

[edit] What is Agile?

Agile methodology is a project management process that is based on breaking down the project development into more manageable tasks, which are completed in short iterations. At the end of each iteration, it is expected to deliver smaller projects, that could be fragments of functionality. It is also an incremental process, meaning that each iteration includes the functionalities of all the previous and current iterations. Therefore, the final delivery contains all the required project functionalities. The iterations normally last around two weeks, depending on the size of the project. ^[2]

The agile philosophy stresses the importance of centering the project development on the customers' needs. It mainly focuses on the collaboration between the development team and their customers. After each of the deliveries, it comes to a testing process together with customers so that they provide feedback to the team. This feedback will allow the team to make changes and improvements through the following iteration. ^{[3] [4]}

In general, agile methods are used in small teams (from 5 to 10 people) that are normally located in the same physical space. ^[5]

Agile process

Mainly, the agile ^[6] process could be divided into different stages:

• Scope: define the project scope, analyze concepts and plan requirements.
• Plan: organize teams and tools and plan the iterations.
• Implementation: frequent development delivery through iterations.
  • Development
  • Test
  • Deliver
  • Feedback
• Release: release the project.
• Maintenance: follow-up process.

The goal of working in small iterations is to deliver fast solutions in order to get feedback from the customers and be able to constantly improve, evolve and respond to changing requirements during the process.

The agile methodology has its origins in the software industry, when software developers were looking for a better and more flexible way to develop software due to the fast changing and continuous updates of technology.

[edit] Agile Manifesto

In the 1990’s, because of the fast-changing new technologies, the software development industry realized that it couldn’t move fast enough to meet customers’ demands and requirements. On February 2001, a group of software developers, who formed the Agile Alliance ^[7], gathered to discuss the main industry practices aiming to find a better approach to the traditional development process, such as the Waterfall methodology ^[8]. They ended up creating the Agile Manifesto ^[9], that marked the birth of agile as a methodology.

This document contains the four basic values and twelve principles that are characteristic of the agile philosophy.

Agile main values defined in the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

and 12 principles:

1. Satisfy the customer through early and continuous delivery of valuable software.
2. Welcome and harness changes for the customer's competitive advantage, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for shorter timescales.
4. Have daily collaboration between business people and developers throughout the project.
5. Build projects around motivated individuals. Create the environment and support developers need, and trust them to get the job done.
6. Prioritize face-to-face conversation as the most efficient and effective method of conveying information to and within a development team.
7. Measure progress by the amount of working software completed.
8. Maintain a constant and sustainable pace of development indefinitely.
9. Enhance agility through continuous attention to technical excellence and good design.
10. Keep it simple. Simplicity—the art of maximizing the amount of work not done—is essential.
11. Recognize that the best architectures, requirements, and designs emerge from self-organizing teams.
12. Regularly reflect and adapt behavior for continual improvement.

[edit] Agile vs. Traditional methods

Agile was born as an alternative to traditional development methods, such as the Waterfall, which are based on a predictive rather than an adaptive approach. Predictive methods focus on up front planning with requirements fully defined at the beginning of the project development meaning that they are less flexible. Sometimes this could become a challenge for more complex and long-term projects where it is difficult to clearly define the requirements in earlier stages. Furthermore, possible changes in the future require a more strict change control management and prioritization. However, this approach can be efficient for very specific and well-defined projects. Therefore, these methods demand a high level of engagement from the customer at the initial stages when defining the project scope and requirements.

Traditional methods follow a sequential process where each stage needs to be completed before the next one can begin. On the other hand, agile breaks down the project development into smaller and adaptive iterations. For this reason, agile doesn't require a detailed planning as there is the opportunity to adapt the work in previous iterations. The team is able to adapt to changing product requirements dynamically and the release and feedback through iterations help to minimize the risk of any major failures in the future and more likely, better align the outcome with the expectations. This fact can, however, lead to the risk of changes not being communicated effectively and cause problems in changing priorities. On the other hand, it requires the customer to be available during the whole development process.

The two different methods also differ in the way in which the work of the project is delivered^[10]. While traditional methods development steps take place in sequences and the project is delivered at the end of the development process, agile delivers smaller projects more frequently at the end of each iteration.

In conclusion, agile can be defined as a project management approach that provides flexibility, while traditional methods offer a better pre-defined and more specific framework that follows a sequential process.

[edit] Application

The agile philosophy can be applied with different frameworks and methodologies, the two most popular are Scrum ^[11] and Extreme Programming (XP) ^[12].

[edit] Agile methodologies

[edit] Scrum

Scrum ^[13] is an agile development method that concentrates specifically on the project management point of view. As the agile philosophy indicates, it employs an iterative and incremental approach and aims to understand customer needs and deliver value to them in short cycles, prioritizing the most valuable features. It is mainly used in product management.

Each iteration of Scrum is known as Sprint. At the end of each sprint, the team delivers a product functionality. Sprints have fixed lengths, typically a maximum of one month, and a new sprint starts immediately after the conclusion of the previous one. Each sprint could be considered as a short project.

The requirements and attributes of the product are defined in the Product backlog. It is a repository of what needs to be done to improve the product and is continuously updated during the development of the project. It defines the Product goal, which is the long-term objective for the Scrum team.

The items in the product backlog are grouped into Sprint backlogs. Each sprint has a sprint backlog which defines the Sprint goal, the set of selected items from the product backlog that would be implemented in the sprint, as well as the actionable plan for delivering. It is also updated throughout the process by the developers.

The goal of each sprint is to add value and functionalities to the project, which are called Increments. Increments are concrete steps towards the product goal. Each increment is additive, meaning that all the increments should work together. Multiple increments can be created within a sprint.

The team working with Scrum is formed by three main roles:

• Scrum master: responsible for organizing the team, removing obstacles to progress and establishing the Scrum methodology.
• Product owner: responsible for maximizing the value of the product resulting from the work of the Scrum team and for the delivery of the functionality at each iteration. It also creates and updates the product backlog and prioritizes the tasks.
• Scrum team: small cross-functional team of people developing the project. It consists of one Scrum master, one product owner and developers. There aren’t hierarchies within the team and it is typically formed by 10 or fewer people.

Sprints are divided into four different stages. First, the Sprint planning, is the beginning of the sprint where the work to be done is defined and planned. It is created by the entire Scrum team and the outcome is the sprint backlog, which includes the items from the product backlog selected to be implemented in the sprint and the plan for delivering them.

During the sprint, the team participates in Daily scrum, 15 mins daily meetings where the Scrum team tracks the progress towards the sprint goal and adapts the sprint backlog as necessary. The goal is to improve the communication and promote quick decision-making.

When the sprint is coming to its end, the Scrum team, reviews, together with the stakeholders, what was accomplished in the sprint and what has changed in the environment. The product backlog may be also adjusted to meet new opportunities. These events can take up to four hours for a one-month sprint and are called Sprint review.

Finally, the Sprint retrospective is the last event in the sprint that focuses on planning a way to increase the quality and effectiveness of the sprint. It can last up to three hours for a one-month sprint. The Scrum team inspects how the last sprint went with regards to individuals, interactions, processes and tools.

This process is repeated for each of the sprints.

SCRUM elements and process

[edit] Extreme Programming

Extreme Programming (XP) ^[14] is one of the most specific agile methodologies for software development. It consists of delivering higher quality software and empathizes teamwork. It is very helpful when there is constantly changing demands or requirements from the customers. It also consists of frequent releases of the product and short development cycles.

It improves the software development process based on five main values ^[15]:

• Communication: communication between all team members, from customers to programmers and managers.
• Simplicity: keep the design simple and clean.
• Feedback: get feedback by testing their software from day one and deliver the system to the customers as early as possible and implement changes as suggested.
• Respect: every small success deepens their respect for the unique contributions of each and every team member.
• Courage: courageously respond to changing requirements and technology.

Extreme Programmings is a way of work based on these values that lead to the XP rules:

• Planning:

It all starts with user stories^[16], things that the user aims the system needs to do for them. They are written by the customer in the format of about three sentences and are used to plan the release schedule through a release planning meeting. The release plan lays out the overall project and is used to create iteration plans. Iterations also consist of frequent small releases. And projects are mainly divided into iterations of one to three weeks long. They are planned through the iteration planning meetings at the beginning of each iteration to determine the iteration programming tasks.

• Managing:

It is important to provide the team with a dedicated and open space that enables communication between team members and avoid physical barriers that divide people. Organize daily stand up meetings and set a sustainable, measurable and predictable pace. The measure of how much work is getting done in the project is called project velocity.

In order to avoid serious knowledge loss and coding bottlenecks, it is important to consider to move people around and cross training activities. A good idea is to encourage everyone to try to work on a new section of the system, at least part of each iteration. Pair programming makes it possible without losing productivity and ensuring continuity of thoughts. It consists of two team members working together on a single computer. Although it is a difficult skill to learn, it increases the software quality without compromising the delivery time.

• Designing:

As mentioned in the values, keep the design simple and structure it in a way that helps new people begin contributing quickly. Use system metaphor to be able to explain the system design to new people without the need of providing huge documents on them.

CRC (Class, Responsibilities and Collaboration) cards are a useful method to design the system as a team and involve entire project teams to contribute to the design. CRC sessions allow people to break away from the procedural mode of thought and more fully appreciate object technology. ^[17]

Create spike solutions, a simple program to explore potential solutions, to figure out answers to technical or design problems. Refactor throughout the entire project life cycle to avoid complexity, try remove redundancy, eliminate unused functionalities and rejuvenate obsolete designs.

• Coding:

The customer should always be available, not only to help the development team, but to be part of it as well. And, the code must follow the agreed coding standards.

As mentioned in the managing section, it is interesting to practice pair programming, as it increases software quality without impacting time to deliver.

Keep continuously integrating the code to avoid possible future integration issues. Developers should be integrating and committing code into the code repository every few hours, whenever possible.

Encourage collective ownership, so that everyone can contribute with new ideas to all segments of the project. Any developer should be able to change any line of code to add a functionality, fix bugs, improve designs or refactor. No one should become a bottleneck for progress.

• Testing:

All code must have a unit test, which are automated tests written by the developers to test functionality as they write it. They build confidence that the code works correctly. All the code must pass the unit test before it can be released.

When bugs are found in the code, an acceptance test should be created. Acceptance tests are created from the user stories, the customer defines scenarios that should be tested when a user story has been correctly implemented.

Extreme Programming elements and process. Source: http://www.extremeprogramming.org/map/project.html

[edit] Limitations

Overall, agile has demonstrated to be a very useful methodology in the current times when everything is so volatile and unpredictable. It has shown to be a realistic approach that results in efficient processes to develop projects that better meet the customer needs.

As mentioned in previous sections, the main strength of agile is the ability to adapt to frequent changes. However, it doesn’t always make sense to follow agile methodology ^[18]. For instance, one of the main values of agile focuses on customer collaboration, so in cases where the customer is not prepared or is not willing to be part of the project development that could result in a difficulty. On the other hand, it is also important to consider that the high level of engagement with the customers can lead to uncontrolled changes to the agreed baseline if not managed correctly.

One of the agile benefits is the customers' satisfaction, because of the rapid and frequent deliveries. Nevertheless, it is important that the team is used to work in a fast-paced and changing environment, so it might be key to educate teams in agile before starting to apply the methodology. Furthermore, agile team members should be highly qualified and experienced, so that they can make fast and relevant decisions. Dealing with strict delivery management and meeting the frequent deadlines could also become a challenge when working with agile.

On the other hand, the fact that the work is split into many short iterations, where requirements change and evolve during the process, also leads to a lack of documentation. The shortage of formal documents could create confusion and crucial decisions taken throughout different phases could be misinterpreted by the team members. Therefore, transferring work between teams for further development or maintenance could also become a difficulty. So, it drives to a high dependency to the individuals in the agile teams.

[edit] Annotated bibliography

Beck, K., et al (2001) Manifesto for Agile Software Development

It marked the origin the agile philosophy and was written by a group of experienced software developers in need to find a better software development approach than the traditional method. The manifesto defines the main values and principles of agile.

Wells, Don (2013) Extreme Programming

Don Wells establishes and defines Extreme Programming, from the main values and rules to all the steps and elements involved in the process.

Schwaber, Ken; Sutherland, Jeff (2020) The Scrum Guide

Jeff Sutherland and Ken Schawabel developed Scrum in the early 1990s and wrote the first version of the Scrum Guide in 2010 to help people worldwide understand Scrum. It defines each element of the framework.

[edit] References

1. ↑ Bennis, Warren; Nanus, Burt (1987) "VUCA"
2. ↑ Pimonova S. (2020) Agile Methodology in Education of IT Students, Application of. In: Tatnall A. (eds) Encyclopedia of Education and Information Technologies. Springer, Cham.
3. ↑ Torgeir Dingsøyr, Sridhar Nerur, VenuGopal Balijepally, Nils Brede Moe (2012) A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software
4. ↑ da Silva, Tiago Silva; Estácio, Bernardo (2017) Agile Methods. Springer International Publishing.
5. ↑ The standard for project management (2021) page 41, In A Guide To the Project Management Body of Knowledge (pmbok® Guide) – Seventh Edition and the Standard for Project Management (english). Project Management Institute, Inc.
6. ↑ Atlassian (2022) Atlassian Agile Coach
7. ↑ Agile Alliance
8. ↑ Waterfall model
9. ↑ Beck, K., et al (2001) "Manifesto for Agile Software Development"
10. ↑ Managing Successful Projects with PRINCE2 6th Edition (2017). TSO
11. ↑ Schwaber, Ken; Sutherland, Jeff (2020) The Scrum Guide
12. ↑ Wells, Don (2013) Extreme Programming
13. ↑ Maximini, Dominik (2015) The Scrum Culture. Springer International Publishing.
14. ↑ Gelowitz C., Sloman I., Benedicenti L., Paranjape R. (2003) Extreme Programming and Agile Processes in Software Engineering. Springer International Publishing.
15. ↑ Bech, K.; Fowler, M. (2001) Planning extreme programming. Addison-Wesley. ISBN: 0201710919
16. ↑ The standard for project management (2021) page 84, In A Guide To the Project Management Body of Knowledge (pmbok® Guide) – Seventh Edition and the Standard for Project Management (english). Project Management Institute, Inc.
17. ↑ Class, Responsibilities and Collaboration cards
18. ↑ Solinski, Adam; Petersen, Kai (2016) Prioritizing agile benefits and limitations in relation to practice usage. In Software Quality Journal. Springer New York LLC.