Skip to content
Search

Agile software development

lastmod 2025-08-31created 2015-03-0416 edits

Agile software development, or the agile development process, is a conceptual framework for software engineering that promotes iterative development throughout a project's life cycle. Recently, partly due to the spread of agile games, pragmatic-minded people in many professional fields beyond software engineering have been trying to apply agile methodologies.

Concept

Agile methodology seeks a compromise between software development methods with no plan at all and those with too much planning. Methodologies without a plan are weak in that future work is hard to predict and they are not efficient, while relying too heavily on planning has the drawbacks that the time and cost of following its formal procedures cannot be ignored and that it slows down the overall flow of development.

Therefore, the biggest difference that agile methodology adopted, and that distinguishes it from other classical methodologies such as the waterfall model or the spiral model, is that it is less document-oriented: rather than developing through documents, it is code-oriented, a methodology driven by actual coding.

Thus, unlike past plan-driven methodologies, agile development does not develop by predicting ahead; it can be described as an adaptive style that builds one large piece of software by continuously producing prototypes on a regular cycle, adding and revising requirements as they arise.

The agile development process does not refer to any particular development methodology; it is "a term for the whole range of methodologies that make agile (Agile = nimble; building good things quickly and without waste) development possible. The agile development process used to be called a "Lightweight" process. Extreme Programming (XP: eXtreme Programming) can be seen as the representative method of the agile development process.

Brief explanation

Methodology-agile.png

Agile-development-diagram.png

Types

Development methodologies called agile development processes include the following.

  • Extreme programming (XP) - The flagship of the agile development process, it played a major role in spreading agile development. It has explicit techniques and practices characterized by roughly two-week iterations with the customer and test-first development (TDD).
  • Scrum - Centered on the Sprint, which delivers a working product every 30 days. A project-management-focused methodology for teams that do short development sessions at a fixed time and place every day.
  • Crystal family - This approach provides several kinds of methodologies depending on the size of the project and the magnitude of its impact. Among them, Crystal Clear, applied to the smallest teams, is neither as strict nor as efficient as extreme programming, but it is an easy methodology to apply to projects.
  • Feature-Driven Development - Runs roughly two-week iterations per feature. A methodology advocated by Peter Coad, closely related to design techniques using UML.
  • Adaptive Software Development, ASD - A methodology created to define software development as chaos itself and, taking chaos as its premise, to present software methods that can adapt to it. Its content is similar to other methodologies, but it differs slightly in using Joint Application Development (a development methodology in which users or customers take part in design).
  • Extreme modeling - Extreme modeling is a modeling-centered methodology using UML. Unlike other modeling methods, however, it repeats the process of writing models that can always be executed and verified, so that ultimately the product is generated automatically from the model.

Each of the agile development processes introduced above has different characteristics and scope, and they can be combined. Projects that adopt an agile development process achieve great results not by adopting a single methodology and merely imitating it by the manual, but by picking and combining the parts of various methods that fit their project and by creating their own methods. The advocates of these agile development processes have formed a free organization called the Agile Alliance and are working to spread agile development processes.

When using an agile framework, "watch out for these"

Frequent team member changes
When team members leave to work on other projects or regularly miss team rituals, the team's Velocity drops.
An ideal Scrum team should be a small team of 3 to 9 people. Some consider 5 the optimal team size. But just as important as the right team size is keeping team membership constant for an appropriate period. If team members change too often, the team's chances of success go down. A stable team can understand its own production capacity well, which improves predictability and ultimately leads to higher productivity.
Overestimating sprint points
Building an accurate sprint backlog using yesterday's weather reduces the chance of putting too many estimate points in and endangering the sprint.
Overestimating the amount of work a team can handle in a sprint is a common problem in Scrum. Sutherland, Harris, and Liddell stressed that the most accurate way to predict how many points a team can complete in the next sprint is to look at how many points the team completed in the previous sprint (commonly called "yesterday's weather"). A team that knows its own capacity well can avoid the mistake of overreaching and increase its chances of sprint success.
Too much work in progress
Swarming lets you move items into the 'done' category faster, increasing velocity.
Scrum teams with too much work in progress have a hard time completing sprints successfully. The authors suggest using a "swarm" to handle high-value backlog items as a group and finish them as quickly as possible. Teams that take the swarm approach can get more done during a sprint.
Insufficient time allocated for interruptions
Teams that prepare for interruptions are far more efficient than teams that do not, even when no interruptions occur.
Interruptions occur in every sprint. That is, things like bugs come up that have to be dealt with. One common problem of Scrum teams is not allocating enough time in each sprint to handle issues that are not in the backlog. Sutherland recommends calculating the time to allocate for interruptions in each sprint based on past experience. He also recommends that if the points spent on interruptions exceed the allocated points, the sprint be stopped to push the whole company to minimize interruptions to that team, since the delivery date is likely to be affected.
Leaving bugs unfixed
A bug not fixed on the day it appears can take up to 24 times longer to fix three weeks later.
The core goal of agile is to have working code at the end of every sprint. But Scrum teams should aim to have clean, working code at the end of every workday. This means bugs must be resolved as quickly as possible as soon as they appear. Bugs left unfixed take more time to fix later.
Waiting too long before declaring an emergency
Don't delay action while you look at what the problem is or what to do. When flying a fighter jet, you can die before you figure out what is happening.
When it is certain that a sprint will go off plan, you should start predefined emergency procedures without wasting time. Very often, time is wasted early in a sprint without dealing with serious problems (e.g., too many backlog items). Deciding as quickly as possible when to take strong action, from offloading some work to stopping the sprint, is the Scrum Master's job.
Leaving impediments in place
Impediments can be people with strong personalities, management interfering with the sprint, or a variety of other people problems. These impediments should be treated the same as process improvements and resolved as quickly as possible.
Teams that do not regularly identify and resolve impediments to sprint success keep losing performance. Sutherland, Harris, and Liddell recommend identifying the single biggest impediment in each sprint, then creating a user story and resolving it in the next sprint. Regularly removing impediments lets you do more than in the previous sprint, so velocity increases.
Not measuring team members' happiness
By monitoring the team's happiness, the Scrum Master can anticipate a drop in velocity and take action.
If Scrum team members are unhappy, it hurts the team's capability. Sources of dissatisfaction vary, such as the company, the team's way of working, or one's own role. The method the authors recommend is for the Scrum Master to regularly have team members rate their own happiness level. When team happiness drops, the cause should be investigated as quickly as possible to identify obstacles and impediments.
Failing to accelerate
Teams that finish work early tend to have higher happiness as well, since they are confident in their ability to complete sprints.
Scrum teams that cannot finish the work allocated to a sprint cannot move forward. If they allocate more work to a sprint, fail to remove impediments, or do not plan properly for interruptions, they cannot finish work on time and the sprint fails. Once the other common problems mentioned here are resolved, the team finishes its allocated work sooner than expected and can increase velocity by handling additional backlog work in the current sprint.

Projects

  • Planbox
  • Atlassian's Jira
  • Axosoft
  • LeanKit
  • Microsoft Visual Studio Team Foundation Server
  • Rally agile platform
  • Telerik TeamPulse

See also

Favorite site

author Zer0 sitemap