This is the continuation of the Agile Field Guide. If you want to check out the first part, I'll leave a link at the end of the post. Hope you enjoy it!
Agile Methodology
As software development gradually evolved, in 2001 the Manifesto for Agile Software Development emerged, introducing a set of revolutionary new practices. This marked the birth of the Agile Methodology, a new philosophy of organization and work, a collection of project management techniques focused on flexibility and adaptability. Unlike earlier models such as Waterfall, Agile emphasizes feedback so there isn’t a strictly predefined product. The goal is to develop products and services that meet the client’s needs in the shortest possible time, through sections with specific delivery deadlines. It also promotes creating development teams that move toward a common goal while respecting stages and timelines.
There are several key points to highlight: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.
Ken Schwaber, Jeff Sutherland (2012) — A manager’s most important work is helping the people doing the work. Give them a goal and let them work. Remove any impediments that get in their way. Do anything that make them more effective or productive. Then the organization can capitalize on the fruits of their work.
Related methodologies
Kanban is one of the most popular Agile frameworks. It requires transparency and real-time communication among teams, with visualization of the work being its core principle. Through cards organized by stages, teams can see the overall progress of the project and even identify bottlenecks. Work is not imposed on teams already at full capacity; instead, pending tasks are added to a queue, and the team pulls in new work as they have available capacity.
As mentioned, the Kanban board is one of the essential tools for applying this practice. Whether using a physical board or a digital application like Jira, the development stages are divided into columns. Typically, these are To Do, In Progress, and Done, although this is not a strict rule.
On the other hand, XP (Extreme Programming) is another framework that focuses on speed and simplicity, with rapid development cycles (sprints). Unlike other frameworks, XP is much more rigorous, as it conducts frequent reviews and unit tests to implement changes more quickly. It focuses on providing direct solutions and avoiding unnecessary complexities.
It promotes face-to-face communication between the client and the developer, is open to change, welcomes feedback, and encourages continuous improvement. Teamwork is one of its core pillars: it is based on respect, collaboration, openness to suggestions, and maintaining good interpersonal relationships.
In addition, the project must be completely accessible and transparent to all team members. Typically, tasks are tackled in pairs (pair programming) to ensure higher quality and continuous knowledge sharing.
Finally, I would like to talk about the Lean methodology, founded by Kiichiro Toyoda after World War II with the goal of saving resources. Its philosophy was later adopted in the software world through the book Lean Software Development: An Agile Toolkit. The main pillar of Lean is efficiency, which is achieved by eliminating activities that do not add value to the customer. This allows us to focus on tasks that do provide significant value, thereby reducing the overall cost of the project.
There is a continuous search for ways to improve development processes (Kaizen) carried out by the teams, while also maintaining an atmosphere of respect and taking the development team’s viewpoints seriously. There are no idle times; the team maintains a steady pace.
Similar to other methodologies, there is direct interaction with the client to gather key insights. To meet these needs, value stream mapping is commonly used to visualize the project process and eliminate waste.
DoD and Acceptance criteria
As the project progresses, there will come a point where we ask ourselves, “Is it really ready?” To answer this question, it will be necessary to bring together the entire project team (testers, developers, product owner…) and evaluate whether the product meets everything proposed by the client. This involves technical reviews, testing, documentation, and acceptance by the Product Owner. It is essentially a common agreement, and for this, we must ensure that everyone has the same understanding of what it means for something to be completed, in order to avoid misunderstandings such as missing documentation or incomplete tests.
In Scrum, when a Product Backlog item meets the DoD it becomes part of the Increment. Teams should evolve a DoD early and keep it visible; it’s the Increment’s quality commitment.
Acceptance Criteria is often confused with DoD, but care must be taken, because it refers to a particular user story, not a general concept. For example, that the user can log in using email and password.
SAFe, LeSS and NEXUS
Now we will talk about what are SAFe, LeSS, and Nexus, how they differ, and more. These are three of the most popular and widely used frameworks in agile at scale.
SAFe (Scaled Agile Framework), first introduced in 2007 by Dean Leffingwell, provides guidelines for scaling agile methodologies across different layers. At the Team level, agile teams use Scrum, Kanban, or XP, among other practices. At the Program level, multiple teams work together as an Agile Release Train (ART) to deliver in a coordinated manner. For Large Solutions, coordination among multiple ARTs is required. Finally, the Portfolio level manages investments, budgets, and strategic alignment.
SAFe defines a set of roles, events, and artifacts for each level, all aimed at increasing productivity at scale. Teams work toward a common objective, and synchronization is essential to achieve this. One key practice is PI Planning, where all members meet to plan objectives for the next quarter, complemented by daily meetings to maintain alignment.
LeSS is nothing more than the scaling of SCRUM to a large scale within big companies, where multiple teams work in a synchronized manner using this framework. It is based on principles such as transparency, Lean thinking, and an overall product vision. There are two variants: the “classic” LeSS, for those with at least two teams and up to eight, and the “huge” LeSS, adapted for larger teams, reaching up to one hundred people.
There is a single Product Owner for all teams and a single Product Backlog. Each team has its own Daily Scrums and Sprint Reviews, although there are also coordination meetings between teams to align work and learn collectively.
Nexus, one of the frameworks offered by Scrum co-creator Ken Schwaber, focuses primarily on coordinating dependencies between teams. This framework is typically applied in organizations with three to nine teams, each following Scrum independently but coordinating through Nexus.
To achieve this, Nexus introduces the Nexus Integration Team, whose role is to oversee the integration of the increments from all teams, identify dependency issues, and ensure that partial products are combined into a potentially shippable product increment at the end of each sprint. This team acts as a point of coordination and conflict resolution, facilitating communication and synchronization among the different teams.
Additionally, Nexus extends Scrum events to a multi-team level. Activities such as Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review, and Nexus Retrospective are conducted, all aimed at detecting and resolving integration issues early.
In conclusion, pick based on organizational needs, not “security vs speed.” SAFe, LeSS, and Nexus all aim to deliver a single, done increment at scale; none is inherently “less secure” or “just faster.” The right choice depends on governance needs, integration complexity, and the culture you want to cultivate.
This article is part of a larger series exploring Agile in practice. You can read the first part in Agile Field Guide Part I
Top comments (0)