hot topic report divya

SCRUM & AGILE HOT TOPIC REPORT

HOT TOPIC REPORT BY DIVYA RAJASRI

1

SCRUM & AGILE

DIVYA RAJASRI TADI

MANAGEMENT INFORMATION SYSTEMS

USF

10.20.2014

ITERATIVE DEVELOPMENT SCRUM

PRINCIPLES

ITERATIVE

DEVELOPMENT

TIMELINES

COOPERATION SELF-

ORGANISATION


2

PROPOSAL

Why I want to take up this topic?

I have worked on an agile project from scratch during my tenure in

Accenture. I have an overall understanding of how agile practices are

implemented in a project. I was assigned user stories to work on and I

myself conducted the daily standup meetings and monthly retrospective

analysis.

Agile is a comparatively new method of software development and I am

passionate about gaining an in-depth knowledge of Agile practices.

What will my report cover?

In my report, I will start by giving an introduction about agile software

development and its values and principles. My main topic of concentration

would be Scrum. Under Scrum I will research on:

-History

-Roles

-Events

-Artifacts

-Terminology


3

TABLE OF CONTENTS

Introduction…………………………………………………………..1

Proposal………………………………………………………………2

Current State of Art..…………………………………………………4

History of Scrum...……………………………………………………5

Overview………………………………………………………………6

Agile Principles.………………………………………………………7

Agile Project Lifecycle ………………………………………………9

Scrum Roles…………………………………………………………11

Scrum………………………………………………………………...14

Product Owner Responsibilities…………………………………...19

Development Team Characteristics……………………………...20

Scrum Events……………………………………………………….24

Transparency of Artifacts.…………………………………………30

Definition of Done…………………………………………………..31


4

CURRENT STATE OF ART

Scrum is an agile schema which can be used in any project where agile is

being implemented. It is best suited to projects that embrace change

throughout the project lifecycle. It is very important for the project managers

to understand the concepts, principles and methodologies of agile and the

schema of scrum to be able to implement it in a project. Highly critical or

long term projects cannot support the agile framework. It is only the less

critical and short term projects that can adapt to these methodologies. Agile

is applied to projects that are collocated and where the team sizes are

small as compared to traditional waterfall methods where team sizes are

huge and teams are located at the same place. It is the duty of the scrum

master, the product owner and the project manager to carefully analyze

each and every aspect of the product that is going to be released and

based on that analysis decide whether agile and scrum can be

implemented successfully for the project or not. Many fortune 500

companies like Accenture, Infosys, TCS, and JPMorgan have implemented

agile projects which have given outstanding results.


5

HISTORY OF SCRUM

Scrum was first implemented in Easel Corporation by Jeff Sutherland along

with his two others group members. They were inspired by an article

named the new product development game which spoke about a rugby

game, where an entire group of people went ahead by passing the ball

among themselves. This is what gave them the idea of working in sprints or

iterations. And years later, Jeff Sutherland along with a group of fifteen

people came up with the Agile Manifesto. Post this the concept of user

stories was introduced by Mike Cohn. All these were put to practice in

many organizations and gained widespread acceptance. People who had

grown out of the traditional software development practices adopted agile

willingly and were impressed by the results it yielded. Now, the IT industry

has widely accepted agile and scrum and there are a huge number of firms

which are implementing agile projects. There are institutions giving Scrum

trainings and certifications to people to make them scrum masters or scrum

product owners. In a nutshell, scrum has been widely accepted as a

successful schema.


6

OVERVIEW

Scrum is a repetitive and cumulative agile schema used to manage

software product development.

Agile is a project management methodology in which results are achieved

by people with different functional expertise working towards a common

goal. Agile is a holistic used to express the multiple phases involved in a

software development process. Agile focuses mainly on delivering good

quality software in short intervals of time. Agile Manifesto was a conscious

effort by the idealists who wanted to bring in a new software development

methodology which was way different from the traditional ones.

Agile is based on speedy reactions to change and consistent advancement.

Agile is described by the division of assignments into short periods of work

and successive reassessment. Agile development was coined by

individuals who were tired of conventional methodologies to programming

advancement. With any agile improvement venture, there is significant

stress on engaging groups and community choice making.


7

1. Customer satisfaction which in case of Agile means timely delivery of

the functioning software.

2. Embrace changes in requirements even though they come in at the

later stages of the development, which gives the customers

competing edge over others.

3. Clients are happy to see a functioning software as compared to

