Agile
What is Agile?

Agile

What is Agile?

Agile methodology is an approach to software development that focuses on flexibility, collaboration, and delivering small pieces of a project at a time. Instead of following a rigid plan, agile embraces changes and aims to adapt to them quickly.

Agile principles

  • Incremental Delivery: Software is delivered in small, manageable parts called sprints or iterations, allowing for quick and constant progress.
  • Constant Collaboration Team members and stakeholders work closely together, sharing information and making sure everyone understands the project's goals.
  • Adaptability to Change: Agile welcomes changes in project requirements and strives to handle them effectively.
  • Focus on Quality: Quality is a priority, with practices like continuous code review, automated testing, and ongoing feedback to ensure high-quality work.
  • Autonomous Teams: Teams are self-organized and have the freedom to make decisions about how to implement and deliver the software.
  • Continuous Feedback: Regular reviews and adjustments are made to optimize efficiency and product quality.
  • Customer Focus: Prioritizing customer needs and ensuring the delivery of value are central to the agile approach. Customer involvement is maintained throughout the process.

Agile methodologies

There are diferent agile methodologies such as Scrum, Kanban, Extreme Programming (XP), and Lean, share agile principles while providing specific practices. They are not limited to software development and have been successfully applied in various fields.

🚧

Comming soon: explain methodologies

Agile manifesto

💡

We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:

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

That is, while there is value in the items onthe right, we value the items on the left more.

Participants of manifesto: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas. source (opens in a new tab)

Agile in software development

In the software development process, several changes are made to a digital asset with the aim of creating a different experience and addressing new needs. This approach is based on making incremental adjustments to the same asset, typically stored in the cloud using version control services like Git.

The business team shares ideas, concerns, fears, inspirations, wishes, and ambiguous concepts. From this, the Product Owner (PO) identifies needs, which are drafted in the form of User Stories (US). A quality User Story focuses solely on a need without proposing solutions. The PO compiles and organizes these needs into a prioritized list (backlog). The development team selects a set of User Stories from this list, addresses them, and works on them incrementally to adjust the digital asset (sprint). At this point, Quality Assurance (QA) comes into play, verifying that the builds address the needs expressed in the User Stories. QA acts as a representative of the PO, working collaboratively to ensure the system meets the need expressed in the User Story.

At the end of each sprint, the involved team gathers to analyze and share the following areas: positive aspects, negative aspects, and potential areas for improvement. This meeting facilitates the evaluation of the team's strengths and weaknesses and allows for proposing attitudes or behaviors to improve in future sprints, which will be addressed in the upcoming retrospectives (retro meetings).

Agile concepts

User Stories (US)

A User Story, or "Historia de Usuario" in Spanish, is a technique used in agile software development methodologies to express the features or functionalities that a team wishes to implement in a product based on client/stakeholders/end-user needs. A User Story focuses on the user's perspective and describes a functionality from the viewpoint of the customer or end-user. USs help teams understand and prioritize user needs. Integrated into the project backlog, these stories are chosen for implementation during sprints, which are short iterations in agile methodologies such as Scrum.

How to write a US

A User Story typically follows a simple structure, such as the following:

💡

As [type of user], I want to [perform a certain action/ need that must be addressed] to [achieve a specific goal / purpose ].

Example

“As a registered user, I want to be able to change my password to enhance the security of my account.”*

️ℹ️

Why this structure?

In this structure checks that there is an end user [type of user] expresses a need that must be addressed [i want], and the purpose [to].

Common errors writting US

Consider the following premises when creating User Stories.

️🚫
  • Only formulate User Stories that start with "As a user"; there is no consideration for framing it “as a company” or “as an institution”.
  • User Stories use non-technical language to provide context to the team. Don’t put words like backend, frontend, DB, API, etc.
  • User Stories should not express implementation details or solutions to the need they present (suggestions may be included in the Story's description).

Agile actors

In an agile team, there are several key positions that play specific roles to ensure the project's success. Here are some of the most common roles:

Product Owner (PO)

  • Represents the interests and needs of the customer or business in the form of user stories.
  • Responsible for defining and prioritizing the product backlog.
  • Works closely with the development team to ensure User Stories are clear and valuable.

Scrum Master

  • Facilitates the agile process and helps the team follow agile practices.
  • Removes obstacles and promotes a collaborative work environment.
  • Not a traditional leader but rather a facilitator and advocate for the team.

Development Team

  • Professionals working on the implementation and delivery of User Stories.
  • Can include developers, designers, testers, and other roles necessary to complete tasks.

Quality Assurance (QA)

  • Ensures the quality of the software by testing and validating features.
  • Collaborates with the development team to define acceptance criteria for User Stories.

Stakeholders

  • Individuals or groups outside the team with an interest in the project or product.
  • Includes customers, managers, marketing, among others.
  • Provides important information and feedback.

Emergent Design

There are various ways to approach solutions and architect a plan, but we could categorize them into two types.

  • The first involves a traditional approach where the intention is to plan everything to the fullest (and hope that the plan unfolds exactly as envisioned).
  • The second option acknowledges that it is challenging to foresee all aspects and details of a system at the project's outset. This approach advocates having a clear goal but not planning everything from end to end. Instead, it involves building and formulating solutions as ideas emerge, solutions are provided, and uncertainties are clarified. This flexible and adaptive approach, known as emergent design, aligns with agile principles, allowing the design to evolve and adjust as more information is gained, and user requirements are better understood.

What brings emergent design?

What does emergent design bring us?

  • Adaptability: Allows the design to evolve and adjust as more information is gained and user requirements are better understood.
  • Continuous Iteration: Adopts an iterative approach where incremental versions of the software are developed, and the design is continuously improved with each iteration.
  • Constant Collaboration: Encourages ongoing collaboration among team members, including developers, designers, and stakeholders, to adapt the design as needed.
  • Active Feedback: Actively seeks feedback from users and other stakeholders to adjust the design based on their needs and expectations.
  • Continuous Learning: Acknowledges that as development progresses, more is learned about the problem, and more effective solutions may emerge during the process.

What is a Spyke?


In Agile development, a "spike" is a time-boxed research or investigative activity aimed at gaining more information or understanding about a particular aspect of a project. A spike is typically used when there is uncertainty or a lack of clarity regarding a specific technical or functional issue.

For example, a spike might be initiated to explore the integration of a new technology, evaluate the performance of a specific component, or investigate the feasibility of implementing a particular feature. The knowledge gained from a spike can then be used to make informed decisions and guide subsequent development efforts.