What is Agile Software Development?

The manifesto for agile software development has revolutionized the way companies plan, develop, test and release software. Throwing away years of accumulated orthodoxy, agile development methods have now become the accepted way to develop software.

Agile Software Development

Traditionally projects are delivered in a series of phases that are based on increasing levels of certainty around the system being built:

However, this approach has many drawbacks:

  • It is not flexible to changes in customer requirements
  • Time is wasted building features that nobody needs
  • The end user cannot give feedback till it’s completed coded
  • You don’t know how stable the system is until the end

How Are Agile Software Development Projects Different?

Instead of phases, projects are broken down into releases and iterations. At the end of each iteration you have a fully functioning system that could be released:

With agile software development, the requirements for the project do not have to be codified upfront, instead they are prioritized and scheduled for each iteration. The requirements are composed of ‘user stories’ that can be scheduled into a particular release and iteration.

There are many different agile software development methods, each of which is described below:

They have specific features that make them better suited to different situations, but in general, the different agile software development methodologies adhere to the same basic principles:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

You can read about the different agile methods and how they compare in our whitepaper: Introduction To Agile Development Methods.


Scrum has become one of the ‘go-to’ techniques for those striving to become Agile. Along with XP, it is perhaps the most well-known of the Agile methods, and also the most precisely defined which means that there is a lot of documentation and pre-built process for teams that are willing to adopt the methodology completely. More Information on Scrum

Kanban / Lean

In general, Kanban is a scheduling system for lean and other JIT processes. In a Kanban process, there are physical (or virtual) “cards” called Kanban that move through the process from start to finish. When used for software development, the aim is to control and manage the flow of features (represented by Kanban cards) so that the number of features entering the process matches those being completed. More Information on Kanban

Extreme Programming

The idea developed by Kent Beck was to use best programming practices but take them to the extreme – hence the name. As such, none of the individual concepts of XP are really new, but their application and combination is what makes XP different. More Information on XP

Agile Unified Process

The Agile Unified Process (AUP) was developed in 2005 as a simplified version of the Rational Unified Process (RUP) with work attributed to Scott Ambler. It was subsequently updated in 2006 before Scott Ambler moved on to the work which became Disciplined Agile Delivery (DAD). RUP is process-heavy, and although the AUP is intended to conform to all the principles of the Agile Manifesto, it debatable how well it succeeds.

For example, Agile methods should support self-organizing teams with no management hierarchy, however it is hard to ignore the fact that the AUP has, to some degree, inherited the process-heavy nature of its parent, RUP. The counter-argument is that the AUP does not enforce any of the process guidelines it offers. However, Project Management is still a major discipline in the AUP.

As with some other Agile methods, initial requirements elicitation are excluded as is any delivery process at the back end. The Agile Unified Process is more up-front loaded than most Agile methods, requiring a considerable amount of modeling before implementation begins, which in turn demands some degree of early requirements analysis.

While this is not a bad thing, care must be taken not to go too far and do waterfall-like detailed requirements analysis. Further, the proposed incremental development releases between production releases are not necessarily production quality and so again, the lifecycle can appear more waterfall than Agile.

Dynamic Systems Development Method (DSDM)

The Rapid Application Development (RAD) is an iterative and incremental method which relies heavily on prototyping in order to obtain feedback from stakeholders. However, this requires early development of the GUI which can produce wasteful discarded versions and de-emphasize underlying functionality.

In 1994, the relative lack of discipline in the RAD method led to the creation of the DSDM Consortium to develop a formalized independent RAD framework incorporating Agile principles. The result was the release of version 1 of the Dynamic Systems Development Method (DSDM) in1995 since when, it has continuously evolved leading to the launch of a new version in 2007 called DSDM Atern.

Like most agile development methods, DSDM Atern puts quality and schedule first, leaving functionality as the lone variable. The method of prioritization used is called MoSCoW, offering four simple requirements categories:

  • Must have;
  • Should have;
  • Could have; and
  • Won’t have this time around.