detailed documentation. And if that can be delivered within short time

periods then the client is more than satisfied.

4. Developers and business analysts need to cooperate on every issue.

5. Frame the projects with enthusiastic individuals and create an

atmosphere which helps them give best results.

6. It is very essential to have face to face conversations in order to

share information.

7. A good quality software with low defects is the elementary for the

growth of the project.

AGILE PRINCIPLES


8

8. In Agile, it is important to work at a consistent pace throughout the

project for everyone involved to get the desired results within the

given time period.

9. Attention to technicality and design of the project improves agility.

Regular interactions with the stakeholders is required to make sure all

the requirements are being met.

10. Clarity is increasing the load of work which need not be done.

11. The team’s collective effort brings out the excellent

architectures, designs and requirements.

12. The team should meet up at frequent intervals and discuss

ways to achieve better performance and avoid bottlenecks.


9

AGILE

TEST

REVIEW

BUILD

DEPLOY

DESIGN

PLANNING

ANALYSIS

AGILE PROJECT LIFE CYCLE


10

Agile lifecycle like any other begins with the Planning phase.

PLANNING - In this phase the entire project is planned. The number of

iterations or sprints that the project will have, the duration of each iteration,

the number of stories that will be executed in every iteration, the number of

team members in each team, the skills required for delivering the product,

the time period within which the entire product will be delivered.

ANALYSIS – In this phase the stakeholders and the business analysts

analyze the requirements. All the requirements that the end product should

have are noted down. The product owner and stakeholders play the most

important role in listing all the requirements that are required for the

accomplishment of the project. Agile welcomes change but it is best to

have all the requirements listed at the initial stage itself so that all the

iterations are well planned and no sprint goals can be achieved within the

given timelines. The development team should also have an overall

understanding of the requirements and the project manager should recruit

people with required skill expertise to work on the project.


11

SCRUM

ROLES

SCRUM

MASTER

USERS

STAKEHOLDER

S

PRODUCT

OWNER

TEAM

MEMBERS

SCRUM ROLES


12

EFFECTIVE FACE TO FACE COMMUNICATION

Every agile team has a Product Owner who is a customer representative

and is selected by the stakeholders. The Product Owner interacts with the

development team on a regular basis and answers all their queries. After

the completion of every iteration, the product owner and all the

stakeholders sit together and figure out the progress and make plans for

maximizing the return on investment making sure it’s in line with the

customer needs and the organization goals.

Every agile project has an information radiator which is a large display

screen giving latest updates of status of the product. Every team’s status is

displayed by a build light indicator. This device is placed centrally in the

project so that every person can easily see it.

The story boards should always give the correct status of all the user

stories whether they have been started, are in progress or completed. Any

user stories not completed or partially completed in a sprint should be


13

marked and carried over to the next sprint. Any bottlenecks should be

highlighted and marked as highest priority.

SHORT EVALUATION CYCLE

Scrum Master is responsible for conducting daily stand up meetings for

team in the project. These meetings require every team member to address

his team and inform them about what he/she has worked on the previous

day, their action items for the current day and the roadblocks they faced

during their tasks.

FOCUS ON QUALITY

Various techniques like automation testing, code refactoring, continuous

integration, pair programming and test-driven development are a part of

agile process and ensure that the end product is of high quality and defect

free.


14

Scrum is a structure that allows people to find solutions to complicated

queries while delivering products of high quality. Scrum is:

Lightweight

Easy to understand

Tough to excel

Scrum is not a technique to build products, it is a skeleton which can make

use of multiple techniques. Scrum explicitly states the competency of the

product and the practices involved so that they can be worked upon and

improved. The Scrum framework has multiple Scrum Teams and

corresponding roles, events, artifacts and rules. Each element in the

framework has particular functionality and is important for Scrum’s

progress.

SCRUM


15

SCRUM THEORY

Scrum is based on experimental process control theory. Experimentation

assures that expertise comes with experience and being able to make

decisions depending on our knowledge base. Scrum has a repetitive,

cumulative approach to improvise certainty and reduce risk. Three pillars

uphold every implementation of empirical process control: transparency,

inspection, and adaptation.

TRANSPARENCY

Critical parts of the procedure must be noticeable to those in charge of the

conclusion. Transparency requires those viewpoints be characterized by a

typical standard so observers have a basic understanding of what is

constantly seen.

For instance:

A universal language referring to the procedure must be followed by all

