Milena Mastrasso

Today I want to share with you a little about Scrum.

Scrum is an agile product development methodology, note that I say product and not software. One of the most important of this methodology is that can be applied in any product development but this has been thought to software development.

Some approaches of this methodology have been used for years. In 1986 Hirotaka Takeuchi e Ikujiro Nonaka wanted to increment the process flexibility and agility of they business, they used transversals team (like rugby) where the whole team “tries to go to the distance as a unit, passing the ball back and forth”. During some years it has been modified. In 2001 Schwaber y Mike Beedle wrote the first book where this methodology was officially called Scrum. This book is “Agile Software development with Scrum”.

How does Scrum work?

Any development project starts with a necessity, this necessity is expressed as a list of requirements that we must fit to satisfy the client, also the client specify which of this requirements are more important and prioritize them. This list is known as product backlog. This product backlog could change during the project; the client could add, remove or reprioritize requirements. When all the requirements of the product backlog where delivered the product is finished.

Scrum’s process starts with a meeting called sprint planning; there a subset of requirements of the product backlog (the highest prioritized in the list) are committed to done in a small period of time called sprint. This subset is called sprint backlog.

Each sprint is a time-boxed period of time (between one and four weeks – depending on the project) where team commits to transform the items in the sprint backlog into an increment of the product; all the requirements which are included in the sprint backlog can not be changed; consider that the sprint backlog should be shipping at the end of the sprint, so IT MUST BE REALIST.

During the sprint, a daily scrum meeting (also known as stand up) is done; there each member of the team has to communicate how his work is going. This has the purpose to synchronize the whole team.

When the sprint ends two meetings take place the sprint review and the sprint retrospective. At the sprint review the teams shows what is done during the sprint, at the end of this meetings the sprint retrospective meeting is done where the team looks for improvements in the process.

After the sprint is complete, the iterative process should start again in the same way. With each sprint you have an increment of the final product. When the product backlog is completely delivered the Scrum process is finished.

The Scrum roles

Scrum determinates two classes of roles, the committed roles and the involved roles. An easy way to understand them is with the very well-known “pig and chicken story”

 The involved roles in Scrum (chickens) are all the people who are interested in the project, who have something to gain if the project is successful. Some of this people are final users, stakeholders, business manager, etc.

Who make the project successful? All the people who are committed to do that (the pigs). The pig roles of Scrum are the following:

• Product Owner:  Something interesting about Scrum is that includes the client in the development process. The product owner is the client, or a client interests representant inside the team. He is who defined the product backlog and prioritize each requirement.

• Scrum Master: he has the responsibility of ensure that the Scrum process is met. He also has to remove impediments to the ability of the team to deliver the sprint goal. 

• Team: is a group of people who has the responsibility of transform the product backlog into a product. The team must be made up with no more than 7 persons, normally between five and seven, with cross functionality. The most important of the Scrum team is that they are self-organized; they must be capable of creating its own dynamic orderliness. In scrum there is not project leader.

Scrum meetings

All the meetings are time-box. What that it means? Each one has a fixed duration, in this time they have to solve all the items.  

• Sprint planning (8 hours or less, depending of sprint duration). This meeting is divided in two phases of 4 hours. In the first part of the meeting all (pig and chickens) are invited. There, the Product Owner explains the highest requirements on the product backlog and the team decided which will be the goal of this sprint, and put this in the sprint backlog. In this part only the pigs can talk. The second part of the meeting is only for the Scrum team; in this time they decided how they will develop these requirements, and which one is the responsible of each task. 

• Daily Scrum meeting (15 minutes). This meeting has the purpose of synchronize the whole team; each member in the team has to know how the sprint goal is going. In this meeting each member of the team must answer three questions to communicate to the whole team how the goal goes:
  1. What have I done since last meeting?
  2. What are you planning to do by the next meeting?
  3. Do you have any problems preventing you from accomplishing your goal?

This meeting is also known as Stand Up because the team members stay stand up to maintain the quickness of the process. Something important is that all team members must be punctual. Some teams tend to put a fine (e.g. 1U$D) for assure this rule is met. Everyone is invited, but just pigs can talk.

• Sprint Review (4 hours or less, depending on the sprint duration). At the end of the sprint the sprint review take place. During this meeting the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.

•  Sprint Retrospective When a sprint ends and after the sprint review the whole team makes a close retrospective meeting where they reflect about the past sprint and each team member must answer two questions:
  1. What went well during the sprint?
  2. What could be improved in the next sprint?

Who use Scrum actually?

Large companies like Microsoft, Google, Yahoo and Verizon. And others no so large like Thoughworks.

Conclusion

Scrum works because is made based on common sense, and considering that software is made by people, human beens.

A book called “The agile software development: The people factor” say “agile development focuses on the talents and skills of individuals, as the process complies with the specific people and teams” the most important of this affirmation is that the process complies with people and not vice versa.

Which are the people factors that make an agile software development successful?

• Competence:  the process ability and knowledge can and must be taught to whole team.

• Common approach: whole team have a goal, this goal must be deliver a software increment to the client in the promised time.

• Collaboration:  all tasks will complete if the team members collaborate with each other, clients and managers.

• Ability to make decisions: team has autonomy and authority to make technical decisions.

• Problem solving skills: All change. Team has to accept that the problem that are solving now is not the problem that will be solving tomorrow. 

• Trust and mutual respect: a book called “Peopleware” says that the team must be match so strongly that the whole is grater than the sum of its parts.

• Organization:  team organizes itself, the process and the work plan. This enhances collaboration and increases the morale of the team.

This is one of the based of agile culture. 

Any agile software process is characterized by fulfilling three key items:

• Is difficult to predict which software requirements will survive and which of them will change.  Also is difficult to presage how can change the client priorities.

• Software design and construction are made in the same time. You never know how much design you need until it’s used by construction. 

• Analysis, Design and Construction are unpredictable. So the planning is very difficult.

An agile process must be adaptable. And a software process must adapt incrementally using the client feedback. Software increments have to be delivered in short periods to maintain a good rate with change.

We know that nobody is against the agility but there are a lot of people that question about things like “How can we built software that satisfy clients needs with a quality level that allow developers to extend and escalate to meet the client needs in the long-term?”.

There are a lot of agile methodologies that adopt and adapt software engineering good concepts. And is important to know that is possible to built quality software with agile.

I will be writing about agile and conventional software development methodologies to discover the strengths and weaknesses of each one.