Agile Project Management

1. Why Agile?

Before agile became mainstream, most software projects followed a sequential, plan-driven approach commonly known as the Waterfall model. In Waterfall, each phase (requirements, design, implementation, testing, deployment) must be completed before the next begins. This works well when requirements are stable and well-understood upfront — think building a bridge or manufacturing a car. But software is different.

Software requirements change constantly. Users don't know what they want until they see it. Markets shift. Technology evolves. The Standish Group's CHAOS reports have consistently shown that over 60% of software features are rarely or never used, and that only about 29% of IT projects succeed on time, on budget, and with satisfactory results. The majority of failures can be traced back to poor requirements, late feedback, and inability to adapt to change.

The Problems with Waterfall

• Late feedback: users only see the product at the very end, when changes are most expensive
• Big-bang integration: components built in isolation often fail when combined
• Change resistance: any change to requirements triggers costly rework across all phases
• Documentation overhead: detailed specs become outdated before code is written
• Risk concentration: all risk is pushed to the end (integration and testing phases)

Agile emerged not as a single methodology, but as a set of values and principles that prioritize human collaboration, working software, and adaptability over rigid processes and comprehensive documentation. It acknowledges that uncertainty is inherent in software development and builds processes that embrace rather than resist change.

2. The Agile Manifesto

The 4 Core Values

The manifesto declares four value pairs. In each pair, while the items on the right have value, the items on the left are valued more:

The 12 Principles

Behind the manifesto are 12 principles that guide agile teams in practice:

1. Customer satisfaction through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. Face-to-face conversation is the most efficient and effective method of conveying information.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

3. Scrum Framework

Scrum is the most widely adopted agile framework. According to the 17th State of Agile Report (2023), 87% of agile teams use Scrum or a Scrum-based hybrid. Scrum is defined in the Scrum Guide (scrumguides.org), a concise 13-page document maintained by Ken Schwaber and Jeff Sutherland, the co-creators of Scrum.

Scrum is built on three pillars of empiricism: transparency (everyone sees the same reality), inspection (regularly check progress and artifacts), and adaptation (adjust when things deviate from the goal).

The Three Roles

The Three Artifacts

• Product Backlog: an ordered list of everything that might be needed in the product. Owned by the PO. Continuously refined (groomed). Items at the top are more detailed and ready.
• Sprint Backlog: the set of Product Backlog items selected for the sprint, plus a plan for delivering them and achieving the Sprint Goal. Owned by the Dev Team.
• Increment: the sum of all completed Product Backlog items during a sprint, plus all previous increments. Must meet the Definition of Done and be potentially releasable.

The Five Events

Every Scrum event is time-boxed — it has a maximum duration that cannot be exceeded. This creates healthy constraints and forces focus.

4. Kanban

Kanban originated in Toyota's manufacturing system in the 1950s. The word literally means "visual signal" or "card" in Japanese. David J. Anderson adapted it for knowledge work and software development in 2010. Unlike Scrum, Kanban does not prescribe roles, ceremonies, or time-boxed iterations. It focuses on three things: visualize work, limit work in progress, and manage flow.

A Kanban board has columns representing stages of your workflow (e.g., Backlog, To Do, In Progress, Review, Done). Cards move from left to right as work progresses. The key innovation is the WIP limit — a maximum number of cards allowed in each column.

Why WIP Limits Matter

Work in Progress (WIP) limits are the single most important element of Kanban. Without them, a Kanban board is just a visual task list. Here's why they work:

• Reduced context switching: studies show that context switching wastes 20-40% of a developer's productive time. Finishing one thing before starting another eliminates this waste.
• Faster flow: Little's Law (from queuing theory) states that Lead Time = WIP / Throughput. Reducing WIP mathematically reduces lead time.
• Earlier bottleneck detection: when a column hits its WIP limit, work backs up, making the bottleneck visible. The team can then address the root cause.
• Higher quality: focused attention on fewer items leads to fewer defects and better craftsmanship.

