Agile & Process
Scrum, Kanban, CI/CD, and technical debt.
6 questions
JuniorTheoryVery commonWhat is Scrum, and what does the Agile manifesto value?
What is Scrum, and what does the Agile manifesto value?
Scrum is an Agile framework built on fixed-length iterations called sprints (~2 weeks); the team commits to a sprint backlog and ships at the end. The Agile manifesto values individuals, working software, and responding to change.
Common mistakes
- ✗Thinking sprints have a flexible length set day-to-day rather than fixed
- ✗Believing
Agilevalues documentation and contracts over working software - ✗Assuming
Scrumremoves planning instead of formalizing it into sprint planning
Follow-up questions
- →What roles and ceremonies does
Scrumdefine around the sprint? - →How does "responding to change" play out when requirements shift mid-sprint?
JuniorTheoryCommonWhat is the difference between CI and CD?
What is the difference between CI and CD?
CI merges code into a shared branch often, building and testing each merge. CD is either Continuous Delivery — automating the pipeline up to a manual prod approval — or Continuous Deployment — shipping changes to prod with no gate.
Common mistakes
- ✗Believing
CIdeploys to production — it only builds, tests, and merges - ✗Conflating Continuous Delivery (manual deploy gate) with Continuous Deployment (no gate)
- ✗Thinking
CDstands for "code documentation" rather than delivery or deployment
Follow-up questions
- →What practices make a Continuous Deployment pipeline safe to run automatically?
- →Why does frequent integration in
CIreduce painful merge conflicts?
JuniorTheoryCommonWhat is technical debt?
What is technical debt?
The future cost of choosing a quick, suboptimal solution now — like financial debt you repay later with interest as slower changes. In Cunningham's original sense it is a deliberate trade-off to ship sooner, not sloppy code.
Common mistakes
- ✗Equating technical debt only with bad code, ignoring deliberate strategic debt
- ✗Believing debt never needs repaying and has no compounding interest cost
- ✗Confusing the metaphor with literal financial or licensing debt
Follow-up questions
- →How is deliberate strategic debt different from accidental reckless debt?
- →What signals tell you accumulated debt is now slowing the team down?
MiddleTheoryCommonHow do Scrum and Kanban differ?
How do Scrum and Kanban differ?
Both are Agile. Scrum works in fixed sprints with committed scope measured by velocity; the goal is finishing the sprint. Kanban is continuous flow — no sprints, tasks reprioritized anytime, measured by Cycle Time.
Common mistakes
- ✗Attributing fixed two-week sprints to
Kanban, which has no sprints - ✗Thinking
Scrumallows free mid-sprint task swaps without breaking the commitment - ✗Swapping the metrics —
Scrumusesvelocity,KanbanusesCycle Time
Follow-up questions
- →When would you pick
KanbanoverScrumfor a support or ops team? - →How does a WIP limit in
KanbanimproveCycle Time?
MiddleTheoryOccasionalHow do teams manage technical debt?
How do teams manage technical debt?
Strategies: incremental refactoring with debt tasks in the backlog next to features, a full rewrite once flexibility is gone, or consciously accepting it. Prevention helps too: MVP prototypes, versioned APIs, and a clear definition of done.
Common mistakes
- ✗Believing a full rewrite is the only legitimate way to handle debt
- ✗Refusing to track debt tasks in the
backlogalongside feature work - ✗Treating conscious acceptance of debt as never an acceptable trade-off
Follow-up questions
- →How do you prioritize a debt task against a customer-facing feature?
- →What makes a
definition of doneeffective at preventing new debt?
SeniorTheoryOccasionalWhat does Continuous Deployment require beyond CI/CD?
What does Continuous Deployment require beyond CI/CD?
Since every passing change ships to prod automatically with no gate, it demands strong monitoring, fast rollback, feature flags, and high automated-test confidence — teams usually automate staging first and keep prod one-click first.
Common mistakes
- ✗Assuming auto-deploy means you can afford weaker tests, not stronger ones
- ✗Confusing it with Continuous Delivery, which keeps a manual prod gate
- ✗Dismissing monitoring and fast rollback as optional rather than mandatory
Follow-up questions
- →How do feature flags decouple deploying code from releasing a feature?
- →What rollback strategy keeps a bad auto-deployed change from harming users?