SCRUM And kanban

MSIN 0019
Introduction to Software Engineering
Niall Roche
Faculty of Engineering
[email protected]
Extreme Programming (Beck 1999)
▪ A disciplined, iterative, agile approach to software systems
development.
▪ Some key XP practices
— Test-driven development
— The tests are the system specification
— Releases are as small and frequent as possible
— Pair programming
— Collective code ownership
— Coding standards
— Continuous integration
— Frequent refactoring of code
— Onsite customer is a member of the development team
— 40-hour work week

2
When to use XP
▪ XP works best when
— Requirements are changing rapidly
— Projects are high-risk with new challenges
— Development can be carried out by small
groups (2-10 developers)
— Automated testing is possible
— Direct customer involvement is possible

Remember that the process must be matched to the problem!

3
Scrum
▪ A widely used iterative/incremental method
used with agile development.
▪ The following slides describing Scrum were
created by Mike Cohn of Mountain Goat
Software.
— Creative Commons License
▪ Widely used by the Open Source movement

4
Scrum in 100 words
• Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest
time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize
to determine the best way to deliver the highest
priority features.
• Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint.
Scrum origins
▪ Jeff Sutherland
— Initial scrums at Easel Corp in 1993
— IDX and 500+ people doing Scrum
▪ Ken Schwaber
— ADM
— Scrum presented at OOPSLA 96 with Sutherland
— Author of three books on Scrum
▪ Mike Beedle
— Scrum patterns in PLOPD4
▪ Ken Schwaber and Mike Cohn
— Co-founded Scrum Alliance in 2002
Scrum is used by a range of companies:
• Microsoft • Nielsen Media
• Yahoo • First American Real Estate
• Google • BMC Software
• Electronic Arts • Ipswitch
• IBM • John Deere
• Lockheed Martin • Lexis Nexis
• Philips • Sabre
• Siemens • Salesforce.com
• Nokia • Time Warner
• Capital One • Turner Broadcasting
• BBC • Oce
• Intuit • Many Many more….
Scrum has been used for:
▪ Commercial software • Video game development
▪ In-house development • FDA-approved, life-critical
systems
▪ Contract development
▪ Fixed-price projects
• Satellite-control software

▪ Financial applications
• Websites

▪ ISO 9001-certified
• Handheld software
applications • Mobile phones
▪ Embedded systems • Network switching applications
▪ 24x7 systems with 99.999% • ISV applications
uptime requirements
• Some of the largest applications
▪ the Joint Strike Fighter in use
Characteristics
▪ Self-organizing teams
▪ Product progresses in a series of 2-4 week
“sprints”
▪ Requirements are captured as items in a list of
“product backlog”
▪ No specific engineering practices prescribed
▪ Uses generative rules to create an agile
environment for delivering projects
▪ One of the “agile processes”
The Agile Manifesto–a
statement of values

Individuals and
over Process and tools
interactions

Comprehensive
Working software over
documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

Source: www.agilemanifesto.org
Scrum
24 hours

Sprint
2-4 weeks
Sprint goal
Return
Sprint Potentially shippable
Return
Cancel backlog product increment
Gift
Coupons
wrap
Gift
Cancel
wrap Coupons
Product
backlog
Putting it all together

Image available at
www.mountaingoatsoftware.com/scrum
Sprints

▪ Scrum projects make progress in a series of

“sprints”
— Analogous to Extreme Programming
iterations
▪ Typical duration is 2–4 weeks or a calendar
month at most
▪ A constant duration leads to a better rhythm
▪ Product is designed, coded, and tested
during the sprint
Sequential vs.
overlapping development
Requirements Design Code Test

Rather than doing all of

one thing at a time...
...Scrum teams do a little
of everything all the time

Source: “The New New Product Development Game” by Takeuchi and

Nonaka. Harvard Business Review, January 1986.
No changes
during a sprint
Change

▪ Plan sprint durations around how long you

can commit to keeping change out of the
sprint
Scrum framework
Roles
• Product owner
• ScrumMaster
• Team
Ceremonies
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Artifacts
• Product backlog
• Sprint backlog
• Burndown charts
Scrum framework
Roles
• Product owner
• ScrumMaster
• Team
Ceremonies
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Artifacts
• Product backlog
• Sprint backlog
• Burndown charts
Product owner

