Agile and Scrum Testing

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.

Agile methods or Agile processes generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Scrum is a lightweight process framework for agile development, and the most widely-used one.

• A “process framework” is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints, the XP framework requires pair programming, and so forth.)
• “Lightweight” means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.

A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Artifacts, and Time Boxes. These and other terms used in Scrum are defined below.

Scrum is most often used to manage complex software and product development, using iterative and incremental practices. Scrum significantly increases productivity and reduces time to benefits relative to classic “waterfall” processes. Scrum processes enable organizations to adjust smoothly to rapidly-changing requirements, and produce a product that meets evolving business goals.

An agile Scrum process benefits the organization by helping it to

• Increase the quality of the deliverables
• Cope better with change (and expect the changes)
• Provide better estimates while spending less time creating them
• Be more in control of the project schedule and state

As a result, Scrum projects achieve higher customer satisfaction rates.

Agile development refers to any development process that is aligned with the concepts of the Agile Manifesto. The Manifesto was developed by a group fourteen leading figures in the software industry, and reflects their experience of what approaches do and do not work for software development.

The Manifesto says:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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

That is, while there is value in the items on the right, we value the items on the left more. The agile philosophy holds that the best way to meet customer needs is through the collaboration of a committed group of people, who focus on achieving results quickly, with as little process overhead as possible.

A key element of this philosophy is that we must trust people and their ability to collaborate, more than we trust any particular process. This principle follows from the fact that people can succeed without a formal process, but no process can succeed without people. For this reason, we should design an agile process that best taps the abilities of team members by emphasizing collaboration, rather than relying on the structure of a process to guarantee success.

The Agile Manifesto does not specify any particular practices that a development team should follow. Specific agile process frameworks, such as Scrum and XP, do define practices that must be followed.

Roles

The three roles defined in Scrum are the ScrumMaster, the Product Owner, and the Team (which consists of Team members). The people who fulfill these roles work together closely, on a daily basis, to ensure the smooth flow of information and the quick resolution of issues.

ScrumMaster

The ScrumMaster (sometimes written “Scrum Master,” although the official term has no space after “Scrum”) is the keeper of the process. He is responsible for making the process run smoothly, for removing obstacles that impact productivity, and for organizing and facilitating the critical meetings.

The ScrumMasters responsibilities include

• Removing the barriers between the development Team and the Product Owner so that the Product Owner directly drives development.
• Teach the Product Owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.
• Improve the lives of the development Team by facilitating creativity and empowerment.
• Improve the productivity of the development Team in any way possible.
• Improve the engineering practices and tools so that each increment of functionality is potentially shippable.
• Keep information about the Team’s progress up to date and visible to all parties.

In practical terms, the ScrumMaster needs to understand Scrum well enough to train and mentor the other roles, and educate and assist other stakeholders who are involved in the process. He should maintain a constant awareness of the status of the project (its progress to date) relative to the expected progress, investigate and facilitate resolution of any roadblocks that hold back progress, and generally be flexible enough to identify and deal with any issues that arise, in any way that is required. He must protect the Team from disturbance from other people by acting as the interface between the two.

The ScrumMaster does not assign tasks to Team members, as task assignment is a Team responsibility. His general approach towards the Team is to encourage and facilitate their decision-making and problem-solving capabilities, so that they can work with increasing efficiency and decreasing need for supervision. His goal is to have a team that is not only empowered to make important decisions, but does so well and routinely.

Product Owner

The Product Owner is the keeper of the requirements. He provides the “single source of truth” for the Team regarding requirements and their planned order of implementation.

In practice, the Product Owner is the interface between the business, the customers, and their product related needs on one side, and the Team on the other. He buffers the Team from feature and bug-fix requests that come from many sources, and is the single point of contact for all questions about product requirements. He works closely with the team to define the user-facing and technical requirements, to document the requirements as needed, and to determine the order of their implementation. He maintains the Product Backlog (which is the repository for all of this information), keeping it up to date and at the level of detail and quality the Team requires.

The Product Owner also sets the schedule for releasing completed work to customers, and makes the final call as to whether implementations have the features and quality required for release.

Team

The Team is a self-organizing and cross-functional group of people who do the hands-on work of developing and testing the product. Since the Team is responsible for producing the product, it must also have the authority to make decisions about how to perform the work. The Team is therefore self-organizing: Team members decide how to break work into tasks, and how to allocate tasks to individuals, throughout the Sprint.

The Team size should be kept in the range from five to nine people, if possible. (A larger number make communication difficult, while a smaller number leads to low productivity and fragility.)

Note: A very similar term, “Scrum Team,” refers to the Team plus the ScrumMaster and Product Owner.