Practical Scrum course day 1

Scrum Workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Practical Scrum 
Day I
Ilan Kirschenbaum
Agile coach
co-founder at Practical Agile
co-founder at Agile Practitioners
twitter: @kirschi_
email: ilan@practical-agile.com
blog: http://www.practical-agile.com/theblog

Connection before content

Parking lot

Physical examination

Agenda
• Introduction
• Overview & History
• Self managing &
Empirical approach
• Scrum overview
• The Scrum Master
• Transparency
• Deﬁnition of DONE
• Waste
• A Scrum team
• Reduce Waste
• Engineering practices

Requirements
Design
Implement
Test
Acceptance
Analysis
Deliver

Question

The waterfall development model originates in
the manufacturing and construction industries
The first description of waterfall
is a 1970 article by Winston W. Royce
Royce presented this model as an
example of a flawed, non-working model
"I believe in this concept, but the implementation
described above is risky and invites failure"
[Royce 1970]

QThe harder we plan and analyze in
the beginning, the less there’s
change in the project and the more
successful the project.
There is change always and responding to
it is vital. Uncertainty is best reduced by
learning from actual implementation

Wishful thinking

"Scrum is a team of eight individuals in Rugby.
Everyone in the pack acts together with everyone
else to move the ball down the ﬁeld in small
incremental steps. Teams work as tight, integrated
units with whole team focusing on a single goal."

Origins of Scrum
• Toyota’s lean concept.
• 1986 – The new, new software development game (Takeuchi &
Nonaka).
• Iterative & incremental development.
• Smalltalk engineering tools.
• Jeff Sutherland.
• Ken Schwaber.

Toyota’s Culture
• “Toyota sincerely believes that teams are more
effective and efﬁcient than the sum of individuals, and
that when they are given the skills and systems of
problem solving, the sky is the limit”  
 
[LikerHoseus 2008 – Toyota culture]

Origins of Agile
20011970
Agile
manifesto
Weinberg:
Psychology of  
computer programming
Rapid Application
Development
1980
1990
1995
DSDM
Extreme
Programming
Scrum
Gilb:
Principles of Software
Engineering
deMarco:
Peopleware
Royce: 
Managing the development
of large software systems
Cockburn:
Surviving OO projects
lean

Exercise

Agile Principles 1…6
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 a shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build project around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
6. The most efﬁcient and effective method of conveying information to and within
development team is face-to-face conversation.

Agile Principles 7…12
7. Working software is the primary measure for progress.
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indeﬁnitely.
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 reﬂects on how to become more effective, then
tunes and adjusts its behavior accordingly.

Scrum Misconceptions
• Scrum != Adhoc
• Disciplined & structured. Not sequential.
• Not an excuse to be sloppy!
• Scrum != A Set of practices.
• Don’t do agile, Be Agile, do Scrum.

Where Scrum Fits

Self Management

Predicted vs. Empirical
• Empirical means we base our actions on our own
experience not on someone else’s.
• Requires high level of transparency.
• Facing our real problems requires a high level of
integrity.
• It take courage to change our habits.

–Wolfgang Puck - chef
“The biggest difference between home cooks
and professional chefs is that home cooks don't
taste the dish often enough as they prepare it.
They just follow the recipe step-by-step, without
getting that feedback along the way. ”

• In our industry people got used to create
and use META solutions to problems.
• The problems we are facing have nothing
to do with technology, it is a people issue.
• In this land the basic assumption is that
there is no META solution, just an
empirical framework to allow inspect &
adapt cycles.
• This experience is frustrating for those
who are looking for predeﬁned processes
and ﬁnal answers.

Scrum

Scrum Principles
• Understanding that we cannot predict the future.
• One size does not ﬁt all.
• Constant improvement.
• Transparency & Visibility
• Team work
• Deliver business value fast (max. 30 days)
• Prioritizing – Industry statistics show: 65% of all features are rarelynever used.
• Empirical approach
• Fun !!!

Who’s Using Scrum?
• Intel
• Microsoft
• Yahoo
• Google
• Electronic Arts
• High Moon Studios
• Lockheed Martin
• Philips
• Siemens
• Capital One
• Boeing
• HP
• Clal Insurance
• Amdocs
• BMC Software
• sviva.gov.il
• Compedia
• Verint
• LivePerson
• Oracle
• eBay

Scrum is Used For…
• Commercial software
• In-house development
• Fixed-price projects
• Financial applications
• ISO 9001-certiﬁed applications
• Embedded systems
• 24x7 systems with 99.999% uptime requirements
• the Joint Strike Fighter
• Video game development
• FDA-approved, life-critical systems
• Satellite-control software
• Automobile R&D and Manufacturing
• Handheld software
• Mobile phones
• Network switching applications
• Some of the largest applications in use

Scrum Process Overview
Sprint
backlog
Working
software

