Software Development Methodologies

Principle

Methodologies are tools. They should improve flow, learning, quality, and outcomes. If a ceremony does not improve decisions, coordination, learning, or delivery, redesign it.

Agile Foundations

Use agile thinking for:

• Short feedback loops.
• Working software.
• Customer collaboration.
• Adaptation to change.
• Team ownership.
• Transparent progress.

Do not reduce agile to standups, story points, and sprint ceremonies.

Scrum

Scrum can work well when:

• The team owns a product or service area.
• Backlog items are tied to outcomes.
• Sprint reviews include real feedback and evidence.
• Retrospectives produce system improvements.
• The Scrum Master or delivery lead removes friction rather than policing rituals.

Scrum weakens when:

• It becomes a ticket factory.
• Sprint commitment hides uncertainty.
• Product discovery is absent.
• Stakeholders treat the team as an execution pool.

Kanban

Kanban is useful when:

• Work arrives continuously.
• Teams need flow visibility.
• Operations and support load is significant.
• Limiting work in progress matters more than sprint boundaries.

Track:

• Work item age.
• Cycle time.
• Blocked time.
• WIP limits.
• Classes of service.

Shape Up-Inspired Cycles

Shape Up is useful for product bets where teams need more autonomy and less micro-management.

Adopt these ideas:

• Shape the problem before committing build capacity.
• Define appetite: how much time is worth spending?
• Give teams responsibility for solving within constraints.
• Identify risks before betting.
• Use cooldown for fixes, debt, research, and reflection.

Avoid treating six-week cycles as a universal law. The useful idea is intentional betting, not calendar worship.

Dual-Track Discovery And Delivery

High-performing product teams continuously discover and deliver:

• Discovery reduces uncertainty about customers, value, usability, feasibility, and business viability.
• Delivery turns validated opportunities into working, reliable software.

Product managers, designers, and engineers should participate in discovery together. Engineers must hear customer evidence, not only receive requirements.

When To Use What

Minimum Process Standard

Every team needs:

• Visible work.
• Clear priorities.
• WIP discipline.
• Definition of ready and done.
• Outcome metrics.
• Retrospective or improvement loop.
• Risk review.
• Demo/review with stakeholders and users where possible.

Team Reference Guide

How To Explain This Page

Software methodologies are not religions. Scrum, Kanban, Shape Up, dual-track discovery, and continuous delivery are operating patterns that solve different problems. The mistake is to copy the ceremony without understanding the value it protects.

Scrum protects cadence and feedback. Kanban protects flow and WIP discipline. Shape Up protects intentional betting and team autonomy. Dual-track discovery protects customer learning. DevOps protects shared ownership between build and operate.

Guidelines For Teams

• Choose the method based on the work type, not fashion.
• Keep work visible and limit work in progress.
• Run planning around outcomes, risks, and learning, not only tasks.
• Use retrospectives to improve the system, not to repeat generic complaints.
• Ensure sprint reviews or demos show working software and learning, not only status.
• For uncertain work, define the decision the experiment should enable.

What Good Looks Like

The method should help the team decide better, finish work faster, learn sooner, and reduce risk. If the method only creates meetings and artifacts, redesign it.

Reflection Questions

• Which ceremony creates the least learning today?
• Are we using our process to control people or to improve flow?
• Where would Kanban, Shape Up, or discovery practices fit better than our current habit?