▪ Define the features of the product

▪ Decide on release date and content
▪ Be responsible for the profitability of the
product (ROI)
▪ Prioritize features according to market value
▪ Adjust features and priority every iteration, as
needed
▪ Accept or reject work results
Product owner

— Makes Business Case

— Does the choice have signoff from
stakeholders and internal champions
— Do users want these features/product
— What is not done as a result
— Estimation of Business Value
— Importance of features – can’t have
everything now
— Stakeholder Management
The ScrumMaster
▪ Represents management to the project
▪ Responsible for enacting Scrum values and
practices
▪ Removes impediments
▪ Ensure that the team is fully functional and
productive
▪ Enable close cooperation across all roles and
functions
▪ Shield the team from external interferences
The team
▪ Typically 5-9 people
▪ Cross-functional:
— Programmers, testers, user experience
designers, etc.
▪ Members should be full-time
▪ May be exceptions (e.g., database administrator)
The team

▪ Teams are self-organizing

— Ideally, no titles but rarely a possibility
▪ Membership should change only between
sprints
Typical Team Roles

▪ Product Owner
▪ Solution Architect
▪ Software Architect
▪ QA team
▪ Ops team
▪ Build/Deployment Manager
▪ SCRUM Master
▪ Support Team
Scrum framework
Roles
• Product owner
• ScrumMaster
• Team
Ceremonies
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Artifacts
• Product backlog
• Sprint backlog
• Burndown charts
 Team Sprint planning meeting
capacity
Sprint prioritization

Product • Analyze and evaluate product Sprint

backlog backlog goal
• Select sprint goal
Business
conditions Sprint planning
• Decide how to achieve sprint
Current goal (design) Sprint
product • Create sprint backlog (tasks)
from product backlog items backlog
(user stories / features)
Technology • Estimate sprint backlog in hours
User Stories

▪ User stories are short, simple description of a feature told from the
perspective of the person who desires the new capability, usually a
user or customer of the system. They typically follow a simple
template:

As a <type of user>, I want <some goal> so that <some reason>

▪ User stories are often written on index cards or sticky notes, stored
in a shoe box, and arranged on walls or tables to facilitate planning
and discussion. As such, they strongly shift the focus from writing
about features to discussing them. In fact, these discussions are
more important than whatever text is written.
Sprint planning
▪ Team selects items from the product backlog
they can commit to completing
▪ Sprint backlog is created
— Tasks are identified and each is estimated (1-16
hours)
— Collaboratively, not done alone by the
ScrumMaster
▪ High-level design is considered
As a vacation Code the middle tier (8 hours)
planner, I want Code the user interface (4)
Write test fixtures (4)
to see photos
Code the foo class (6)
of the hotels. Update performance tests (4)
The daily scrum
▪ Parameters
— Daily
— 15-minutes
— Stand-up
▪ Not for problem solving
— Whole world is invited
— Only team members, ScrumMaster, product
owner, can talk
▪ Helps avoid other unnecessary meetings
Everyone answers 3
questions
1
What did you do yesterday?

2
What will you do today?

3
Is anything in your way?
▪ These are not status for the ScrumMaster
— They are commitments in front of peers
The sprint review
▪ Team presents what it accomplished during
the sprint
▪ Typically takes the form of a demo of new
features or underlying architecture
▪ Informal
— 2-hour prep time rule
— No slides
▪ Whole team participates
▪ Invite the world
Sprint retrospective
▪ Periodically take a look at what is and is not
working
▪ Typically 15–30 minutes
▪ Done after every sprint
▪ Whole team participates
— ScrumMaster
— Product owner
— Team
— Possibly customers and others
Sprint retrospective
▪ Periodically take a look at what is and is not
working
▪ Typically 15–30 minutes
▪ Done after every sprint
▪ Whole team participates
— ScrumMaster
— Product owner
— Team
— Possibly customers and others
Scrum framework
Roles
• Product owner
• ScrumMaster
• Team
Ceremonies
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Artifacts
• Product backlog
• Sprint backlog
• Burndown charts
Product backlog

