-dp-

Agile Series – Scrum

Durgaprasad B. R

Flow, Value, Feedback, Collaboration

-dp-

-dp-

Agile

Kanban

Product Owners

Scrum Master/ Project

Manager

XP/ Engineering Practices

ScrumbanLean

Lean Software Development

Scrum

Agile HR Practices

Agile Leadership

Test Automation

Program Governance

Coaching

Continuous Integration/ Deployment

Development Projects

Sustenance Projects

Verification Projects

Technical Support

Web Application

Development

Embedded Applications

Legacy Systems

Continuous Improvement

Agile Offshoring

-dp-

Backlog1. Agile Manifesto and Principles2. Scrum Principles3. Starting Scrum4. Managing Scrum

-dp-

Scrum - Background

Term coined by Hirotaka Takeuchi and Ikujiro Nonaka

Scrum – was described by them as a new approach to software product development

They studied companies like Fuji Films, Toyota, Xerox and 3M which were operating in tough markets.

They call it the Rugby approach: as the whole process is done by a cross-functional teams. The teams try to go the distance as a unit, passing the ball back and forth.

Scrum – an event in Rugby, where likeminded people get together and discuss the ownership of the ball

-dp-

Scrum

Scrum like Chess, has limited set of rules. With those rules, different situations arise and the team as a whole should use their collective intelligence to come up with the next best move …..

But, unlike Chess, there is no “Touch and Move” rule

On a wrong move (feedback from customer/opponent in chess), you can immediately revert back the last move/few moves easily

Scrum is so popular in Agile, that people interchangeably use Scrum for Agile

-dp-

What is Scrum ?

Scrum is a

Software Management Process

not a Software Engineering Process

-dp-

What is Scrum ?

• Greatness of Scrum is its independence from Software Engineering Process

• Generally, XP engineering practices are popular with Scrum

-dp-

Scrum OverviewEverything in scrum is within an iterative, incremental framework consisting of timeboxes

called “Sprints’. Each sprint duration is fixed for a project(2 to 4 weeks).

Everything is done by small cross functional team (8-9 members) who are responsible for managing themselves

At the beginning of every sprint, this team commits to implement a set of high priority items from a prioritized list called ‘Product Backlog’ to implement within a timebox

During the sprint, everyday team briefly discusses the progress during Daily Scrum, and plans next steps to complete the work

Team should deliver something “done” called increment, at the end of each iterations which is of value of customer

At the end of the spring, the team does a Sprint review with the stakeholders to demonstrate the build and get valuable feedback.

The team also does an Sprint Retrospective at the end of every sprint, to look at things to improve for the next sprint (continuous improvement)

-dp-

Sprint Planning (2-4 hr)

Prioritization Task Breakdown Team Commitment Sprint Backlog

Product Backlog

Sprint Backlog

Daily Scrum(15 min)

- 3 Questions

2-4 weeks Sprint

Refine Product Backlog (8-10% Sprint)

Potentially Shippable Product

Increment

Sprint Review (2-4 hr)

Demo

Sprint Retrospective (2-3 hr)

- Continuously Improve

Scrum Master Responsible for Process Support the team Remove Impediments

Product Owner Prioritization Voice of Customer Owns the Product Backlog

Scrum Team Cross Functional Deliver Each Sprint

MinimumReleasable Features

(PO with help of other members creates the

product backlog)

(Use burndown charts and dashboards to

track progress)

Scrum Flow

-dp-

It takes an hour to learn and lifetime to master

-dp-

Backlog1. Agile Manifesto and Principles2. Scrum Principles3. Starting Scrum4. Managing Scrum5. Continuous Improvement

-dp-

Scrum – Core Values• Commitment• Focus• Openness• Respect• Courage

Note: Scrum core values sound a bit like US Army’s seven commandments: Loyalty, duty, respect, selfless service, honor, Integrity and personal courage. This may not be very surprising as two founders of scrum have military background: Jeff Sutherland was a fighter pilot and Ken Schwaber attended U.S. Merchant Marine Academy

-dp-

