Agile model

Revision as of 17:29, 15 March 2022

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 thoughout the process. 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 describes the different Agile frameworks, SCRUM and Extreme Programming and its applications. The last part of the article mentions possible limitations of Agile.

Big idea

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 fragments of functionality. It is also an incremental process, meaning that each iteration include the functionalities of all the previous and current iterations. The iterations normally last around two weeks, depending on the size of the project. Therefore, the final delivery contains all the required functionalities. ^[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 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 a following iteration. ^{[3] [4]}

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

Mainly, the Agile ^[6] process could be divided into different phases:

Agile process

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

It aims to deliver fast solutions in order to get feedback from the customers and being able to constantly improve, evolve and respond to changing requirements during the process.

It 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 continuously updates of technology.

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 Waterfall methodology ^[8]. They ended up creating the Agile Manifesto ^[9], that marked the birth of Agile as a methodology.

This document contains the basic principles that are characteristic of Agile philosophy in project management. It outlines 4 values and 12 principles that guide the Agile philosophy:

Agile main values:

• 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. eliver 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.

Agile vs. Traditional methods

The project approach is the way in which the work of the project is to be delivered. It may rely on one or more delivery approaches, which are the specialist approaches used by work package s to create the products. Typical approaches include:

a waterfall approach where each of the delivery step s to create the products takes place in sequence (e.g. in a construction project where requirements gathering and design take place before building begins) and the product is made available during or at the end of the project

an agile approach often, but not exclusively, for software development where requirements gathering, design, coding and testing all take place iteratively through the project. There are typically a number of delivery steps within the delivery approach (e.g. the sprint s within an agile approach or steps such as study, design, build, test, etc. within a waterfall approach). The application of PRINCE2 can be very different depending on which delivery approach is used.

^[10]

It is also important to recognize that the project’s delivery approach might work to mitigate or reinforce specific risks. For example, an agile way of working inherently ensures that customers do not inappropriately constrain and over-specify requirements at the beginning of a project, which can be a risk in a more traditional ‘waterfall’ approach. Similarly, even though agile is characterized by a high level of engagement with customers directly involved in the project, it can lead to uncontrolled changes to the agreed baseline if not managed correctly. More traditional approaches tend to reinforce the impression of ‘controlled change’, but at a risk of appearing unresponsive. What is important is that the risk management approach recognizes these inherent differences.

Application

The Agile philosophy can be applied with different frameworks and methodologies, the two most popular are Scrum ^[11] and Extreme Programming (XP) ^[12]. Some other Agile methods are Kanban and Lean development.

Agile methodologies

Scrum

Scrum ^[13] is an agile development method which 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 maximum 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 and 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, so 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 Mater, one Product owner and Developers. There aren’t hierarchies within the team and it is typically formed by 10 or fewer people.

The Scrum process is 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, that 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 adapt 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

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 team work. 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 length. 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 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 also called project velocity.

In order to avoid serious knowledge loss and coding bottle necks, 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, 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 commiting code into the code repository every few hours, when ever 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 bottle neck 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, that build confidence that the code works correctly. And all the code must pass the unit test before it can be released.

When bugs are found in the code, acceptance test should be created. Acceptance tests are created form 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

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.

One of the Agile benefits is the customer 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 be 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 lead 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.

Annotated bibliography

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.