Practicing Agile through Scrum
-
Upload
naveen-kumar-singh -
Category
Software
-
view
382 -
download
0
Transcript of Practicing Agile through Scrum
1
Practicing Agile through Scrum
Naveen Kumar Singh, PMP, PMI-ACP, CSM
VP – Program, PMI North India Chapter
• 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.
• 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 in 100 words
Characteristics
• Self-organizing teams
• Product progresses in a series of month-long “sprints”
• Requirements are captured as items in a list of “product
backlog”
• No specific engineering practices prescribed
• One of the “agile processes”
Scrum
Cancel
Gift wrap
Return
Sprint30 Days
Return
Sprint goal
Sprint backlog Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.
Rather than doing all of one thing at a time...
...Scrum teams do a little of everything all the time
Requirements Design Code Test
Sequential Vs. Overlapping Development
Scrum Framework
•Scrum Master•Product Owner•Team
Roles
•Sprint planning•Daily scrum meeting•Sprint review•Sprint retrospective
Ceremonies
•Product backlog•Sprint backlog•Increment
Artifacts
Sprints
• Scrum projects make progress in a
series of “sprints”
• Analogous to Extreme Programming
iterations
• Typical duration is a calendar month
at most
• Product is designed, coded, and
tested during the sprint
Sprint30 Days
Characteristic of Sprint
Sprint
Timeboxed
Short Duration
Consistent duration
Goal shouldn’t be altered
once started
Selecting Sprint Length
• Length of the release
• Amount of uncertainty
• How easy is to get feedbacks
• Stability of priorities
• The overhead of iterating
• Give a feeling of urgency
Short Duration
Short Duration
Ease of Planning
Fast feedback
Expose Issues
Improved return on
Investment
Rejuvenating
Frequent Check point
Consistent Duration
Consistent Duration
Predictable rhythm
Reduces coordination overhead.
Allows synchronizati
on
Simplifies planning activities.
Scrum Master
I never teach my pupils; I only attempt to provide the conditions in which they can learn. —Albert Einstein
Scrum Master
• Observes the team and
ensures adherence to
scrum rules
• Responsible for enacting
Scrum values and
practices
• Introduces Scrum Roles to
the team
• Coach & Manage Team
Members
Scrum Master
• Create productivity team
• Acts as a team moderator.
• The Facilitation of daily Scrum
• Remove hurdles or any other
external interference
• Improve the engineering
practices and tools.
Scrum Master
• Remove the barriers between
development and the Product
Owner.
• Teach the Product Owner how to
maximize ROI.
• Shield the team from external
interferences
• Keep information about the
team’s progress up-to-date and
visible to all parties.
Dos Don’ts
Guides and facilitates Direct or drive
Keeps everyone focused on delivering business value
Stick to deadlines and approaches that no longer work
Has a keen interest in the team’s overall Performance
Become attached to specific outcomes from the team
Coaches the team for high performance
Get involved in task-level direction
Promotes the skills and growth of every team member
Become the only voice of the team
Scrum Master Behaviours
Product Owner
• Mouthpiece of stakeholders
and customers. Facilitate the
scrum financing.
• Ensures profit returns from
the product development and
its launch in the market
(ROI).
Product Owner
• Visualizes the conception,
management, outcome, and
launch of the product.
• Decide on release date and
content
• Prioritize features according
to market value
Product Owner
• Controls the right use of
backlog.
• Has right to accept or reject
the outcome of the project.
• Adjust features and priority
every iteration, as needed
• Accept or reject work results
Product Owner is CRACK
• Committed to the work and engaged in
it fully
• Responsible for the outcome
• Authorized by the person paying the
bills to make decisions about the product
under development and to know which
decisions can be made solo and which
require consultation with others
• Collaborative as a normal mode of
interacting with people
• Knowledgeable about the business
purposes of the endeavor and the
business domain itself
Development Team
• Responsible for product
quality, estimation, and
delivery.
• Responsible for converting
product backlog into
shippable product
• Responsible for managing
their day to day tasks
Development Team
• Makes Rules for living
together
• Identifies missing items in
Product Backlog
• Prepares Sprint Backlog
• Prepares definition of Done
Development Team
• It is right sized i.e. 3 to 9
• It is self dependent which
means it is self managed and
self organized.
• It is also multifunctional.
• Interlaces with customers,
end users, PO, and even
PMOs (project management
organizations)
Sprint Planning
• The Team and the Product Owner collaborate to help the
Team determine how much Product Backlog it can turn into
functionality during the upcoming Sprint.
• The Team create plans (Sprint Backlog) by identifying tasks
for converting selected Product Backlog into functionality
Sprint planning meeting
Sprint prioritization
• Analyze and evaluate product backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint goal (design)
• Create sprint backlog (tasks) from product backlog items (user stories / features)
• Estimate sprint backlog in hours
Sprintgoal
Sprintgoal
Sprintbacklog
Sprintbacklog
Business conditions
Business conditions
Team capacity
Team capacity
Product backlog
Product backlog
TechnologyTechnology
Current product
Current product
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 Scrum Master
• High-level design is considered
As a vacation planner, I want to see photos of the hotels.
As a vacation planner, I want to see photos of the hotels.
Code the middle tier (8 hours)Code the user interface (4)Write test fixtures (4)Code the foo class (6)Update performance tests (4)
Why Daily Scrum?
• Fine-grain coordination
• Daily commitment
• Raising impediments
• Peer pressure
• Access Progress towards sprint goal
• Replanning
The Daily Scrum
• Parameters• Daily
• 15-minutes
• Stand-up
• Not for problem solving
• Only team members, Scrum
Master, Product Owner, can talk
• Helps avoid other unnecessary
meetings
• Team is responsible of conducting
this meeting
Daily Scrum
Facilitate
Observe What did you do yesterday?What did you do yesterday? 11
What will you do today?What will you do today?22
Is anything in your way?Is anything in your way? 33
These are not status for the Scrum Master• 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
• Done after every sprint
• Participants • Scrum Master
• Team
• Product owner (Optional)
Sprint Retrospective Meeting
A meeting time-boxed for 3 hours and facilitated by the Scrum Master at which the Team discusses the just-concluded Sprint
and determines what could be changed that might make the next Sprint more enjoyable or
productive.
Start / Stop / Continue
Facilitate
Observe Start doingStart doing
Stop doingStop doing
Continue doingContinue doing
This is just one of many ways to do a sprint retrospective
Product Backlog
• The requirements
• A list of all desired work (Product Backlog Item) on the project
• Ideally expressed such that each item has value to the users
or customers of the product
• Prioritized by the product owner
• Reprioritized at the start of each sprint
Good Product Backlog
• Good product backlogs should be DEEP (Coined by Roman
Pichler and Mike)
• Detailed appropriately
• Emergent
• Estimated
• Prioritized
Constituents Of Product Backlog
PBI Type Example
Feature As a job seeker I want to search job using keywords so that I can find the suitable job
Change As a job seeker I want default ordering od job search results to be by freshness rather than location so that its easier to see latest jobs first
Defects Fix defect #245 so that special character in search wont crash the system
Technical Improvement
Move to the latest version of Internet Explorer
Knowledge Acquisition Create prototype using two databases (RDMS and NO SQL) and run performance test to determine which would be better approach for our system.
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 reservation. 3
As a hotel employee, I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
... 30
... 50
Sprint Backlog
• The Sprint Backlog defines the work the Team will perform to
turn Selected Product Backlog items into a “Done” Increment.
• The list emerges during the Sprint.
• Each ongoing task identifies those responsible for doing the
work
• Each Tasks has information about estimated amount of work
remaining on the task on any given day during the Sprint.
The Sprint Goal
• A short statement of what the work will be focused on
during the sprint
Database Application
Financial services
Life Sciences
Support features necessary for population genetics studies.
Support more technical indicators than company ABC with real-time, streaming data.
Make the application run on SQL Server in addition to Oracle.
The Increment
• The Increment is the sum of all the Product Backlog items
completed during a Sprint and all previous Sprints.
• At the end of a Sprint, the new Increment must be “Done,”
• It must be in useable condition (Potentially shippable product)
Definition of Done
• Everyone must understand what done means
• This varies significantly per Scrum Team, members must have
a shared understanding of what it means for work to be
complete, to ensure transparency
• This guides Development Team in knowing how many Product
Backlog items it can select during a Sprint Planning Meeting.
• The purpose of each Sprint is to deliver Increments of
potentially releasable functionality that adhere to Definition of
“Done.”
• Definition of Done may change during the project
Stay Connected
Naveen Kumar Singh
References - http://www.mountaingoatsoftware.com/www.izenbridge.com