Scrum Process Overview
•Product owner
•ScrumMaster
•Team
Roles
•Sprint planning
•Sprint retrospective
•Daily scrum meeting
•Sprint review
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts

The Product Owner
• Defines the features of the product
• Defines release dates and content
• Responsible for ROI
• Prioritizes feature according to value
• Can change features and priority  
once every predefined interval
• Decides what will be worked on in each iteration
• Accepts or rejects results

The Team
• Cross-functional, Typically 5-9 people
• Provide estimate for the tasks
• Decides how much it can do in each iteration
• Decides how to reach the sprint goal within the project’s boundaries
• Organizes itself and it’s work
• Presents results to the product owner

The Scrum Master

The Scrum Master
• Responsible for the scrum process
• Ensures that the team is functional and productive
• Protects the team
• Helps removing impediments
• He is standing at the nexus between:
• The product management that believes that any amount of work can be
done
• Developer’s that have the willingness to cut quality to support the
managements belief

The Scrum Master
• Help the product owner to understand how to maximize ROI within the
Scrum process
• Improve the life of the team by encouraging creativity and empowerment
• Help the team to improve the productivity
• Help the team to improve their engineering practices so that we have a
working product increment at the end of every sprint
Holds a management position but… 
is not a manager! – a facilitatorleader

The Scrum Master
• Is not a team leader or a project manager
• Team is self organizing
• Has no authority over the team or the product owner
• Asking questions / making observations
• Challenges the organization, a change agent
• A dead Scrum master  
is a useless Scrum Master

A different Management Style
• Traditional managers (Supervisors):
• Assign task and verify completion
• Micro manage to have the “illusion of control”
• Makes decisions for the team
• Limit the information & resources available to the team
• Traditional managers (Supervisors):  
DO NOT TRUST THE TEAM!
• This creates an environment which blocks innovation and encourages conformity
• The transition from manager to SM is extremely hard

Ask the Team!
• Replace suggestions with questions.
• What do you think we should do?
• What have you decided?
• What do you think this means?
• Who has any idea about….?
• Is this thing useful ?
• Replace opinions with observations.
• I noticed that <fact>, what shall we do?
• I have seen that <observation> is that important?

The Team is Wrong(?)
• Sometimes failing is the only way to learn
• Let the team fail
• Create an environment where it is ok to fail
• Failure ampliﬁes learning
• Where failure is allowed, innovation and experiments are encouraged
• Increases trust
• Are you sure you are right ?
• All of us are smarter than any of us

Ofer Eini’s Project(1)
• Ofer had realized tickets for popular soccer games are being sold
on EBay for as much as 100 times the price.
• Ofer decided to start a campaign for prohibition by law of reselling
tickets for proﬁt unless done through a specially dedicated system.
• The law was passed.
• This system is similar to EBay in principle, whenever a bid is over,
after the money had been transferred, the seller gets a check in the
mail with the price the ticket was sold minus 25% commission to the
union.

• The law will be affective within three month, Ofer scheduled a press conference for one
month from now and hopes to be able to show some functionality.
• In 3 month the system should be up:
• Allowing buyers and seller to register.
• Sellers can make tickets available at full price.
• Buyers can use a credit card to buy tickets, with the union as “middleman” getting
25% of the deal.
• Ofer is willing to invest funds in this product, you can do whatever is needed to have a
working system including, outsourcing, buying s/w modules or develop it.
• Ofer would like your assessment regarding the chances of achieving these targets.

• Functional requirements:
• Register and maintain an account of sellers with userid and
password for identification.
• Register and maintain an account of buyers with userid and
password for identification.
• Allow buyers to store credit card and shipping details.
• The accounts should include personal information such as
name, age, id number, email, address, birthday.
• Place tickets for auction, monitor the auction.
• Search feature by matchteamdate.
• Email notifications for events such as auction complete, auction
started, winninglosing in an auction.
• On line support for buyerssellers.
• Chat window.
• More Functional Requirements
• Transfer 25% of each transaction to the union’s account.
• Support promotions and advertising.
• Administration capabilities like delete users.
• Support updating latest news from the union.
• Non-functional requirements:
• Support 10,000 simultanious users.
• Response time under 300mSec.
• Secure financial activity according to standard
IEEE76.2s
• 95% up time.

• Development (facts)
• Microsoft platform
• .NET environment using SQL server DB
• Development is co-located.
• Developers are sitting in cubicles.
• The team that will be doing it is considered a good one.
• All team members like soccer (Maccabi fans)
• No automatic buildtest systems exist.
• You have a good QA team.
• Scrum will be used for this project.

