scrum training

Introduction 
Scrum Origins 
Roles
Practices
Planning 
Sprints 
Scaling Scrum
Distributed Teams
Motorola How-to 




1， Introduction 
What is Scrum?
An empirical methodology for maximizing ROI of software development projects;
Scrum is a way of harnessing creativity, the joy of work, the pleasure of teamwork into extraordinary productivity in building complex products;


2, Scrum  Origins 
2.1 Scrum is a Disciplined Management Method
Empirical management & control process
Wraps existing engineering practices, including Extreme Programming, RUP and CMM
Maximizes ROI
Delivers business functionality in <= 30 days
Scalable to distributed, large, and long projects
CMM Level 3 and ISO 9001 compliant
Extremely simple but very hard

2.2 Scrum is Defined
There is a simple, Boolean test for whether a project is practicing Scrum
___Scrum has specific roles
___Scrum has specific practices
___Scrum has specific artifacts
Everything else is not part of Scrum

2.3 Scrum has a mindset
Scrum is commitment-oriented: You’ll be introduced to chickens later.
Scrum is results-oriented: projects produce increments of a shippable product, activities are time boxed, and ceremony is discouraged.
Scrum is disciplined. There are practices you must follow on a specified time table.

2.4 Scrum’s Roles
The Product Owner
The Scrum Master
The Team
Everyone else is not part of Scrum

2.5 Scrum’s Practices
The Sprint Planning Meeting
The Sprint
The Sprint Review Meeting
The Sprint Retrospective
The Daily Scrum
All other practices are not part of Scrum

2.6 Scrum’s Artifacts
The Product Backlog
The Sprint Backlog
The Sprint Burndown Chart
The Release Burndown Chart
The Product Increment
Everything else is not part of Scrum

2.7 Scrum is…    
A management methodology
A discipline
A mindset
A way to obtain measurable ROI
Visible




3.- A Closer look at Scrum

3.1 Scrum’s Roles:
The Product Owner
___Owns definition of success
___Manages ROI through prioritization and release plans
The Scrum Master
___Owns the process
___Teaches the Product Owner and the Team
The Team
___Owns the production and engineering process

3.2 Product Owner:
“The Product Owner’s focus is ROI. The Product Owner directs the project, Sprint by Sprint, to provide the greatest ROI and value to the organization.”
One person;
Sets development schedule by prioritizing backlog;
Can be influenced by committees, management, customers, sales people, but is the only person that prioritizes;
Responsible for ensuring that the most important business value is developed first;
This mechanism ensures that only one set of requirements drives development; and
Eliminates confusion of multiple bosses, different opinions, and interference.


3.3 ScrumMaster:
“The Scrum Master is responsible for the success of the project, and he or she helps increase the probability of success by helping the Product Owner select the most valuable product backlog and by helping the Team turn that backlog into functionality.”
Responsible for establishing Scrum practices and rules;
Representative to management;
Representative to team;
A coach;
Engineering and development skills; and
Agile version of IT project manager
Responsible for:
___Removing the barriers between development and the customer so the customer directly drives development;
___Teaching the customer how to maximize ROI and meet their objectives through Scrum;
___Improving the lives of the development team by facilitating creativity and empowerment;
___Improving the productivity of the development team in any way possible; and,
___Improving the engineering practices and tools so each increment of functionality is potentially shippable.
___Leader and Facilitator


3.4 Scrum Teams:
“The Team is responsible for managing itself and has the full authority to do anything to meet the Sprint goal within the guidelines, standards, and conventions of the organization and of Scrum.”
Self-organizing
Cross-functional with no roles
Seven plus or minus two
Responsible for committing to work
Authority to do whatever is needed to meet commitment
Open, collocated space
Resolution of conflicts



4 Scrum’s Practices
The Sprint Planning Meeting
The Sprint
The Sprint Review Meeting
The Sprint Retrospective
The Daily Scrum

4.1, The Sprint Planning Meeting:
Product Owner describes highest priority features to the Team. 
Team decides what the can commit to delivering in the Sprint.

Segment One: Four Hours
The Product Owner selects the ideal backlog for the coming Sprint and communicates its meaning and importance to the team.
Chickens may be invited to provide clarification, but they are immediately dismissed.
Team may ask questions.


