INTRODUCTION

Scrum is an agile software development methodology. Agile software development processes are different from traditional process models like the waterfall model in the sense that they try to address the fundamental problem, How to get the real progress?. Traditional process models give a long-winded path to project completion with the promise that if a development team follows it, it will have a fair chance of success. The problem with traditional process models, like the waterfall model, is that one does not really know when a project has deviated from the given path and when it has turned from a potential success to a likely failure. Only when it becomes very clear that the project is headed for complete disaster, the management comes to know about it. But then it is too late and not much can be done about it.

Agile software processes focus on the economic aspect of the project. The goal of a software project is make products which can be used in the customer's business operations. Rather than getting an idea about project's requirements and then going about development as per programmers' convenience, it is better to develop software incrementally, with each increment implementing the most important pending requirements of the project as per customer's business interests. In other words, it is best to develop software incrementally, first developing a small kernel satisfying the very basic requirements and then adding more functionality in each increment and ensuring that we have a working product with all previously developed functions after each update. Also, since a software product will have a lot of requirements, it is best if the customer can select the most important functions for each incremental development effort, based on his or her business needs.

THE SCRUM SOFTWARE PROCESS

Scrum is an incremental software development process. The project starts with a set of user requirements, which would be referred as the Product Backlog during the project. The development takes place in discrete efforts called sprints. The project owner, called Product Owner in Scrum terminology, selects a subset of requirements, based on their importance to customer's business, form the Product Backlog for a sprint. The project team members go through the subset and select the requirements they feel they can finish in the coming sprint. These selected requirements are frozen as the work to be done during the sprint and is known as the Sprint Backlog. During the sprint, the requirements from the Sprint Backlog are implemented and at the end of the sprint, the software product with more functionality becomes available. The duration of a typical sprint is about 30 days, with the project team meeting everyday for about 15 minutes to keep track of everyone's status and overall sprint issues.

Figure 1: The Scrum Software Process

SCRUM HISTORY

The term, Scrum, comes from the sport of rugby. Scrum is a way to restart the game after an interruption. The forwards of a side come together in a tight formation to gain control of the ball tossed among them. Thus the idea of Scrum comes from close-knit teams, willing to work hard together for a common goal.

Hirotaka Takeuchi and Ikujiro Nonaka[1] described a new way of product development in manufacturing industry. Traditional method involved many sequential phases like concept development, feasibility study, product design, development, prototyping and final production. Takeuchi and Nonaka proposed a holistic or rugby approach – where a team tries to go the distance as a unit, passing the ball back and forth. It was supposed to be a multi-disciplinary team that took responsibility for all aspects like concept building, feasibility, design, development, prototyping and final manufacture. The activities were not done sequentially. Some of the team members could start the design phase before the feasibility study work was completed. The team would do the development iteratively and would continue an iteration even though results from a concurrent activity required reconsideration of certain decisions. The team would incorporate the newly found information in the development during the next iteration. It might surprise software developers that agile development was proposed in manufacturing at a time (mid-80s) when waterfall model of software development was supposed to be the state of art in software engineering.

Peter DeGrace and Leslie Hulet Stahl used the term Scrum for this approach in their book “Wicked Problems, Righteous Solutions” in 1990.

Ken Schwaber used this approach in his company, Advanced Development Methods in the early 1990s. Jeff Sutherland also used this technique at Easel Corporation around the same time. Schwaber and Sutherland jointly presented Scrum at OOPSLA’95 in Austin, TX. Schwaber and Mike Beedle described the methodology in their book “Agile Software Development with SCRUM” in 2001.

ROLES

The central theme in Scrum roles is the story of the chicken and the pig. A chicken and a pig explore the possibility of opening a restaurant. The chicken suggests the name Ham and Eggs. The pig is not impressed because while the chicken would only be involved, the pig would have to be totally committed. The chicken can lay some eggs and take a walk while the pig has to lose its life to make Ham and Eggs a reality.

So there are pig and chicken roles in a software project. Those who play pig roles are the people who directly do the work and are most affected by a project failure and also by various project decisions. People who play chicken roles attend meetings and are around the project. People with chicken roles are not affected by project decisions to the same extent. Also, they are not that much affected by a project failure. In order to make a project a success, it is necessary to have an adequate number of people with pig roles and also to ensure that the people with pig roles are empowered enough so that they can do the work which is necessary for a project's success.

PIG ROLES

There are three pig roles in Scrum. These are Product Owner, Scrum Master and the Team.

PRODUCT OWNER

The Product Owner represents the customer. He or she has the complete understanding project's requirements in relation to customer's business operations and interests. The Product Owner adds project requirements in the form of user stories to the Product Backlog. He or she is able to prioritize the projects requirements as per the customer's business interests for implementation during sprints.

SCRUM MASTER

Scrum Master is the facilitator for the team. His or her job is to ensure that there are no obstacles in the way of the team. Scrum Master is not the leader of the team as the team is self-organizing. Scrum Master acts as a buffer between the team and the external world, helping the team in focusing on the job and following the Scrum process.

TEAM

The team is a multi-disciplinary group of professionals, who take care of all activities like design, coding, testing, documentation, etc. The typical team size is between 5 to 9 persons. The team is self-organizing and is able to take care of resource management for its work. The team does not have members as designer, programmer, tester, document writer, etc. It is a close-knit group of people who get together to do the job.

CHICKEN ROLES

The chicken roles are played by customers, vendors and managers. The customers are the people for whom the project is being done. The vendors supply various equipment and products necessary for the project. The managers create the infrastructure so that the work can be done. People playing chicken roles attend sprint review meetings.

MEETINGS

SPRINT PLANNING MEETING