• The union already invested $34m in passing the law and developing the
requirements.
• The law will be effective in three month.
• Ofer needs your team to build the system so it will at least allow people
to buy and sell tickets, otherwise the law will be useless.
• Money is not a problem.
• Ofer wants to know: Can your team build this skeletal system for him?
The unions marketing division wants to set the press conference to one
month, do you agree? What should he announce in this conference ?

Transparency
• We should stop taking risks for our customers without even
letting them know.
• We should share the risk
• maximize the chances of success.
• Create a common interest.
• We should really know the status of our projects, and share it
with the customer.

Transparency

Transparency
• It is important to know how is our project really coming along
• Avoid the 90% done syndrome
• It may mean facing hard facts. Early
• Unﬁnished work is waste
• We achieve this by:
• Having working s/w at the end of the iteration
• Tracking progress with burn down charts

Burndown ChartEffortremaining
0
25
50
75
100
Sprint
1 2 3 4 5 6 7 8

Gantt charts
Hierarchy
Low Quality
Core code
What Reduces Visibility?

Core Code
• AKA infrastructure or legacy code
• Most functionality depends on it
• Usually fragile, does not have a test harness
• only a few people really know it
• Changes are time consuming
• Becomes a bottleneck

Technical Debt
Time
Work
left
20
10 12 14 16 18

QYou can save time by “good-
enough” development.
Any technical debt will slow development
down and thus we don’t allow technical
debt to accumulate.

Deﬁnition of Done

Definition of Done
• Terms of satisfaction of the product owner
• Defined by the PO with the team
• Example:
• Design, code, unit tested, integrated
• Code coverage, system tests
• Refactored, deployable
• Done is a mirror reflecting the technical abilities of the team
• Items that are not Done “do not count”

Expanding the Deﬁnition of Done
Designed
Coded
analyzed
Unit tested
Perf. tested
Code coverage
Live
Deployable
Acc. tested
*This is just one example

Undone Work
Undone
Undone Undone
Undone
Stabilization  
sprint(s)
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Undone = risk
Undone = no visibility
Can we
release ?

Ball point game

Scrum Teams

What Makes a Team
• Common purpose, basic task, Interdependent
• Common goal
• We ALL are responsible for reaching the WHOLE goal
• Team members need each other to reach the goal
• Complementing technical and social skills
• The team is more than the sum of it’s members
• Trust
• Commonly agreed ways of working

Scrum Team
• Self organizing – Team manages itself
• Typically 5-9 people
• cross functional
• Preferably a feature team
• Decides how much it can do
• The team is responsible for the outcome

The Team is Responsible
• Biggest concept change is:
• The team decides what it can do, and how to do it
• The team is responsible for the quality
• The team is in charge of getting the work done, it decides how
• All of the other roles in the scrum are there to provide the team all of the
things it needs to get the job DONE in time
• If the job is successful, the team gets the credit
• If the job is not DONE, the team is responsible

Obstacles to Team Growth
• Strong leadership (c&c)
• Lack of authority and responsibility
• Fear of errors
• Lack of trust
• Fear of conﬂict
• Lack of boundaries

QDivision of work to specialized
teams (specification, design and
testing) is efficient
Cross-functional teams reduce the amount
of handovers and are more productive

Becoming a Team
Workgroup Team
Self Organized Team
Self Directed Team
Bruce Tuckman’s Model
of Team Development

Team Decision Making - Thumb Vote
• The rules are simple:
• Thumbs up – I agree completely, this is the best solution (how come I did not think of that
one…)
• Thumbs down – NO! This is a mistake, I veto this option.
• Thumbs in the middle – I don’t have any strong opinion. I’ll go with the team.
• Everyone can veto, it’s the team responsibility to reach a decision.
• If someone veto’s ask:
• How can we reﬁne this option so you will agree.
• Why do you think this is the wrong choice.
• Do you have another option

Team Decision Making - Dot Voting
• Used to choose from several available options.
• Can also be used to prioritize.
• Depending on the number of people and options, each person gets <x>
points.
• After the options are clear each person distributes his points between the
options as he likes.
• Can even place all votes on a single option.
• When everyone ﬁnished we have a clearer picture of which options the team
prefers.

Reduce Waste

Kaizen
• Mindset:
• My work is to do my work and to improve my work.
• Practice:
• Choose and practice techniques the team has agreed to try, until
they are well understood—that is, master standardized work
• Experiment until you ﬁnd a better way
• Repeat forever

Kaizen - Reduce Waste
• Value: The moments of action  
or thought creating the  
product that the customer is  
willing to pay for.
• Waste: All other moments or  
actions that do not add value  
but consume resources.
• value ratio = 
total-value-time / total-cycle-time

Types of Waste - TIMWOODS
Transport
Inventory
Motion
WaitingOver Processing
Over Production
Defects
Ignored 
Skills/Talent

QResource usage and cost
optimization is the key to increased
productivity
Concentrating on value stream
optimization, removing waste and
sustainable flow increases productivity