Backlog1. Agile Manifesto and Principles

2. Scrum Principles3. Starting Scrum

Roles Ceremonies Artifacts

4. Managing Scrum5. Continuous Improvement

-dp-

SprintNot more than 4 weeks. Smaller the better. Ideally 2 weeksAim is to deliver a releasable software at the

end of every sprintSprint includes require gathering to user

acceptance testingThe teams are not interrupted during the sprintSprint duration once fixed cannot be changed

-dp-

Scrum Framework

Scrum Framewo

rk

Scrum Roles - Scrum Master - Product Owner - Team Member

Ceremonies - Sprint Planning - Sprint Review - Sprint

Retrospective - Daily Scrum

Artifacts - Product Backlog - Sprint Backlog - Burndown

charts - Increments

-dp-

Scrum Roles

Advocates three roles within the team

- Scrum Master- Product Owner- Team Member

-dp-

Scrum Metaphors Classic Story of the Pig and Chicken

Pig roles are considered core team members. Performers. People who “do” work The team, product owner and scrum master are pigs in the team

A chicken is someone who has something to gain by the Pigs performance, but in the end, really do not contribute day to day to “getting things done”

You cannot be a Pig and a Chicken at the same time. Especially Middle management.

Dear Pig. We should open a restaurant – “Ham and Eggs”

No Sorry! I’d be committed and you’d be only involved!!!

Note: Chicken and Pig story is an old story and good for small startup teams, which wants to keep management away. However, as teams grow, including management is very important. It may be time to get rid of this story !!!!

-dp-

Scrum Master• SM represents the management to the team

• Helps the team to learn and apply Scrum

• SM protects, guides, and serves the team while also activating as a change agent

• Primary role of Scrum Master is of a coach and not a facilitator

• Has no delivery responsibility, does not commit to date, budgets and profits etc.

• Full time role and servant leader

-dp-

Scrum MasterServant Leader, team protector, trouble

shooter, Scrum guide Removes impediments Prevents interruptions Facilitate the team Support the process Manage management Continuous Improvement Self development and Team Development

-dp-

Scrum Master – Servant Leader

3 C’s of Servant Leader

Character to influence othersCourage to pursue a purposeCommitment to develop others

-dp-

Scrum Product Owner• The Product Owner is responsible for maximizing the value of the

product

• He / She is the navigator choosing features and providing feedback to deliver value

• Product owner is the single “wring-able neck” for the product. Responsible for ROI and answerable to the management and customer

• Represents customer / sponsor the development team

• Product owner can be a busy role in a complex product team and can take help from the team members for his activity (business analysts)

• Ensure that the PO’s are available. Non-availability has major impact on output

-dp-

Scrum Product Owner - Activities

• The first step in Scrum is to articulate the Product Vision – done by the Product owner.

• This product vision will evolve into a list of features called Product Backlog, created and owned through out the project by the Product Owner.

• Backlog grooming on an ongoing basis• Define features based on the vision• Prioritizing backlog items based on the business value/ROI• Classify backlog items consists of Epics->Themes->Features->User Stories• Define Release contents and release dates• User stories should be right sized enough to be done within an iteration

• Participate in daily scrum (optional), sprint planning, sprint reviews and retrospectives (optional)

• Inspect the “incremental” delivery at the end of the sprint. Has authority to approve, ask for change or reject the deliverables

• Provides product status updates to the customer and the management regularly

-dp-

Scrum Product Owner - Activities

• Product Owners activities during the sprint, would include • Coordinating with the team and Scrum master on the product

issues, • Preparing the user stories for the next few sprints, • maintaining backlog, • Helping team with writing test cases,• Working with the business to get feedback from the end

user/customer

• Authority to terminate sprint if the game plan has changed

• Question the team if they are not following a plan or working on non-priority work items

-dp-

Scrum Product Owner - Profile

• Subject Matter Expert (Domain)

• Understand end user and champion for their cause

• Understand business – ROI and priorities

• Able communicator

• Decision Maker – handles conflicting goals/situations in the best interest of the customer

-dp-

