Agile methodologies

Agile methodologies emerged as a response to the limitations of traditional methodologies such as the waterfall. The agile approach focuses on flexibility, adaptability, and fast delivery of value. The key principles of agile methodologies are summarized in the Agile Manifesto, which includes four fundamental 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.

There are several popular agile methodologies, including Scrum, Kanban, and Extreme Programming (XP). Here are brief descriptions of these methodologies:

• Scrum: Scrum is an agile framework based on iterations called "sprints," which usually last 2 to 4 weeks. The development team works together to deliver software increments at the end of each sprint. Scrum uses specific roles, such as the Scrum Master (facilitator) and the Product Owner (customer representative), as well as events and artifacts, such as the product backlog, sprint planning meetings, and daily Scrum meetings. This framework is discussed in more depth at the following link Scrum Methodology.
• Kanban: Kanban is an agile approach based on visualizing the workflow and limiting work in progress (WIP). A Kanban board is used to visualize the status of tasks in different columns (e.g., "To Do," "In Progress," and "Done"). The goal is to improve efficiency and reduce delivery time by managing workflow and eliminating bottlenecks. Unlike Scrum, Kanban does not use fixed sprints and focuses on continuous delivery of value. Kanban is discussed in more depth at Kanban Methodology.
• Extreme Programming (XP): XP is an agile methodology that focuses on code quality and collaboration within the development team. XP introduces practices such as pair programming, continuous integration, test-driven development (TDD), and refactoring to improve software quality and adaptability to changes. XP also promotes direct communication and feedback between developers and customers. This framework is discussed at Extreme Programming.

Although each agile methodology has its own peculiarities, they all share an iterative, incremental, and adaptable approach to software development. These methodologies allow teams to quickly respond to changes in requirements, improve communication and collaboration, and deliver value continuously to the customer.

The history of agile methodologies dates back to the 1990s and early 2000s, when several software industry experts began seeking more flexible and adaptable approaches to software development in response to the limitations of traditional approaches like the waterfall model. Traditional approaches were often rigid, slow, and didn't adapt well to changes in project requirements or market conditions.

In 2001, a group of 17 software development experts met in Snowbird, Utah to discuss and define a set of common principles and values that would address these issues. This group included notable figures like Kent Beck, Ward Cunningham, Alistair Cockburn, Martin Fowler, Jim Highsmith, and others. As a result of this meeting, the Agile Manifesto was created, which establishes the four fundamental values and twelve principles of agile software development.

The four values of the Agile Manifesto are as follows:

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

The Agile Manifesto does not represent a specific methodology but provides a basis for a wide range of approaches and practices that align with these values and principles.

Some important references in agile methodology literature include:

• "Manifesto for Agile Software Development" (2001): The original Agile Manifesto, which can be found online at .
• "Extreme Programming Explained: Embrace Change" by Kent Beck (1999): This book introduces eXtreme Programming (XP), an agile methodology focused on improving software quality and adaptability to changes.
• "Agile Estimating and Planning" by Mike Cohn (2005): This book provides a guide to effective planning and estimation in agile software development projects.
• "Lean Software Development: An Agile Toolkit" by Mary and Tom Poppendieck (2003): The authors apply the principles of lean manufacturing to software development and present a set of tools and techniques for implementing the Lean approach in software projects.
• "Agile Software Development: The Cooperative Game" by Alistair Cockburn (2006): This book provides an overview of agile methodologies and focuses on the cooperative nature of agile software development.

Stakeholders

Stakeholders are individuals, groups, or organizations who have an interest in or are affected by the decisions and activities of a project, product, or company. Stakeholders can have a direct or indirect impact on the success of a project and can benefit from or be harmed by its results.

In a software development project, stakeholders typically include:

• Customers: They fund the project and will receive the final product. Customers can be internal (within the same organization) or external (another company or individual). Their primary interest is that the product meets their needs and business objectives.
• End users: They are the people who will use the product or service developed in the project. End users may have different needs and expectations, and their satisfaction is crucial to the success of the product.
• Development team: They are the professionals responsible for designing, building, and delivering the product. Members of the development team may include programmers, designers, analysts, testers, and other technical roles.
• Product Owner: As mentioned earlier, the Product Owner represents the interests of the customer and end users in a Scrum project and is responsible for defining and prioritizing the product features.
• Scrum Master: In a Scrum project, the Scrum Master facilitates the process and helps the team to follow the Scrum framework.
• Managers and executives: The managers and executives of the organization may be stakeholders if the project affects their responsibilities or if they have the authority to make decisions related to the project.
• Suppliers and partners: Companies and organizations that provide resources, services, or support to the project can also be considered stakeholders.

