Real World Agile

Everyone talks about Agile, but do you really know what it is? I can't think of a single company anymore that doesn't work with Agile principles!

Agile is a software development approach (I prefer to think of it as a mindset) based on fundamental principles established in the Agile Manifesto.

Fundamental Principles:

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

Mindset Transformation

Traditional software development often feels like ordering a car without ever visiting the factory. The customer makes a detailed initial request, the development team starts working, and three months later, when the customer finally sees the product, that familiar phrase emerges: "This wasn't quite what I had in mind."

The problem isn't just technical—it's a problem of expectations and visibility. The customer thinks: "How can it take so long and cost so much money?" Meanwhile, the development team gets frustrated because they've received 47 change requests since the project began, each one impacting the work already completed.

This is where Agile comes in as a solution—not just as a methodology, but as a transformation in the customer-team relationship. Imagine that instead of waiting three months to see the product, the customer participates in weekly meetings where they can watch the software grow, like observing a car being built in real time.

In each meeting, the customer sees real progress: "Look, we implemented the login you requested. Oh, you want to change the button colors? Sure, but that means we'll need to postpone the report feature that was scheduled for this week." The customer starts to understand that each change has a real impact on development.

This transparency brings three fundamental benefits:

1. The customer sees their money turning into product every week, not just at the end of the project.
2. Requirement changes are discussed and prioritized in real time, with a clear understanding of impacts.
3. The team can quickly adapt to the customer's most important needs, instead of blindly following an obsolete plan.

Agile doesn't eliminate changes—it makes them visible and manageable. When the customer says "we need to change this," they understand they're not just modifying a line in a document, but redirecting the work of real people they see every week.

This new work model transforms the "us versus them" relationship into a true partnership. The customer stops being a distant observer who only judges the final result and becomes an active part of the development process, understanding that each of their decisions shapes not only the product, but also the path to get there.

In the end, Agile isn't about delivering software faster—it's about delivering the right software, with total transparency of the process and the decisions that shaped it. It's about transforming software development from a mysterious black box into a collaborative process where everyone understands the challenges, costs, and impacts of each decision.

A phrase to reflect on... For the company, it stops working with contracts and starts working with daily rates.

For the Company:

• Guarantees compensation for time and expertise dedicated
• Protects against constant scope changes
• Can clearly demonstrate the work performed
• Has flexibility to adapt the team as needed

For the Customer:

• Maintains decision-making power over priorities while considering advice and dependencies highlighted by the company
• Visualizes return on investment in short cycles
• Can adjust the project's direction while understanding the impacts
• Pays for value actually delivered

---

In practice, agile development works like this:

• Incremental Deliveries
  • The product is developed in small functional increments
  • Each increment delivers real value to the customer
  • Short development cycles (usually 1-4 weeks)
• Constant Collaboration
• Self-organizing teams
• Daily communication between team members
• Customer actively participates in development
• Continuous feedback and adaptation
• Flexibility to Changes
• Adaptive planning
• Acceptance that requirements can change
• Continuous prioritization based on business value

The backlog is the task list of what needs to be done. It's constantly updated, and tasks gain priorities over time.

• Common Practices:

  • Daily Standups are to discuss what each person did yesterday and will do today. If there's something blocking the task and what's needed to move forward. This is a quick meeting, just to show the customer some progress and synchronize the team.
  • Sprint Planning (cycle planning meeting). Part of the backlog tasks will be addressed in the proposed cycle.
  • Sprint Review (cycle review). At the end of the cycle, it's common to have a meeting to discuss pending tasks and the reasons.
  • Retrospectives. Sometimes done in the same review meeting to align things between the team and discuss process improvements.
  • Backlog Refinement. Not all tasks in the backlog are always viable, so we discard some, include others, and set priorities. Usually the highest priority items go to the cycles.

• Typical Roles:

  • Product Owner. The person who controls backlog items and prioritizes things. Of course, to prioritize effectively, it's necessary to understand the dependencies between items. This person can be the customer who talks with the team leader to give direction, but can also be someone dedicated to this role.
  • Team Leader (in Scrum teams often referred to as the Scrum Master). This figure is usually the person with the most knowledge on the team. It can be technical knowledge that helps the team choose the right tools and the best approach, but it can also be deep business knowledge and understanding backlog priorities while acting as a product owner.
  • Development Team

  These positions vary greatly depending on the project. I've seen projects where the Tech Lead is the product owner, the DevOps engineer, the cloud architect, and even the most experienced developer. Companies don't always have the budget to hire each person for a specific position—the business goal is to cut costs. Think of the Tech Lead as the head!

• Benefits:

  • Greater customer satisfaction
  • Risk reduction
  • Early problem detection
  • Better product quality
  • Greater team engagement
  • Faster and more frequent deliveries

Agile is not just a set of practices, but a mindset that values:

• Continuous adaptation
• Constant learning
• Iterative improvement
• Transparency
• Effective collaboration