Segment Two: Four Hours:
The Team decides how much it can commit to delivering in the coming Sprint.
The Product Owner answers questions but does not direct the team’s choices. No chickens allowed.
The outcome is the Sprint Backlog.


“The Team decides how to turn the selected requirements into an increment of potentially shippable product functionality. The Team devises its own tasks and figures out who will do them.”



4.2 Technique: Planning Poker
Can we distinguish between 11 and 12?
Between 1 and 2?
What is easier?
Use units that make sense
1, 2, 3, 5. 8, 13
1, 2, 4, 8, …
Include 0 and ½ if you want to

4.3 Sprint
Strictly time boxed to 30 consecutive calendar days: it’s more important to fall short than to slip the date
Activities are visible through the Sprint Backlog and Sprint Burndown Charts
Team builds functionality that includes product backlog and meets Sprint goal
The Product Owner refrains from tinkering with priorities
Within the sprint, there are many possible engineering practices!

If the Sprint requires >20% more work during the Sprint than was planned by the second day after the Sprint Planning meeting, it needs to plan better.
If team members report the same item more than one day, they need to plan better and decompose the tasks to a greater level of granularity.
The Product Backlog estimate is a mutually agreed to budget, even if it is a SWAG. If the team is going to exceed the budget, it needs to escalate the decision. Otherwise, the team introduces scope creep.
Every member of the team is responsible for managing the team.

4.4 Sprint Abnormal Termination
Sprints can be cancelled before the allotted thirty days are over;
Team can cancel Sprint if they feel they are unable to meet Sprint goal;
Management can cancel Sprint if external circumstances negate the value of the Sprint goal; and
If a Sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.


4.5 Daily Scrums:
Daily 15 minute status meeting
Same place and time every day
Meeting room
Chickens and pigs
Three questions
_    What have you done since last meeting?
_    What will you do before next meeting?
_    What is in your way?
Impediments and Decisions

What Is Being Made Visible?
When a Team member says done, what does that mean?
Code adheres to standards, is clean, has been refactored, has been unit tested, has been checked in, has been built, and has had a suite of unit tests applied to it
Development environment for this to happen requires source code library, coding standards, automated build facility, and unit test harness


4.6 The Sprint Review Meeting:
Time boxed to one hour of prep and four hours of meeting.
Team demonstrates product increment to product owner’s satisfaction.
Informality is encouraged. PowerPoint is discouraged.
Chickens are welcome. Comments from chickens are discouraged.
Provides input for next sprint goal.

What Is Being Made Visible?
When the Team says done, What does that mean?
Maintaining trust with customer by not hiding undone work.
Functionality has been code reviewed, functionality has been integrated and built, acceptance tests have been run, and documentation has been created.
QA environment for this has automated acceptance testing tools.

Evaluation Consequences:
Restoring unfinished functionality to the Product Backlog and prioritizing it.
Removing functionality from the Product Backlog that the team unexpectedly completed.
Working with the ScrumMaster to reformulate the team.
Reprioritizing the Product Backlog to take advantage of opportunities that the demonstrated functionality presents.
Ask for a release Sprint to implement the demonstrated functionality, alone or with increments from previous Sprints.
Choosing not to proceed further with the project and not authorizing another Sprint.
Requesting that the project progress be sped up by authorizing additional teams to work on the Product Backlog.

4.7 The Sprint Retrospective
Time boxed to three hours.
Process improvement at end of every Sprint
Team, Scrum Master, and (optionally) Product Owner review the last Sprint
What went well?
What can be improved?
ScrumMaster prioritizes output items based on team direction
Team devises solution to problems
“Project Retrospectives,” Norman Kerth

4.8 Scrum’s Artifacts
The Product Backlog
The Sprint Backlog
The Sprint Burndown Chart
The Release Burndown Chart
The Product Increment

Product Backlog:
List of functionality, technology, issues, prioritized by organizational value
Emergent, prioritized, estimated
Must be no coarser than a Sprint in size
More detail on higher priority backlog
Product Owner responsible for priority
Anyone can contribute
Maintained and posted visibly