members. Those performing the work and those accepting the work item

must make sure that they have the same definition of "Done".


16

INSPECTION

It is always advisable for the scrum users to go through the scrum archives

and then advance to the Sprint Goal to figure out unwanted changes. The

inspection should be done at specific intervals of time so that it does not

hinder the work. The best way to perform Inspections is to ask experts to

inspect all the work going on at a given point in time.

ADAPTATION

Inspections are conducted by experts who know the correct manner in

which the project should function so that desired results can be achieved.

In case during the inspection, it is pointed out that certain aspects of the

process are beyond the scope of the process and such aspects will affect

the end product which is not acceptable, then immediate changes should

be made to the aspects to reduce the risk.

There are four events prescribed by Scrum for inspection and adaptation

Events section of this document:

Sprint Planning


17

Daily Scrum

Sprint Review

Sprint Retrospective

SCRUM TEAM

A Scrum Team comprises of a Product Owner, the Development Team,

and a Scrum Master. Scrum Teams are mostly cross - functional. Self-

constructing teams figure out ways how best to achieve their work, instead

of being regulated by others outside the group. Cross-functional teams

have all the essential skills needed to fulfill the work without relying upon

others to complete their work. The team structure in scrum intended to

enhance adaptability, inventiveness, and profit. Scrum Teams deliver

results repetitively and cumulatively, in order to receive evaluation based

on which changes can made. Repetitive release of "Done" product

guarantees a conceivably valuable variant of working product is constantly

available.


18

PRODUCT OWNER

Product Owner is in charge of increasing the estimation of the product and

the work load of the Development Team. The way it is implemented may

differ broadly across associations, Scrum Teams, and people. Product

Backlog is single handedly maintained by the Product Owner.

The Product Owner is held accountable for all the above activities. The

Product Owner is an individual and not a team, though he may be a

representative of a team. Any variations in the product backlog items

priority have to be reported to the product owner. It is very important for a

company to appreciate the decisions of the product owner for him to

succeed. All the decisions taken by the product owner are visible in the

content and requesting of the product backlog. The development team has

the liberty to work any set of requirements and no one is allowed to

question their decision.


19

PRODUCT OWNER

Improvising the work done by development team and

ensuring they have a common understanding of

items in the product backlog

Requesting items in the Product Backlog to best accomplish objectives

and missions

Ensures product backlog is accessible by all and correctly conveys the next steps of Scrum

Team

Ensures product backlog explicitly mentions

items so that they are easy to understand

PRODUCT OWNER RESPONSIBILITIES


20

DEVELOPMENT TEAM

It is a group of experts who are responsible for delivering a functioning part

of the product at the end of each sprint. These teams are organized and

empowered by the organization to handle their own work. The collaborative

effort enhances the proficiency of the development team.

Are self-organizing and function independently. Even the Scrum Master cannot tell them how to convert the Product Backlog into

parts of working product that can be released in every sprint.

These teams have experts from all domains and hence are self sufficient

to create a part f the working product to be delivered. all the

members of the team are known as developers irrespective of the work

they do.

There are no sub-teams in the Development Team, even though

there are people working in different domains like testing, coding, etc...

The entire team is accountable for the success or failure of a part of the

product released in every sprint.

DEVELOPMENT TEAM

CHARACTERISTICS


21

SIZE OF DEVELOPMENT TEAM

Technically, Development Team size should be such that it can remain

agile and accomplish the required work at the end of each sprint. Lesser

than three people in a team leads to lesser skills and effects the

productivity. This in turn will affect the delivery at the end of each sprint.

And more than ten people in a team will lead to communication gaps and

coordination failures. It is advisable that a development team size from 4 to

9 members.

SCRUM MASTER

The main responsibility of the Scrum Master is to make sure that Scrum is

understood and implemented by the project. A Scrum Masters must ensure

that all the teams in the project are adhering to the rules and practices of

Scrum. The Scrum master interacts with everyone in the scrum team and

outside of it as well. He facilitates communication among all the people in

the project to improve the productivity of the project as a whole.


22

SCRUM MASTER SERVICES:

TO THE PRODUCT OWNER

Figuring out the right approach for efficient management of product

backlog

Explaining to the Scrum Team the requirement for explicit

mentioning of Product Backlog items

Conveying the importance of product planning in an experimental

environment

Helping out with scrum events as and when required

Making sure the Product Owner knows the best way to organize

items in the Product Backlog

Have profound knowledge of agile practices and implementing them

