Process terms get eye-rolls until a project goes sideways. Then everyone suddenly cares deeply about how the work was organized, tested, and tracked.
This category covers the methodologies that show up around every data and software effort. Term by term 👇
30-Second Summary
Development methodology terms describe how teams organize technical work: the agile family of methods, the testing practices that keep quality honest, and the management disciplines around data and supply chains.
What This Category Covers
- The agile family: agile methodology, agile development, and agile testing
- The management disciplines: test data management and supply chain management
📌 Quick take: Methodology is a tool, not a religion. The right question is never 'are we agile?' It's 'does our process surface problems early enough to fix them cheaply?'
The Terms in This Category, Walked Through
The agile trio forms the spine. Agile methodology covers the philosophy: short cycles, continuous feedback, adaptation over prediction. You get the manifesto’s values translated into daily behavior, plus the scaling mechanics that survive contact with forty teams. There’s an honest section on what transfers to data work. And a measurement set that resists gaming.
Agile development is the philosophy at the keyboard. Thin vertical slices. Continuous integration. Always-shippable mains. Plus the delivery pipeline whose quality decides whether small increments are a discipline or simply the easiest way to work.
Agile testing completes it: quality checks woven through every cycle. The page maps coverage with the four quadrants, then covers the flaky-test and environment logistics where suites actually die. And it carries the data-system adaptations. Asserting on datasets, contracts at boundaries, monitors as production tests.
Test data management serves the trio’s hungriest dependency. Continuous testing needs data that’s realistic enough to matter and safe enough to expose. So the page builds the TDM pipeline (masking catalog, referentially whole subsets, versioned on-demand provisioning) and covers the synthetic-data frontier with its fidelity caveats. Its adoption rule generalizes widely: the compliant path must beat the workaround on convenience, or the workaround wins.
And supply chain management is the folder’s field trip. The page shows how goods, information, and money coordinate across company networks. It earns its place through its lessons. The bullwhip effect is the definitive story of what partial information does to multi-stage systems. Meanwhile the digital SCM stack is a mature reference architecture. And the resilience redesign is a case study in optimizing for more than efficiency.
Every data professional wiring systems together is running a small supply chain. This page is the discipline that ran them first, at container-ship scale.
The Folder’s Common Thread
Every page here is about the same economic trick: making feedback cheap and early so mistakes die small. Sprints surface misdirection in weeks. Continuous integration surfaces conflicts in hours. Tests surface defects in minutes. TDM makes the testing possible. And supply chains show what happens at industrial scale when feedback arrives late and partial.
The methodologies differ in vocabulary and ceremony. But the physics underneath is one idea, applied at five altitudes.
Using This Folder
Adopting agile practices on a data team? Read methodology → development → testing, in that order. Then TDM before the test suite grows. Because retrofitting safe test data costs far more than starting with it.
Diagnosing a delivery problem instead? The development page’s four health metrics locate it fast. And for the long view, the supply-chain page rewards a slow read. Its decades of hard-won lessons about shared truth and synchronized information are the same lessons every data platform relearns. Cheaper to import than to rediscover.
Questions This Category Answers
“Why do our projects surprise us so late?” The folder’s shared answer: feedback arriving too slowly. Methodology shortens the planning loop. development shortens the integration loop. And testing shortens the defect loop. Same fix, three altitudes.
“Are we actually improving?” The delivery-health metrics answer without inviting theater: cycle time, deploy frequency paired with failure rate, restore time. And the retrospective-honesty test answers for the humans.
“Why is testing always the bottleneck?” Usually logistics, not philosophy. Flaky suites, irreproducible environments, unsafe test data. The testing page’s quadrants find the coverage gaps, and TDM fixes the data half: realistic, masked, versioned, on demand.
“Does any of this apply to data work?” Directly. Pipelines and models as increments, CI on transformations, monitors as production tests, plus honest exceptions for genuinely lumpy work. The pages carry the translations explicitly.
“What does a supply chain have to do with us?” The SCM page is the folder’s proof-at-scale. The bullwhip effect is what partial, delayed information does to ANY multi-stage system. A warning label written in container ships.
One test for everything in this folder: does the practice surface problems earlier and cheaper? If yes, keep it, whatever it’s called. If it’s ceremony without feedback, retire it, whatever it’s called.
How This Category Connects to the Rest of the Wiki
Methodology is how the rest of this wiki gets built. The data engineering discipline imports this folder wholesale (versioned increments, CI, tests) and applies it to pipelines and warehouse models. The quality folder‘s monitors are this folder’s testing philosophy running permanently in production. Even the analytics practice pages borrow the shape: backlogs of questions, iterative delivery, retrospective honesty.
The dependencies flow back too. TDM leans on masking from the privacy folder. Delivery pipelines authenticate through the identity machinery. And the supply-chain page’s information-flow lessons echo through every synchronization and integration page in the wiki.
The meta-lesson this folder carries for all the others: process is a technology. It versions. It has failure modes. And it needs maintenance and compounds, exactly like the systems it builds. Teams that treat their way-of-working as an engineered artifact, reviewed and refactored like code, end up with better methods AND better everything-else. That, compressed, is why these five pages live in a data glossary at all.
Start Here If You’re New
New to process vocabulary? Read methodology first, for the philosophy and its honest limits. Development second: what it means at the keyboard. Testing third, because that’s where quality actually lives. Then TDM when your tests need data, and supply chain whenever you want the industrial-strength version of every lesson.
Burned by a ceremony-heavy adoption? Start with the measurement sections instead: cycle time, deploy frequency, failure rate. Instrument first. Adopt practices that move the numbers, and skip everything that doesn’t. The folder fully endorses that ordering. The methods were always means, never ends.
One habit to build regardless of entry point: retrospectives that actually retire problems. Everything else in this folder is installable tooling. That one is culture. And it’s the part that compounds.
Frequently Asked Questions
What is a development methodology?
A team’s organized way of planning, building, and testing technical work. It’s the loop that turns effort into shipped results. The good ones share one trait: they surface problems early, while fixes are still cheap.
What is the difference between agile methodology and agile development?
Methodology is the philosophy (short cycles, feedback, adaptation). Development is the engineering practice (increments, continuous integration, automated tests). One shapes the plan, the other shapes the code.
Does agile work for data teams?
Yes, with translation: pipelines and models become the increments, CI runs data tests, and monitors act as production tests. Genuinely lumpy work, like migrations, gets honest exceptions, not forced sprints.
Why is supply chain management in a data glossary?
Because supply chains are the oldest large-scale data-integration story in business, with decades of lessons about shared truth and error amplification. The bullwhip effect alone is worth the visit for anyone wiring systems together.