Methodologies

I won't dive deep into a single methodology because that doesn't make sense anymore. Scrum has many rituals and roles that, in practice, I don't see anyone wanting to invest that much in.

What frequently happens in practice is an adaptation of Scrum, where teams keep only the elements that add real value to their process. It's common to see teams keeping:

Daily standups (for quick alignment) Sprints (for work organization) Product Backlog (for prioritization)

And simplifying or eliminating:

• Extensive planning rituals
• Long formal retrospectives
• Excessive documentation
• Rigid role definitions

This adaptation is natural and even healthy, as long as it maintains the fundamental principles of Agile.

A practical example is a team that reduced the retrospective from 2 hours to a 30-minute coffee break where they discuss improvements more naturally and effectively.

The important thing is not to follow Scrum to the letter, but to find the process that works best for your team and your context.

Below are the two most well-known methodologies.

Scrum vs Kanban

I'll explain the main differences between Scrum and Kanban:

Characteristic	Scrum	Kanban
Work Cycles	Fixed sprints (usually 2 weeks)	Continuous flow, no defined cycles
Roles	Product Owner, Scrum Master, Dev Team	Doesn't define specific roles
Rituals	Daily, Planning, Review, Retrospective	Doesn't require specific rituals
Planning	Commitment to Sprint deliveries	Continuous and flexible planning
Metrics	Team velocity, Burndown	Lead time, Cycle time
Work Limitation	Based on Sprint capacity	WIP Limits (work in progress limit)
Mid-Cycle Changes	Ideally no changes during Sprint	Allows changes at any time
Board	Cleared every Sprint	Continuous, no reset
Estimates	Story Points, Planning Poker	Optional, focus on item size
Prioritization	Ordered Product Backlog	Visual by columns and swimlanes
Recommended for	Projects with some predictability	Continuous services (maintenance, support)
Deliveries	At the end of each Sprint	Continuous, as completion occurs
Meetings	Fixed and timeboxed ceremonies	On demand
Process Visual	Sprint columns	Complete workflow
Documentation	Product/Sprint Backlog, Increment	Explicit board policies

I see that in the end, companies use Scrumban, a hybrid approach that takes a bit from each methodology. I call this "Real Life Scrumban."

The Daily standup is maintained daily and kept brief.

Some Scrum rituals (Daily, Planning, Review and Retro) are maintained, as well as the backlog concept. However, the backlog stays available in a Kanban board column, with priorities defined by card ordering (which represent the tasks).

The Sprint concept transforms into a cycle of meetings for Planning and Review that, in practice, happen together, usually every two weeks, but the workflow remains continuous.

The Epic concept is emphasized, which represents the goal or objective with a determined time frame—usually 2 or 3 months—varying according to what needs to be implemented.

The process becomes more balanced, avoiding both the micromanagement imposed by Scrum and the excessive flexibility of Kanban, thus finding a pragmatic middle ground.

Backlog Prioritization

I'll explain the concept of L1, L2, L3, L4, L5, and L6 prioritization in the agile context.

In the agile context, levels L1 to L6 are a way to categorize the priority and severity of different items (like bugs, incidents, or tasks). Usually, a task comes with its priority defined so you know what to pick first.

L1 (Critical Priority)

• Severe impact affecting critical business functions
• Requires immediate action, usually within hours

Example: System completely down, making essential operations impossible Usually involves team mobilization even outside business hours

L2 (High Priority)

• Significant impact, but without completely paralyzing operations
• Needs quick resolution, typically within 24-48 hours

Example: Important functionality with a defect, but there's a temporary workaround Team prioritizes this activity and may need to reorganize other tasks.

Here's one of the reasons you can't apply full Scrum—problems always arise that interfere with the sprint!

L3 (Medium Priority)

• Moderate impact on operations
• Can be resolved within a week or in the next sprint

Example: Bug in a non-critical function or important but not urgent improvements It's normally planned in the next sprint's backlog and usually jumps the queue!

L4 (Low Priority)

• Minimal business impact
• Can wait several sprints to be resolved

Example: Cosmetic improvements or minor optimizations Goes into the product's normal backlog for future prioritization

L5 (Very Low Priority)

• Non-urgent cosmetic improvements
• Minor optimizations that don't affect user experience
• Tasks that can wait months to be implemented
• Ideas for future product versions

Example: Changing the color of a non-critical icon, reformatting code that already works

L6 (Minimal Priority)

• Wishes or "nice to have" items
• Backlog items that may never be implemented
• Ideas to be considered in the distant future

Example: Refactoring code that already works well, purely aesthetic changes

---

In most organizations, items classified as L5 or L6 often end up being:

• Removed from the backlog after a while
• Reclassified to a higher priority if they gain importance
• Kept only as reference for future discussions

That's why most companies work only with the L1 to L4 scale, which is already sufficient to adequately categorize work item priorities.