The Agile Manifesto is based on twelve principles (I’ve highlighted a couple – 2 and 12 – that are of the most interest for this post):
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily cooperation between business people and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Self-organizing teams
- Regular adaptation to changing circumstances
Things Change. That’s one thing you can always count on, no matter what sort of activities you are involved in. As the German Field Marshall Moltke observed — “no plan survives contact with the enemy”.
The same is true for those requirements you so painstakingly crafted; organizations shift priorities, technologies change, customers change their minds, budgets ebb and flow, and myriad other variables can throw a monkey wrench in the works. The good news is that the business objectives don’t fundamentally change much, or at least not very quickly. Walking the requirements back to the business drivers makes it more straightforward to accommodate unexpected changes.
An Agile coach told me that a user story is “a promise of a future conversation”. It isn’t expected that the user story in the Agile development paradigm is not meant to document every detail of the work. It is complete enough to get going on the design and to estimate the effort, but it is expected that the engineers will regularly be asking the Product Owner about what the customer really wants. This “just enough” approach is part of what makes Agile so adaptable and responsive.