in the project.


23

TO THE DEVELOPMENT TEAM

Training the team to be self-sufficient and independent

Ensuring that the team comes up with the good products

Remove any roadblocks hindering the progress of the team

Helping out with scrum events as and when required

Training the team to adapt to environments where scrum is not been

implemented.

TO THE ORGANIZATION

Training and leading the company in adopting Scrum

Organizing scrum executions in the company

Facilitating team members and stakeholders comprehend and

implement Scrum

Bringing out the change that maximizes the profit of the Scrum Team

Brainstorming with other Scrum Masters to improve the efficiency of

the application of Scrum in an organization.


24

SCRUM EVENTS

There are defined events in Scrum to enhance the consistency. Every

event has a stipulated time within which it has to be completed.

After the commencement of a sprint its duration cannot be increased or

decreased. Rest of the events are terminated as when there goals are

accomplished. Every event in scrum is a chance to evaluate and change

something. Every event is created to make sure there is transparency and

investigation. Failure to incorporate any of these events amounts to losing

an opportunity to evaluate and make changes.

SPRINT

It is the heart of Scrum. It can be defined as a stipulated time period of a

month or so within which a fully functional deliverable part of the product is

created. There are no gaps in between two sprints. As soon as one sprint

gets over the next begins. Sprints involve daily scrum meetings, sprint

planning, retrospective analysis, sprint reviews.


25

DURING THE SPRINT:

Any changes that will or may affect the sprint goal are not made

There is never reduction in the quality of the product being delivered

The Product Owner and Development Team should clearly define the

scope of the project.

Every sprint is like a mini project at the end of which a working

product has to be delivered to the customer.

Every sprint should clearly state the product that is to be built, the

required design, the plan to execute the design and the features of

the end product.

It is very important to have a well-defined scope for a sprint because

if the scope is not defined then it is very difficult to come up with the

required end result within the given timelines. This will avoid risk and

any complexity in the sprint.

The end result in a sprint is quite predictable as there are regular

inspections and evaluations based on which changes are

incorporated in to the sprint.


26

The best part about a sprint is that if the end product is not as desired

then the effort and money lost is only for that period of one month or

so which is way less compared to the traditional methods where the

loss is enormous.

CANCELLATION OF A SPRINT

The product owner is the only person who has the authority to cancel a

sprint even though he/she does it due to pressure from the scrum master,

development or the stakeholders. A sprint can be cancelled before its time

period is over. If the goal that a sprint is trying to achieve becomes

outdated, then it is be cancelled. This may occur if the organization decides

to take up a new technology in the market. As the time period of a sprint is

four weeks, cancelling it does not make sense. On cancellation of a sprint,

all the completed items in the product backlog are assessed. All the

incomplete items are reviewed and put back in the product backlog. Very

rarely a sprint is cancelled as it affects the morale of the scrum team. And

as there are no gaps between sprints, the next sprint is immediately


27

commenced and if the team is not enthusiastic about it the delivery is

affected. So, it is very essential to analyze whether a sprint should be

cancelled or not as it has unwanted consequences.

PLANNING A SPRINT

Sprint planning is done by the scrum team. After a brainstorming session of

not more than 8 hours, the scrum team comes up with a plan for a four

week long sprint. Planning is supervised by the Scrum Master who makes

sure that the session does not exceed the given time limit and all the

people attending it understand the importance and contribute actively. The

sprint planning session basically focusses on what work need to be done to

deliver a part of the product at the end of the sprint and what additional

features can be included in the product that is being delivered.

WHAT ALL CAN BE ESTABLISHED IN ONE SPRINT

Every sprint has a goal that is to be accomplished before its completion. It

is the responsibility of the Product owner to clearly state the goal of the

sprint and the product backlog items that if completed will achieve the


28

sprint goal. The development team selects a set of items from the product

backlog and can estimate what can be accomplished in the current sprint

as well as the next sprints. Scrum team acknowledges all the work that is

supposed to be done in the current sprint. Sprint work plans are made

based on the product backlog, the strength of the development team and

its prior achievements. Once the development team is done listing the

items it is going to deliver at the end of the current sprint, the scrum team

comes up with a sprint goal. The sprint goal helps the development team

focus on what is to be achieved as an end result. Sprint goal is like a suite

of all the criteria that have to be met in order to achieve it. It is necessary to

have a sprint goal as it explicitly states what is the desired end result at the

end of four weeks and so that no time is wasted working on anything that is

beyond the scope of the defined goal.

HOW TO GET THINGS GOING IN A SPRINT

After defining the sprint goal and selecting the items from product backlog

for implementation in the current sprint, development team starts to work

on building the functionality of the end product. The items from product


29

backlog along with their delivery plan define what is called the sprint

backlog. While working on the sprint, if the development team realizes that

it has more work or less work then it reviews the items from the product

backlog along with the product owner. Other team members are also asked

to give their opinion on this as it affects the end result that will be delivered.

Technical help and domain advice is sort in these cases from the entire

project. Once the sprint planning is done, the development team is

responsible for communicating all the work that is to be done within the

sprint and the steps to accomplish the sprint goal to the scrum master and

the product owner.

TRANSPARENCY OF ARTIFACTS:

Transparency of archived material is an important aspect on which scrum

relies heavily. Scrum does not involve too much documentation but

stresses on the correct amount of documentation that is required for

traceability. A requirement traceability matrix is maintained in agile projects

which maps all the user stories to the corresponding sprints and the test

cases. It is the duty of the scrum master to ensure that all the artifacts are


30

visible and accessible by all the team members. All the changes

incorporated at a later stage have been updated in the documentation.

Development team should make sure that all the test cases and scenarios

for a particular sprint are self-explanatory and are properly documented if

required. Any flaws in transparency can be identified by the scrum master

through frequent inspection and acted upon. It becomes easier to trace any

changes or defects in the end product that is delivered to the customer if

there is complete transparency of artifacts and proper documentation in

place.

DEFINITION OF DONE

It is important that all the team members have a common understanding of

the term “DONE”.

All the listed to do items in the code are completed

There are comments in the code and the latest version of the code is

checked in by the programmers

The code adheres to all the coding standards and is peer reviewed.


31

The build is defect free and all the unit tests are yielding positive

results.

Deployed to system test environment and passed system tests

All the build, deployment and configuration changes have been

implemented and documented.

The documentation is up to date.

All the tasks are closed.

There are no unsolved roadblocks which might come up in the code

at a later point of time.

This definition of done should be explicit to all the people working on a

project. At the end of each sprint, a part of the software product is delivered

which adheres to the definition of DONE and this should be true for all the

sprint releases.


32

RECOMMENDATIONS TO MANAGER

Agile methodologies are widely being used in the IT industry. There

repetitive and cumulative nature has been beneficial to many projects. The

concept of delivering a part of the end product at regular intervals has

received appreciation from the customers as they get to see a fully

functional part of the product and are assured that the end product will also

be as good. The responsibility of the project manager is to ensure that all

the agile principles are being implemented in the project. All the scrum

roles are explicit to the scrum master, development team and the product

owner. The project has the required logistics like the information radiator,

story board, burn down charts, etc… it is very important that the team sizes

are small, team members collaborate with each other, there should be a

willingness to accept change, all the team members have an expertise in

one or the other domain and the documentation and requirement

traceability matrix are updated with all the incorporated changes.


33

References –

http://en.wikipedia.org/wiki/Agile_software_development

http://www.agilesherpa.org/intro_to_agile/what_is_agile_development/

http://agilemanifesto.org/principles.html

https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scru

m-Guide.pdf

https://www.scrumalliance.org/why-scrum/resources

http://www.scrumguides.org/

http://scrummethodology.com/

http://www.scrum-

institute.org/Introduction_to_Scrum_A_Real_World_Example.php

http://www.allaboutagile.com/definition-of-done-10-point-

checklist/#sthash.WGpiUJUr.dpuf



http://en.wikipedia.org/wiki/Agile_software_development



https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf

https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf




http://www.scrum-institute.org/Introduction_to_Scrum_A_Real_World_Example.php

http://www.scrum-institute.org/Introduction_to_Scrum_A_Real_World_Example.php

http://www.allaboutagile.com/definition-of-done-10-point-checklist/%23sthash.WGpiUJUr.dpuf

http://www.allaboutagile.com/definition-of-done-10-point-checklist/%23sthash.WGpiUJUr.dpuf

Divya%20HOT%20TOPIC%20REPORT%20(1).docx



34

https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scru

m-Guide.pdf




http://www.scrum-

institute.org/Introduction_to_Scrum_A_Real_World_Example.php

http://www.allaboutagile.com/definition-of-done-10-point-

checklist/#sthash.WGpiUJUr.dpuf