Scrum Product Owner – Who ?

Ideally customer / end user can be a product owner, provided they can dedicate their time to the project

If not, then, the team can identify proxy Product Owner someone who is mature, understands customer domain, and co-ordinate with the customer

-dp-

Scrum Product Owner – Who ?

How do you handle a customer ?

Treat your customer like a neighbor whom you can count on everyday rather than a intrusive relative who moves in for a while and then not to be seen for a year

-dp-

Scrum Project TeamAmazon – 2 Pizza Rule

“If your team can’t be fed on two pizzas, then cut people”

• The idea of a “two pizza team” was coined by Jeff Bezo, founder of Amazon.com

• Limit the task force to five to seven people (depending on their appetite )

-dp-

Scrum Project Team - Characteristics

Like a player in a rugby/football team -• Have positions and not roles• Generalization Specialists – if required should play in any

position• Cross Functional – Don’t hold on to your position, help team win• Have Clear objectives – Know what winning means• Co-located (to the maximum extent possible)• Self Organizing – team organizes itself during the play• Empowered• Quality Driven• Mutually Accountable (no finger pointing)• Focused on value delivery (Goals)• Open honest (feedback, appreciation)• Have FUN !!!

-dp-

The teamSmall (5-9 persons), co-located, cross-

functional, Self organized, full time Define tasks Estimate effort Develop product Ensure quality Evolve processes

-dp-

Scrum Framework

Scrum Framewo

rk

Scrum Roles - Scrum Master - Product Owner - Team Member

Ceremonies - Sprint Planning - Sprint Review - Sprint

Retrospective - Daily Scrum

Artifacts - Product Backlog - Sprint Backlog - Burndown

charts - Increments

-dp-

Scrum Ceremonies

Advocates four ceremonies in Scrum

- Sprint Planning- Sprint Review- Sprint Retrospective- Daily Scrum

-dp-

Sprint Planning (2-4 hr)

Prioritization Task Breakdown Team Commitment Sprint Backlog

Product Backlog

Sprint Backlog

Daily Scrum(15 min)

- 3 Questions

2-4 weeks Sprint

Refine Product Backlog (8-10% Sprint)

Potentially Shippable Product

Increment

Sprint Review (2-4 hr)

Demo

Sprint Retrospective (2-3 hr)

- Continuously Improve

Scrum Master Responsible for Process Support the team Remove Impediments

Product Owner Prioritization Voice of Customer Owns the Product Backlog

Scrum Team Cross Functional Deliver Each Sprint

MinimumReleasable Features

(PO with help of other members creates the

product backlog)

(Use burndown charts and dashboards to

track progress)

Scrum Flow

-dp-

Meeting ScheduleMeeting Frequency Length

Strategy Typically once a year 4-16 hours

Release Planning 1st day of each release 4-8 hours

Iteration (sprint) planning 1st day of each iteration 2-4 hours

Iteration (sprint) review Last day of each iteration 1-2 hours

Retrospective Last day of each iteration 1-2 hours

Daily standup Each day at the same place and time

15 minutes

Ref: VersionOne

-dp-

strategyPurpose: • To define strategy, vision, goals of the

program

Agenda: • Involve all stakeholders and list down their

interests• Question “Why” this is required

-dp-

StrategyAttendees

Product Owners, Product and or Project Managers,Team Members,Key Stakeholders

Input

Market ReportsCustomer FeedbackManagement inputs

Output

Vision and strategyKey assumptions and issuesDelivery dates

Common Obstacles

• Clear understanding of the market needs• Clear understanding of the market sizing• Stakeholder interests and commitment

-dp-

Release PlanningPurpose: • To articulate themes, functional

priorities and delivery dates are defined

• Allows for the communication of the entire scope of the release to project teams and stakeholders about high level plan

• Release backlog is identified and estimated at a high level

• Based on an initial estimate and / or velocity, a preliminary delivery plan is agreed upon

Agenda: • Review meeting agenda and guidelines• PO reviews product vision, strategy and goals• PO reviews key dates and milestones• PO presents the first cut at the prioritized product

