I attended a talk by Scott Ambler today where he covered a number of growing pains in the Agile Development community. Particularly of interest was the observation that the agile methodology is not independent of modeling - particularly requirement and architectural modeling. Scott really drove into this point fairly thoroughly for the time alloted, but its something that many organizations should keep firmly in mind. Being agile doesn't mean ignoring the proper setting of direction.
Now the interesting question should be: how do organizations take requirements and architecture and bring some of that agile methodology to these disciplines as well. Take requirements modeling for example:
• User Stories - most of us know that user stories are great, but they don't really tell the whole story; really, they just tell the user's experience, not the needs of other stakeholders who have equally valid needs
• Operational Scenarios - user stories for the operations folk; this can be a lot of fun - how can things go wrong and what do we need to support these scenarios; this is really dependent on having people who can really think in mean and nasty ways about things that are supposed to work normally
• Quality Capabilities - this refers to the "ilities" that make our systems worth using; our experience has shown that these are best fulfilled through some basic scorecard structure (we also recommend throwing this at your architects or operational folks)
What about those architecture guys?
• Strategy - architecture really needs to be responsible for projecting out and explaining where the development is headed after the first major iterations; this doesn't need to be grandiose or full of detail, but it does need to clearly articulate major concepts and changes from initial direction
• High Level Design - this really needs to occur at what we call the "box and pipes" level; nothing as rigorous as UML, but just a basic indication of the players and why they are needed (if you're going below the component level, you've gone way too far)
• Standards - this one seems obvious, but we recommend a slight change to the norm: don't develop all-inclusive standards; instead, focus on the bare minimum needed that everyone will have to bide by in order for development to be orderly and without conflict (this, like many things in agile requires a bit of experience)