Product Backlog Refactoring:
Re-evaluate calculated priority of top 20% of Product Backlog every Sprint and reprioritize accordingly;
Granularize and estimate probable Product Backlog for next Sprint;
Have team allocate 5% of their Sprint time for this activity, which should be compartmentalized to minimize interruption; and
Never allow the Product Owner to go into the Sprint Planning meeting with an inadequate Product Backlog.


Sprint Backlog:
Selected by team at outset of Sprint
Changes during Sprint as information is discovered
Okay to use other engineering practices (stories, micro-iterations), but progress must be reported in the backlog
Time estimates must be updated daily

Task Board


Sprint Burndown Chart:



4.9 Sprint Backlog Estimates
Work remaining reporting during a Sprint updates the estimated number of hours required to complete a task. 
This should not be confused with time reporting, which is not part of Scrum. 
There are no mechanisms in Scrum for tracking the amount of time that a team works. 
Teams are measured by meeting goals, not by how many hours they take to meet the goal. Scrum is results oriented, not effort driven. 

4.10 The Product Increment
Delivers measurable value
“Potentially Shippable”: the process can be halted after every Sprint and there will be some value, some ROI
Must be a product, no matter how incomplete

4.11 Sashimi
Increment of Potentially Shippable 
Product Functionality

4.12 Potentially Shippable Product Increment
Single Use Software: Tested, debugged executable and documentation
Commercial Software: Tested, debugged executable, help, training materials, documentation
FDA Approved Software: Tested, debugged executable, training materials, documentation, requirements traceability, FDA required documentation

4.13 Artifact Redefinition
If all artifacts and documentation required by this organization haven’t been fully defined and aren’t well known to the development team, the following work must be done prior to delivering too many increments:

“Define all documentation and artifacts that are part of each increment of product functionality”


5, Tracking and Reporting- Plans and Their Status.
Forward-looking: Plans
Current progress: Status
Project health: Indicators
Measure and Report:
___What you need to communicate outside the team.
___What you need to tell what’s happening and measure improvements.

5.1 Plans: 
Product Backlog

Plans: Product Backlog as Gantt
Create a master line item for each Sprint
__Duration is 30 days
__Link the Sprints together as dependent tasks
Create sub-tasks for each backlog item
__Each is 30 days long
__No dependencies between them
Useful for mapping to existing PMO process

5.2 Status: Product Backlog
Size of Product Backlog over time
Rate of burn-down over time
Estimation status (if using multi-stage)
__Portion of backlog w/initial estimates
__Portion of backlog with refined estimates

Status:  Basic Release Burndown Chart
Project slope of work remaining to determine probable release date
By ninth month, not enough productivity to hit desired release date in 20th month
Customer reduced expected functionality in release which raised the line for release date



Status:  Enhanced Burndown Chart

Status: Release Burn-Up Chart w/Trends

Status: Burn-down w/Estimate Status

Status: Roll-Up to Business Goals

Status: Dashboard for an Executive

Status: Rate of Development


5.3 Plans: Sprint Backlog



5.4 Status: Sprint Burn Down Chart


Status: Sprint Daily Velocity


5.5  Metrics
Metrics must have a purpose.
Choose wisely – the team will optimize to the metrics.
Metrics are needed for:
Supporting necessary reporting.
Complying with CMM(I), FDA, etc.
Feeding improvement efforts – Six Sigma.
Gather metrics at existing synchronization points with minimal fuss:
Daily Scrums, Task Completion, Backlog Item Completion, Sprint End, Release End

Other Potential Tracking Metrics:
Cost of Product Backlog items:
__Backlog Points Completed / Developer Hours
Time to deliver items (value stream)
Time from code change to test
Bugs that escaped the Sprint
Rework time from design or code debt
Code quality – method size, complexity, etc.
Satisfaction surveys
Retrospective results & Action items



6,  Scaling Agile: Organizing Large Products

6.1 Scaling
Type of application
Type of system
Team size and location
Duration
etc.

Anything that is different about the upcoming project that is different from what you are prepared to do.

6.2 Requirements For Scaling
Co-ordination
Communication
Parsing
Coupling & cohesion
Performance models
Proof of compliance
Traceability
Development environment
Development practices
Artifact definition
Detailed architecture for parsing among multiple teams

Anything that has to be done for an upcoming project to scale it.  

6.3 Staging Scalability Requirements

6.4 How Agile Methods Scale

