Agile Metrics và Scaling

Agile Metrics

Why Metrics?

Good metrics:
- Guide decisions
- Reveal trends
- Inspect & adapt
- Transparent

Bad uses:
- Performance reviews
- Comparison between teams
- Gaming the system
- Micromanagement

Leading vs Lagging Indicators

Leading:
- Predictive
- Early signals
- Actions now
Ví dụ: Test coverage, WIP, Cycle time

Lagging:
- Outcome-based
- After the fact
Ví dụ: Bugs in production, Revenue, NPS

Best: Both

Velocity

Definition

Velocity = Sum of story points completed per Sprint

Track:
- Over 5+ sprints
- Average, not single sprint
- Trend, not absolute

Ví dụ:
Sprint 1: 25
Sprint 2: 30
Sprint 3: 28
Sprint 4: 32
Sprint 5: 35
Average: 30
Trend: Increasing

Forecast:
Next sprint: 30-35 points
Release (10 sprints): 300-350 points

Velocity Anti-patterns

1. Use as KPI for individuals
2. Compare teams
3. Bonus based on velocity
4. Inflate story points
5. Decrease story points same work

Better:
- Use for forecasting
- Focus on value delivered
- Team commitment

Burndown Chart

Types

Sprint Burndown:
- X: Days in sprint
- Y: Story points remaining
- Update: Daily

Release Burndown:
- X: Sprints
- Y: Story points remaining
- Tracked: Per sprint

Reading Burndown

Ideal line: Straight line from total to 0

Actual:
- Above ideal: Behind
- Below ideal: Ahead
- Flat: Blocked/stuck
- Going up: Scope added

Ví dụ:
Day 0: 30
Day 1: 28
Day 2: 26
Day 3: 26 (flat - problem!)
Day 4: 20 (recovered)
...
Day 10: 0 ✓

Burnup Chart

Structure

Lines:
- Total scope (may change)
- Work completed

Ví dụ:
Sprint 1: Scope 50, Done 30
Sprint 2: Scope 55, Done 50
Sprint 3: Scope 60, Done 55

Advantages vs Burndown:
- Shows scope changes
- Progress visible
- Easier to read

Cumulative Flow Diagram (CFD)

Structure

Stacked area chart:
Y-axis: Number of items
X-axis: Time

Bands (bottom to top):
- Done
- In Testing
- In Progress
- Ready for Dev
- Backlog

Read:
- Band width = WIP
- Parallel bands = Flow
- Widen = Increasing WIP
- Narrow = Decreasing WIP

CFD Patterns

Healthy: Parallel bands, steady flow

Problem 1: "In Progress" widening
→ Too much WIP, need to focus

Problem 2: "Testing" widening
→ Bottleneck, need more testers or automation

Problem 3: "Backlog" widening
→ Scope growing faster than delivery

Problem 4: Bands not parallel
→ Inconsistent flow

Lead Time & Cycle Time

Definitions

Lead Time:
From: Request created
To: Request delivered
Includes: Wait + Work time

Cycle Time:
From: Work started
To: Work delivered
Only: Actual work time

Ví dụ

Story timeline:
Jan 1: Created
Jan 3: Moved to In Progress
Jan 5: Moved to Testing
Jan 6: Deployed

Lead Time: Jan 1 → Jan 6 = 5 days
Cycle Time: Jan 3 → Jan 6 = 3 days
Wait Time: Jan 1 → Jan 3 = 2 days

Improvements:
- Reduce lead time (earlier start)
- Reduce cycle time (faster work)
- Reduce wait time (less queue)

Little's Law

Cycle Time = WIP / Throughput

Ví dụ:
WIP = 20 items
Throughput = 4 items/week
Cycle Time = 20/4 = 5 weeks

To reduce cycle time:
- Reduce WIP
- Increase throughput
- Both

Throughput

Definition

Throughput = Items completed per time period

Track:
- Daily
- Weekly
- Sprint

Ví dụ:
Week 1: 5 stories
Week 2: 6 stories
Week 3: 4 stories
Week 4: 7 stories

Average: 5.5 stories/week

Flow Metrics

Flow Distribution

Types:
- Story: 60%
- Bug: 25%
- Tech Debt: 10%
- Support: 5%

Healthy:
- Story > 70%
- Bug < 15%
- Balanced

Warning:
- Bug > 30%: Quality issue
- Support > 20%: Operational issue

Flow Efficiency

Flow Efficiency = Work Time / Total Time × 100%

Ví dụ:
Total time: 5 days
Work time: 2 days
Wait time: 3 days
Efficiency = 2/5 = 40%

Industry average: 15-40%
Best-in-class: > 50%

Scaling Agile

When to Scale?

Signals:
- Multiple teams
- Same product
- Coordination needed
- Dependencies common
- Shared architecture
- Same customer

Not scaled when:
- Independent products
- Different business units
- Stable interfaces

Scaling Frameworks

1. Scrum of Scrums

Structure:
- Multiple Scrum teams
- Each sends 1-2 representatives
- Daily sync (SoS)
- Weekly coordination