A sprint starts with the Sprint Planning Meeting. The Product Owner, Scrum Master and the team all sit together and the Product Owner lets the team know the most important requirements from the customer's business point of view. The team goes through these requirements and selects the ones it can complete during the sprint. Since the team realizes the importance of the project in the context of customer's business, it selects the items to be done in the order prioritized by the Product Owner as far as possible. The selected requirements form the Sprint Backlog. The Sprint Planning Meeting should not take more than eight hours.

DAILY SCRUM

During a sprint, the team meets everyday for less than fifteen minutes at the same time and at the same location. This is called the Daily Scrum. The objective of Daily Scrum is for the team members to know what each person has done on the previous day and what everybody would do on the current day. The team members also tell whether there were any obstacles coming in the way in meeting the objectives for the current day. After the Daily Scrum, the Scrum Master would try to clear the impediments coming in team members way in achieving the day's objectives.

SCRUM OF SCRUMS

Big projects are normally broken into smaller manageable sub-projects and Scrum process is used in each sub-project separately. After the Daily Scrum of small sub-projects, one designated member from each team attends a meeting called the Scrum of Scrums. Here, the members exchange information on what had happened for his or her team on the previous day and what was planned for the current day and whether there were any obstacles in achieving objectives. The representative members discuss the interface and integration issues on a daily basis.

SPRINT REVIEW MEETING

At the end of a sprint, a review meeting is held where the work done and also the work not done is discussed. The requirements implemented from the Sprint Backlog are demonstrated to the customers. Requirements, which are partially done, are considered not done and are not demonstrated. The Sprint Review Meeting must not take more than four hours.

SPRINT RETROSPECTIVE

After the Sprint Review Meeting, the team gets together for a Sprint Retrospective. The team members reflect on the past sprint. The objective of Sprint Retrospective is to have a continuous software process improvement. The team members look at the positives from the sprint, the approaches that worked well. They also look at attempts that could have been better. The Sprint Retrospective must not take more than three hours.

ARTIFACTS

PRODUCT BACKLOG

The Product Backlog is a prioritized list of requirements for the project, listed in the order of decreasing importance to customer's business.

SPRINT BACKLOG

The Sprint Backlog is a prioritized list of requirements for the current sprint, listed in the order of decreasing importance to customer's business.

SPRINT BURN DOWN CHART

The Sprint Burn Down Chart gives the progress made during the sprint on a daily basis.

ANALYSIS

Scrum is a quantum leap for software process as compared to the traditional software process models like the waterfall model. In traditional process models, the progress is not visible during the first 25-50% of project’s duration. Scrum sprints have a clear output in terms of a software usable increment and the sprint duration is about four weeks. So every four weeks or so, there is visible, verifiable progress tuned to customer's business interests. Traditional process models are a kind of heavy; the customer's business interests may get suppressed by the weight of a traditional process. In traditional processes, a lot of time is spent if making documents and attending meetings, whose real contribution towards project progress is, at best, of dubious nature. Scrum artifacts are simple, easy to make and to the point. Meetings in Scrum always have a time limit. Moreover, meetings are held daily, attended by all concerned so that the work is not held up because of lack of communication. In fact, people are proactively looking for likely impediments and taking the necessary steps, so that progress is smooth as well as fast.

Requirements have been a prominent factor in software process models. People have tried in vain to have well understood frozen requirements right in first phase of a project. But in the last twenty five years or so, it has been an accepted fact that the requirements would change during the project execution, much to the relief of customers. It is, actually, not possible to be 100% perfect in communicating and understanding requirements[4]. But, still, the developers would like to have some kind of stability in requirements because a change in requirements results in a corresponding change in design and programming. Scrum handles the problem by mandating that the Sprint Backlog can not be changed during the course of a sprint. That is, the requirements for a sprint are frozen at the start of sprint. Of course, the product Backlog can change during the course of a project and the Product Owner can take care of changing requirements and business priorities by suitably configuring the scope of the next sprint.

FACTORS AFFECTING SUCCESS WITH THE SCRUM PROCESS

Scrum is not a silver bullet[5]; just officially designating it to be the software development process will not result in a project's success. The spirit is more important than the letter. The single most important factor affecting success is the attitude of the people involved in the project. Scrum calls for people to have an enlightened sense of leadership. It is said that the power to give up power is the greatest power an individual can possess. The Product Owner must display great capability for delegation of work and should be comfortable when the team selects a subset of requirements prioritized by him or her for the Sprint Backlog. The Product Owner must have a great understanding of customer's business and project's requirements. All the stakeholder's like customers, Scrum Master and the team must have confidence in the Product Owner. The Product Owner must be a person of high integrity; he or she must say and do the same thing. Although the Scrum literature says otherwise, the Scrum Master must be a real leader and not a manager in the traditional sense. The Scrum Master is more of a mentor who is able to groom people in an unintrusive way. The Scrum Master must also be an unselfish person who is happy to be out of limelight after making all arrangements for the project. Finally, the team members must have a great sense of working in a group. It is said that one and one make eleven and not just two and a cohesive, co-operating, communicating and non-competitive team can go a long way in ensuring a project's success.

REFERENCES

1. Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game, Harvard Business Review, January – February 1986.

2. Peter DeGrace and Leslie Hulet Stahl, Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms, ISBN: 978-0-13-590126-7, Prentice Hall, 1990.

3. Ken Schwaber and Mike Beedle, Agile Software Development with SCRUM, ISBN: 978-0-13-067634-4, Prentice Hall, 2001.

4. David Lorge Parnas and Paul C. Clements, A Rational Design Process: How and Why to fake It, IEEE Transactions on Software Engineering, Vol. SE-12, No. 2, February 1986.

5. Frederick P. Brooks, No Silver Bullet Essence and Accidents of Software Engineering, IEEE Computer, vol. 20, no. 4, pp. 10-19, Apr. 1987.