6.5 Multiple Teams
Synchronize within teams
Synchronize across teams


6.6 External Dependencies
Within the Sprint cycle
__Have the dependency commit to your team’s Sprint goal
Outside the Sprint cycle
__Use prioritization of Product Backlog to synchronize dependencies; readjust as necessary.

6.7 Multiple Team Integration
Teams separated along layers
One code base, continuous integration, work tested at integration layer and integration bugs passed back for immediate fixing
Teams separated along functional lines
One code base, continuous integration, work divided by functionality

6.8 Scaling Recommendations
Correlate team organization to subsystems or modules with minimal cross-over.
Implement development infrastructure to support number of developers and location of developers so it acts as a single development environment.
Implement meeting and communication infrastructure optimized for number and location of teams. 
Develop standards, guidelines, training courses, templates, and frameworks to minimize the coordination required for intended scaling.
Develop coordination mechanisms for multiple teams.
Ensure each team has sufficient resources. Carefully consider shared resources.
Implement ways to develop a common culture 
across teams.



7  Distributed Agile: Dispersed Teams

7.1 Dispersed Team Recommendations
Co-locate team as often as possible, especially at inception and key milestones. Rotate members around.
Invest in (and plan for) tools that provide a shared environment. Plan to experiment.
Establish a single global instance of project assets, easily accessible by all.
Try virtual team building (team wiki w/bios & photos).
Establish known hours, with as much overlap as possible.
Apply high cohesion and low coupling to allocation of work to sites.
Develop a shared team vocabulary.
Don’t let anyone go dark.
Apply Scrum-of-Scrums concept when mass remote
meetings unproductive.


7.2 Dispersed Development
Xerox, Pearson Educational (Sub-Contractor model)
__Development of requirements, specifications, architectures, and design at business
__Development of code offshore.
__Use iterative, incremental development offshore, monitored by the two inspect/adapt cycles (Sprint Review, Daily Scrum)

ThoughtWorks(Single, Virtual Team Model)
__Build an infrastructure such that everyone is an equal employee and location is irrelevant.
__Spend some savings to ensure people know  and work with each other.



8, Tool Support: For Scrum Teams

8.1 Tool Support For Scrum
Doing Scrum requires no tools
Using a tool will not make you do Scrum
Identify your metrics and reporting needs first
Find tools that work with you
Start simple and stay that way
Find tools with unobtrusive touch points
Assign a Toolmeister to handle tool usage

8.2 Type of Tools Used by Agile Teams
Collaboration Tools
__Whiteboards, wiki, NetMeeting
Communication Tools
__Talking, eMail, IM, video conferencing
Management Tools
__Big charts, spreadsheets, tracking tools
Development Tools
__Version control, build (Ant), automated testing (xUnit, Fit), integration (Cruise Control), IDE w/refactoring support (Eclipse, RefactorIT)

8.3 Tool Support
Simple spreadsheets and documents


Version One (www.VersionOne.net)

Rally (www.RallyDev.com)

ScrumWorks (www.ScrumWorks.com)


9 Scrum In Practice-When Reality Kicks In

9.1 How does Scrum Handle…
Engineering Documentation?
Coding and Design Standards?
Non-functional Requirements?
Where does the “QA Team”, “Chief Architect”, “Oracle Guru” or “PMO” fit?
What happens when…
__There’s a SNAFU within a Sprint?
__The team decides it needs more than 30 days to get anything meaningful done?
__The team finds itself working on ‘minor requests’
__The product owner is too busy to participate?

9.2 Why are sprints 30 days long?
Increments that are too large are inefficient: need artifacts, too much planning
Increments that are too small are inefficient: hard to deliver increments of value
People are lunatics

9.3 How Big is a Team?
Typically 5-10 people
Mike Cohn has led teams of 100+
Ken Schwaber has led teams of 600+
Obviously, very large teams are a very special case
“Scrum of Scrums” technique

9.4 Some reasons to avoid Scrum
Your current software development produces acceptable results
You are a ‘chicken’
You are a pig, but you work in a ‘chicken coop’
Your project cannot be decomposed into good, increment-able requirements (“big ball of mud”)

