Scrum

57
Scrum…getting software done
  • date post

    17-Sep-2014
  • Category

    Technology

  • view

    2
  • download

    0

description

A presentation of Scrum basics.

Transcript of Scrum

Page 1: Scrum

Scrum…getting software done

Page 2: Scrum

What is Scrum?

An Agile framework for completing complex projects– Simple concepts, difficult to implement

Practices

Principles

Values

Page 3: Scrum

How Scrum Helps

IT systems + abstract ideas + requirements + PEOPLE = craziness!

– Many pieces of unreliable and complex systems

– No tangible products or measurable designs

– Requirements….

• Not fully known

• Frequently changing

• Hard to articulate

• Many stakeholders

– People…we’re just nutsR

eq

uir

em

en

ts

Technology

Graph: http://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm

Page 4: Scrum

How Scrum Helps

• Defined processes, like waterfall, don’t handle complexity well

Traditionally we:– Define the requirements up front

– Break down the work

– Estimate effort/duration

– Plan out the work

– And then we begin to build

– But don’t change the plan!

This • then

That • then

This • then

Page 5: Scrum

How Scrum Helps

• Empirical processes account for complexity

– Visibility: aspects of the process that affect the outcome must be visible, and correct.

– Inspection: aspects of the process must be inspected frequently enough to detect unacceptable variance

– Adaptation: if through inspection, it is found there is unacceptable variance then the process must be changed as quickly as possible to minimize further deviation

• Scrum uses a short iterative cycle to verify everything is going like we had hoped

Page 6: Scrum

SCRUMMY VALUES & PRINCIPLES

The ideas that guide a Scrum implementation

Page 7: Scrum

Agile Values

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.

http://agilemanifesto.org/

Page 8: Scrum

Agile Principles1. Our highest priority is to satisfy the

customer through early and continuous

delivery of valuable software.

2. Welcome changing requirements, even

late in development. Agile processes harness

change for the customer's competitive

advantage.

3. Deliver working software frequently, from

a couple of weeks to a couple of months,

with a preference to the shorter timescale.

4. Business people and developers must

work together daily throughout the project.

5. Build projects around motivated

individuals. Give them the environment and

support they need, and trust them to get the

job done.

6. The most efficient and effective method of

conveying information to and within a

development team is face-to-face

conversation.

7. Working software is the primary measure

of progress.

8. Agile processes promote sustainable

development. The sponsors, developers, and

users should be able to maintain a constant

pace indefinitely.

9. Continuous attention to technical

excellence and good design enhances agility.

10. Simplicity--the art of maximizing the

amount of work not done--is essential.

11. The best architectures, requirements, and

designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on

how to become more effective, then tunes

and adjusts its behavior accordingly.

Page 9: Scrum

Scrum Values

• Commitment and Focus

• Openness

• Respect

• Courage

http://www.scrumalliance.org/pages/code_of_ethics

Page 10: Scrum

Commitment and Focus

• Commitment is our willingness to dedicate ourselves to a goal and to do our best to meet that goal.

• Focus means that we concentrate on and are answerable for doing the things that we have committed ourselves to do, rather than allowing ourselves to become distracted or diverted.

As practitioners in the global Scrum community:– We take responsibility for and fulfill the commitments that we undertake – we do what we say

we will do.

– We make decisions and take actions based on the best interests of society, public safety, and the environment.

– When we make errors or omissions, we take ownership and make corrections promptly. When we discover errors or omissions caused by others, we promptly communicate them to the appropriate individual or body. We accept accountability for any issues resulting from our errors or omissions and any resulting consequences.

– We protect proprietary or confidential information that has been entrusted to us.

– We proactively and fully disclose any real or potential conflicts of interest to the appropriate parties.

http://www.scrumalliance.org/pages/code_of_ethics

Page 11: Scrum

Openness

• Openness: affording unobstructed entrance and exit; not shut or closed.; Carried

on in full view;*

As practitioners in the global Scrum community:

– We earnestly seek to understand the truth.

– We strive to create an environment in which others feel safe to tell the truth.

– We are truthful in our communications and in our conduct.

– We demonstrate transparency in our decision-making process.

– We provide accurate information in a highly visible and timely manner.

– We make commitments and promises, implied or explicit, in good faith.

– We do not engage in or condone behavior that is designed to deceive others.

http://www.scrumalliance.org/pages/code_of_ethics * http://www.thefreedictionary.com/openness

Page 12: Scrum

Respect

• Respect means that we show a high regard for ourselves, others, and the resources entrusted to us. Resources entrusted to us may include people, money, reputation, the safety of others, and natural or environmental resources.

• An environment of respect engenders trust, confidence, and performance excellence by fostering mutual cooperation and collaboration — an environment where diverse perspectives and views are encouraged and valued.

As practitioners in the global Scrum community:

– We respect the rights and beliefs of others.

– We listen to others’ points of view, seeking to understand them.

– We approach directly those persons with whom we have a conflict or disagreement.

– We conduct ourselves in a professional manner, even when it is not reciprocated.

– We negotiate in good faith.

– We do not exercise the power of our expertise or position to influence inappropriately the decisions or actions of others in order to benefit personally at their expense.

– We do not discriminate against others based on, but not limited to, gender, race, age, religion, disability, nationality, or sexual orientation.

– We do not engage in any illegal behavior.

http://www.scrumalliance.org/pages/code_of_ethics

Page 13: Scrum

Courage

• Courage means that we have the daring to do the best that we can and the

endurance not to give up. We have the determination and resolution to take

ownership of the decisions we make or fail to make, the actions we take or fail to

take, and the consequences that result.

As practitioners in the global Scrum community:

– We share bad news even when it may be poorly received.

– We avoid burying information or shifting blame to others when outcomes are negative.

– We avoid taking credit for the achievements of others when outcomes are positive.

– We would rather say, “no,” than make false promises.

– We accept the possibility of failure but also know that we can learn from failure and

apply those learnings to our next attempt.

– We acknowledge that change is inevitable, that change leads to growth, and that growth

guides us toward improvement.

– We admit when we need help and we ask for help.

http://www.scrumalliance.org/pages/code_of_ethics

Page 14: Scrum

How can we better adopt these values

and principles?• Individuals and

interactions over processes

and tools

• Working software over

comprehensive documentation

• Customer

collaboration over contract

negotiation

• Responding to

change over following a plan

• Commitment and Focus

• Openness

• Respect

• Courage

1. Our highest priority is to satisfy the customer through early

and continuous delivery of valuable software.

2. Welcome changing requirements, even late in

development. Agile processes harness change for the

customer's competitive advantage.

3. Deliver working software frequently, from a couple of

weeks to a couple of months, with a preference to the shorter

timescale.

4. Business people and developers must work together daily

throughout the project.

5. Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the

job done.

6. The most efficient and effective method of conveying

information to and within a development team is face-to-face

conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a

constant pace indefinitely.

9. Continuous attention to technical excellence and good

design enhances agility.

10. Simplicity--the art of maximizing the amount of work not

done--is essential.

11. The best architectures, requirements, and designs emerge

from self-organizing teams.

12. At regular intervals, the team reflects on how to become

more effective, then tunes and adjusts its behavior

accordingly.

Page 15: Scrum

SCRUMMY ROLES

The people in Scrum

Page 16: Scrum

The people in Scrum

• The Team

– Self-organizes to get the work done

• Product Owner

– Responsible for the business value of the project

• ScrumMaster

– Ensures the team is functional and productive

Page 17: Scrum

The Team• Is cross-functional

• Is right-sized (the ideal size is seven -- plus/minus two -- members)

• Selects the sprint goal and specifies work results

• Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal

• Organizes itself and its work

• Demos work results to the product owner and any other interested parties.

http://www.scrumalliance.org/pages/scrum_roles

Page 18: Scrum

The Team

• Cross Functional– Different specialties

• Developers

• Testers

• Tech writers

• Usability engineers

• Architects

• Designers

• Analysts

• Any one needed to complete the sprint!

– Fuzzy role boundaries

– Common goal

– Each member is held accountable to reach the goal

Page 19: Scrum

The Team: A Lacrosse Story

Page 20: Scrum

The Team: A Lacrosse Story

Page 21: Scrum

The Team

• Self-organizing

– Pulls in work

– Plans their own work

– Cooperative development

and decision making

– Authority to do what is

needed to reach the sprint

goal