# Little's Law: L = λ × W
# L = average number of items in the system (WIP)
# λ = average arrival rate (throughput)
# W = average time in the system (lead time)

# Example: Team delivers 8 items/week, has 24 items in progress
lead_time = WIP / throughput
lead_time = 24 / 8  # = 3 weeks per item

# Reduce WIP to 16:
lead_time = 16 / 8  # = 2 weeks per item (33% faster!)

# The math is clear: less WIP = faster delivery

5. User Stories & Estimation

A user story is a short, plain-language description of a feature told from the perspective of the person who desires the new capability, usually a user or customer. The canonical format is:

As a [type of user],
I want [some goal],
So that [some reason/business value].

# Example:
As a logged-in customer,
I want to filter my orders by date range,
So that I can quickly find a specific purchase for a return.

# Acceptance Criteria (Given-When-Then):
Given I am on the orders page
When I select a start and end date
Then only orders within that range are displayed
And the total count updates accordingly

Good user stories follow the INVEST criteria:

• Independent — can be developed in any order
• Negotiable — details are discussed, not dictated
• Valuable — delivers value to the user or business
• Estimable — small enough to estimate effort
• Small — fits within a single sprint
• Testable — has clear acceptance criteria

Estimation Techniques

Definition of Done (DoD)

The Definition of Done is the team's shared agreement on what "done" really means. Without it, "done" is subjective — one person thinks it means "code written," another thinks it means "tested and deployed." A good DoD eliminates ambiguity and ensures consistent quality.

# Definition of Done — Team Agreement
done_when:
  - "Code reviewed by at least 1 peer"
  - "Unit tests written and passing (>80% coverage)"
  - "Integration tests green on CI"
  - "No critical/high SonarQube issues"
  - "API documentation updated (if applicable)"
  - "Deployed to staging environment"
  - "PO has accepted the increment"

# The DoD is not negotiable during a sprint.
# Items that don't meet the DoD are NOT done.

6. Agile Metrics

What gets measured gets managed — but only if you measure the right things. Agile metrics should focus on outcomes (value delivered) and flow (how smoothly work moves through the system), not outputs (lines of code) or utilization (hours worked).

Burndown Charts & Cumulative Flow Diagrams

A Burndown Chart plots the amount of work remaining (y-axis) against time (x-axis) within a sprint. The ideal line is a diagonal from top-left (all work remaining) to bottom-right (zero remaining). If the actual line is above the ideal, the team is behind; below means ahead.

A Cumulative Flow Diagram (CFD) is Kanban's primary diagnostic tool. It shows the number of items in each state (To Do, In Progress, Done) over time as stacked area bands. Key insights:

• Widening bands: indicate a bottleneck (work is piling up in that state)
• Flat top line: means no new work is entering the system (scope freeze)
• Horizontal distance: approximates lead time
• Vertical distance: shows WIP at any point in time

7. Agile Tools

Tools support the process — they don't define it. A team using sticky notes on a wall can be more agile than a team with a $50,000 Jira instance. That said, for distributed teams and complex projects, digital tools are essential.

# Create an issue with labels and assignment
gh issue create --title "Add user authentication API" \
  --label "feature,sprint-3" --assignee @me

# List open issues for the current sprint
gh issue list --label "sprint-3" --state open

# Close an issue when the PR is merged
gh issue close 42 --reason completed

# View project board status
gh project item-list 1 --owner @me --format json

8. Agile Anti-Patterns

Adopting agile is easy. Being agile is hard. Many organizations adopt the ceremonies and vocabulary of agile without embracing the underlying values. Here are the most common anti-patterns to watch for:

9. Scrumban — The Best of Both Worlds

Many mature teams evolve toward Scrumban, a hybrid that combines Scrum's structure with Kanban's flow optimization. Scrumban works particularly well for teams that:

• Have a mix of planned work and unplanned support/bug-fix work
• Want to keep sprint cadence but reduce planning overhead
• Need WIP limits to manage flow but still value regular retrospectives

10. Agile Checklist

Use this checklist to assess whether your team is practicing agile effectively. Click to check off items: