DAY 03 — MALAYALAM NOTES
JUMP TO →
SLIDE 01 Title — Agile + DevOps Title
🎤 Opening
"Day 1-ൽ DevOps culture, Day 2-ൽ tools. ഇന്ന് Day 3 — Agile + DevOps. ഇവ രണ്ടും ഒന്നല്ല. ഒരു common confusion clear ചെയ്ത് start ആകാം: Agile ഒരു development process ആണ്. DevOps delivery + operations. ഇവ complement ചെയ്യുന്നു. ഒന്നിനൊന്ന് replace ചെയ്യുന്നില്ല."
💡 Ice Breaker
"നിങ്ങളുടെ team Scrum use ചെയ്യുന്നുണ്ടോ? Kanban? Daily standup ഉണ്ടോ?" — Response gather ചെയ്ത ശേഷം "ഇന്ന് ആ processes-ഉം DevOps pipelines-ഉം connect ആക്കാം" — pivot ചെയ്യൂ.
➜ SLIDE 2-ലേക്ക്
"ഇന്ന് cover ചെയ്യുന്നത്…"
SLIDE 02 Agenda Theory
🎤 Agenda overview
"ഇന്ന് 5 topics. ആദ്യം Agile vs DevOps-ൻ്റേ difference. ഫ്ലോ theory-ൽ Scrum deep dive, Kanban explanation. DORA metrics-ഉ Scrum retro-ൽ embed ചെയ്യൽ. 'Done' redefine ചെയ്യൽ. Lab-ൽ GitHub Project board setup — ഇത് നിങ്ങളുടെ 35-day course Kanban board ആകും."
➜ SLIDE 3-ലേക്ക്
"Agile-ഉം DevOps-ഉം — difference-ഉം connection-ഉം…"
SLIDE 03 Agile vs DevOps — Different but Inseparable Theory
🎤 Venn Diagram explain ചെയ്യുക
"Slide-ൽ ഒരു Venn diagram ആണ്. Left — Agile (blue). Right — DevOps (green). Center — shared values. ഒരൊറ്റ sentence-ൽ difference: Agile — 'ശരിയായ software build ചെയ്യാൻ'. DevOps — 'ആ software safely, quickly deliver ചെയ്യാൻ'. ഒന്ന് ഇല്ലാതെ മറ്റൊന്ന് incomplete."
🔵
Agile Only (Left side)
Sprint planning, daily standups, sprint review, retrospective, user stories, estimation — ഇവ pure Agile concepts ആണ്. Development team-ൻ്റേ work organize ചെയ്യൽ. "What to build and when" ഇതിൻ്റേ answer.
🟣
Shared Center
Collaboration, fast feedback, continuous improvement, automation — ഇവ Agile-ഉം DevOps-ഉം share ചെയ്യുന്ന values ആണ്. ഈ shared values-ൻ്റേ foundation-ൽ ആണ് ഇവ complement ചെയ്യുന്നത്.
🟢
DevOps Only (Right side)
CI/CD pipelines, Infrastructure as Code, automated testing, monitoring, release management, on-call practices — ഇവ pure DevOps. "How to deliver reliably and operate safely" ഇതിൻ്റേ answer.

Analogy: Agile ഒരു kitchen recipe-ക്ക് similar ആണ് — what ingredients, what steps, in what order. DevOps ഒരു kitchen delivery system-ക്ക് similar — ആ dish customer-ൻ്റേ door-ൽ hot ആയി, on time arrive ചെയ്യുന്നതെങ്ങനെ.

➜ SLIDE 4-ലേക്ക്
"Agile Manifesto — 2001-ൽ write ചെയ്‌ത 4 values. ഇന്നും relevant. DevOps-ഉ connect ചെയ്‌ത് explain ചെയ്യാം…"
SLIDE 04 Agile Manifesto — DevOps Bridge Theory
🎤 Manifesto explain ചെയ്യുക
"Agile Manifesto 2001-ൽ 17 software engineers Utah-ൽ ഒരു ski resort-ൽ ഒരുമിച്ചിരുന്ന് write ചെയ്‌ത ഒരു document ആണ്. 4 values, 12 principles. ഇന്നും most software teams follow ചെയ്യുന്നു. DevOps ഈ values-ൻ്റേ operational extension ആണ്."
Agile ValueDevOps Connection
"Individuals & interactions
over processes & tools"
Dev-ഉം Ops-ഉം shared on-call. Blameless culture. Daily standup-ൽ ഒരുമിച്ചിരിക്കൽ. Human collaboration tools-ഉകൊണ്ടും important.
"Working software
over comprehensive documentation"
CI/CD pipeline ഉള്ളതുകൊണ്ട് ഓരോ commit-ഉം deployable artifact produce ചെയ്യുന്നു. Working = deployed = running in production.
"Customer collaboration
over contract negotiation"
Feature flags ഉപയോഗിച്ച് real users-ൽ production-ൽ test ചെയ്യൽ. A/B testing. Canary deployments. Direct customer feedback loop.
"Responding to change
over following a plan"
Automated pipelines = change-ഉ minutes-ൽ ship ആകും. Manual process-ൽ change-ൻ്റേ cost high — DevOps-ൽ change-ൻ്റേ cost low, frequent changes safe.
⚠ Common Misconception — Clarify This
"Agile means no documentation" — ഇത് wrong interpretation ആണ്. Manifesto പറയുന്നത് "over" — "instead of" അല്ല. Documentation important, but don't let it block delivery. Running software > perfect docs.
➜ SLIDE 5-ലേക്ക്
"Agile-ൻ്റേ most popular framework — Scrum. DevOps perspective-ൽ deep dive ആകാം…"
SLIDE 05 Scrum — The Most Widely Used Agile Framework Theory
🎤 Scrum Pipeline Flow explain ചെയ്യുക
"Slide-ൽ Scrum cycle ഒരു pipeline-ആ കാണിക്കുന്നു. Product Backlog → Sprint Planning → Sprint → Sprint Review → Retrospective → (next sprint). ഈ cycle ഓരോ 2 ആഴ്ചയും repeat ആകുന്നു. DevOps ഇതിൽ 3 critical additions ചെയ്യുന്നു — sprint planning-ൽ infra tasks, review-ൽ deployed demo, retro-ൽ DORA metrics."
👤
Product Owner (PO)
Business-ൻ്റേ voice. Backlog prioritise ചെയ്യുന്നു. "ഈ feature customer-ന് ഏത്ര value deliver ചെയ്യും?" ഇതിൻ്റേ answer PO-ൻ്റേ കയ്യിൽ ആണ്. DevOps context-ൽ: PO infrastructure reliability-ഉ user experience-ൻ്റേ part ആയി consider ചെയ്യണം.
🛡
Scrum Master (SM)
Facilitator. Blockers remove ചെയ്യുന്നു. Team-ൻ്റേ shield. DevOps context-ൽ: "CI pipeline broken-ആ sprint slow ആകുന്നോ?" ഇത് Scrum Master identify ചെയ്‌ത address ചെയ്യണം.
👨‍💻
Development Team
DevOps-ൽ "development team" = developers + testers + Ops engineers + security. Cross-functional ആകണം. "Dev-ൻ്റേ job feature write ചെയ്യൽ, Ops-ൻ്റേ job deploy ചെയ്യൽ" — ഈ separation DevOps-ൽ disappear ആകണം.
Sprint Planning Addition
Traditional sprint planning-ൽ: features only. DevOps addition: CI/CD tasks, monitoring setup, security scanning, IaC updates, runbooks — ഇവ ഒക്കെ backlog-ൽ ഉണ്ടാകണം. Estimate ചെയ്‌ത sprint-ൽ include ചെയ്യണം.
Daily Standup Addition
Traditional 3 questions: What did I do? What will I do? Blockers? DevOps 4th question: "Any CI/CD or infra blockers? Build failing? Pipeline broken?" — ഇത് daily surface ആകണം.
Sprint Review Addition
"It works on my machine" demo not acceptable. Sprint review-ൽ live deployment-ൻ്റേ URL show ചെയ്‌ത demo. Staging-ൽ deployed ആകിയ feature live-ആ show ചെയ്‌ത ഒക്കെ available ആകണം.
➜ SLIDE 6-ലേക്ക്
"ഓരോ ceremony-ഉം detail-ൽ DevOps perspective-ൽ നോക്കാം…"
SLIDE 06 Scrum Ceremonies — DevOps Perspective Table Theory
🎤 Table row-by-row walk ചെയ്യുക
"ഈ table-ൽ ഓരോ ceremony-ഉം traditional-ഉം DevOps-ഉം compare ചെയ്‌ത കാണിക്കുന്നു. Right column (green) — DevOps addition-ആ. ഇവ team adopt ചെയ്‌ത ശേഷം DORA metrics improve ആകും."

Sprint Review row — ഇത് emphasize ചെയ്യൂ: "Demo must be a live deployment." ഒരു team ഇത് practice ആക്കിയ ശേഷം, team automatically deployable code write ചെയ്യും. Nobody wants to demo broken code. Demo pressure = quality pressure = better engineering.

Retrospective row — DORA metrics trend review. "This sprint-ൽ Lead Time കൂടി? Why? Pipeline slow ആയോ? Long-running tests?" ഇത് identify ചെയ്‌ത next sprint-ൽ address ചെയ്യൽ. Continuous improvement.

💡 Powerful Retro Question
Sprint retro-ൽ ചോദിക്കേണ്ട best DevOps question: "If we had to deploy right now, in 5 minutes, what would prevent us?" — ഈ question-ൻ്റേ answer team-ൻ്റേ biggest delivery bottleneck reveal ചെയ്യും.
➜ SLIDE 7-ലേക്ക്
"Sprint review-ൽ deployed demo — ഇത് 'Done' redefine ചെയ്യുന്നു. Full definition…"
SLIDE 07 Redefining "Done" Theory
🎤 ഈ slide-ഉ emotional impact ഉള്ളതാണ്
"ഇത് ഈ course-ൻ്റേ most important concept-ഉകൊണ്ടൊരന്ന് ആകും. Traditional team-ൽ 'Done' = code merged. DevOps team-ൽ 'Done' = deployed + monitored + healthy. ഈ definition change ആകുമ്പോൾ team-ൻ്റേ entire behavior change ആകുന്നു."
Traditional "Done" — What's Missing
Code merged ✓, QA approved ✓, PO signed off ✓, deployment scheduled for "next release" — ഇത് traditional Done. ഇതിൽ problem: deployment still pending. Monitoring ഇല്ല. Rollback plan ഇല്ല. Users-ൻ്റേ hands-ൽ feature reach ആകാൻ weeks ആകും.
DevOps Definition of Done
Code reviewed + CI checks pass + Docker image built + staging deployed + smoke tested + production deployed + monitoring healthy + rollback documented. ഇതൊക്കെ done-ൽ include ആകണം. 8 checkboxes ഒക്കെ ✓ ആകുമ്പോൾ Done.

Lean connection: Undeployed code = inventory. Toyota factory-ൽ excess inventory = waste. Software-ൽ undeployed features = waste. Features-ൻ്റേ value users-ൻ്റേ hands-ൽ reach ആകുമ്പോഴേ create ആകൂ — code repository-ൽ sit ചെയ്‌ത വള്ള value create ആകില്ല.

💡 Team Exercise
Audience-നോട്: "നിങ്ങളുടെ team-ൻ്റേ current 'Definition of Done' checklist-ൽ 'deployed to production' ഉണ്ടോ? 'Monitoring healthy' ഉണ്ടോ?" — Most will say no. "ഇന്ന് ഇത് change ചെയ്യൂ."
➜ SLIDE 8-ലേക്ക്
"Scrum feature development-ന്. Ops work-ന് better framework ഉണ്ട് — Kanban…"
SLIDE 08 Kanban — For Ops and Support Work Theory
🎤 ഇങ്ങനെ introduce ചെയ്യുക
"Kanban-ഉ ഒരു Japanese word ആണ് — 'visual signal' or 'card'. Toyota Production System-ൽ inventory manage ചെയ്യാൻ ഉപയോഗിച്ചിരുന്നു. Software-ൽ David Anderson 2007-ൽ adapt ചെയ്‌ത. Ops work-ന് perfect: incidents, support tickets, security patches — ഇവ predictable schedule-ൽ come ചെയ്യില്ല. Kanban handles this."

Slide-ൽ ഒരു live Kanban board ഉണ്ട്: Backlog → In Progress (max 3) → Review (max 2) → Done. ഓരോ card-ഉം ഒരു task represent ചെയ്യുന്നു. Color-coded labels: P1 (priority), INFRA, SEC, DEVOPS, FEAT.

🔢
WIP Limits — Work In Progress Limits
ഒരു column-ൽ maximum-ൽ എത്ര cards allowed എന്ന് define ചെയ്യുന്നു. "In Progress: max 3" — 3 cards already ഉണ്ടെങ്കിൽ 4th card pull ചെയ്യരുത്. First finish one, then pull next. ഇത് multitasking prevent ചെയ്‌ത focus ഉണ്ടാക്കുന്നു. Context-switching = productivity killer.
Cycle Time — The Kanban KPI
ഒരു task "In Progress"-ൽ move ആകിയ time മുതൽ "Done"-ൽ move ആകിയ time വരെ = Cycle Time. ഇത് lower ആക്കുക ആണ് Kanban-ൻ്റേ goal. Deploy Frequency-ഉ Lead Time-ഉ Kanban team-ൻ്റേ cycle time-ൽ reflect ആകുന്നു.
💡 Lab Preview
ഇന്നത്തെ lab-ൽ ഇതേ Kanban structure GitHub Projects-ൽ create ചെയ്യും. Backlog (35 days) → This Week (5) → In Progress (3) → Review (2) → Done. നിങ്ങളുടെ learning journey ഇതിൽ track ആകും.
➜ SLIDE 9-ലേക്ക്
"Scrum vs Kanban — ഏത് situation-ൽ ഏതാണ് better? Side-by-side comparison…"
SLIDE 09 Scrum vs Kanban — When to Use Which Theory
🎤 Table walk-through
"Scrum vs Kanban — ഇവ enemies അല്ല. Different jobs-ന് different tools. Feature development-ന് Scrum better. Ops/support work-ന് Kanban better. Real-world-ൽ most mature DevOps orgs-ൽ ഇവ ഒരുമിച്ച് use ചെയ്യുന്നു — 'Scrumban' hybrid."
🔵
Scrum Best For
Feature development teams — predictable work, sprint commitment possible, product backlog have ചെയ്യുന്ന teams. 2-week cadence, planned delivery. Dev team-ൻ്റേ primary framework.
🟣
Kanban Best For
Ops/SRE teams, support teams, on-call rotations. Unpredictable incoming work. Incidents, patches, customer support — ഇവ 2-week sprint-ൽ commit ചെയ്യൽ impossible. Kanban-ൻ്റേ continuous flow perfect fit.
Scrumban — The Hybrid
Dev team — Scrum sprints for features. Ops team — Kanban for operational work. High-priority incidents automatically override sprint. ഇത് enterprise DevOps teams-ൽ most common pattern ആണ്.
➜ SLIDE 10-ലേക്ക്
"DORA metrics-ഉ sprint cycle-ൽ track ചെയ്യൽ — practical implementation…"
SLIDE 10 DORA Metrics Inside the Sprint Theory
🎤 DORA + Sprint connection
"Day 1-ൽ DORA metrics baseline measure ചെയ്‌ത document ചെയ്‌ത ഉണ്ടല്ലോ. ഇപ്പോൾ ആ metrics-ഉ sprint cycle-ൽ embed ചെയ്‌ത track ചെയ്യൽ. Retro-ൽ 5 minutes DORA review — ഇത് team-ൻ്റേ engineering health continuously improve ആക്കും."

Traditional sprint backlog-ൽ user stories മാത്രം. DevOps team-ൻ്റേ backlog-ൽ ഇവ ഒക്കെ ഉണ്ടാകണം:

🔧
Tech Debt Items
"npm packages update ചെയ്യണം" / "deprecated API remove ചെയ്യണം" — ഇവ backlog-ൽ ഇടൂ. Sprint-ൽ 20% time tech debt-ന് allocate ചെയ്യൂ. Ignore ചെയ്‌ത ഓടിക്കൊണ്ടേ ഇരിക്കാൻ ആകില്ല.
📊
Observability Items
"Payments service-ൻ്റേ Prometheus metrics add ചെയ്യണം" / "Grafana dashboard create ചെയ്യണം" — monitoring ഒരിക്കലും "later" task ആക്കരുത്. Production-ൽ fly ചെയ്‌ത ശേഷം blind ആകരുത്.
🛡
Security Items
"Trivy scan CI pipeline-ൽ add ചെയ്യണം" / "Rotate expired API keys" — security backlog-ൽ visible ആകണം. "Security team-ൻ്റേ job" — ഈ mindset DevOps-ൽ work ആകില്ല. Shared responsibility.
➜ SLIDE 11-ലേക്ക്
"User story-ഉ DevOps-ready ആക്കൽ — practical example…"
SLIDE 11 DevOps-Ready User Stories Theory
🎤 Story comparison
"Slide-ൽ ഒരേ user story — login feature — traditional version-ഉ DevOps version-ഉ side-by-side compare ചെയ്‌ത കാണിക്കുന്നു. Left — incomplete (red). Right — complete with DevOps DoD (green). Difference note ചെയ്യൂ: green version-ൽ deployment, monitoring, security scan — ഇവ acceptance criteria-ൻ്റേ part ആണ്."

DevOps acceptance criteria — ഇവ engineering team-ൻ്റേ responsibility ആണ്. PO ഇത് write ചെയ്യേണ്ടതില്ല. Dev team sprint planning-ൽ ഇവ add ചെയ്യണം. ഒരോ story-ഉം estimate ചെയ്യുമ്പോൾ deployment + monitoring-ൻ്റേ time-ഉ include ആകണം.

Real example: "Login feature" — just code ചെയ്‌ത push ചെയ്‌ത 2 hours. But deployed + monitored + secured = 4 hours. Estimate ആ 4 hours ആകണം, 2 hours അല്ല. Honest estimation = reliable sprint delivery.

💡 Practical Tip
Story-ൻ്റേ acceptance criteria template create ചെയ്‌ത Jira/GitHub Projects-ൽ save ചെയ്യൂ. ഓരോ story-ഉം create ചെയ്യുമ്പോൾ ആ template-ഉ starting point ആകും. Consistency ensures nothing is forgotten.
➜ SLIDE 12-ലേക്ക്
"Lab time! GitHub Project board setup ആകാം…"
SLIDE 12 Lab Section Break Lab Intro
🎤 Lab transition
"Theory complete! ഇനി 25 minutes lab. ഇന്ന് tools install ഇല്ല. Browser-ൽ github.com open ആകണം. Day 2-ൽ GitHub account create ചെയ്‌ത ഉണ്ടാകണം. Lab goal: GitHub Projects-ൽ ഒരു Kanban board create ചെയ്‌ത് 35 day cards add ചെയ്‌ത് course journey track ചെയ്യൽ."
💡 Screen Share
Lab step-by-step screen share ചെയ്‌ത guide ചെയ്യൂ. GitHub Projects UI ഇടയ്ക്ക് update ആകാറുണ്ട് — screenshots-ൻ്റേ പകരം live demo ആണ് better.
SLIDE 13 Lab Steps — GitHub Project Board Lab
1️⃣
Step 1: Create GitHub Project
github.com → Profile icon (top right) → Your Projects → New project → Board template select ചെയ്യൂ (Kanban ആണ്). Name: "DevOps 35-Day Journey". Create project click.
2️⃣
Step 2: Columns with WIP Limits
Default columns rename ചെയ്‌ത് 5 columns create: Backlog | This Week | In Progress | Review/Blocked | Done. Each column-ൻ്റേ ... menu → Settings → Limit ➜ In Progress=3, Review=2, This Week=5.
3️⃣
Step 3: Add Day Cards
Backlog column-ൽ + Add item → ഓരോ day-ഉം ഒരു card ആക്കി add: "Day 4 — Linux for DevOps", "Day 5 — Networking for DevOps"... Day 35 വരെ. Days 4–8 "This Week"-ലേക്ക് move ചെയ്‌ത ഇന്നത്തെ sprint start ആകൂ!
4️⃣
Step 4: Custom Fields
+ Add field → Single select → Name: "Week" → Options: W1, W2, W3, W4, W5, W6, W7, W8. ഓരോ card-ഉം ആ week assign ചെയ്യൂ. Filter by week-ആ work ചെയ്‌ത progress track ചെയ്യാം.
5️⃣
Step 5: Link Repository
Project Settings → Linked repositories → devops-35days-labs repo select ചെയ്‌ത് Add. ഇനി repo-ൽ create ആകുന്ന issues + PRs automatically project-ൽ appear ആകും. Day 3 card Done-ൽ move ചെയ്‌ത് mark ആക്കൂ!
SLIDE 14 Lab — DoD Template + Card Template Lab
🎤 Template explain ചെയ്യുക
"Slide-ൽ 2 code blocks: ഒന്ന് Course Definition of Done template — repo-ൽ add ചെയ്‌ത commit ചെയ്യൂ. Second — individual day card-ൻ്റേ template. Day 11 (Jenkins/CI day) example ആകുന്നു. ഈ structure follow ചെയ്‌ത ഓരോ day-ഉം organized ആക്കൂ."

Commit convention ഓർക്കൂ: feat(dayN): description. Example: feat(day3): add github project kanban board. ഈ convention Week 3-ൽ Conventional Commits-ൽ revisit ആകും — now you have the practice built in.

💡 GitHub Power Feature
GitHub Issues-ൽ ഒരു issue create ചെയ്‌ത് project-ൽ link ചെയ്‌ത ആ issue close ചെയ്‌ത (commit message-ൽ "closes #1" write ചെയ്‌ത) project card automatically Done-ലേക്ക് move ആകും. Automation even in project tracking!
SLIDE 15 Lab Bonus — Sprint Simulation Lab
🎤 Bonus exercise
"Time allow ചെയ്‌ത ഉണ്ടെങ്കിൽ — mini sprint planning exercise. Days 4–10 ഒരു sprint ആക്കൂ. ഓരോ day-ഉം: Goal (1 sentence), Deliverable (lab output), Risks (install issues? knowledge gap?). ഇത് sprint planning thinking practice ആക്കും."

Weekly self-retro habit start ആക്കൂ: ഓരോ 7 days-ഉം (Sunday evening maybe) — ഈ week-ൽ complete ആകിയ days, hardest concept, what to improve next week. ഇത് DORA-ൻ്റേ Measurement pillar-ൻ്റേ personal application ആണ്.

