The people at VersionOne have collated a list of agile hallmarks that are shared across the different methodologies Click for the full original article.
Summarized below are several of the key characteristics that successful Agile projects seem to share. For some methodologies these correspond exactly with individual practices, whereas for other methodologies there is a looser correspondence.
1. Releases and Fixed-Length Iterations
Agile methods have two main units of delivery: releases and iterations. A release consists of several iterations, each of which is like a micro-project of its own. Features, defects, enhancement requests and other work items are organized, estimated and prioritized, then assigned to a release. Within a release, these work items are then assigned by priority to iterations.
The result of each iteration is working, tested, accepted software and associated work items.
2. Running, Tested Software
Running, tested features are an Agile team's primary measure of progress. Working features serve as the basis for enabling and improving team collaboration, customer feedback, and overall project visibility. They provide the evidence that both the system and the project are on track.
Consistently measuring success with actual software gives a project a very different feeling than traditional projects. Programmers, customers, managers, and other stakeholders are focused, engaged, and confident.
See Related article:
How to Effectively Deploy Agile Testing
3. Value-Driven Development
Agile methods focus rigorously on delivering business value early and continously, as measured by running, tested software. This requires that the team focuses on product features as the main unit of planning, tracking, and delivery. From week to week and from iteration to iteration, the team tracks how many running, tested features they are delivering. They may also require documents and other artifacts, but working features are paramount. This in turn requires that each "feature" is small enough to be delivered in a single iteration. Focusing on business value also requires that features be prioritized, and delivered in priority order.
Different methodologies use different terminology an techniques to describe features, but ultimately they concern the same thing: discrete units of product functionality.
| Methodology | Feature Terminology |
| Extreme Programming | User Stories |
| Scrum | Product Backlog |
| DSDM | Requirements |
| Unified Process | Use Cases & Scenarios |
| FDD | Features |
See Related articles:
How to Implement Scrum in 10 Simple Steps
How to Utilize eXtreme Programming
4. Continuous (Adaptive) Planning
It is a myth that Agile methods forbid up-front planning. It is true that Agile methods insist that up-front planning be held accountable for the resources it consumes. Agile planning is also based as much as possible on solid, historical data, not speculation. But most importantly, Agile methods insist that planning continues throughout the project. The plan must continuously demonstrate its accuracy: nobody on an Agile project will take it for granted that the plan is workable.
It turns out that Agile projects typically involve more planning, and much better planning, than waterfall projects. One of the criticisms of "successful" waterfall projects is that they tend to deliver what was originally requested in the requirements document, not what the stakeholders discover they actually need as the project and system unfolds. Waterfall projects, because they can only "work the plan" in its original static state, get married in a shotgun wedding to every flaw in that plan. Agile projects are not bound by these initial flaws. Continuous planning, being based on solid, accurate, recent data, enables Agile projects to allow priorities and exact scope to evolve, within reason, to accommodate the inescapable ways in which business needs continuously evolve. Continuous planning keeps the team and the system honed in on maximum business value by the deadline.
See Related article:
Exploit "Just-Good-Enough" Artifacts
5. Multi-Level Planning
Continuous planning is much more accurate if it occurs on at least two levels:
- At the release level, we identify and prioritize the features we must have, would like to have, and can do without by the deadline.
- At the iteration level, we pick and plan for the next batch of features to implement, in priority order. If features are too large to be estimated or delivered within a single iteration, we break them down further.
As features are prioritized and scheduled for an iteration, they are broken down into their discrete technical tasks.
This just-in-time approach to planning is easier and more accurate than large-scale up-front planning, because it aligns the level of information available with the level of detail necessary at the time. We do not make wild guesses about features far in the future. We don't waste time trying to plan at a level of detail that the data currently available to us does not support. We plan in little bites, instead of trying to swallow the entire cow at once.
6. Relative Estimation
Many Agile development teams use the practice of relative estimation for features to accelerate planning and remove unnecessary complexity. Instead of estimating features across a spectrum of unit lengths, they select a few (3-5) relative estimation categories, or buckets, and estimate all features in terms of these categories. Examples include:
- 1-5 days
- 1, 2, or 3 story points
- 4, 8, 16, 40, or 80 hours
With relative estimation, estimating categories are approximate multiples of one another. For example, a 3-day feature should take 3 times as long as a 1-day feature, just as a 40-hour feature is approximately 5 times as time-consuming as an 8-hour feature. The concepts of relative estimation and/or predefined estimation buckets prevent the team from wasting time debating whether a particular feature is really 17.5 units or 19 units. While each individual estimate may not be as precise, the benefit of additional precision diminishes tremendously when aggregated across a large group of features. The significant time and effort saved by planning with this type of process often outweighs any costs of imprecise estimates. Just as with everything else in an Agile project, we get better at it as we go along. We refine our estimation successively.
See Related article:
How to play Planning Poker for Agile Estimating
7. Emergent Feature Discovery
As opposed to spending weeks or months detailing requirements before initiating development, Agile development projects quickly prioritize and estimate features, and then refine details when necessary. As features for an iteration are described in more detail by the customers, testers, and developers working together. Additional features can be identified, but no feature is described in detail untilit is prioritized for an iteration.
8. Continuous Testing
With continuous testing we deterministically measure progress and prevent defects. We crank out the running, tested features. We also reduce the risk of failure late in the project. What could be riskier than postponing all testing till the end of the project? Many waterfall projects have failed when they have discovered, in an endless late-project "test-and-fix" phase, that the architecture is fatally flawed, or the components of the system cannot be integrated, or the features are entirely unusable, or the defects cannot possibly be corrected in time. With continuous testing we more easily avoid both the risk that this will occur, and the constant dread of it.
9. Continuous Improvement
We continuously refine both the system and the project by reflecting on what we have done (using both hard metrics like running, tested features and more subjective measures), and then adjusting our estimates and plans accordingly. But we also use the same mechanism to successively refine and continuously improve the process itself.
See Related article:
How to Revive your Sprint Retrospectives
10. Small, Cross-functional Teams
Smaller teams have been proven to be much more productive than larger teams, with the ideal ranging from five to ten people. If you have to scale a project up to more people, make every effort to keep individual teams as small as possible and coordinate efforts across the teams. Scrum-based organizations of up to 800 have successfully employed a "Scrum of Scrums" approach to project planning and coordination.
See Related articles:
Avoid 5 Scrum Transition Anti-patterns
A Best Practice Roadmap for Paired Programming
By Oliver McPhee
Comments