Pros:
- Simple
- Low overhead
- Flexible

Cons:
- Limited scaling
- Communication gaps
- No architectural focus

Best for: 2-5 teams

2. SAFe (Scaled Agile Framework)

Structure:
- Team level: Scrum teams
- Program level: Agile Release Train (ART)
- Large Solution: Multiple ARTs
- Portfolio: Strategic

Key elements:
- PI Planning (quarterly, 2 days)
- Program Increment (8-12 weeks)
- Release Train Engineer (RTE)
- System Architect
- Product Management

Ceremonies:
- PI Planning
- Scrum of Scrums
- PO Sync
- System Demo
- Inspect & Adapt
- ART Sync

Pros:
- Comprehensive
- Enterprise-ready
- Well documented

Cons:
- Heavy
- Can be bureaucratic
- Requires training

Best for: 50+ people, enterprises

3. LeSS (Large-Scale Scrum)

Structure:
- One Product Owner
- One Product Backlog
- Multiple teams (2-8+)
- Same Sprint

Ceremonies:
- Sprint Planning 1 (all teams)
- Sprint Planning 2 (per team)
- Daily Scrum (per team)
- SoS (Scrum of Scrums)
- Overall Retro

Rules:
- Same length sprint
- Same Definition of Done
- Common codebase

Pros:
- Simple rules
- Team autonomy
- Less overhead

Cons:
- Hard to adopt
- Requires disciplined teams
- Organizational change

Best for: Product companies

4. Nexus

Structure:
- Scrum.org framework
- 3-9 Scrum teams
- Nexus Integration Team (NIT)
- One Product Backlog

Ceremonies:
- Nexus Sprint Planning
- Nexus Daily Scrum
- Nexus Sprint Review
- Nexus Sprint Retro

Focus:
- Dependencies
- Integration
- Common goals

Pros:
- Scrum-aligned
- Simple
- Well-defined

Cons:
- Newer
- Less adoption

Best for: Scrum.org users

Scaling Comparison

| Aspect | SoS | SAFe | LeSS | Nexus |
|--------|-----|------|------|-------|
| Teams | 2-5 | 50+ | 2-8+ | 3-9 |
| Complexity | Low | High | Medium | Medium |
| Ceremony | Light | Heavy | Medium | Medium |
| Framework | Simple | Full | Minimal | Scrum-aligned |
| Cost | Low | High | Medium | Low |
| Adoption | Easy | Complex | Hard | Medium |

Cross-Team Dependencies

Types

1. Same codebase
   - Merge conflicts
   - Breaking changes

2. Shared services
   - API changes
   - Versioning

3. Shared resources
   - Test environment
   - DevOps support

4. Sequential work
   - Team A waits for Team B
   - Handoffs

5. Architectural
   - Platform changes
   - Standards

Managing Dependencies

1. Identify early
   - PI Planning
   - Dependency mapping
   - Board visualization

2. Minimize
   - Architecture
   - API-first
   - Team topology
   - Vertical slicing

3. Coordinate
   - Regular syncs
   - Slack channels
   - Joint refinement
   - Pair work

4. Visualize
   - Dependency board
   - Colored strings
   - Owner tracking

Scaled Ceremonies

PI Planning (SAFe)

Duration: 2 days
Frequency: Every 8-12 weeks

Attendees:
- All teams
- Product Managers
- Architects
- Stakeholders

Agenda Day 1:
- Business context
- Product vision
- Architecture vision
- Team breakouts (plan)
- Draft plans

Agenda Day 2:
- Draft plan review
- Management review
- Adjust
- Final plan
- Confidence vote

Outputs:
- PI Objectives
- Team PI plans
- Program Board
- Risks

Scrum of Scrums

Frequency: Daily or 2-3x/week
Duration: 15 min
Attendees: 1-2 from each team

Questions:
1. What did team do?
2. What will team do?
3. What blockers?
4. What dependencies?
5. What risks?

Follow-up: After sync

Agile Transformation

Kotter's 8 Steps

1. Create urgency
2. Build guiding coalition
3. Form vision
4. Communicate vision
5. Empower action
6. Create short-term wins
7. Consolidate gains
8. Anchor changes

Common Pitfalls

1. "Doing" Agile, not "Being" Agile
   - Ceremonies only
   - No mindset change

2. Top-down push
   - No buy-in
   - Resistance

3. Too fast
   - Everything at once
   - Overwhelming

4. Not enough training
   - Teams don't know how
   - Bad practices

5. No executive support
   - Middle managers block
   - Budgets unchanged

6. Copy-paste
   - One size fits all
   - No context

7. Metrics misuse
   - Velocity as KPI
   - Performance reviews

8. Stop halfway
   - Revert to old ways
   - Cynicism

Success Factors

1. Executive sponsorship
2. Middle management engaged
3. Coaches experienced
4. Clear vision
5. Training investment
6. Patience (2-5 years)
7. Cultural fit
8. Metrics aligned
9. Continuous improvement
10. Celebrate wins

Bài tập thực hành

Hãy thiết kế scaling approach cho tổ chức!