Agile Methodology: Iterative and Incremental Development
The Agile methodology represents a revolution in software development. Born as a reaction to the limitations of traditional methods, Agile promotes flexibility, collaboration, and continuous value delivery to the customer.
🎯 What You'll Learn
- The 4 values of the Agile Manifesto and their meaning
- The 12 Agile principles in detail with practical examples
- Iterative and incremental cycle: how it works
- Agile mindset and culture
- User stories and backlog management
- Agile metrics: velocity, burndown, burnup
- Common challenges in Agile adoption
The Birth of Agile: The Manifesto
In February 2001, 17 developers met at a ski resort in Snowbird, Utah. Their goal: find an alternative to the heavy, bureaucratic processes that dominated the software industry. From this meeting, the Agile Manifesto was born.
📜 The 4 Values of the Agile Manifesto
The Manifesto is based on 4 fundamental values. Note: it's not about eliminating the elements on the right, but valuing more those on the left.
1️⃣ Individuals and interactions > Processes and tools
└─ People are the heart of the project
2️⃣ Working software > Comprehensive documentation
└─ Working code is the true measure of progress
3️⃣ Customer collaboration > Contract negotiation
└─ Active partnership instead of rigid contracts
4️⃣ Responding to change > Following a plan
└─ Adaptability is more important than rigid planningValue 1: Individuals and Interactions
Agile recognizes that software is built by people, not processes. Face-to-face communication is more effective than complex documents and tools.
👥 In Practice
- Co-located teams (same room) when possible
- Daily standup meetings (15 min)
- Pair programming and mob programming
- Retrospectives for continuous improvement
- Self-organizing teams
❌ Anti-Pattern
- Communication only via email/ticketing
- Team silos without interaction
- Complex tools that slow down
- Top-down micromanagement
- Lack of trust in the team
Value 2: Working Software
Working software is the primary metric of progress. Better working code with minimal documentation than perfect documents without code.
💻 What It Means
- Potentially releasable: Each iteration produces deployable software
- Frequent increments: Releases every 1-4 weeks instead of months
- Early feedback: Customer sees the product immediately and can provide input
- Definition of Done: Clear criteria for "completed" (tested, integrated, documented)
✅ DEFINITION OF DONE (DoD)
A user story is "Done" when:
□ Code written and peer reviewed
□ Unit tests written (coverage ≥ 80%)
□ Integration tests passed
□ API documentation updated
□ No critical bugs open
□ Product Owner approval
□ Deployed to staging environment
□ Acceptance criteria satisfiedValue 3: Customer Collaboration
The customer is not an "enemy" to protect yourself from with rigid contracts, but a collaborative partner who works together with the team.
🤝 Continuous Involvement
- Product Owner: Customer representative in the team (in Scrum)
- Sprint Reviews: Demo of completed work every iteration
- Backlog Refinement: Continuous prioritization with the customer
- Rapid feedback: Changes accepted and managed
- Transparency: Customer has complete visibility on progress and issues
Value 4: Responding to Change
Requirements change. Market changes. Technology changes. Agile embraces change instead of resisting it.
🔄 Agile Approach
- Adaptive planning (rolling wave)
- Backlog as dynamic tool
- Priorities re-evaluated every iteration
- Emergent architecture
- Continuous refactoring
📋 Waterfall Approach
- Complete upfront planning
- Requirements freeze
- Formal Change Request (expensive)
- Big Design Up Front (BDUF)
- Resistance to change
The 12 Agile Principles
Beyond the 4 values, the Manifesto includes 12 principles that guide Agile team behavior:
🎯 CUSTOMER SATISFACTION
1. Continuous delivery of value to customer
└─ Frequent and incremental releases
2. Welcome changing requirements
└─ Even late in development
⏱️ TIME-TO-MARKET
3. Deliver working software frequently
└─ From weeks to months (preferably weeks)
🤝 COLLABORATION
4. Business people and developers work together
└─ Daily collaboration
5. Build projects around motivated individuals
└─ Give support and trust to the team
6. Face-to-face conversation
└─ Most effective way to communicate
💯 QUALITY
7. Working software is the measure of progress
└─ Not documents or completion percentages
8. Sustainable development
└─ Maintain constant pace indefinitely
9. Continuous attention to technical excellence
└─ Quality design improves agility
🔄 CONTINUOUS IMPROVEMENT
10. Simplicity: maximize work not done
└─ Do only what's necessary (YAGNI)
11. Self-organizing teams
└─ Best solutions emerge from the team
12. Regular retrospectives
└─ Reflect and adapt behaviorPrinciples 1-3: Customer Focus
1. Customer Satisfaction Through Continuous Delivery
Objective: Maximize value delivered to customer through frequent and regular releases.
Practical example:
- E-commerce: Release every 2 weeks with new features
- SaaS: Continuous deployment (CD) with feature flags
- Mobile app: Bi-weekly updates on store
2. Welcome Change
Mindset: Changes in requirements are a competitive advantage, not a problem.
Scenario: Customer requests different feature at 70% project completion
- ❌ Waterfall: "Too late, Change Request with extra costs"
- ✅ Agile: "Let's update the backlog and reprioritize"
3. Frequent Deliveries (Timeboxing)
Rhythm: Short iterations of 1-4 weeks (sprints).
| Sprint Length | Pros | Cons | When to Use |
|---|---|---|---|
| 1 week | Very rapid feedback | Little time for complex features | Senior teams, mature products |
| 2 weeks | Balanced (most common) | - | Standard Scrum |
| 3 weeks | More space to complete | Less frequent feedback | Distributed teams |
| 4 weeks | Larger features | Risk of scope creep | Junior teams, high complexity |
Principles 4-6: Collaboration
4. Business and Dev Work Together Daily
The Product Owner (or customer) is an active part of the team, not just at the beginning and end.
Practices:
- Product Owner available for clarifications (same office or Slack/Teams)
- Participation in daily standup (optional)
- Sprint Planning together
- Sprint Review with demo
5. Motivated and Supported Teams
Give the team autonomy, tools, and trust.
How to motivate:
- Ownership of work (team decides "how")
- Comfortable work environment
- Continuous training
- Public recognition of successes
- Respected work-life balance
6. Face-to-Face Conversation
The most effective communication is direct and synchronous.
Effectiveness hierarchy:
- 🥇 Face-to-face in same room (best)
- 🥈 Video call (second best)
- 🥉 Voice call
- 📧 Chat/Slack (quick but risk of misunderstandings)
- 📄 Email (slow, formal)
- 📋 Documentation (reference, not primary communication)
Principles 7-9: Quality and Sustainability
7. Working Software as Metric
Don't measure progress with lines of code, documents, or "completion percentage". Measure with completed and deployable features.
Agile Metrics:
- Velocity: Story points completed per sprint
- Burndown Chart: Remaining work vs time
- Lead Time: Time from request to production
- Deployment Frequency: How many releases/week
8. Sustainable Pace (No Crunch Time)
Problem: Overloaded teams burn out and make mistakes.
Agile Solution:
- Realistic sprint planning (don't overcommit)
- 40 hours/week as norm
- Overtime only exceptionally and briefly
- Historical velocity as guide
- Team has right to say "no" to excessive pressure
"Agile is a marathon, not a sprint (ironically!)"
9. Technical Excellence and Good Design
Speed without quality leads to technical debt that slows the future.
Agile technical practices:
- TDD (Test-Driven Development): Tests before code
- Continuous refactoring: Improve design without changing behavior
- Code reviews: Mandatory peer reviews
- CI/CD: Continuous Integration and Deployment
- Coding standards: Lint, formatters, static analysis
- Pair/Mob Programming: Quality through collaboration
Principles 10-12: Simplicity and Improvement
10. Simplicity (YAGNI - You Aren't Gonna Need It)
Principle: Do only what's necessary now. Don't anticipate hypothetical future requirements.
Examples:
- ❌ Build super-flexible system for "future needs"
- ✅ Implement exactly what's needed today, refactor tomorrow if needed
- ❌ Over-engineering with complex design patterns
- ✅ Simple solution that works
11. Self-Organizing Teams
The team decides how to realize the work. No top-down micromanagement.
Characteristics:
- Cross-functional: Team has all necessary skills
- Self-organizing: Distributes tasks internally
- Empowered: Authority to make technical decisions
- Accountable: Responsible for results
12. Retrospectives and Inspect & Adapt
Kaizen (改善): Continuous improvement, small and constant.
Sprint Retrospective: Event at the end of each sprint to reflect.
- Key questions:
- What went well? (keep doing)
- What went wrong? (stop doing)
- What can we improve? (start doing)
- Output: 1-3 concrete action items for next sprint
- Rule: Safe space, no blame, focus on process
Iterative and Incremental Cycle
The heart of Agile is iterative (repeated in cycles) and incremental (each cycle adds value) development.
📅 SPRINT (2 weeks example)
🔵 DAY 1: SPRINT PLANNING (4 hours)
├─ Part 1: WHAT (2 hours)
│ ├─ Product Owner presents backlog priorities
│ ├─ Team selects user stories for sprint
│ └─ Sprint Goal defined
└─ Part 2: HOW (2 hours)
├─ Team breaks down stories into tasks
├─ Estimate effort in hours
└─ Sprint Backlog created
🟢 DAYS 2-9: DEVELOPMENT
├─ Daily Standup every morning (15 min)
│ ├─ What did I do yesterday?
│ ├─ What will I do today?
│ └─ Do I have impediments/blockers?
├─ Coding, testing, continuous integration
├─ Backlog Refinement (mid-sprint, 1 hour)
└─ Collaboration with Product Owner
🟡 DAY 10: SPRINT REVIEW (2 hours)
├─ Demo of completed work
├─ Stakeholders provide feedback
├─ Product Owner accepts/rejects stories
└─ Backlog updated with insights
🔴 DAY 10: SPRINT RETROSPECTIVE (1.5 hours)
├─ What went well?
├─ What went wrong?
├─ Action items to improve
└─ Team commitment
🔵 Repeat cycle with new Sprint...User Stories and Backlog Management
📝 User Stories
User stories are the Agile way of capturing requirements. Format:
"As [user type], I want [action] so that [benefit]"
✅ WELL-WRITTEN STORY
As an e-commerce customer,
I want to save products in a wishlist
so that I can purchase them in the future without searching again.
Acceptance Criteria:
- "Add to Wishlist" button on every product
- "My Wishlist" page accessible from header
- Ability to remove items from wishlist
- Wishlist persists between sessions (login required)
Story Points: 5
Priority: Medium
---
✅ TECHNICAL STORY (SPIKE)
As a development team,
I want to explore NoSQL databases (MongoDB vs DynamoDB)
so that we can choose the best solution for our use case.
Acceptance Criteria:
- Proof of concept with both
- Comparison document (performance, cost, scalability)
- Final recommendation
Timebox: 3 days
Priority: High (blocker)📚 Product Backlog
- Ordered list of all work
- Prioritized by Product Owner
- Continuously evolving (living document)
- Top items more detailed (ready)
- Bottom items vague (placeholder)
📋 Sprint Backlog
- Subset of Product Backlog
- Work for this sprint
- Owned by Development Team
- Broken down into tasks (2-8 hours)
- Updated daily
Agile Metrics
1. Velocity
Definition: Story points completed per sprint (average).
Sprint | Committed | Completed | Velocity
-------|-----------|-----------|----------
1 | 20 | 15 | 15
2 | 18 | 18 | 16.5
3 | 20 | 17 | 16.7
4 | 17 | 19 | 17.3
5 | 18 | 18 | 17.4 ← Stabilized
📊 Insights:
- Team has velocity ~17-18 story points
- Use for future planning
- Don't compare velocity between different teams!2. Burndown Chart
Graph showing remaining work vs time.
Story Points
↑
40 │●
│ ╲
30 │ ●╲ ← Ideal (dashed line)
│ ╲●
20 │ ╲ ●
│ ╲ ● ← Actual (solid line)
10 │ ╲ ●
│ ╲ ●
0 └────────╲─────●─→ Days
1 2 3 4 5 6 7 8 9 10
✅ GOOD: Actual follows ideal
⚠️ WARNING: Actual above ideal = at risk
❌ BAD: Flat actual = no progress3. Cumulative Flow Diagram (CFD)
Visualizes work flow through states (To Do, In Progress, Done).
Agile Mindset and Culture
Agile is not just a process, it's a mindset. Deep cultural change.
| Aspect | Traditional Mindset | Agile Mindset |
|---|---|---|
| Failures | Avoid at all costs | Learning opportunities |
| Planning | More detailed is better | Just enough, adaptive |
| Change | Problem, resistance | Opportunity, welcome |
| Control | Command & control | Servant leadership |
| Responsibility | Individual | Collective (team) |
| Knowledge | Silos, specialized expertise | Shared, T-shaped skills |
| Decisions | Top-down | Decentralized |
| Success Metric | On time, on budget | Customer value |
Challenges in Agile Adoption
🚧 Common Obstacles
1. Resistance to Change
Problem: "We've always done it this way, why change?"
Solution:
- Start small: pilot team
- Demonstrate quick win successes
- Executive sponsorship
- Training and coaching
2. Fake Agile (Agile in Name Only)
Problem: Team does Scrum ceremonies but maintains Waterfall mindset.
Symptoms:
- Sprint planning is top-down command
- No retrospectives or they don't produce changes
- Team has no ownership
- Daily standup becomes status report to manager
3. Lack of Dedicated Product Owner
Problem: Part-time or absent PO.
Impact: Backlog not prioritized, team blocked, scope drift.
4. Ignored Technical Debt
Problem: Focus only on features, quality neglected.
Consequence: Velocity decreases over time, bugs increase.
5. Distributed Teams
Problem: Teams in different time zones, asynchronous communication.
Solution:
- Overlap working hours (core hours)
- Over-communicate in writing
- Collaborative tools (Miro, Mural)
- Video always on in team room
Agile vs Waterfall: When to Use What
| Factor | Use Agile | Use Waterfall |
|---|---|---|
| Requirements | Uncertain, evolving | Clear, stable, fixed |
| Customer | Available, collaborative | Distant, approval only |
| Time-to-Market | Critical, high competition | Flexible |
| Team | Co-located, senior | Distributed, junior |
| Technology | New, experimental | Mature, proven |
| Compliance | Low | High (FDA, aerospace) |
| Budget | Flexible | Fixed, rigid contract |
| Project | Innovative, MVP | Maintenance, migration |
Popular Agile Frameworks
Agile is an umbrella that includes various frameworks. The most used:
🏃 Scrum
- Most popular framework (70% adoption)
- Sprints of 1-4 weeks
- 3 roles, 5 events, 3 artifacts
- Highly structured
📊 Kanban
- Continuous flow, no sprints
- WIP (Work In Progress) limits
- Visualization with board
- Less prescriptive than Scrum
🔧 XP (Extreme Programming)
- Focus on technical practices
- TDD, Pair Programming, CI
- Very frequent releases
- Code excellence
🏭 Lean Software Development
- Inspired by Toyota Production System
- Waste elimination
- Value Stream Mapping
- Continuous improvement (Kaizen)
Conclusions
Agile has revolutionized the software industry by bringing focus on people, collaboration, and adaptability. It's not a magic formula but a mindset that requires cultural commitment and constant practice.
💡 Key Takeaways
- Agile is based on 4 values and 12 principles of the Manifesto
- Iterative and incremental development with frequent releases
- Continuous customer collaboration is essential
- Self-organizing and cross-functional teams
- Technical quality and sustainable pace are fundamental
- Retrospectives for continuous improvement (Kaizen)
- Mindset more important than process: embrace change
📚 Next Article
In the next article, we'll explore Scrum Framework in detail: the 3 roles (Product Owner, Scrum Master, Dev Team), the 5 ceremonies, the 3 artifacts, and how to implement Scrum effectively.