Alongside all the standard principles that define Agile processes such as stakeholder involvement, and build early and often, DSDM Atern also advocates a degree of formal tracking and reporting which is not so common amongst Agile methods.

DSDM Atern addresses the narrow scope of some other methods such as Scrum by including pre and post-development phases in its purview making it a true project management process as opposed to a focused development process. It is also a method with a detailed process description and therefore it can take some time to embrace DSDM Atern fully.

Disciplined Agile Delivery (DAD)

In 1996 Rational Software Corporation created the Rational Unified Process (RUP) which was mostly a combination of UML and ideas developed by others such as Grady Booch and Jim Rumbaugh. RUP was a framework from which elements could be used for each project as necessary, which was a good job really as over the years it grew to be humongous and it is highly improbable that any single project used it all. The Agile Unified Process was developed in 2005 as a simplified version of RUP with work attributed to Scott Ambler who in 2012 wrote the book ‘Disciplined Agile Development’ with Mark Lines taking us from AUP to DAD.

A criticism of Scrum, XP and some other agile development methods is that they only address the software creation aspect of a project and leave other aspects, especially those at the start and end of the project, as a sort of ‘exercise for the reader.’ The DAD process framework attempts to expand the agile influence beyond mere software generation to the entire product process while additionally addressing the needs of the enterprise such that the methods are scalable.

As with its early forbears, DAD offers more than any single project would want and, in some cases, even proposes a number of alternative solutions from which to choose. Because DAD is rather comprehensive it is not easy to describe concisely in just a few paragraphs, but the following is a list of DAD’s characteristics summarized:

  • Self-organizing, cross functional teams of individuals with multiple skills often called generalizing specialists;
  • An environment that promotes learning to include user needs, how to improve processes and a growth in technical knowledge;
  • An adherence to the principles of the Agile manifesto;
  • The borrowing of ideas and principles from other Agile, iterative or lean methods such as XP, Kanban and Scrum;
  • An expansion of the vision from just software to all aspects of a product such as hardware and user process improvement and in doing so, extending agile principles to all project disciplines;
  • Encompassing the full project lifecycle from initiation to production delivery with an understanding that the nature of activities within iterations will change as the product matures;
  • Sufficient guidelines to help those starting up but not too many to put them into straightjackets, essentially trying to provide balance between too little and too much guidance;
  • Methods to address risk, evaluate product viability and ensure value through regular production of potentially deliverable solutions; and
  • Accommodation of demands from the enterprise such as governance, corporate vision, and other active projects teams.

Being relatively new, it remains to be seen whether DAD gains sufficient popularity to earn its place as a ‘standard’ alongside Scrum and XP. Even if it is not adopted in full, DAD offers ideas that can be integrated into other project environments.

Feature-Driven Development (FDD)

Feature-driven development (FDD) is an iterative and incremental software development process that follows the principles of the agile manifesto. The idea is to develop the high-level features, scope and domain object model and then use that to plan, design, develop and test the specific requirements and tasks based on the overarching feature that they belong to. More Information on Feature-Driven Development

Test-Driven-Development (TDD)

Test-Driven Development (TDD) originally was created as part of the Extreme Programming (XP) methodology, where it was known as the ‘Test-First’ concept. The idea is that developers generally write their tests after the code is written and therefore are only testing the functionality as they wrote it, as opposed to testing it to make sure it works the way it was actually intended! More Information on Test-Driven Development

Rapid Application Development (RAD)

The Rapid Application Development (RAD) approach was championed by James Martin in his book of the same name in 1991, although the process had been around for some time before that. RAD is an iterative and incremental method which relies heavily on prototyping in order to obtain feedback from stakeholders. However, this requires early development of the GUI which can produce wasteful discarded versions and de-emphasize underlying functionality.

The idea of RAD is to build a functioning prototype which the stakeholders can use to visualize the intended functionality. This prototype is then successively improved to eventually become a robust application that meets the intended functionality. This approach avoids the issue with more traditional requirements-centric approaches where the stakeholders cannot conceive of the desired solution and where there are missing ‘latent’ requirements that only become known once the first version of the application is released.

