Agile Hallmarks

Summarized below are several of the key characteristics shared by every successful agile project. 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, as shown in the diagram below.

Iteration Diagram

The outcome from each iteration is working, tested, accepted software and associated work items. Agile development projects thrive on the rhythm or heartbeat of fixed-length iterations. The continuous flow of new running, tested features at each iteration provides the feedback that enables the team to keep both the project and the system on track. Only from the features that emerge from fixed-length ("time-boxed") iterations can you get meaningful answers to questions like "How much work did we do last month compared to what we predicted we would?" and "How much work did we get done compared to the month before?" and our personal favorite, "How many features will we really get done before the deadline?" The cruelty of several tight, fixed deadlines within a release cycle focuses everyone's mind. Face to face with highly-visible outcomes from the last iteration (some positive, some negative), the team finds itself focused on refining the process for the next iteration. They are less tempted to "gold-plate" features, to be fuzzy about scope, or to let scope creep. Everyone can actually see and feel how every week, every day, and every hour counts. Everyone can help each other remain focused on the highest possible business value per unit time. The operating mechanics of an agile development process are highly interdependent. Another way to represent an iterative development process is through a set of interlocking processes that turn at different speeds:

Agile Planning & Delivery Cycle Each day, the team is planning, constructing, and completing work (shared during daily meetings). Software is designed, coded, tested and integrated for customer acceptance. Every iteration includes planning, testing, and delivering working software. Every release includes planning, testing, and deploying software into production. Team communication and collaboration are critical, in order to coordinate and successfully deliver in such a highly adaptive and productive process. As the iterations are fulfilled, the team hits its stride, and the heartbeat of each iteration is welcomed, not dreaded. Teams realize there is time for continuous process improvement, continuous learning and mentoring, and other best practices.

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. In early iterations of a new project, the team may not deliver many features. Within a few iterations, the team usually hits its stride. As the system emerges, the application design, architecture, and business priorities are all continuously evaluated. At every step along the way, the team continuously works to converge on the best business solution, using the latest input from customers, users, and other stakeholders. Iteration by iteration, everyone involved can see whether or not they will get what they want, and management can see whether they will get their money's worth. 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.

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
Unified Process Use Cases & Scenarios
FDD Features

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. At project launch, the team does just enough planning to get going with the initial iteration and, if appropriate, to lay out a high-level release plan of features. And iterating is the key to continuous planning. Think of each iteration as a mini-project that receives "just-enough" of its own planning. At iteration start, the team selects a set of features to implement, and identifies and estimates each technical task for each feature. (This task estimation is a critical agile skill.) For each iteration, this planning process repeats. 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 as the project and system unfold. 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. In the agile community, waterfall projects are sometimes compared to "fire and forget" weapons, for which you painstakingly adjust a precise trajectory, press a fire button, and hope for the best. Agile projects are like cruise missiles, capable of continuous course correction as they fly, and therefore much likelier to hit a target (a feature-set and a date) accurately.

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. If a feature exceeds an agreed maximum estimate, then it should be broken down further into multiple features. The features generated as a result of this planning ultimately need to be able to be delivered within a single iteration. So if the team determines that features should not exceed 5 ideal days, then any feature that exceeds 5 days should be broken into smaller features. In this way we "normalize" the granularity of our features: the ratio of feature sizes is not enormous.

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 until it is prioritized for an iteration.

8. Continuous Testing

With continuous testing the team deterministically measure progress and prevent defects. It cranks out the running, tested features, which reduces 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 the team avoids that risk. At the unit level and acceptance (feature) level, the tean characterizes tests as the code itself is written or (better yet) beforehand. The most agile of agile projects strive to automate as many tests as possible, relying on manual tests only when absolutely necessary. This speeds testing and makes it more deterministic, which in turn gives us more continuous and more reliable feedback. There is an emerging wealth of new tools, techniques, and best practices for rigorous continuous testing; much of the innovation is originating in the Test-Driven Development (TDD) community. When is a feature done? When all of its unit tests and acceptance tests pass, and the customer accepts it. This is exactly what defines a running, tested feature. There is no better source of meaningful, highly-visible project metrics.

9. Continuous Improvement

The team continuously refines 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 the team also uses the same mechanism to successively refine and continuously improve the process itself. Especially at the close of major milestones (iterations, releases, etc.), the team may find problems with iteration planning, problems with the build process or integration process, problems with islands of knowledge among programmers, or any number of other problems. It looks for points of leverage from which to shift those problems. The team adjusts its processes, and acquires or invent new ones, improving after every release. Its process evolve to deliver incremental value per unit time to the customer, the team, and the organization. It matures and evolves, like a healthy organism.

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. With increments of production-ready software being delivered every iteration, teams must also be cross-functional in order to be successful. That means teams include members with all of the skills necessary to successfully deliver software, including analysis, design, coding, testing, writing, user interface design, planning, and management. Teams work together to determine how best to take advantage of one another's skills and mentor each other. Teams transition away from designated testers and coders and designers to integrated teams in which each member helps do whatever needs doing to get the iteration done. Individual team members derive less personal identity from being a competitive expert with a narrow focus, and increasingly derive identity and satisfaction from being part of an extraordinarily productive and efficient team. As the positive reinforcement accumulates from iteration to iteration, the team becomes more cohesive. Ambient levels of trust, comeraderie, empathy, collaboration, and job satisfaction increase, associated with any well-managed agile project.

If you liked my post, feel free to subscribe to my rss feeds

Post Agile Hallmarks to digg. Post Agile Hallmarks to Reddit add to stumbleupon Google Bookmark myweb bookmark on del.cio.us newsvine Tailrank magnolia Furl co.mments shadows simpy blinklist

One Trackback

  1. By Agile roadmap « One Yoxel on October 16, 2007 at 1:24 pm

    [...] The point of having two plans long term release plan (or roadmap plan) and a short term iteration plan comes up all the time with agile/SCRUM. (Agile Hallmarks post brings this topic up again and again, accompanied with very neat diagrams and chars.) I believe it is quite challenging to follow your roadmap. Sure you can create it as your management and marketing books tell you but will you be able to follow it exactly? If the market requirements change swiftly, will it make sense to follow it? In my case, having prioritized backlog gives me an idea of my overall roadmap but it is also quite flexible, because the iteration plans are really the ones that align that roadmap with current market situation. I have written down a few more thoughts on this topic before: [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*