In project management, it is important to identify and understand stakeholders and their expectations to ensure effective communication and informed decision-making. Successful projects often involve stakeholders actively and regularly, seeking their feedback and considering their interests when making decisions.

Definition of Done

The "Definition of Done" (DoD) is an agreed-upon set of criteria that an item of work, such as a feature, improvement, or bug fix, must meet before being considered "done" in the context of a Scrum project. The Definition of Done provides a common and shared understanding between the development team and the Product Owner of what it means to complete work in a sprint and helps ensure that software increments delivered are of high quality and ready for deployment.

The Definition of Done may vary between teams and projects, but generally includes criteria related to code quality, testing, documentation, and integration. Some examples of criteria that could be included in a Definition of Done are:

• Code is written according to coding guidelines and standards agreed upon by the team.
• Code has been reviewed by at least one other member of the development team.
• All unit tests have been written and pass successfully.
• The software has been tested in an environment simulating production and all critical defects have been identified and corrected.
• Necessary documentation, such as user guides, release notes, or comments in code, has been created and updated.
• The software increment has been successfully integrated into the existing system or product.
• The Product Owner has reviewed and accepted the work according to acceptance criteria.

The Definition of Done should be reviewed and agreed upon by the development team and the Product Owner at the start of the project and may be adjusted over time if necessary. By adhering to the Definition of Done, the development team ensures that delivered work is consistent, of high quality, and ready for deployment in a production environment. Additionally, it helps avoid technical debt accumulation and ensures that the team focuses on delivering real value to the customer and end-users.

Value delivery

The concept of "value delivery" is fundamental in agile methodologies, as these methodologies focus on maximizing the value that is delivered to the customer and end-users through an iterative and incremental approach. Value delivery refers to the creation of products and solutions that meet the needs and expectations of the customer and provide benefits for both the customer and end-users. Below are some key aspects of value delivery in agile methodologies:

• Customer orientation: Agile methodologies strongly emphasize understanding and meeting the needs and expectations of the customer. The Product Owner works closely with the customer to define and prioritize the items in the Product Backlog based on the value they will bring to the customer and end-users.
• Short iterations and incremental deliveries: Agile methodologies, such as Scrum, use short iterations (called sprints) to enable the fast and frequent delivery of software increments that bring value. By delivering software increments regularly, agile teams can receive early feedback and adjust the product accordingly, which helps ensure that the desired value is being delivered.
• Value-based prioritization: Agile teams prioritize work based on the value it brings to the customer and end-users. This means that the most valuable features and improvements are addressed first, allowing the most important benefits to be delivered quickly and ensuring a return on investment.
• Inspection and adaptation: Agile methodologies promote constant inspection and adaptation to continuously improve the process and ensure the team stays focused on delivering value. Agile teams use events such as sprint reviews and retrospectives to evaluate their performance and adjust their approach as necessary.
• Collaboration and communication: Effective collaboration and communication are essential for value delivery in agile methodologies. Agile teams work closely with customers and other stakeholders to ensure they understand their needs and expectations and can adapt quickly to changes.
• Quality and technical excellence: Value delivery also involves ensuring that the product has high quality and meets technical and design standards. Agile teams focus on quality throughout the development process and use practices such as code review, automated testing, and continuous integration to ensure the quality of the product.

Value delivery in agile methodologies focuses on understanding and meeting the needs and expectations of the customer and end-users through an iterative, incremental, and customer-centric approach. By prioritizing value and adapting quickly to changes, agile teams can deliver effective and high-quality solutions that benefit their customers and end-users.

Sprints

A sprint is a fixed and short period of time in agile methodologies, especially in Scrum, during which a development team works on a selected set of tasks to complete and deliver a potentially shippable product increment. Sprints typically last between one and four weeks, although the duration can vary depending on the project needs and team preferences.

The sprint is a key component of the iterative and incremental approach of agile methodologies. It enables teams to tackle and deliver value in small parts, facilitating adaptability to changes and continuous improvement. Each sprint is immediately followed by another sprint, creating a cycle of continuous planning, development, testing, and delivery of value.

The sprint approach allows agile teams to quickly adapt to changes in requirements, priorities, and market conditions, and facilitates greater collaboration and communication among team members, the product owner, and stakeholders.