Waste I
• Overproduction
• features or services the customer doesn’t want
• large engineering documents, more detailed designs than can be quickly implemented
• duplication of data
• Waiting / delay
• for clariﬁcation
• Documents
• Approval
• Components
• other groups to ﬁnish something

Waste II
• Handoff, conveyance, moving
• Giving a speciﬁcation from an analyst to an engineer
• Giving a component to another group for testing
• Extra processing
• Relearning, lose of information.
• Forced conformance to centralized process checklists of
• Recreating something made

Waste III
• Partially done work – WIP DIP
• Designs documented but not built
• Things built but not integrated or tested
• Things tested but not delivered.
• Task switching
• Interruption
• Multitasking on 3 projects
• Partial allocation of a person to many projects

Waste IV
• Under-realizing people
• People only working to single speciality job
• Do people have the chance to change what they see is waste.
• Information scatter or loss
• Information spread across many separate documents
• Communication barriers such as walls between people, or
people in multiple locations.

Waste V
• Wishful thinking
• “We MUST follow the plan”
• “The estimate cannot increase; the effort estimate is
what we want it to be, not what it is now
proposed.”
• “We’re behind schedule, but we’ll make it up
later.”

Engineering Practices

Common Agile Engineering Practices
• Pair programming
• Refactoring
• TDD ATDD
• Continuous integration

Pair Programming
• A technique used to:
• Increase quality level (code review is built in).
• Increase knowledge sharing.
• Over time increase productivity.

Refactoring
• Refactoring ≠ Redesign.
• Refactoring is a form of editing, whose goal is to improve readability
while preserving meaning.
• Done as a series of steps, each step does a little.
• Does not ﬁx bugs.
• Most modern IDE’s have auto-refactoring tools.
• Refactoring is not a “standalone” task.

Test First - TDD/BDD
• TDD – Test driven development:
• A Design technique.
• Never write a line of code unless it ﬁxes a failing test.
• Red -> Green -> Refactor.
• ATDD – Acceptance TDD:
• A Requirements management technique.
• Requirements are written as functional tests.
• Usually with tools such as Cucumber / SpecFlow
• For every failing functional test run the TDD cycle.

Continuous Integration
• The system is always integrated (even multiple sites multiple components).
• CI systems can and should be aggregated.
• Requires check ins as often as possible.
• Usually done by a system that automatically:
• Generates a new build version.
• Runs all unit tests.
• Creates a deployable package.
• Installs it to production equipment.
• Runs all system tests.
• Run LSP tests.
• Publishes results.

Summary

Agenda
• Introduction
• Overview & History
• Self managing & Empirical approach
• Scrum overview
• The Scrum Master
• Transparency
• Deﬁnition of DONE
• Waste
• A Scrum team
• Eliminate Waste
• Engineering practices

References and Additional Sources
• 1970 - Managing the development of large software systems (aka Waterfall
Model, Winston Royce) http://leadinganswers.typepad.com/leading_answers/
ﬁles/original_waterfall_paper_winston_royce.pdf
• 1986 – The new, new software development game (Takeuchi & Nonaka) http://
ﬁles.meetup.com/1671339/The%20New%20New%20Product%20Development
%20Game.pdf
• LikerHoseus 2008 – The Toyota Way http://www.amazon.com/The-Toyota-
Way-Management-Manufacturer/dp/0071392319
• 2001 - Agile Manifesto http://agilemanifesto.org
• 1991-2013 - The Scrum Guide (Schwabber, Sutherland) https://www.scrum.org/
Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf

• 1971 - The Psychology of Computer Programming (G. Weinberg) http://
www.amazon.com/The-Psychology-Computer-Programming-Anniversary/dp/
0932633420
• 1987 - Peopleware, Productive Projects and Teams (T. De-Marco) http://
www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113
• 2003 - Lean Software Development: An Agile Toolkit (M&T Poppendieck)
http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/
0321150783
• 1999 - Extreme Programming Explained (K. Beck & C. Andres) http://
www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/
0321278658

• 2004 - Working Effectively with Legacy Code (M.
Feathers) http://www.amazon.com/Working-Effectively-
Legacy-Michael-Feathers/dp/0131177052
• 1975 - The Mythical Man-Month (F. P. Brooks) http://
www.amazon.com/Mythical-Man-Month-Software-
Engineering-Anniversary/dp/0201835959
• Promiscuous Pairing and Beginner’s Mind http://
user.it.uu.se/~carle/softcraft/notes/PromiscuousPairing.pdf

End of
day 1

Practical Scrum course day 1

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (19)

Semelhante a Practical Scrum course day 1

Semelhante a Practical Scrum course day 1 (20)

Mais de Ilan Kirschenbaum

Mais de Ilan Kirschenbaum (16)

Último

Último (15)

Practical Scrum course day 1