Every agile discussion is dominated by two questions:
- What is agile;
- Why agile?
The first question is answered this way:
Agile is a name given to a number of different methodologies that are all responses to the answer to the second question. Though agile methodologies differ in many respects, they are composed of both management practices and technical practices.
These practices are not too much different than those we know from the PMBOK. However, they are arranged in unique ways, given different priorities and names and relationships, and so the project management narrative is quite different even though the constituents may be familiar.
In effect "old dots connected in new ways" = new narrative, but the new narrative is why agile is effective.
The second question is the more important:
Agilists say that the predictability offered by traditional methods is a myth, that predictability is not really possible. Predictability of cost, schedule, and scope is problematic because of these two reasons:
- Requirements paradox: we want requirements to be stable; but (user) requirements are never stable. But, other non-user requirements taken from standards, infrastructure specs, and the like can be, and usually are, stable. So, requirements are like a layered structure: the bottom layers are usually stable; it's the user layer that's not.
- Systems (of requirements) have chaotic and emergent properties, actions, reactions, and functions/performance. These emergent actions and reactions are simply not predictable; they can only be experienced. Once revealed they can be dealt with.
Agile deals with these two problems these ways:
- A bargain is struck with the project sponsor (call this a business case): in trade for the flexibility to handle user requirements as evolutionary and emergent, agilists pledge that they will deliver the best possible value (not a specific scope) within the time and budget given by the sponsor.
- Requirements (in the form of stories) are discussed conversationally with developers. When understanding is reached, the conversations are then frozen in time boxes and developed to the point of DONE; then the backlog is unfrozen, a new batch are selected, and 'do again, until ...' ("Done" may be an alpha release, a beta release, a prototype for a focus group, or a production release)
- Estimation depends on benchmarks of past performance on similar stories.
- Time box performance by teams depends on the teams sticking together and practicing together so that their performance over the duration of a timebox is predictable.
- Users exercise the system to tease out the unpredictable; these then become 'debt' in the backlog, to be prioritized with other requirements
- Verification is done incrementally; validation is only done at the project epic narrative level
Bookmark this on Delicious
