What is Agile Software Development?

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:

• Scrum

• Kanban / Lean

• Extreme Programming (XP)

• Agile Unified Process (AUP)

• Dynamic Systems Development Method (DSDM)

• Disciplined Agile Delivery (DAD)

• Feature-Driven Development (FDD)

• Test-Driven Development (TDD)

• Rapid Application Development (RAD)

• Scaled Agile Framework (SAFe)

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

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

Scrum is often deployed in conjunction with other agile methods such as Extreme Programming (XP) since such methods are in reality mostly complimentary, with XP focusing on the engineering (continuous integration, test-driven development, etc.) and Scrum focusing more on the project management side (burn-down, fixed scope for sprints/iterations).

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

The principle behind Kanban that allows it to be incremental and Agile, is limited throughput. With no iterations a Kanban project has no defined start or end points for individual work items; each can start and end independently from one another, and work items have no pre-determined duration for that matter. Instead, each phase of the lifecycle is recognized as having a limited capacity for work at any one time.

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.

XP advocates adaptability; recognizing that each project faces different problems, applying those methods that will work and discarding those that will not. Partial XP therefore becomes a true possibility, often combined with Scrum, which has gaps in its definition particularly suited to adoption of XP practices.

XP embraces standard agile principles such as short iterations; requirements being loosely defined with user stories until they are needed; almost immediate and regular testing; close, on-site stakeholder involvement with a rapid feedback loop; and team responsibility for success or failure.

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 is 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® 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:

• It is a complete solution that includes requirements management, release planning, iteration planning, task estimation and defect tracking all fully integrated from day one.

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

• Methodology Agnostic – SpiraTeam® can be used equally well for any agile software development methodology – including Scrum, AUP, XP, DSDM

• Ability to leverage your existing technology investments. SpiraTeam® integrates with many third-party defect-management systems and software configuration management (SCM) systems.

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:

• Take a tour of the available features

• Read some of the testimonials from satisfied customers

• Sign up for a 30-day trial version to try it out for yourself

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.

Self-Healing Tests

One of the obstacles to implementing test automation on an agile development project is that the application’s user interface may be changing frequently, with new pushes to production daily. Therefore, it is critical that tests created one day, continue to work seamlessly the next.

Rapise comes with a built-in machine learning engine that records multiple different ways to locate each UI object and measures that against user feedback to determine the probabilistic likelihood of a match. This means that even when you change the UI, Rapise can still execute the test and determine if there is a failure or not.

How do I Get Started?

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

• Take a tour of the available features

• Read some of the testimonials from satisfied customers

• Sign up for a 30-day trial version to try it out for yourself