💡 Metacognition
Best DevOps engineers continuous learners ആണ്. Own learning-ഉ retrospect ചെയ്യൽ — not just work — ഒരു superpower ആണ്. ഈ habit build ആക്കൂ.
SLIDE 16 Quiz Introduction Quiz Intro
🎤 Quiz intro
"Lab complete! ഇനി 5 minutes, 3 questions. Today-ൻ്റേ key concepts check ആകും: Done definition, Kanban vs Scrum, Sprint backlog. ആദ്യം ഒരു quick recall — 'DevOps Done definition-ൽ production deploy required ആണോ?' — Yes. OK, quiz start!"
SLIDE 17 Quiz Q1 — Definition of Done Quiz
🎤 Question
"Q1: DevOps-aligned Scrum team-ൽ user story 'Done' ആകുന്നത് എപ്പോൾ? A — Code merged. B — QA approved. C — Production deployed + monitored. D — PO signed off."
✅ ശരിയായ ഉത്തരം — C
Production deployed + monitored as healthy ആകുമ്പോഴേ Done. Code merged-ഉ QA approved-ഉ PO signed off-ഉ intermediate states ആണ്. DevOps Definition of Done-ൽ deployed + healthy + rollback documented ഒക്കെ include ആകണം.

Undeployed code = inventory = waste (Lean principle).
SLIDE 18 Quiz Q2 — Kanban for Ops Quiz
🎤 Question
"Q2: Ops/on-call work-ന് ഏത് framework best suited? A — 2-week Scrum. B — Kanban with WIP limits. C — SAFe. D — Waterfall."
✅ ശരിയായ ഉത്തരം — B
Kanban with WIP limits — Ops work unpredictable ആണ്: incidents, security patches, support tickets. Scrum-ൻ്റേ 2-week sprint commitment ഇതിന് fit ആകില്ല. Kanban continuous flow + WIP limits = overload prevent + context-switching avoid.

SAFe = large-scale enterprise Agile, overkill. Waterfall = most opposite of DevOps.
SLIDE 19 Quiz Q3 — Sprint Planning DevOps Addition Quiz
🎤 Question
"Q3: Traditional Scrum Sprint Planning-ൽ DevOps-ൻ്റേ key addition ഏതാണ്? A — More documentation. B — Separate Ops planning meeting. C — Reduce sprint to 1 week. D — Infrastructure, pipeline, monitoring, security tasks backlog-ൽ include ചെയ്യൽ."
✅ ശരിയായ ഉത്തരം — D
Infrastructure tasks, CI/CD pipeline work, monitoring setup, security scanning, runbooks — ഇവ backlog-ൽ feature stories-ൻ്റൊപ്പം visible-ആ ഉണ്ടാകണം. Backlog-ൽ ഇല്ലെങ്കിൽ prioritised ആകില്ല, estimated ആകില്ല, done ആകില്ല. Tech debt silently accumulate ആകും.

Other options: more documentation → DevOps minimises doc overhead. Separate meeting → breaks the "one team" principle. 1-week sprints → might help but not the key addition.
SLIDE 20 Day 3 Summary + Day 4 Preview Summary
🎤 Closing
"Day 3 complete! ഇന്ന് Agile + DevOps-ൻ്റേ connection clear ആയി. Scrum-ൻ്റേ 3 DevOps additions, Kanban-ൻ്റേ WIP limits, 'Done' redefine ചെയ്‌ത ഒക്കെ learn ചെയ്‌ത ഉണ്ടല്ലോ. Lab-ൽ GitHub Project board create ആകിയോ? Day 3 card Done-ൽ move ചെയ്‌ത ആ board-ൻ്റേ first Done! Congrats! നാളെ Day 4 — Linux. Terminal open ആക്കി ready ആകൂ."

1. Agile vs DevOps: Agile = how to plan + build. DevOps = how to deliver + operate. Best together.

2. Scrum + DevOps: 3 additions — infra tasks in backlog, deployed demo in review, DORA metrics in retro.

3. Kanban for Ops: WIP limits (max 3 in progress), cycle time tracking, continuous flow for unpredictable work.

4. Done = Deployed + Monitored: The single most impactful Definition of Done change for any team.

⚠ Before Day 4 — Action Items
1. GitHub Project board — 5 columns + WIP limits + 32 day cards in Backlog ✓
2. Days 4–8 in "This Week" column — sprint started! ✓
3. .github/COURSE_DOD.md committed to lab repo ✓
4. Day 3 card moved to Done ✓
5. Terminal/command prompt open ആക്കി ready ആകൂ — Day 4 fully command-line based.