Mental model
Software development methods are how a team organises the work of building software. Not the tools, not the code. The sequencing, roles and feedback loops.
Three methods you need to know for Cisco objective 1.4:
| Method | Core idea | Team cadence |
|---|---|---|
| Waterfall | Finish each phase before starting the next: requirements → design → build → test → ship | Weeks to months per phase |
| Agile | Short iterations with working software at the end of each; adjust scope every sprint | 1 to 4 week sprints |
| Lean | Build the smallest useful thing, ship it, measure, decide what to do next; eliminate waste | Continuous (daily / weekly) |
They are not mutually exclusive. Most real teams blend them.
Waterfall
Requirements ─▶ Design ─▶ Build ─▶ Test ─▶ Deploy ─▶ Maintain
- Each phase has a dated handoff document. The design doc goes to engineering; engineering ships a build; QA tests; ops deploys.
- Scope is fixed up front. Changes mid-project are expensive and require a formal change request.
- Works when: the problem is well understood, requirements genuinely will not change, and compliance / safety requires a paper trail (aerospace, medical, some government).
- Breaks when: the business learns something halfway through and wants to pivot. The ship date slips, the budget blows up, or the team delivers something no one wants.
Agile
Umbrella term for iterative methods. The two popular variants are Scrum and Kanban.
Scrum (time-boxed sprints)
- Fixed-length sprints (usually 2 weeks). At the end of every sprint there is a demo of working software.
- Roles: Product Owner (what to build), Scrum Master (process), Development Team (how to build).
- Ceremonies: sprint planning, daily stand-up (15 min), sprint review (demo), retrospective (what to improve).
- Scope flexes between sprints, not within one.
Kanban (continuous flow)
- No sprints. Work moves across a board (To Do → In Progress → Done) with limits on how much can be “In Progress” at once (WIP limit).
- Good when work arrives unpredictably (ops / support teams, network automation on-call rotations).
Agile values (the Agile Manifesto, abbreviated)
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
“Over” does not mean “instead of” — it means “when you have to choose, pick the left”.
Lean
Borrowed from Toyota’s manufacturing system. In software:
- Build-measure-learn loop. Ship the smallest version that is useful. Measure how it is used. Decide the next thing from the measurement, not from an up-front plan.
- Eliminate waste. Features no one uses, documentation no one reads, meetings that could be an email. Cut them.
- Pairs well with Kanban (continuous flow) and with “Minimum Viable Product” (MVP) thinking.
Side-by-side comparison
| Waterfall | Agile (Scrum) | Lean | |
|---|---|---|---|
| Planning horizon | Full project | One sprint (2 weeks) | Current iteration (hours to days) |
| Response to change | Expensive | Cheap between sprints | Cheap any time |
| Working software by | End of project | End of every sprint | After each change |
| Documentation style | Heavy, formal, up front | Just enough, written as code | Minimal; prefers measurement |
| Best fit | Regulated / fixed-scope | Product teams with evolving requirements | New products with uncertain demand |
| Downside | Slow to react, risk of waste | Hard without a committed Product Owner | Can lose sight of long-term strategy |
How this maps to a network automation team
Reality for most teams:
- Kanban board (Jira / Trello / GitHub Projects) tracks all work: new playbooks, failed deployments, support tickets, mentor requests.
- Short iterations (1 or 2 weeks) with a demo at the end of each.
- Lean mindset for any new tool or feature: ship a prototype in a day, let one team use it, decide whether to invest more.
- Waterfall discipline for migrations with a hard cutover (DC refresh, cert renewal, firewall rule rewrite) where you need a dated plan with go/no-go gates.
The exam does not ask which is “best”. It asks you to describe each and name their strengths.
FAQ
Is DevOps a development method? No. DevOps is a culture / set of practices (merge developers and operations, automate everything, deploy small changes often). It overlaps with lean and agile but is orthogonal to all three methods above. See the DevOps principles topic in a later phase.
What is “Scaled Agile” (SAFe)? A heavyweight framework for applying agile ideas at hundreds-of-engineers scale. Opinions vary; some teams love it, some say it is agile-in-name-only. Not on 200-901.
Is XP (eXtreme Programming) agile? Yes. XP is an earlier agile method with specific engineering practices: pair programming, TDD, continuous integration, small releases. Many XP practices (TDD, CI) became industry defaults.
Is iterative the same as agile? Iterative means “do it in loops”. Agile is a specific set of iterative methods with values and ceremonies attached. All agile is iterative; not all iterative is agile.
My team says “we do agile” but there are no sprints or demos. Is that agile? No. That is the single biggest myth in the industry. “Agile” without short iterations, working software and retrospectives is usually ad-hoc development with a brand name. Honest teams call it “we build when we can”.