▪ The requirements
▪ A list of all desired work
on the project
▪ Ideally expressed such
that each item has value
to the users or customers
of the product
▪ Prioritized by the product
owner
This is the
product backlog
▪ Reprioritized at the start
of each sprint
A sample product backlog

Backlog item Estimate

Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a
3
reservation.
As a hotel employee, I can run RevPAR
8
reports (revenue-per-available-room)
Improve exception handling 8
... 30
... 50
The sprint goal
▪ A short statement of what the work will be
focused on during the sprint
Life Sciences
Support features necessary for
Database Application population genetics studies.
Make the application run on SQL
Server in addition to Oracle.
Financial services
Support more technical
indicators than company ABC
with real-time, streaming data.
Managing the sprint backlog
▪ Individuals sign up for work of their own choosing
— Work is never assigned
▪ Estimated work remaining is updated daily
▪ Any team member can add, delete or change the
sprint backlog
▪ Work for the sprint emerges
▪ If work is unclear, define a sprint backlog item with
a larger amount of time and break it down later
▪ Update work remaining as more becomes known
A sprint backlog

Tasks Mon Tues Wed Thur Fri

Code the user interface 8 4 8
Code the middle tier 16 12 10 4
Test the middle tier 8 16 16 11 8
Write online help 12
Write the foo class 8 8 8 8 8
Add error logging 8 4
A sprint burndown chart
Hours
 Tasks Mon Tues Wed Thur Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 7
Test the middle tier 8 16 16 11 8
Write online help 12

50

40

30
Hours

20

10
0
Mon Tue Wed Thu Fri
Scalability
▪ Typical individual team is 7 ± 2 people
— Scalability comes from teams of teams
▪ Factors in scaling
— Type of application
— Team size
— Team dispersion
— Project duration
▪ Scrum has been used on multiple 500+ person
projects
Scaling through the
Scrum of scrums
Scrum of scrums of
scrums
A Scrum reading list
▪ Agile and Iterative Development: A Manager’s Guide by Craig
Larman
▪ Agile Estimating and Planning by Mike Cohn
▪ Agile Project Management with Scrum by Ken Schwaber
▪ Agile Retrospectives by Esther Derby and Diana Larsen
▪ Agile Software Development Ecosystems by Jim Highsmith
▪ Agile Software Development with Scrum by Ken Schwaber and
Mike Beedle
▪ Scrum and The Enterprise by Ken Schwaber
▪ User Stories Applied for Agile Software Development by Mike
Cohn
▪ Lots of weekly articles at www.scrumalliance.org
Key Points
▪ UP is the iterative and incremental software
engineering process for the UML.
— UP has four phases: Inception, Elaboration,
Construction, Transition.
— Each phase may have one or more iterations.
— Each iteration has five core workflows.
▪ Requirements, Analysis, Design, Implementation,Test.
▪ Agile methods are being increasingly used.
— eXtreme Programming, Scrum
— iterative/incremental development, sprints
4
5
 Modern Agile

http://modernagile.org
http://www.scaledagileframework.com
http://www.agilemodeling.com/essays/introductionToAM.htm
Kanban
Key Principles of Kanban
1. Visualize workflow
2. Limit work in progress (WIP)
3. Focus on flow
4. Use of feedback loops
5. Continuous improvement

5
0
Background

• Evolved from a methodology developed by Toyota in

their car manufacturing in the 1940s
• Used by many software and other teams
• Emphasis is in having the right materials available just
in time (JIT) for each stage of the process
• A kanban team is only focused on the work that's
actively in progress
• Once the team completes a work item, they take the
next work item off the top of the backlog
Planning workflow

• The product owner reprioritises work in the backlog

without disrupting the team, because any changes
outside the current work items don't impact the team.
• As long as the product owner keeps the most
important work items on top of the backlog, the
development team is assured they are delivering
maximum value back to the business.
Planning estimation

• Kanban does not use fixed-length iterations that you

