Agile Testing Quadrants.

Agile Testing Quadrants.

Overview ScrumMaster Role.............

Overview ScrumMaster Role:

The ScrumMaster is responsible for making sure that all the pieces of the Scrum process come together and work as a whole. The Product Owner must do his or her job. The Team must do its job. The chickens must be kept in line. The Product Owner and the Team must collaborate appropriately and use the Scrum meetings for inspection and adaptation.

The responsibilities of the ScrumMasters can be summarized as follows:

• Remove the barriers between development and the Product Owner so that the Product Owner directly drives development.

• Teach the Product Owner how to maximize ROI and meet his or 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.

When the ScrumMaster fulfills these responsibilities, the project usually stays on track. These responsibilities should be enough to keep the ScrumMaster busy; no ScrumMaster should have any time left over to act like a typical boss.

Indeed, a ScrumMaster who acts like a program manager probably isn’t fulfilling all of his or her duties as a ScrumMaster.

ScrumMaster.......

ScrumMaster:

A strange name like “ScrumMaster” for the person who facilitates Scrum projects?

Why didn’t I continue to use the standard title “project manager”? 

The ScrumMaster are different from those of a traditional project manager. 

This difference in terminology is symbolic of a drastic change managers must make to their approach if they are to effectively manage Scrum projects.

The authority of the ScrumMaster is largely indirect; it springs mainly from the ScrumMaster’s knowledge of Scrum rules and practices and his or her work to ensure that they are followed.

The ScrumMaster is responsible for the success of the project, and he or she helps increase the probability of success by helping the Product Owner select the most valuable Product Backlog and by helping the Team turn that backlog into functionality. 

The ScrumMaster earns no awards or medals because the ScrumMaster is only a facilitator.

Roles in Scrum........

Roles in Scrum:

There are only three roles in Scrum:

1.) The Product Owner.

2.) The Team.

3.) The ScrumMaster.

All management responsibilities in a project are divided among these three roles.

The Product Owner is responsible for representing the interests of everyone with a stake in the project and its resulting system. The Product Owner achieves initial and ongoing funding for the project by creating the project’s initial overall requirements, return on investment (ROI) objectives, and release plans. The list of requirements is called the Product Backlog. The Product Owner is responsible for using the Product Backlog to ensure that the most valuable functionality is produced first and built upon; this is achieved by frequently prioritizing the Product Backlog to queue up the most valuable requirements for the next iteration.

The Team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional, and they are responsible for figuring out how to turn Product Backlog into an increment of functionality within an iteration and managing their own work to do so. Team members are collectively responsible for the success of each iteration and of the project as a whole.

The ScrumMaster is responsible for the Scrum process, for teaching Scrum to everyone involved in the project, for implementing Scrum so that it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows Scrum rules and practices.

Scrum Basics...........

Scrum Basics :

Scrum hangs all of its practices on an iterative, incremental process. The lower circle represents an iteration of development activities that occur one after another. The output of each iteration is an increment of product.

The upper circle represents the daily inspection that occurs during the iteration, in which the individual team members meet to inspect each others’ activities and make appropriate adaptations. Driving the iteration is a list of requirements. This cycle repeats until the project is no longer funded. 

The above figure operates this way: At the start of an iteration, the team reviews what it must do. It then selects what it believes it can turn into an increment of potentially shippable functionality by the end of the iteration. The team is then left alone to make its best effort for the rest of the iteration. At the end of the iteration, the team presents the increment of functionality it built so that the stakeholders can inspect the functionality and timely adaptations to the project can be made.

The core of Scrum lies in the iteration. The team takes a look at the requirements, considers the available technology, and evaluates its own skills and capabilities. It then collectively determines how to build the functionality, modifying its approach daily as it encounters new complexities, difficulties, and surprises. The team figures out what needs to be done and selects the best way to do it. This creative process is the core of the Scrum’s productivity. 

Extreme Programming Practices in brief

Extreme Programming Practices in brief :

XP is an adaptive method, so although all XP teams need to consistently embrace the values and
principles, the details of the actual day-to-day operation of an XP project vary from team to team.

A reasonable question then is “where do I start?”.

XP provides a set of daily practices that, used together, have been demonstrated to efficiently produce high quality software.

These practices are:

· Whole Team
· Planning Game
· Customer Tests
· Small Releases
· Simple Designs
· Pair Programming
· Test-Driven Development
· Design Improvement
· Continuous Integration
· Collective Ownership
· Coding Standard
· Sustainable Pace
· Metaphor

Extreme Programming

Extreme Programming Values and Principles :

The XP values are:
· Communication
· Simplicity
· Feedback
· Courage

An XP project relies on these four values. If your organisation or team doesn' t truly share these
values, then an XP project will fail.

Of course, most of those values are motherhood-and-apple pie – it would be hard to find an organisation that said that it didn' t believe in them.

XP tries to remove some of the vagueness from these values by describing principles that embody the values.

· Open, honest communication
· Quality work
· Rapid feedback at all levels
· Assume Simplicity