Scrum
-
date post
17-Sep-2014 -
Category
Technology
-
view
2 -
download
0
description
Transcript of Scrum
Scrum…getting software done
What is Scrum?
An Agile framework for completing complex projects– Simple concepts, difficult to implement
Practices
Principles
Values
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
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
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
SCRUMMY VALUES & PRINCIPLES
The ideas that guide a Scrum implementation
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/
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.
Scrum Values
• Commitment and Focus
• Openness
• Respect
• Courage
http://www.scrumalliance.org/pages/code_of_ethics
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
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
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
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
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.
SCRUMMY ROLES
The people in 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
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
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
The Team: A Lacrosse Story
The Team: A Lacrosse Story
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
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
Product Owner
• What makes a great
Product Owner?
http://agilescout.com/infographic-what-is-a-product-owner-
responsible-for/
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/
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/
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
ScrumMaster
• The goals
– Increase collaboration between the team and
product owner
– Remove impediments inside the organization
– Help the team reach their potential
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
ScrumMaster
• Some ScrumMaster traps
– Responsible for product delivery
ScrumMaster
• Some ScrumMaster traps
– Responsible for product delivery
– Becoming a manager
ScrumMaster
• Some ScrumMaster traps
– Responsible for product delivery
– Becoming a manager
– Making team decisions
SCRUMMY ARTIFACTS
The deliverables
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
Product Backlog
• Product
Owner owns
and prioritizes
• Anyone can
add to it
• If it isn’t in
the product
backlog, it
doesn’t exist
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
Product Backlog
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!
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/
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
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/
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 #.
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
Definition of Done
http://www.scrumalliance.org/articles/107-how-do-we-know-when-
we-are-done
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
Reporting Progress
• Task Board
– Electronic vs Wall
Reporting Progress
Burndown Burnup
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/
SCRUMMY CEREMONIES
Aka Meetings
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?
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
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
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
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
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
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
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
Where to now?