– Self inspecting

Page 22: Scrum

Product Owner

• Decides what will be built and in which order

• Defines the features of the product or desired outcome of the project

• Chooses release date and content

• Ensures profitability(ROI)

• Prioritizes features and outcomes according to market value

• Adjusts features/outcomes and priority as needed

• Accepts or rejects work results

• Facilitates sprint planning ceremony

• "single wringable neck"

http://www.scrumalliance.org/pages/scrum_roles

Page 23: Scrum

Product Owner

• What makes a great

Product Owner?

http://agilescout.com/infographic-what-is-a-product-owner-

responsible-for/

Page 24: Scrum

Product Owner

• What makes a great

Product Owner?

– Visionary

– Open to negotiation

– Available within reason

– Informed about product

– Communicative

http://agilescout.com/top-10-essential-product-owner-characteristics/

Page 25: Scrum

Product Owner

• Answers 4 questions:

1. Why are we building

this, and what problem

are we solving?

2. Who is it for: Primary

Audience? Secondary?

3. What is important to

that audience?

4. What are the

constraints?

http://agilescout.com/agile-product-management-product-owners-

are-key/

Page 26: Scrum

ScrumMaster

• Ensures that the team is fully functional and productive

• Enables close cooperation across all roles and functions

• Removes barriers

• Shields the team from external interferences

• Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning

• Facilitates the daily scrums

http://www.scrumalliance.org/pages/scrum_roles

Page 27: Scrum

ScrumMaster

• The goals

– Increase collaboration between the team and

product owner

– Remove impediments inside the organization

– Help the team reach their potential

Page 28: Scrum

ScrumMaster

• The goals

– Increase collaboration between the team and product owner

– Remove impediments inside the organization

– Help the team reach their potential

• The obstacles

– Waterfall development

– Command and control

– Breaking down barriers between departments

– Skeletons in the closet

Page 29: Scrum

ScrumMaster

• Some ScrumMaster traps

– Responsible for product delivery

Page 30: Scrum

ScrumMaster

• Some ScrumMaster traps

– Responsible for product delivery

– Becoming a manager

Page 31: Scrum

ScrumMaster

• Some ScrumMaster traps

– Responsible for product delivery

– Becoming a manager

– Making team decisions

Page 32: Scrum

SCRUMMY ARTIFACTS

The deliverables

Page 33: Scrum

Artifacts

• Product Backlog – list of items to be done

• Sprint Backlog – items to be done in this sprint

• Product Increment – shippable product

Also, the burn down charts

Page 34: Scrum

Product Backlog

• Product

Owner owns

and prioritizes

• Anyone can

add to it

• If it isn’t in

the product

backlog, it

doesn’t exist

Page 35: Scrum

Product Backlog

• Is software ever “correct” the first release?

– More requirements will emerge as the product is

built…it’s what is expected and wanted

– Customer feedback and changes are reflected in

backlog

• Invest time and money only in high-priority

features

– 80% of value from 20% of features

Page 36: Scrum

Product Backlog

Page 37: Scrum

Product Backlog Items

• Just enough detail to complete the item in one sprint

– Might contain

• business processes

• Data needed

• Designs

• Items further in the future can be larger and more vague

• Item descriptions should be as brief as possible

– User stories!

Page 38: Scrum

User Stories

• Three C’s– Card : User stories are written on cards. The card does

not contain all the information that makes up the requirement.

– Conversation: The requirement itself is communicated from customer to programmers through conversation: an exchange of thoughts, opinions, and feelings. Usually over a period of time.

– Confirmation: At the beginning of the iteration, the customer communicates to the programmers what she wants, by telling them how she will confirm that they’ve done what is needed.

http://xprogramming.com/articles/expcardconversationconfirmation/

Page 39: Scrum

User Stories

• Describes a feature

from a user’s

perspective

As a user I want to filter my search

results by order # so that I don’t

have to scroll through all the

results

Page 40: Scrum

User Stories

• I ndependent – schedule and implement in any order

• N egotiable - co-created by the customer and programmer

• V aluable - valuable to the customer

• E stimable - can be estimated

• S mall – easy to know what's in the story's scope

• T estable - I understand what I want well enough that

I could write a test for it

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Page 41: Scrum

User Stories