backlog• Team asks questions to understand user stories• Team estimates user stories at a high level (i.e.

story points, ideal days etc.)• Team estimates its initial capacity and/or velocity

per iteration• Team finalizes its delivery objectives in the form

of a release plan• Meeting facilitator records and key decisions,

assumptions, risks and/or issues• Stakeholder consensus is achieved and a

commitment to proceed is given

Ref: VersionOne

-dp-

Release PlanningAttendees

Product Owners, Product and or Project Managers,Team Members,Key Stakeholders

Input

Vision and strategyKey assumptions and issuesDelivery dates

Output

Release planBacklogKey assumptions and issuesDelivery dates

Common Obstacles

• Inability to negotiate time, scope and budget constraints• Lack of acceptance of team based estimation and planning• Lack of understanding that the plan is not frozen and will change

Ref: VersionOne

-dp-

Sprint PlanningPurpose: • To plan and agree on the stories or

backlog items the team is confident about to complete within the sprint

• To identify the detailed tasks and tests for delivery and acceptance

• Sprint planning can have two parts• Part 1: Deciding sprint goal and deliverables• Part 2 : Task planning

• Team first estimates the available time/capacity (excluding meeting time, leaves etc.) for the sprint and then self assigns the backlog items that can be completed within the sprint

Agenda: • Review meeting agenda and guidelines• Part 1 – Deciding Sprint goal and

deliverables• PO proposes the product backlog for review• Team ideally defines the iteration goal or theme• PO and team review and clarify each item• Larger stories are broken down as needed• Team selects the stories they can complete within

the iteration• Review “Definition of Done” for all work items• PO shares his goal and team clarifies their doubts

• Part 2 – Task Planning• Team estimates any resulting new stories• Team breaks each story into tasks and clearly

define acceptance criteria• Team estimates each task (typically in hours)• Team members sign up for tasks initially during the

iteration• Team may review the workload to make certain it is

feasible and balanced• Team plays an active role and PO supports the

team

• Product Owner agrees with the work that will be completed

Ref: VersionOne

-dp-

Sprint PlanningAttendees

Product Owners,Team Members,Scrum Master,and/or Project Master

Input

Prioritized product backlog, prior velocity, team member capacity and/or schedule testsBacklog Grooming

Output

Iteration goals, Sprint Backlog and acceptance tests, Task Breakdown,Prepare index cards and paste it on a kanban wall

When: During Start of every Sprint Duration: ~2-4 hoursKey Considerations• The team always has the final say when it comes to estimating• Every team member should have a vote and or voice • Dependencies should be minimized, if not prevented entirely• The team should consistently identify and impediments preventing them from completing their work

that need to be addressed

Common Obstacles• Driving into too much detail and designing each feature in full rather than identifying the task work

necessary

Ref: VersionOne

-dp-

Sprint ReviewPurpose: • Conducted by the PO to ensure all

acceptance criteria of the work completed have been met

• Following the review, the team then demonstrates completed functionality to showcase their work to stakeholders and/or customers

Agenda: • Review meeting agenda and

guidelines• Team walks through completed

functionality with PO• Team identifies any incomplete stories• The PO moves/or splits incomplete

stories or backlog items back into product backlog

• PO closes out iteration and accepts appropriate functionality

• Team demonstrates working software to interested stakeholders

• Any open issues / impediments and action items are noted and assigned

Ref: VersionOne

-dp-

Sprint ReviewAttendees

Team Members,Scrum Members and/or Facilitator,Product Owner

Input

Accomplishments from the prior iteration, List of issues and impediments

Output

Increment DemoList of suggested changesConfirmation and closure of accepted User Stories

Key Considerations• Demonstrate stories as they get completed. Insist on feedback and signoff.• Mid sprint review on completion may be an option to get early feedback and fix

within the same review• PO is the most important participant of this meeting. Ensure that he is present.• Ensure that the feedback comes from PO. All other stakeholders can give their

feedback to the PO and not to the team.

Ref: VersionOne

-dp-

