Upload
hawkman-academy
View
695
Download
4
Embed Size (px)
Citation preview
Introduction to Agile & Scrum Workshop
Introduction
• Course Overview• Content• Learning Outcomes
Who is here today?• Name
• Current role
• Who is your favourite artist of all time?
• Expectations from this workshop
Today…• Learn about Agile & Scrum
• Lots of group exercises
• Please ask questions
• Have fun!
What we will cover
• Agile
• Scrum
• User Stories
• Agile Estimation
• Backlog Management
• Continuous Development
Learning OutcomesAt the end of today you will be able to:
• Describe agile, and how it differs from Scrum.
• Describe the basic rules of Scrum.
• Write and Evaluate User Stories.
• Describe Relative and Absolute Estimation
• Describe Story Points
• Play Planning Poker
• Play Fast Estimation
• Prioritise a Backlog, while considering Value and Risk.
• ...
Learning Outcomes (cont’d)At the end of today you will also be able to:
• Describe how Sequential and Continuous Development differ.
• List some of the practices that are used in Continuous
Development.
• Describe Technical Debt and list some elements of managing
debt.
Agile
Introduction to Agile
• Why Agile?
• Agile Manifesto
• Domination of Scrum
Would you trust this man?
You Should!
• In the early 90’s• Most software projects were failing• But they were all succeeding• What was different?• ‘agile’
Very brief history of agile & Scrum
70 ‘s
Waterfallcreated
ScrumcreatedRate of Business Change
Accelerates
2013199390’s
ScrumDominate
Light weight Methodologies
arise
2001
agileManifesto
created
The New New Product
Development Game
1986
Source: http://www.versionone.com/Agile101/Agile-Software-Development-Benefits/
How to Sell Agile to your Boss?
Exercise - Presto Manifesto
1. Define a successful project?
2. Form teams.
3. List of ‘critical elements of successful projects’.
4. Reach team consensus & signs those that they agree with.
5. Review similarities between teams.
6. Review similarities to the agile manifesto.
Agile manifesto (just value statement)
Process and toolsIndividuals and interactions
over
Following a planResponding to change over
Comprehensive documentationWorking software over
Contract negotiationCustomer collaboration over
Full Manifesto: http://agilemanifesto.org/
Why is Agile Hard?
• Values & Principles
• New practices
• Best learnt by doing
• Requires time to master
Domination of Scrum
0%
10%
20%
30%
40%
50%
60% DSDM
Agile Modeling
Agile Unified Process
Other
Lean
FDD
XP
Don't Know
Kanban
Scrumban
Custom Hybrid
Scrum / XP Hybrid
Scrum
Source: Version One – 7th Annual State of Agile Survey
Domination of Scrum
Scrum variantsOther
Source: Version One – 7th Annual State of Agile Survey
Scrum
Introduction to Scrum
• Why use Scrum?
• Scrum Frameworks
• Variations
• Success
Why use Scrum?
• Adheres to agile manifesto
• Find the fun earlier
• Faster feedback
• Reduce crunch periods
Scrum Roles
Person Scrum Master Product Owner Team Member
A Yes No Yes
B No Yes No
Personby
Responsibilities in Scrum
Scrum Master Product Owner Team Member
Adherence to rules Return on Investment Deliver
Whole team effectiveness What, Why How
Roleby
Scrum Artefacts
• Product Backlog
• Sprint Backlog
• Shippable Software Increment
Scrum Ceremonies• Backlog Refinement/Grooming
• Sprint Planning
• Daily Standup
• Sprint Review
• Spring Retrospective
Values: Focus, Courage, Openness, Commitment, Respect
Definition of Done• Defines what gets to ‘Done’
• Used to ensure Quality
• Used to reduce debt
• Created by whole team
• Can be updated
• Automated Tests passing• Code Reviewed
• Product Owner accepted• Checked into mainline• Tracking tool updated• Deployed to Intg. Env.
e.g.
Sprint Commitments• Product Owner: Won’t change the Sprint Backlog.
• Team: Deliver the Sprint Backlog.
• Scrum Master: Protect the team from outside influences.
Keep in mind we will learn through the sprint, and we should deliver the most value that we can.
Exercise – match activities by role• Divide the large paper into three equal sections: Team, SM, PO.
• Match up the activity cards to the section.
• NOTE: Some cards are duplicated.
• NOTE: Blue cards are for the Primary role, Pink for the Secondary
role. E.g. ‘Create Product Backlog Items’ – Blue (Primary) for PO,
Pink (Secondary) for Team.
“Scrum is free and offered in this guide, Scrum’s roles, artifacts, events, and rules
are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.”
Scrum Guide Oct 2011http://www.scrum.org/Scrum-Guides
Immutable (Cannot change)Roles Ceremonies Artifacts Rules
1 x Scrum Master Sprint Planning Product Backlog Cross Functional
1 x Product Owner Daily Standup Sprint Backlog Self Organising
Developers Sprint ReviewPotentially Shippable Increment
Max Sprint length <= 1 month
Sprint Retrospective
Mutable – some examplesRoles Ceremonies Artifacts Rules
Scrum Master also contributes to
team
Planning involves experts from other
teamsNot using User
StoriesT.D.D. mandated
for backend code.
Product Owner across 2 teams
Standup uses speaking token
Use a burn up chart
Some team capacity put aside
for defectsDemo done by diff.
team member each week
No task board Co-location
Hold Retro in café. Using Use Cases
Co-location• Not mandated in Scrum, however;
• Agile manifesto: 2 of 4 Values Statements and 1 Principle
relate to it.
• Generally accepted that it is a crucial success factor.
Co-locationCo-location results in:
• Significantly increased collaboration.
• Enhanced feeling of being in a team.
• Impediments being resolved faster.
• Reduces delays with the team.
• Overall Success!
ScrumbutWe do Scrum but ....
• We have two PO’s for our team.
• We need team X to finish each User Story.
• Retrospectives are a waste, so we don’t do them.
• Management keeps changing the Sprint Goals.
SuccessWhat does a successful Scrum team look like?
• Delivering consistently.
• Regularly finishing their top priority stories first.
• Team actively managing Technical Debt.
• Collaborating extensively with PO.
• Try’s from Retrospectives result in change.
• Team rarely works overtime.
Scrum takeawaysWhy: Faster Feedback, Find the Fun earlier, Reduce Crunch.
Roles: Scrum Master, Product Owner, Team Member.
Ceremonies: Planning, Backlog Refinement, Stand up, Review,
Retrospective.
Artefacts: Product Backlog, Sprint Backlog, Burn-down, Product
Increment.
Values: Focus, Courage, Commitment, Openness, Respect.
Other: Immutable rules, Co-location recommended
Questions?
User Stories
User Stories
• Why User Stories?
• Different Formats
• INVEST
• Vertical Slices
• Iterative and Incremental
Why use User Stories?• Low overhead
• Encourage Collaboration
• Supportive of change
Format of User Stories
As a [USER]
I want [GOAL]
So that [BUSINESS BENEFIT]
Example User Story
As a Player who is new to Poker
I want to see tips pop up in game, that explain good moves I missed out on making
So that I feel like I am learning and hence want to keep playing
War Stories
• Stories about User Stories that have caused
problems?
• What characteristics did those stories have?
What makes for a good User Story?• Independent
• Negotiable
• Valuable
• Estimatable• Small
• Testable
What is wrong with these Stories?
I want the phoenix animation to be visually spectacular
As a regular bingo playerI want to be notified when I have played for 30 minutes
So that I know when time is up
As a seasoned poker playerI want the tips on the flop to be
tested
As a normal roulette playerI want the roulette wheel
animation to glint at 60 degrees from centre with a silver flash
on every second revolutionSo that it seems more realistic
and engaging.
Component Approach
User Interface
Business Logic
Adapters
ServicesSt
ory
DSt
ory
CSt
ory
BSt
ory
A
Vertical Slice
User Interface
Business Logic
Adapters
ServicesSt
ory
A
Stor
y B
Iterative & Incremental approachCombines:
• Vertical Slices of Functionality
• Deferring non-functional aspects
1 2 3
Building complete bits
“incrementing” builds a bit at a time
“iterating” builds a rough version, validates it, then slowly builds up quality
1 2 3
Move from vague idea to realization
Incremental, Iteration combines the ideas
1 2 53 4
User Stories takeawaysWhy: Low overhead, Support Change, Encourage
Collaboration.
Format: As a USER, I want GOAL, so that BUSINESS BENEFIT.
INVEST: Independent, Negotiable, Valuable, Estimatable,
Small, Testable.
Splitting: Incremental & Iterative and Vertical Slices.
Questions?
Agile Estimation
Agile Estimation
• What is it?
• Story Points
• Planning Poker
Human Capabilities for estimating
Roughly how long is this line?
Is this line, twice as long as the previous line?
What is Agile Estimation?• Relative Estimation
• Uses team knowledge
• Focus on speed over accuracy
Story Points• Represent Size of a Story
• Size = Effort, Complexity and Doubt
• Relative to each other. i.e. 2 is twice the size of 1
• Maths holds, i.e. 1 + 2 = 3Effort
DoubtComplexity
Story Points vs. Time
Relative Sizing (Story Points)
is more accurate over a large sample compared to
Time Estimation (Hours or Days)
Story Points are also quicker
Effort
DoubtComplexity
Story Points do not equate to Time
Complexity
1pt
8pts
Duration for Grads = 5 days Duration for Seniors = 5 days
Duration for Seniors = 1 day Duration for Grads = 30 days
Planning Poker• Facilitated by Scrum Master
• 1st time the team selects a Reference story.
• Reference Story is allocated 2 or 3 story points.
• All future stories are compared to this story.
Planning Poker Process1. PO Explains the User Story to be estimated.
2. Team members select card and place face down.
3. Entire team reveals cards at same time.
4. Discuss high and low numbers.
5. Repeat steps 2..4 until consensus is reached.
Planning Poker Number Scale
0 1 2 3 5 80.5
Exercise - Estimating Eating Fruit• Apple (Reference Story, 2 Story Points)
• Banana
• Orange
• Mango
• ½ Watermelon
• Pomegranate
• Peach
Exercise – Estimating Cooking Meals• You are now the Meal Cooking team.
• We produce high quality meals from raw ingredients.
• There is a bakery next door so all bread products are supplied by
them.
Agile Estimation takeaways• Relative Estimation
• Uses team knowledge
• Focus on speed over accuracy
• Story Points: Effort + Complexity + Doubt
• Story Points != Time
• Planning Poker
• Fast Estimation
Questions?
Product Backlog
Management
Product Backlog Management
• Ownership
• Prioritize by Value
• Prioritize by Risk
Ownership• Everyone should feel ownership for the Product.
• Product Owner – is responsible for the backlog.
• Backlog is not locked down, anyone can add to it.
• Not a free for all.
• Product Owner considers all stakeholders, including the
team.
Prioritise by Value• To maximise ROI, should prioritise Value first.
• Need effective User Stories.
• PO assists the team by explaining the business
value.
Prioritise by Risk Mitigation• To reduce Product and Project risk, we need to tackle the
unknowns.
• Team assists the Product Owner by explaining these risks.
• Technical Debt should also be considered
Combined result1. Early: Reduce Product and Project Risk
2. Middle: Focus on Value
3. End: Trim the tail
Exercise – Prioritising the City Break Backlog
Velocity• Post Measure of delivery rate of the Team.
• Velocity = Sum of Story Points of User Stories that got to
‘Done’.
• Will fluctuate
• Average Velocity is useful guide
What happens with undone Stories?• Do not count towards velocity.
• Carry over to next planning meeting, either included or
dropped.
• Count towards velocity in the sprint that they are done.
• Velocity will fluctuate but will average out.
Product Backlog takeaways• PO owns the backlog, but anyone can add to it
• Backlog prioritisation balances Value delivery with Risk mitigation
Questions?
Continuous Development
Continuous Development
• Sequential vs. Continuous
• Approaches
Sequential development
Sprint N Sprint N + 1 Sprint N + 2
Continuous Development• Scrum teams do a little of everything at once: Design, FE, BE,
QA.
• Hence different approaches are needed
Sprint N Sprint N + 1 Sprint N + 2
Approaches for Continuous Development
• Iterative and Incremental User Stories
• Evolutionary design and architecture
• Management of Technical Debt
• Technical Practices
• Agile testing
Iterative and Incremental User Stories• Covered in a previous section
Evolutionary Design & Architecture• While some Design and Architecture will occur upfront
• It will also occur continuously throughout development
Evolutionary Design &
Architecture
Continuous Integration
Refactoring
Simple Design
Technical Debt• What is Technical Debt?
• Who is responsible for Managing Technical Debt?
Technical Debt• Team identify debt, raise User Story
• Write User Story in business terms
• Work with PO to prioritise the User Story
Technical Practices• Version Control
• Coding Standards
• Code Reviews
• Refactoring
• Test Driven Development (TDD)
• Continuous Integration (CI)
• Simple Design
• Pair Programming
• Acceptance Test Driven Development (ATDD)
Traditional Testing vs. Agile testing
Conformance to Requirements.
Identify issues.
Quality meets the Customers needs.
Maximise Value.
Agile testing• Quality Assurance is a whole team responsibility.
• Test Specialists will focus on testing, but
everyone should be involved.
• Consider Testing from the very beginning.
• Focus on Repeatable, Fully Automated, Self
Reporting Testing.
Continuous Development takeaways• Game Design, UX, Code Design, Architecture all occur
continuously.
• Rigorous Technical Practices are needed.
• We need to manage our Technical Debt.
• Quality assurance is everyone's responsibility.
Questions?
Wrap up
Wrap Up
• Review
• Reference Material
• Other Available Workshops
Putting it all together
Agile ManifestoSet of Values and Principles
You can be ‘agile’, you cannot do ‘agile’
Framework based on ScrumWork and technology agnostic extensible framework that adheres to Agile Manifesto
You can do Scrum, if done well, you will be agile
Technical Practices Code Reviews, TDD, CI, etc.
Make it possible to do Scrum
Other Practices Co-location, User Stories, Story Points, etc.
Very effective extensions for Scrum
Organisational Management System Rules, Practices, Portfolio Management, etc.
scaling of methodology, specific to your organisation
Summary of today
Agile manifesto: what is it, where it came from.
Scrum: roles, ceremonies, artefacts, rules.
User Stories: format, Acceptance, INVEST, Iterative &
Incremental.
Agile Estimation: Story Points, Planning Poker, Fast Estimation
Backlog management: Ownership, Value, Risk.
Continuous Development: Design, UX, Practices, Testing,
Tech. Debt.
One thing you will take away
• Please take 2 minutes
• Write down one thing you will take away from
today
• We will share them with the group
Reference Material
Other Available Workshops
Agile & Scrum Workshop
Effective User Stories
Scrum Master
Product Owner
Software Development Workshops
Software Testing Workshops
Agile Leadership Workshop
Becoming a Technical Leader