Agile Software Development and Lean and Agile Test Driven Development

1 Introduction

In a fast-moving business environment, it is imperative that a rapid system development method be used. Rapid software development processes are designed to produce useful software quickly. Unlike traditional plan-driven approaches, the software is developed through increments – each increment focusing on a new system functionality.

1.1 Agile Characteristics

Agile methodologies are small incremental development methods characterized by the following set of principles:

• The processes of specification, design and implementation are interleaved. Unlike plan-driven approaches such as the Waterfall Life Cycle Model, wherein one process could not proceed without the the prior stepbeing accomplished, Agile Methodologies could be characterized by a series of Waterfall Models.
• The system is developed in a series of versions.
• System user interfaces are often developed using an interactive developmentsystem that allows the interface design to be quickly created by drawing and placing icons on the interface

1.2 History

The need for agile methods was proposed by a number of software developers in the 1990s usually involved in small and medium-sized business systems development. There was dissatisfaction with the heavyweight approaches to software engineering. The new method allowed the development team to focus on the software itself rather than on its design and extensive documentations.

1.3 Agile Manifesto

A team referred to as the Agile Alliance signed the Manifesto for Agile Software Development in 2001. The team comprised of Kent Beck, and some other developers and consultants in the software. Together, they came up with better ways of developing software. The gist of the manifesto include:

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

2 Agile Software Development

The success of some methods led to some integration with more traditional development methods based on system modelling, resulting in the notion of agile modelling and agile instantiations of the Rational Unified Process.

Agile methods are all based around the notion of incremental development and delivery, but with different processes. However, there is a shared set of common principles based on the agile manifesto. Other agile approaches exist, however, the following two are the most widely used methods:

2.1 Extreme Programming

Extreme programming is perhaps one of the most popular and widely used agile methods. The name was coined by Beck (2000) because the approach was developed by pushing recognized good practice, such as iterative development, to ‘extreme’ levels (Sommerville, 2012).

How extreme do you think could it be? Well, in XP, several new versions of a system may be developed by different programmers, integrated and tested in a day.

Let’s go through an overview of the process before diving in deeper into details. These processes result to a short time gap between releases of the system.

• Requirements are expressed as scenarios (or user stories) which are implemented directly as a series of tasks.
• Programmers work in pairs and develop tests for each task before writing the code.
• All tests must be successfully executed when new code is integrated into the system.

Extreme programming also involves a number of practices which basically reflects the principles of agile methods.The principles are summarized below:

Despite the numerous principles above, most companies never really implement them all. They choose the perfect recipe for their development needs or situations.

2.2 Scrum

Scrum is a general agile method but its focus is on managing iterative development rather than specific technical approaches to agile software engineering. Scrum does not prescribe the use of programming practices such as pair programming and test-first development. It can therefore be used with more technical agile approaches, such as XP, to provide a management framework for the project.

There are three phases in scrum:

• The first is an outline planning phase where you establish the general objectives for the project and design the software architecture.
• This is followed by a series of sprint cycles, where each cycle develops an increment of the system.
• Finally, the project closure phase wraps up the project, completes required documentation such as system help frames and user manuals, and assesses the lessons learned from the project.

The innovative feature of Scrum is its central phase, namely the sprint cycles. A Scrum sprint is a planning unit in which the work to be done is assessed, features are selected for development, and the software is implemented. At the end of a sprint, the completed functionality is delivered to stakeholders. Key characteristics of this process are as follows:

• Sprints are fixed length, normally 2–4 weeks. They correspond to the development of a release of the system in XP.
• The starting point for planning is the product backlog, which is the list of work to be done on the project. During the assessment phase of the sprint, this is reviewed, and priorities and risks are assigned. The customer is closely involved in this process and can introduce new requirements or tasks at the beginning of each sprint.
• The selection phase involves all of the project team who work with the customer to select the features and functionality to be developed during the sprint.
• Once these are agreed, the team organizes themselves to develop the software. Short daily meetings involving all team members are held to review progress and if necessary, re-prioritize work. During this stage the team is isolated from the customer and the organization, with all communications channelled through the so-called ‘Scrum master’. The role of the Scrum master is to protect the development team from external distractions. The way in which the work is done depends on the problem and the team. Unlike XP, Scrum does not make specific suggestions on how to write requirements, test-first development, etc. However, these XP practices can be used if the team thinks they are appropriate.
• At the end of the sprint, the work done is reviewed and presented to stakeholders. The next sprint cycle then begins.

The idea behind Scrum is that the whole team should be empowered to make decisions so the term ‘project manager’, has been deliberately avoided. Instead, the ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the backlog of work to be done, records decisions, measures progress against the backlog, and communicates with customers and management outside of the team.

Scrum, as originally designed, was intended for use with co-located teams where all team members could get together every day in stand-up meetings. However, much software development now involves distributed teams with team members located in different places around the world. Consequently, there are various experiments going on to develop Scrum for distributed development environments

3 Lean and Agile Test Driven Development

One of the important differences between incremental development and plan-driven development is the way that the system is tested. With incremental development, there is no system specification that can be used by an external testing team to develop system tests. As a consequence, some approaches to incremental development have a very informal testing process, in comparison with plan-driven testing.

In order to avoid such problems in testing, agile methods such as XP includes an approach to testing that reduces the chances of introducing undiscovered errors into the current version of the system. Test-first development is perhaps the most important aspect in XP. Instead of writing some code and then writing tests for that code, you write the tests before you write the code. This means that you can run the test as the code is being written and discover problems during development.

One major emphasis in lean software development is eliminating waste and delivering quickly. You examine the value stream—the process by which you turn ideas into deliverables. Then you cut out delays. For example, putting the authoring of tests first eliminates delays. Lean-agile testing works together primarily because one of the agile principles is that “working software is the primary measure of progress.” How do you know it works? It at least has to pass the tests. Getting the tests done without delay is the lean part.

Lean and Agile Acceptance Test Driven Development (ATDD) is not just about testing, though. It’s about communicating the requirements. And it’s not just for testers. It’s for the entire team—the customer, developer, and tester units referred to as the triad. Requirements and tests go together. You can’t have one without the other.

Acceptance tests clarify the requirements and provide a check on when the requirement has been implemented. The triad collaborates at each phase in the process—the initial creation of features, the breakdown into stories, and the development of scenarios. When features are initially created, acceptance criteria should be associated with them. These are general plans for how the feature will be tested. When the stories are created, more specific acceptance criteria are developed for them. Finally, when specific scenarios are established, then acceptance tests are created. A story is not done until the acceptance tests pass for all scenarios. They provide the doneness measure for the story. If an acceptance test is created for a story after the story is declared done, then the test really represents a new requirement.

4 Conclusion

Agile software development encourages customer satisfaction and rapid development with frequent releases of the software and producing high-quality code. The customer is directly involved in the development process. Agile development is characterized by small, highly motivated teams, informal methods and minimal software engineering work products developed with utmost simplicity. There is an emphasis on delivery over analysis and design and communication between the developers and customers. Although agile could provide us important benefits, we could not immediately conclude that it works in every software project, teams, or situations because it doesn’t. However, with the urgent need for revolutionary methods and innovations, I sigh with relief that our processes are evolving, and that software development doesn’t dull as our world and technology continues to evolve.