Daily StandupPurpose: • A standing meeting that

facilitates team communication

Agenda: The 3 questions which are typically addressed by each team member include: What have you done since we last met? What are you planning to do until we met

again? What, if any, impediments are you

encountering that are preventing you from making forward progress?

Ref: VersionOne

-dp-

Daily StandupAttendees

Product Owners,Team Members,Scrum Master,and/or Project Manager, Interested stakeholder

Input

Individual team members state of work currently and completed

Output

Team communication and understanding of individual and iteration progress, task status, critical issues or impediments

Key Considerations• Only people with work assigned in the iteration should speak• Topics outside the 3 questions should be addressed outside the meeting• The team should report progress to the team as opposed to one member or a

ScrumMaster or manager• An unaddressed impediments and issues should be noted

Common Obstacles• All team members are not present• Non-core members consume the meeting with discussion • Time is spent on general discussion or detailed tangents vs. targeted progress

Ref: VersionOne

-dp-

RetrospectivePurpose: • Provides team a dedicated

opportunity to collectively evaluate their processes.

• A great opportunity for Continuous Improvement

• Goal is to inspect and adapt team practices and processes in an effort to identify and take actions on key issues that are impending the teams progress or health

Agenda: • Review meeting agenda and guidelines• Team reviews what went well during the last

iteration• Team reviews what did not go well or as

planned during the last iteration & why• Team identifies the most important items or

issues to focus on next iteration• Team notes any additional impediments

preventing them from adopting and/or improving their process

Ref: VersionOne

-dp-

RetrospectivesAttendees

Team MembersScrum MastersAnd/or Facilitators, Product Owner

Input

Details and accomplishments from the prior iterations, list of issues or impediments

Output

Prioritized impediments Changes as stories to BacklogAction plan for improvement with dates and Action item ownersEscalations

Key Considerations• Retrospectives are intended to focus on the process and not people• Avoid chickens, as team would want to critically look at improvements. Even

Scrum Master can be optional.• Effective retrospective requires a feeling of safety. Any feel of punishment for

raising uncomfortable issue may make the retrospectives ineffective.

Ref: VersionOne

No Problem ….. is problem – Toyota Saying

-dp-

Scrum Framework

Scrum Framewo

rk

Scrum Roles - Scrum Master - Product Owner - Team Member

Ceremonies - Sprint Planning - Sprint Review - Sprint

Retrospective - Daily Scrum

Artifacts - Product Backlog - Sprint Backlog - Burndown

charts - Increments

-dp-

Scrum Artifacts

Advocates four artifacts prescribed by Scrum

- Product Backlog- Sprint Backlog- Burndown charts- Increments

-dp-

Product Backlog – Heart of Scrum

• Scrum uses concept of product backlog to track requirements and issues

• The principle is to feed the project teams with small chunks of work which can be completed with a short interval of time

• Team is shielded from other complexities and allowed to focus on the work in hand

• The product backlog contains a list of prioritized user stories, feature requests, change requests, bugs and other requests from business

-dp-

Sprint Planning (2-4 hr)

Prioritization Task Breakdown Team Commitment Sprint Backlog

Product Backlog

Sprint Backlog

Daily Scrum(15 min)

- 3 Questions

2-4 weeks Sprint

Refine Product Backlog (8-10% Sprint)

Potentially Shippable Product

Increment

Sprint Review (2-4 hr)

Demo

Sprint Retrospective (2-3 hr)

- Continuously Improve

Scrum Master Responsible for Process Support the team Remove Impediments

Product Owner Prioritization Voice of Customer Owns the Product Backlog

Scrum Team Cross Functional Deliver Each Sprint

MinimumReleasable Features

(PO with help of other members creates the

product backlog)

(Use burndown charts and dashboards to

track progress)

Scrum Flow

-dp-

Product Backlog• Agile teams implement work

items which are of high priority in the product backlog

• Requirements may be added, removed or reprioritized any time by the product owner

• Requirements which are of high priority are detailed in their description and may be further broken down into user stories

• Product owner is responsible managing the backlog