find in scrum
• The entire team focus is on the work in progress WIP
• By optimizing cycle time, the team can confidently
forecast the delivery of future work
• Bottlenecks need to be identified and managed
• When only one person holds a skill set, that person
becomes a bottleneck in the workflow
Information about work items on
Kanban Cards
• visibility into who is responsible for that item of work
• a brief description of the job being done
• how long that piece of work is estimated to take

• Cards on virtual kanban boards will often also feature

screenshots and other technical details that is
valuable to the assignee
Flow Metrics

Lead time - how long does it take for a card to move from
“TO-DO” to “DONE”?
Cycle time - how long does it take for a card to move from
“Doing” to “Done”?
Number of items not started - are you struggling with your
workload?
Number of items that are WIP - are you staying within your
WIP limits?
Blockage areas - do you see any areas where cards build
up, causing a blockage in flow?
http://www.kanbanway.com/predict-project-failure-using-cumulative-flow-diagrams
http://leanguru.pro/the-cumulative-flow-chart-cfd-in-a-nutshell/
http://leanguru.pro/the-cumulative-flow-chart-cfd-in-a-nutshell/
Comparison of SCRUM – Kanban

KANBAN
SCRUM

Regular fixed length sprints (ie, 2

Cadence Continuous flow
weeks)

At the end of each sprint if approved Continuous delivery or at the team's

Release methodology
by the product owner discretion

Product owner, scrum master, No existing roles. Some teams enlist

Roles
development team the help of an agile coach.

Key metrics Velocity Cycle time

Teams should strive to not make

changes to the sprint forecast during
Change philosophy Change can happen at any time
the sprint. Doing so compromises
learnings around estimation.

https://www.atlassian.com/agile/kanban
Books

▪ Read the official Scrum Guide online

— http://www.scrumguides.org/scrum-guide.html
▪ https://www.amazon.co.uk/d/cka/Learning-Agile-
Understanding-Scrum-XP-Lean-
Kanban/1449331920/ref=sr_1_8?s=books&ie=UTF8&qi
d=1502467456&sr=1-8&keywords=SCRUM
▪ https://www.amazon.co.uk/gp/product/1847941109/ref=
pd_cp_14_4?ie=UTF8&psc=1&refRID=6MXVM39AGJV
CAYP70SDB
Books

▪ https://www.amazon.co.uk/d/cka/Agile-Estimating-
Planning-Robert-Martin-Mike-Cohn/0131479415
▪ https://www.amazon.co.uk/Essential-Scrum-Practical-
Addison-Wesley-
Signature/dp/0137043295/ref=pd_lpo_sbs_14_img_0?_
encoding=UTF8&psc=1&refRID=NH6CG9AH4VKSTW4
2WSQA
Additional Content and
Resources
▪ http://modernagile.org
▪ https://www.atlassian.com/blog/
▪ https://blog.newrelic.com
▪ https://dzone.com
▪ https://www.thoughtworks.com
▪ http://www.scrumtrainingseries.com
▪ http://www.mountaingoatsoftware.com/scrum
Additional Content and
Resources
▪ http://stateofagile.versionone.com
▪ https://www.slideshare.net/ChrisDavies59/agile-
leadership-73088974
▪ https://www.slideshare.net/JonTerry2/intro-to-lean-
practices-tools
▪ https://www.slideshare.net/JonTerry2/intro-to-lean-lean-
software-development-and-kanban
▪ https://www.versionone.com/pdf/AgileCheckList.pdf
Additional Content and
Resources
▪ https://skillsmatter.com/skillscasts/7759-adopting-agile-
as-a-cultural-change
▪ https://skillsmatter.com/skillscasts/7631-principles-of-
effective-agile-project-governance
▪ https://hbr.org/2011/05/two-structures-one-organizatio
▪ https://dzone.com/articles/what-is-software-architecture-
in-
scrum?edition=317392&utm_source=Daily%20Digest&
utm_medium=email&utm_campaign=Daily%20Digest%
202017-08-13
IMB Attendance Capturing - Year
2
Module Code: MSIN2009
Session Keyword: scrum

http://bit.ly/IMB-Y2

Presentation Title 65