Formal project scheduling begins with a chart, not a philosophy. Henry Gantt, an American mechanical engineer working in the scientific-management tradition, published the horizontal bar chart that still carries his name around 1910–1915: a visual plan showing which tasks happen when, and in what sequence, against a fixed timeline (APM, n.d.). That scheduling discipline hardened, across the following decades, into what later became known as the waterfall model — requirements, design, build, test, deploy, each phase completed and signed off before the next begins. The label is usually traced to Winston Royce's 1970 paper "Managing the Development of Large Software Systems" (Royce, 1970), though the attribution carries an irony worth keeping in mind: Royce used the sequential diagram to illustrate why a purely linear process is risky for software, not to recommend it outright. The industry adopted the diagram and left the warning behind.

A strictly sequential process suits work where requirements are genuinely stable and the destination is known in advance — a bridge, a building, a chart of fixed tasks. Digital products rarely offer that luxury: what users actually need often only becomes clear once something real exists for them to react to, and a plan-driven process that defers all feedback to the end of a long specification phase finds out it was wrong only when changing course is most expensive. This mismatch had already earned a name by the late 1960s, the "software crisis", and it persisted through the 1980s and 1990s: large projects running over time and budget, delivering systems nobody quite wanted. Responses emerged gradually rather than all at once: Barry Boehm's spiral model (Boehm, 1986) wrapped Royce's phases into repeated, risk-driven cycles instead of one long pass; rapid application development and incremental delivery broke a single big release into smaller ones. These were steps towards iteration, but they kept much of waterfall's process weight — detailed plans, heavy documentation, formal sign-offs — rather than replacing it outright. That remaining weight is exactly what the next generation of thinking set out to challenge.

In February 2001, seventeen software practitioners met at a ski resort in Snowbird, Utah, representing a handful of competing lightweight methods — Extreme Programming, Scrum, DSDM, Crystal, Feature-Driven Development and others — to find what they had in common (Beck et al., 2001). What they produced, the Manifesto for Agile Software Development, is deliberately short: four value statements, each phrased as a preference rather than an absolute — individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan — backed by twelve supporting principles. It is the work of seventeen named signatories acting collectively, published at agilemanifesto.org, not the output of any single author, and treating it as one person's idea misreads how it came about.

A separate but complementary lineage runs through lean thinking. Lean originates in the Toyota Production System and was adapted specifically for software by Mary and Tom Poppendieck (Poppendieck and Poppendieck, 2003) into seven principles: eliminate waste, amplify learning, decide as late as responsibly possible, deliver as fast as possible, empower the team, build integrity in, and see the whole. The two lineages reinforce each other — lean's instinct to defer decisions and cut waste sits comfortably alongside agile's preference for working software over heavy documentation — but they are not interchangeable with specific delivery frameworks. Scrum structures work into fixed-length sprints with defined roles and ceremonies; Kanban visualises flow on a board and limits how much work is in progress at any one time, without prescribing fixed iterations at all. Both are frameworks that can be used to put agile values into practice; neither is a synonym for "agile" itself, and a team can follow Scrum's ceremonies to the letter while missing the values entirely.

A cross-functional team is built around a problem rather than a department: it contains everyone who can decide, design and build without leaving the room, rather than passing work between specialist teams that each hold a piece of the authority needed to finish it. This matters most exactly where Module 2's operating-model exercise finds a gap — when no single team owns an outcome, a cross-functional team is often the structural fix, because it collapses the handoffs where ownership previously went missing rather than adding another layer to coordinate.

Once a team exists, the next discipline is scoping what it builds first. A minimum viable product, in Eric Ries's sense (Ries, 2011), is not a smaller or lower-quality version of the eventual product; it is the smallest thing a team can build that lets it test a specific, real assumption with real users, and then decide what to build next from evidence rather than opinion. The riskiest assumption is the one whose failure would undermine everything else — not the easiest thing to build, and not the most visible feature on a roadmap. Ries's build-measure-learn loop makes the sequence explicit: build the smallest test of the assumption, measure what actually happens, and let that evidence — not the original plan — decide the next iteration. Treating an MVP as a synonym for "rushed" or "low quality" misses the point entirely; a well-scoped MVP is a deliberately narrow experiment, not an excuse for a poor one.

Once a team is assembled and a first iteration scoped, delivery still runs through people who were not in the room when those decisions were made — and not all of them need, or want, the same kind of attention. Mendelow's Matrix plots stakeholders on two axes, power and interest, producing four quadrants: manage closely (high power, high interest), keep satisfied (high power, lower interest), keep informed (high interest, lower power), and monitor (low power, low interest) (Mendelow, cited in Johnson and Scholes, 1991). The grid's dating carries a genuine wrinkle worth naming rather than smoothing over: the matrix is most commonly cited to a 1991 source, but at least one source traces the underlying framework to Mendelow's own 1981 conference paper on environmental scanning, with the 1991 date originating from its later popularisation in Johnson and Scholes's strategy text — making 1991 a widely reproduced citation for a framework that may be a decade older. Cite it with that uncertainty rather than asserting one year with unwarranted confidence.

The matrix's value is not the label a stakeholder lands on but the engagement decision that follows from it. A stakeholder with high power but currently moderate interest needs enough information, on a timescale that suits them, to stay satisfied without constant involvement in delivery detail; a stakeholder with high interest but limited formal power needs honest, regular updates precisely because they lack other means of finding out what's happening. Misjudging either placement has a cost: treating a "keep satisfied" stakeholder as merely "monitor" risks a late, high-power intervention that could have been avoided; treating a "keep informed" stakeholder as unimportant risks a loss of trust that outlasts the project. Placements are not fixed for the life of an initiative — power and interest can both shift as delivery proceeds, which is why the matrix is worth revisiting rather than filling in once and filing away.