Product Backlog

High

Low

-dp-

Product Backlog

Features/User Stories

Epics/Features

The Product Planning Iceberg

User Stories

Release Plan

Sprint Plan

Future releases

-dp-

Product Backlog - Planning

Release planning

Sprint planning

Product Backlog

Release Backlog

Sprint Backlog

Features, epics Features,

epics

User stories, Tasks

-dp-

Product Backlog - ExampleId Description Priority Size How to demo Comments1 Service Contract

renewal notificationHigh M Email notification to the Service administrator

2 weeks prior to expiry

2 Log “Field Change Requests” Calls

Medium S Allow creation, modification and deletion of FCR calls with call type as “Field Change Request’

3 Part Pickup reminder Medium M Email notification to the Service administrator for parts not picked up beyond 2 days of service call closure

4 ……. Low XL …..

5 ….. Low L …..

-dp-

Sprint Backlog• Sprint backlog contains a prioritized list of user

stories and related work breakdown tasks to be implemented within an iteration

• Each task item in the backlog contains• Unique identifier• Task description• Task author, owner• Status• Effort remaining in hours• The data is updated in the backlog on a daily basis

-dp-

Sprint Burndown chart• Sprint burndown chart shows the work

remaining in a sprint • The project manager/scrum master is

responsible for tracking this chart on a daily basis

• This chart helps to estimate the remaining effort involved in completing the iteration

-dp-

Sprint Burndown

-dp-

Backlog1. Agile Manifesto and Principles2. Scrum Principles3. Starting Scrum4. Managing Scrum

When to apply Scrum? Visual Process Control – Task Board, Information Radiators Shared workspaces Information flow (?) Other meetings – Discovery sessions, Release Planning Other Artifacts – User Stories, CFD Scaling Scrum Technical Debt Distributed Development

5. Finally

-dp-

Backlog1. Agile Manifesto and Principles2. Scrum Principles3. Starting Scrum4. Managing Scrum5. Finally

-dp-

Finally ….

“Scrum can be used by a bunch of idiots, who don’t know software, tools, but using Scrum they can uniformly generate crap every increment….

Everyone knows at the end of every timebox, where you are …. Which is good”

- Ken Schwaber

-dp-

Agile Fluency Levels

Start Building Code

Focus on Value

• 2-6 months• 45% of teams

Deliver Value

• 3-24 months• 35% of teams

Optimize Value

• 1-5 years• 5%- rare

Optimize for Systems

See programs from business perspective

Redirect teams when needed

Ship on market Cadence

Capture value frequently

Reveal obstructions early

Make excellent product decisions

Eliminate handoffs Speed decision

making

Cross-pollinate perspectives

Stimulate innovation

Optimize value stream

Team Culture Shift

Team Skills Shift

Organization Structure shift

Organization Culture shift

© James Shore and Diana Larsen

-dp-

Agile Fluency Levels• Teams progress faster when they practice advanced

techniques alongside basic ones• Appropriate level of teams depend on organization

• Larger the organization lower the level. For large, bureaucratic organization, Level 2 is appropriate

• High levels have been achieved by smaller, nimbler organization

• Losing fluency: reasons are• New management/policy changes

• Without organization support agile fails• Attrition – assembly new teams for every project, rather

than assigning projects to long-lasting teams

-dp-

Scrum Project Team

“Scrum assumes you are all adults”

Ken Schwaber (co-developed Scrum)

-dp-

Next step…..

-dp-

Agile

Kanban

Product Owners

Scrum Master/ Project

Manager

XP/ Engineering Practices

ScrumbanLean

Lean Software Development

Scrum

Agile HR Practices

Agile Leadership

Test Automation

Program Governance

Coaching

Continuous Integration/ Deployment

Development Projects

Sustenance Projects

Verification Projects

Technical Support

Web Application

Development

Embedded Applications

Legacy Systems

Continuous Improvement

Agile Offshoring

Follow SCRUM o

r Kanban

-dp-

Thank YouDurgaprasad B. Rprasadbr@hotmail.comCell - +91 9845558474