Iterative Development

57 team-iterative-development

The purpose of working iteratively is to allow more flexibility for changes. With each iteration, software is improved through the addition of greater detail.

Explore More.

Related Mindset:

Lean-Agile

Segment:

Team

Inputs:

The user stories, technical stories, and defects that make up the team commitment for an iteration.

Outputs:

Completed, tested, and approved code that satisfies the acceptance criteria of the sprint’s allocated user stories, technical stories, and defects.

Iterative Development is a method of breaking down software development for large applications into smaller portions.

In Iterative Development, code is designed, developed, and tested in repeated cycles. With each iteration, features can be added or refined until there is a fully functional software application ready to be deployed to customers.

The mantas of Iterative Development are:

  • Iterations are time-boxed not functionally-boxed - Basing planning, development, and testing on a predictable time schedule limits variances in product development.
  • Build quality in - To ensure sustainable development velocity, code must be held to a high standard. Best practices include Test-Driven Development, code reviews, and Continuous Integration.
  • Test early, Test often - Automated testing, as well as breaking development into small testable pieces, allows for faster task throughput.
  • Release on demand - Code that is complete at the end of each sprint should be production-safe. Feature flagging and code branching strategies can aid in making incomplete features releasable.

Daily Stand-up

Each day in the iteration, usually at the beginning of the day, the entire team meets for a quick update. This update is moderated by the scrum master and is time-boxed for 15 minutes. In it, each person on the team gives an update to their teammates on any progress, impediments, or successes they have had within the past day’s work. The daily stand-up is not a status report for stakeholders. It is a short declaration of what was done the day before, what is planned for today, and what impediments exist.

Task Workflow

After planning the team’s iteration, each team member will have tasks they have committed to completing. These tasks will be tracked using the Team Board. The Team Board is a tabular list of each team member and the workflow each task goes through. For example, a team’s development workflow could consist of the following task states:

  • Ready
  • In Progress
  • Review
  • Done

These task states are specific to each team and the type of work that they do. Here is an example of a task workflow using the states listed above:

  • Sally is assigned a task. The task is placed in the “Ready” column next to Sally’s name on the Team Board.
  • Sally begins working on the task and moves the it to the “In Progress” column.
  • Sally finishes work on the task, moves it to the “Review” column, and assigns the task to Harry.
  • Harry reviews Sally’s work approves it.
  • Harry moves the task to the “Done” column.

Backlog Grooming

In order to maintain work velocity, an effort needs to be made to prepare for the next iteration while working in the current one. To do this, scrum masters will often hold Backlog Grooming sessions. In these sessions, stakeholder and developers discuss upcoming features, existing defects, and other areas for improvement via refactoring.

Common Pitfalls

Organizations that follow an iterative approach to development can still fall victim to some common pitfalls:

  • Modifying scope within an iteration - Scope must be locked down for a given iteration. Any changes to that scope will cause the metrics to become invalid and diminish the value of the overall iterative process.
  • Resources with variable capacity - Ideally, resources are completely allocated for their Scrum team. In some cases, individuals may have other responsibilities. It is critical that an individual’s allocation does not change either within an iteration or from iteration to iteration. Any changes to allocations will invalidate Sprint commitments from the team.
  • Multiple areas of responsibility - In some organizations, a scrum team or individuals within a team can be retasked to deal with production issues, critical defects, or work outside the scope of the team. Just as with the previous pitfalls, this will work to undercut the entire process. If a team may have to do some level of production support, a percentage of time should be allocated to those efforts before the team commits to scope. This can be handled through appropriate Capacity Planning.
  • Inconsistent teams - If team members are constantly changing, team estimates and metrics will be skewed. Teams work best when the members of the team are consistent from iteration to iteration.