• Acceptance Criteria

– Product owner defines acceptance criteria before

sprint planning

– During sprint planning acceptance criteria are

discussed and negotiated

– Should be short and easy to understand

As a user I want to filter my search

results by order # so that I don’t

have to scroll through all the

results

Acceptance Criteria:

Entering a order # should only show

orders with that order #.

Page 42: Scrum

When is a Story Done?

• Definition of Done

– Applies to all stories

– States the deliverables for each story (code, etc)

DoD

Helps to build the thing right

(quality)

Acceptance Criteria

Helps to build the right thing

(functionality)vs

Page 43: Scrum

Definition of Done

http://www.scrumalliance.org/articles/107-how-do-we-know-when-

we-are-done

Page 44: Scrum

Sprint Backlog

• The team commits to a certain number of

stories during Sprint Planning

• Each Story also contains technical tasks to

build it

http://www.mountaingoatsoftware.com/scrum/sprint-backlog

Page 45: Scrum

Reporting Progress

• Task Board

– Electronic vs Wall

Page 46: Scrum

Reporting Progress

Burndown Burnup

Page 47: Scrum

Product Increment

• The product with the new functionality built during the sprint

• New features are “done”

• Potentially shippable“Scrum requires Teams to build an increment of product

functionality every Sprint. This increment must be potentially

shippable...the increment must be a complete slice of the product. It

must be “done.” Each increment should be additive to all prior

increments and thoroughly tested, ensuring that all increments

work together.” Scrum Guide: http://www.scrum.org/scrumguideenglish/

Page 48: Scrum

SCRUMMY CEREMONIES

Aka Meetings

Page 49: Scrum

Ceremonies

• Sprint Planning– Plan the next iteration

• Daily Scrum– Collaborate with team members

• Sprint Reviews– Show off what was built

• Sprint Retrospectives– What went well? what did not go well?

Page 50: Scrum

Sprint Planning

• Who Participates?– The team

– Product Owner

– Customers and Management

• Inputs– Product Backlog

– Team capabilities

– Business Conditions

– Definition of Done

– Technology

– Current Product

– Velocity

Sprint Backlog

• Detailed tasks

• Priorities

• Detailed Estimates

Page 51: Scrum

Daily Scrum

• Who participates?

– The team

• Each team member answers 3 questions

– What did you do yesterday?

– What are you doing today?

– What is getting in your way?

• It is not a status report to anyone

• It is a way to collaborate with team members

• Timeboxed to 15 minutes

Page 52: Scrum

Scrum of Scrums

• Some suggestions from Mike Cohn– A designated rep from each team attends

– Timeboxed 15min for daily meetings• Leave time after for resolving problems

– Problems that arise should be addressed and fixed

– Suggested Questions:1. What has your team done since we last met?

2. What will your team do before we meet again?

3. Is anything slowing your team down or getting in their way?

4. Are you about to put something in another team’s way?

– No names are used in reporting…speeds things up

http://www.scrumalliance.org/articles/46-advice-on-conducting-the-

scrum-of-scrums-meeting

Page 53: Scrum

Sprint Review

• Who participates?

– The team

– ScrumMaster

– Product Owner, Customers

– Stakeholders and other interested parties

• Team presents what it is has accomplished

– Demo or fair style

• Verify “done” with customers/product owner

• Don’t hide undone work

Page 54: Scrum

Sprint Review w/ Multiple Projects and

Teams

• Demo format

– Planned agenda so customers can come and go to

see their product

• Fair format

– Teams set up booths that customers can interact

with the product

Page 55: Scrum

Sprint Retrospective

• Who participates?

– The team

– The ScrumMaster facilitates

• An open environment is needed

– Means no managers or product owners

• What went well, what didn’t

– Improvements prioritized

– Team devises solutions

Page 56: Scrum

Review

• Agile and Scrum Values and Principles– Individuals and interactions over processes and tools, Completed

functionality over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan

– Commitment, Focus, Openness, Respect, Courage

• 3 Roles

– Product Owner, Scrum Master, The Team

• 4 Ceremonies

– Sprint planning, Daily scrum, Sprint review, Sprint retrospective

• 3 Artifacts

– Product backlog, Spring backlog, Product increment

Page 57: Scrum

Where to now?