RAD is not always considered an agile approach and in 1994 the relative lack of discipline in the method led to the creation of the DSDM Consortium to develop a formalized independent RAD framework incorporating Agile principles. The result was the release of version 1 of the Dynamic Systems Development Method (DSDM) in1995 since when, it has continuously evolved leading to the launch of a new version in 2007 called DSDM Atern.

Scaled Agile Framework (SAFe)

The Scaled Agile Framework (or SAFe) is an Agile software development framework that takes the concepts of agile development and provides a “larger picture” methodology that allows you to use agile approaches across an entire enterprise. Unlike traditional agile which is project-focused, SAFe scales up agile to work across large distributed programs and entire organizations:

(Image is Copyright Scaled Agile Inc).

SAFe is based on a number of immutable, underlying Lean and Agile principles. These are the fundamental tenets, the basic truths and economic underpinnings that drive the roles and practices of SAFe:

  • Take an economic view
  • Apply systems thinking
  • Assume variability; preserve options
  • Build incrementally with fast, integrated learning cycles
  • Base milestones on objective evaluation of working systems
  • Visualize and limit WIP, reduce batch sizes, and manage queue lengths
  • Apply cadence (timing), synchronize with cross-domain planning
  • Unlock the intrinsic motivation of knowledge workers
  • Decentralize decision-making

Why Choose SpiraTeam for Agile Software Development

When your company requires better agile software development tools, there are a lot of choices in the marketplace. However, if you want the best in agile software development with there is only one solution.

SpiraTeam® is a complete agile software development management system that manages your project's requirements, releases, iterations, tasks and bugs/issues. Designed specifically to support agile methodologies such as Scrum, Extreme Programming (XP), DSDM and Agile Unified Process (AUP) it allows teams to manage all their information in one environment.

SpiraTeam Extreme Programming Scrum AgileUP / DSDM / DAD
Summary Requirement Epic Epic Feature Group
Requirement User Story Backlog Item Requirement
Task Task Task Task
Release Release Release Release
Iteration Iteration Sprint Iteration
Test Case Acceptance Test Acceptance Test Test Scenario

SpiraTeam® provides reporting dashboards of key project quality and progress indicators - requirements test coverage, task progress, project velocity, as well as top risk and issues – in one consolidated view that is tailor-made for agile software development methodologies as well as supporting your legacy/hybrid waterfall projects.

The top reasons that our customers choose SpiraTeam® over other solutions are:

  • Highly intuitive web application that provides a complete picture of a project’s status and health yet requires only a web-browser.

In addition, we provide superb technical support that ensures that enquiries and questions are dealt with in a timely and professional manner.

How do I Get Started?

To learn more about SpiraTeam and how it can improve your agile software development processes please:

Why Should I Use Rapise For My Agile Projects?

One of the key tenets of most agile methods is that fully integrated, tested and releasable code is available at all times. When you couple this requirement with the accelerated timeframes possible with agile methodologies, manual testing alone is not going to cut it. You need a test automation solution that can be integrated fully into your development process and that be adapted to your changing needs:

Rapise is the most powerful and flexible automated testing tool on the market. With support for testing desktop, web and mobile applications, Rapise can be used by testers, developers and business users to rapidly and easily create automated acceptance tests that integrate with your requirements and other project artifacts in SpiraTeam.

How do I Get Started?

To learn more about Rapise and how it can improve your agile software testing please:

About Inflectra

Our mission to helping our customers - large corporations, small businesses, professional services firms, government agencies and individual developers – with the means to effectively and affordably manage their software development and testing lifecycles, so as to decrease the time to market and increase return on investment.

At Inflectra, we are fully committed to provide our customers with the very best products and customer service. We believe in going the extra mile to ensure that each customer is satisfied with our software products. We have the experience and the commitment to deliver the products customers need to deliver their projects and assure quality every step of the way. (Learn More)

Our Guarantee

We are so confident that you will be fully satisfied with our products that we offer a 30-day, unconditional, money back guarantee! (Learn More)