Agile Requirements: Oxymoron?
Adult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons — self-contradictory phrases, often with an ironic meaning. Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?
Traditionally, defining requirements involves careful analysis and documentation and checking and rechecking for understanding. It’s a disciplined approach backed by documentation, including models and specifications. For many organizations, this means weeks or months of analysis, minimal cross-team collaboration, and reams of documentation. In contrast, agile practices — Lean, Scrum, XP, FDD, Crystal, and so on — involve understanding small slices of requirements and developing them with an eye toward using tests as truth. You confirm customers’ needs by showing them delivered snippets of software.
But agile projects still produce requirements and documentation, and they involve plenty of analysis. On the best agile projects, requirements practices combine discipline, rigor, and analysis with speed, adaptation, and collaboration. Because software development is a knotty “wicked problem” with evolving requirements, using iterative and agile practices is not only common sense but also economically desirable.
Indeed, agile requirements drive
Please log in or sign up below to read the rest of the article.