9.5  More reasons to run from Scrum
Your engineering practices embrace heavy, up-front design, the construction of baroque frameworks, and throw-it-over-the-wall attitudes towards QA.
Nobody can agree on ‘done-ness’
Your management practices embrace ‘do it now and forget what I told you to do yesterday’.
The software really isn’t a core competency and that’s okay because the software isn’t mission critical.

9.6 Reasons to consider Scrum
This slide left intentionally blank.

Based on what you have seen and heard, 
would your org benefit from trying Scrum?

9.7 scrum flow



9.8 Recommended Readings
Agile Estimating and Planning, Mike Cohn, Prentice Hall PTR, 2005
User Stories Applied, Mike Cohn, Pearson Education, 2004
Extreme Programming Explained, Kent Beck, Addison Wessley, 2000
American Ground, William Langewiesche, North Point Press, 2002
The Blind Men and the Elephant: Mastering Project Work,
David Schmaltz, Berrett-Koehler Publishers; , March 2003 
Corps Business, David Freedman, HarperCollins, 2000
Industrial Dynamics, Jay W. Forrester, MIT Press, 1961
Complexity and Management, Ralph D. Stacey, Routledge, 2000
Project Retrospectives, Norman Kerth, Dorset House, 2001
The Art of Focused Conversation, Brian Stanfield, New Society Publishers, 2000
The Alphabet Versus the Goddess, Leonard Shlain, Viking, 1998
The Remembered Present, Gerald Edelman, Basic Books, 1989
The Dreams of Reason, Heinz Pagels, Simon and Schuster, 1988
The Knowledge Creating Company, Nonaka and Takeuchi, Oxford University Press, 1995
The Pragmatic Programmer, Hunt and Thomas, Addison Wesley, 2001
Lean Software Development, Poppendieck and Poppendieck, Addison Wesley, 2003
The Capability Maturity Model, Paulk et al, Addison Wesley, 1994
Agile & Iterative Development, Craig Larman, Pearson Education, 2004

9.9 Resources
Control Chaos:
http://www.controlchaos.com 
Agile Alliance:
http://www.agilealliance.org   
Scrum Alliance:
http://www.scrumalliance.org

Based on:
Certified ScrumMaster Training material and
Reg Braithwaite presentation
http://www.braithwaite-lee.com/opinions/scrum.ppt  



10 Some Backup Stuff
That does not necessarily fit into the session

10.1 Scrum and Extreme Programming





10.2 Scrum Compliance with CMM



10.3 Multi-team or Offshore Development
Martin Fowler observed at a recent workshop (Canadian Workshop on Scaling XP/Agile Processes, Banff, Alberta, Canada, February, 2003)., “scaling agile projects is the last thing you should do.”
Agile is optimized for a single team of developers working in an optimized environment
Don’t scale Agile up – scale projects down!!

James Coplien. Borland Software Craftsmanship: 
A New Look at Process, Quality, and Productivity.  
Proceedings of the 5th Annual Borland International Conference, Orlando, 1994.

10.4 Managing a Release
Business determines when a release is needed, what functionality it must contain, and what is an acceptable level of quality and cost
Development determines how long it takes to build the release.
Development creates preliminary estimates
Development refines the estimates as priority increases
Development selects the product backlog for development, each Sprint.
Business focuses on business value derived from the release.

Customer Collaboration over Contract Negotiation
80% of the business value can be derived from 20% of the functionality

Agile Collaboration - Value Driven Releases 
business value = f(cost, time, quality, functionality)

Fixed Price Contracts
cost = f(time, quality,functionality)

10.5 Beware of “Core Functionality”


Burndown Chart … the velocity of turning requirements into potentially shippable increments of functionality. 
The core functionality line shows the impact of continued poor quality practices from the era of opacity. Although poor quality may SEEM necessary at the start of a company, it is NOT a sustainable practice.


10.6  Project QuickStart

www.controlchaos.com/quickstart.pdf

Participants: Team, Product Owner, ScrumMaster, chickens, teacher

Agenda
__Teach Scrum concepts, theory, practices
__Present project vision, goals, timelines
__Teach Sprint planning
__Define Product Backlog for at least three months
__Brainstorm about overcoming impediments
__Brainstorm about Product Backlog for next Sprint – team commits
__Team defines Sprint Backlog
__Teach daily Scrum, Sprint review, Sprint signature, and management
__Discuss engineering tools and practices