Agile & Scrum
The dominant project management paradigm for software and IT projects. Replaces Waterfall’s sequential phases with iterative, feedback-driven cycles.
Why Agile Replaced Waterfall
Waterfall (1970s–1990s): Requirements → Design → Development → Testing → Deployment → Maintenance. Sequential, each phase completes before the next starts. Borrowed from construction and manufacturing (Taylor’s OST applied to software).
Problem discovered (Standish Group CHAOS Report, 1994): 31% of software projects cancelled, 53% over budget, 16% delivered on time/budget. Root cause: requirements change mid-project, but Waterfall can’t adapt.
Agile Manifesto (2001, 17 signatories including Beck, Fowler, Martin): Four values over their counterparts:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
This is Mayo’s behavioral school applied to software: the human element + adaptability beats rigid structure.
The 12 Agile Principles (condensed)
- Deliver working software frequently (weeks, not months)
- Welcome changing requirements, even late in development
- Business people and developers work together daily
- Build projects around motivated individuals; trust them
- Face-to-face conversation is most efficient communication
- Working software is the primary measure of progress
- Sustainable pace — can maintain indefinitely
- Continuous attention to technical excellence
- Simplicity — maximize work NOT done
- Self-organizing teams produce the best architectures
- Regularly reflect and adjust behavior (retrospectives)
Scrum — The Most Widely Used Agile Framework
Author: Ken Schwaber & Jeff Sutherland (1990s, formalized 2001)
The Three Pillars (SIE)
- Transparency: everyone sees the same truth
- Inspection: frequent checks of progress and process
- Adaptation: adjust when deviation detected
The Five Values
Commitment · Focus · Openness · Respect · Courage
Scrum Roles
| Role | Responsibilities |
|---|---|
| Product Owner (PO) | Owns the Product Backlog. Defines priorities. Represents the customer. Says what to build. |
| Scrum Master (SM) | Facilitates Scrum events. Removes impediments. Coaches the team on Scrum. Not a PM. |
| Development Team | Cross-functional (dev, QA, design). Self-organizing. 3–9 people. Does the actual work. |
In solo or small-team projects (like yours): Ahmed = PO + SM + Dev Team. This works but creates tension — the PO must be willing to say “no” to the developer.
Scrum Artifacts
| Artifact | Description |
|---|---|
| Product Backlog | Ordered list of all features, bugs, improvements (PBIs). PO owns it. |
| Sprint Backlog | Subset of Product Backlog committed for the current Sprint. Dev Team owns it. |
| Increment | The sum of all PBIs completed in the Sprint + all previous Sprints. Must be “Done.” |
| Definition of Done (DoD) | Shared understanding of when a PBI is complete (e.g., code reviewed, tests passing, deployed to staging) |
Scrum Events
Sprint Planning (2–4h for 2-week sprint)
↓
Sprint (1–4 weeks, fixed duration)
├── Daily Scrum (15 min, same time, same place)
│ └── 3 questions: What did I do yesterday? What will I do today? What's blocking me?
└── Sprint ends → Sprint Review (demo to stakeholders) + Sprint Retrospective (team improves process)
Sprint Goal
One sentence describing what value will be delivered by end of Sprint. Keeps team aligned even if individual tasks change.
Kanban — Flow-Based Agile
Origin: Toyota Production System (TPS) — Taiichi Ohno. Pull-based inventory system adapted to knowledge work by David Anderson (2007).
Core principles:
- Visualize the workflow
- Limit Work In Progress (WIP)
- Manage flow
- Make policies explicit
- Implement feedback loops
- Improve collaboratively
Kanban Board (your Task Board is this)
| BACKLOG | TO DO | IN PROGRESS | REVIEW | DONE |
|---------|-------|-------------|--------|------|
| ... | ... | WIP limit:3 | ... | ... |
WIP Limit: the key mechanism. Limiting “In Progress” columns forces finishing before starting new work. Reduces context switching (a hidden Muda from Lean).
Key Kanban Metrics
- Lead Time: time from “requested” to “delivered”
- Cycle Time: time from “started” to “delivered”
- Throughput: items completed per unit time
- Cumulative Flow Diagram (CFD): shows bottlenecks visually
Scrum vs Kanban
| Scrum | Kanban | |
|---|---|---|
| Cadence | Fixed Sprints (1–4 weeks) | Continuous flow |
| Roles | PO, SM, Dev Team | No prescribed roles |
| Changes | Wait for next Sprint | Anytime |
| Best for | New features, product development | Support, maintenance, operational work |
| Metrics | Velocity (story points/sprint) | Lead time, cycle time |
Your context: Use Scrum-like waves for SijiLab feature development. Use Kanban for SijilPharma PR reviews and bug fixes.
SAFe — Scaled Agile Framework
For large organizations (50+ engineers). Hierarchy: Teams → Programs → Large Solutions → Portfolio. Includes Portfolio Kanban, PI Planning (quarterly), Agile Release Trains (ART).
Not relevant at your current scale, but relevant when selling to large Moroccan enterprises (OCP, Maroc Telecom) who may use SAFe internally.
Shape Up — Basecamp’s Alternative to Scrum
Author: Ryan Singer at Basecamp (2019).
Key concepts:
- 6-week cycles (not 2-week sprints): long enough for meaningful work
- Shaping (before the cycle): de-risk and define scope before assigning to a team
- Appetite (not estimates): decide how much time a problem is worth before you scope it
- Circuit breaker: if not done in 6 weeks, project is cancelled or re-shaped (not extended)
- Betting table: choose what to work on from shaped pitches
- No backlog: the backlog is a trap (most items die anyway)
Shape Up is increasingly popular in product-focused startups. Consider it for DigiTPME Platform work.
Estimation Techniques
Story Points (Scrum)
Relative effort estimate, not time. Uses Fibonacci: 1, 2, 3, 5, 8, 13, 21.
- 1 point = trivial change
- 3 points = clear task, some unknowns
- 8 points = complex, needs discovery
- 13+ = too large, must be split
Planning Poker: each team member privately estimates, reveals simultaneously, discusses disagreements.
T-Shirt Sizing
XS / S / M / L / XL. Used in roadmap planning (low precision needed).
PERT Estimate
(Optimistic + 4 × Most Likely + Pessimistic) / 6
Gives weighted average accounting for uncertainty.
Technical Practices (XP — Extreme Programming)
Key practices that complement Scrum and Kanban:
| Practice | Description | Your Context |
|---|---|---|
| TDD (Test-Driven Development) | Write test → fail → write code → pass → refactor | SijilPharma has 0 frontend tests (risk) |
| Pair Programming | Two devs on one problem simultaneously | Use for complex SijiLab modules |
| Continuous Integration (CI) | Merge and test multiple times per day | GitHub Actions in NOTQIN |
| Continuous Delivery (CD) | Every commit is potentially deployable | Target for all SaaS products |
| Refactoring | Improve code structure without changing behavior | Manage technical debt proactively |
| YAGNI | ”You Aren’t Gonna Need It” — don’t build speculative features | Critical discipline for solo founders |
Agile in IT/Industrial Projects (Your Context)
OT/IT Projects (NOTQIN)
Industrial projects have hardware constraints that pure software Agile doesn’t account for:
- Hardware sprints have longer cycles (procurement, installation)
- Use dual-track Agile: discovery track + delivery track run in parallel
- Firmware/edge code needs stricter DoD (hardware-in-the-loop tests)
- Safety-critical code (PLC, sensors) → IEC 62443, DO-178C standards exist alongside Agile
Data/ML Projects
→ See AI & Data Project Management for Agile adaptations to ML (CRISP-DM, MLOps sprints)
SaaS Projects
- Sprint = Wave (your terminology already matches)
- Each wave: scope → build → test → deploy → measure → next wave
- Combine with Product Discovery to ensure you’re building the right things
Retrospective Formats (improving the team)
Start / Stop / Continue
What should we START doing? STOP doing? CONTINUE doing?
4Ls
Liked / Learned / Lacked / Longed For
Mad / Sad / Glad
Emotional check-in on the team’s experience in the sprint.
5 Whys
For root cause analysis of a recurring problem. Ask “why?” 5 times.
Applied to Your Projects
| Project | Agile Approach |
|---|---|
| SijiLab | Waves = Sprints. Define DoD per wave (52 uncommitted files → missing DoD). Add “deployed to staging” to DoD. |
| NOTQIN IEIA | 20 waves completed — good velocity. Add retrospective after Wave 20 to extract learnings. |
| DigiTPME Diagnostic | Shape Up: shape the questionnaire feature (6-week appetite). Don’t sprint on unvalidated features. |
| SijilPharma | Kanban: manage PRs as flow items, limit WIP to 2 PRs at once. |
| Idarati RAG | Dual-track: discovery (user interviews) + delivery (RAG improvements) in parallel. |
Key Vocabulary for Interviews / Client Conversations
| Term | Definition |
|---|---|
| Sprint | Fixed-duration iteration (1–4 weeks) in Scrum |
| Velocity | Story points completed per sprint (team capacity measure) |
| Backlog refinement | Regular grooming of Product Backlog to clarify and estimate upcoming items |
| Definition of Ready | Criteria for a PBI to enter a Sprint (clear, estimated, testable) |
| Definition of Done | Criteria for a PBI to be considered complete |
| Epic | Large body of work, broken into Stories |
| User Story | ”As a [role], I want [feature], so that [benefit]“ |
| Acceptance Criteria | Conditions the User Story must satisfy |
| Impediment | Anything blocking the team’s progress |
| Burndown Chart | Work remaining vs. time in a Sprint |
| Retrospective | Sprint closing meeting: team reflects on process |
See Also
- Modern Management Overview
- OKRs — Objectives & Key Results
- AI & Data Project Management
- Product Management Frameworks
- Team Topologies & Org Design
- Coordinator OS/02 — Weekly Cadence