Table of Contents
1. Agile development releases and fixed-length iterations
Agile software development 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 diagram below summarizes this.
The result of 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 an agile development 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 allow 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 of 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 gears that turn at different speeds:
Each day, the agile development team is planning, working on, and completing tasks while the software is being designed, coded, tested, and integrated for customer acceptance. Each iteration, the team is planning, testing, and delivering working software. Each release, the team is planning, testing, and deploying software into production. In order to coordinate and successfully deliver in such a highly adaptive and productive process, team communication and collaboration are critical throughout the entire agile development process.
As the iterations go by the team hits its stride, and the heartbeat of iteration deadlines is welcomed, not dreaded. Suddenly, once the team gets the hang of it, there is time for continuous process improvement, continuous learning and mentoring, and other best practices.
2. Agile development delivers working, tested software
Delivering working, tested features is an agile development 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 an agile development project a very different feeling than traditional projects. Programmers, customers, managers, and other stakeholders are focused, engaged, and confident.
Digital.ai Agility, formerly VersionOne, allows you to easily incorporate QA testing into your agile development projects via an integrated suite of acceptance and regression test planning, tracking, and reporting.
3. Value-driven development
Agile development methods focus rigorously on delivering business value early and continuously, 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 agile development methodologies use different terminology and techniques to describe features, but ultimately they concern the same thing: discrete units of product functionality.
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 development 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. Task estimation is a critical agile skill. This same planning process repeats for each iteration.
It turns out that agile development 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.
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 likened to cruise missiles: capable of continuous course correction as they fly, and therefore much more likely to hit the targeted feature-set and date accurately.
5. Multi-level planning in agile development
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.
Plan and manage your agile product requirements, epics, stories, and goals across multiple projects, products and teams using Digital.ai Agility, formerly VersionOne.
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 (three to five) relative estimation categories, or buckets, and estimate all features in terms of these categories.
Examples include:
- One to five days
- One, two, or three story points
- Four, eight, 16, 40, or 80 hours
With relative estimation, estimating categories are approximate multiples of one another. For example, a three-day feature should take three times as long as a one-day feature, just as a 40-hour feature is approximately five times as time-consuming as an eight-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 five ideal days, then any feature that exceeds five 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. 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 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 until 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. By practicing continuous testing in agile development, we more easily avoid both the risk that this will occur, and the constant dread of it.
At both the unit level and acceptance feature level, we write the tests as the code itself is written beforehand. The most agile of agile development projects strive to automate as many tests as possible, relying on manual tests only when absolutely necessary. This speeds testing and delivers software that behaves predictably, 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
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, we can then adjust our estimates and plans accordingly. But we also use the same mechanism to successively refine and continuously improve the process itself.
Especially at the close of major milestones (iterations, releases, etc.), we 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. We look for points of leverage from which to shift those problems.
We adjust the factory’s machines, and acquire or invent new ones, to keep doing it a little better each release. We keep finding ways to adapt the process to keep delivering a little more value per unit time to the customer, the team, and the organization. We keep maturing and evolving, like any healthy organism.
10. Small, cross-functional teams
Smaller agile development 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. This means that an agile development team needs to include members with all of the skills necessary to successfully deliver software, including analysis, design, coding, testing, writing, user interface design, planning, and management. We need this because, again, each iteration is its own mini-project.
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, camaraderie, empathy, collaboration, and job satisfaction increase. Software development becomes fun again. These outcomes are not guaranteed, but they are much likelier in well-managed agile development projects than elsewhere.
