Practice 1. Iterative Development
Iterative development can be thought of as plan a little, do a little, learn a little. Iterative development is a core practice of sustainable software development because it gives the team a lightweight way to make measurable progress and to get feedback from customers as frequently and as early as possible. Getting feedback as early as possible is critical to ensuring that the system meets user requirements, that it is as simple as possible, and that there is minimal wasted effort. Minimizing wasted effort (features that users don't care about, features that are built in unusable ways, etc.) is an important business consideration because wasted effort has a cost and is inefficient.
Iterative development is amazingly simple. The schedule is broken up into a number of short equal-length iterations (2 to 6 weeks). At the end of each iteration, the software must be in a shippable state because it is given to customers for feedback. Each iteration has a little bit of planning, some real work is done, feedback is received from customers, the team records its progress to date, and reflects on how they can improve in the future.
Iterative development allows the team to replan and reprioritize at the beginning of every iteration. Planning is done in a lightweight but very effective manner using feature cards, with one feature card per feature. A feature card is a simple 3.5"x 5" index card. Because each iteration requires customer feedback, the team is able to keep its feature cards sorted into those that are done, those that are going to be worked on in the current iteration, and those that are going to be worked on in future iterations. Uncompleted features are arranged into a number of future iterations, and as the project proceeds, features will be added, removed, and reprioritized by the customer.
In iterative development, the feature cards and their arrangement into a number of iterations is the project schedule. The cards should be posted onto a board in a place that is accessible to the team. There are no detailed project schedules (PERT or Gantt charts), user requirement documents, etc. Instead, the feature cards contain all the documentation required to begin the work: a feature description, a time estimate, key acceptance criteria, risk (high, medium, low), and just about anything else that is useful to the team that will fit. One way to look at feature cards is that they are collaboration enablers: The cards themselves are less valuable than the conversations (and collaboration) that result from filling them out, moving them around, and understanding them. Hence, feature cards are meant to be barely sufficient, so that the team's emphasis is on producing a working product, not a stack of documentation.
Iterative development is important for sustainable development because it provides a regular heartbeat or checkpoint to the development effort. The regular rhythm is good for the team because it breaks the effort down into manageable pieces; it's good for project stakeholders and customers because they know they can expect to see progress on a regular basis [Cohn 2005]. Furthermore, since the goal of iterative development is to get feedback, teams are encouraged to keep the software in a working state; if the software is unreliable, then customers won't use it and can't give meaningful feedback. This topic of a Working Product is the focus of Chapter 4.
Collaboration and Iterative Development
Iterative development is most effective when there is broad participation in iteration planning. At the beginning of each iteration, the entire team (business people, technical staff, and customers) has a short and intense iteration planning session. In this planning session the team analyzes and sorts the current set of desired features into an iteration plan based on risk (do the risky things early) and priority (determined by the customer). Tradeoffs are made through conversations within the team during the planning session.
Cross-functional collaboration is important to sustainable development because there is no hiding risk from any of the participants. Hence, active risk management is encouraged. Also, because it is a team exercise, everyone involved understands the current product status, what still needs to be accomplished, and also what can be accomplished in the time available. And because the planning is focused on providing value to customers real tradeoffs can be made, for example, between new features and making existing features work better for customers.
Iterative development is a humbling (in a good sense!) experience for the entire team. It's always easy to get enthused about a particular feature, but you can only introduce it once it is compared to the other features already in the plan. Collaboration helps to ensure that the right tradeoffs are made and the best possible priorities are set. There is no hiding the harsh reality that when someone wants to add a feature, in order to do so, another feature has to be removed from the plan!
A key component of iterative development is the tracking of the project's velocity. Each feature card documents the time required to complete that feature in feature points. Feature points can be relative or absolute, though most people seem to prefer that feature points roughly equate to the number of ideal days of effort by a canonical developer. The card also documents the customer acceptance criteria; when these criteria have been met, the feature is completed. The velocity essentially is a record of the number of feature points completed in any given iteration.
Velocity is tracked throughout the project and gives an immediate indication of how well the project is (or is not) progressing. Incorporating velocity into the iteration planning sessions the team allows team members to make realistic plans for each iteration and also ask themselves difficult questions in cases where they are not making progress.
Given a record of velocity and the use of iterative development, all that team members really need to chart their progress is two charts that are easily maintained on a whiteboard or web page: velocity (by iteration) and number of feature points remaining. Some examples are shown in Figure 7-1. Although velocity cannot be compared between teams, within a team these two charts provide status of the project at a glance and a realistic gauge of when the project will complete based on the past and current progress.
Figure 7-1. These two charts are sufficient for most projects to document and understand the state of their project. The chart on the left is a simple line chart that shows the velocity in each iteration. The chart on the right shows the number of feature points remaining in the project. By simply projecting a straight line and using the team's current and average velocity to date, the project team can visually determine when the product will ship with the current feature set. In this case, in iteration 7.
Iteration 0 is a short iteration (2 to 6 weeks) that the team can use to perform critical analysis work before starting actual development. Iteration 0 also helps teams identify and document longer term considerations. Iteration 0 is an excellent time to: