Short notes derived from Youtube video

What is scrum

scrum is for project based work

iterative
lightweight
simple to understand
transparent
built in quality
flexible adaptable
each sprint delivers functional, tested, implementable code
product owner-part of team represents business, participates daily
short sprints. at the end of each sprint, there is a sprint retrospective

scrum roles
1) scrum master-not a project manager, is guide, facilitator, participating team member, has no
authority but lot of influence
2) product owner-has authority on what is done. reports to business owner
3) team-authority on how to accomplish. self organizing and managing team
4) sme-not part of team. called in as needed
5) business owner-person with dollars and need. appoints product owner

releases and sprints

1) product 6-12 months
2) release-product comprised of release. add business value. 1-2 months

3) sprint-release broken into sprints. very short timeframes 2-3 weeks. accomplishes user stories

no change management or approvals for additions or deletions

scrum rituals
1) daily scrum - 15 minutes standup meeting. what did we do yesterday. what to do today. discuss
issues/problems
1) planning meeting-first half: product owner selects stories for next sprint second half:team validates
whether they are ready
2) scrum review at end of sprint. present results. declare sprint complete
3) scrum retrospective- what worked, what did not. do process improvement

scrum management
it is lightweight
1) burn down chart-main. how well are we doing
2) story cards-product owner defines the what. hand written index cards maintained on cork boards
3) combine story cards on story cork board to give product release backlog

product owner selects next high priority stories from product backlog. this creates the sprint backlog.
sprint backlog is input to the burn down chart

4) velocity- how long is a story. how much work can a team do in a sprint

where does agile fit in?

scrum is most popular agile process. it is the management light weight software development process
scrum applies tdd, pair programming, refactoring, recognises techical debt, continous integration

scrum produces small usable results delivered often

scrum and traditional approaches

scrum has analysis, design, development, testing and implementation of each user story done by team
member. implementation includes documentation
scrum roles
Scrum Master
1) main job remove roadblocks
2) ensure scrum principles are applied
3) has no managerial authority
4) he is not a project manager
5) sometimes not a full time position
6) he can be a working team member

product owner (most important position)

1) owns the product vision
2) identifies work for the team (creates and prioritizes user stories)
3) approves each sprint
4) manages the backlog
5) must be available 3-4 hours every day collocated
6) understands what the business wants and agrees to change in vision
7) needs to demonstrate, vocalize, show, document the product vision
8) needs to make the product vision visible , understandable and undestood by the team

Team

1) picksup the story. analysis, design, development, testing, documentation

2) accountable to each other
3) total authority on how
4) includes scrum master & product owner-no authority on how
5) self organizing and self directing
6) 5-7 people

Subject Matter Experts

1) not part of team
2) supplement product owners business knowledge
3) no project authority or responsibility
4) called in by product owner

Business Owner
1) The person the product owner reports to
2) provides resources($) to the project
3) Ultimately owns the final product
4) not part of the team
5) delegates full responsibility for product vision to product owner

Rest of the organization (Not Part of scrum)

1) Casual Onlookers
2) Supporters or opponents
3) Not to be ignored

4) Rules, Standards and Procedures (Scrum team will adhere to)

Scrum Meetings
1) Daily Scrum - 15 minutes standup quick status
2) Planning Meeting - select stories and secure commitment
3) Sprint Review - demo of the results and secure acceptance that the stories are done
4) Sprint Retrospective-lessons learnt, process improvements

Daily Scrum-15 min daily standup. all team memebers get together to discuss the sprint
1) Mandatory- sm, po and team should attend
2) stand up
3) consistent time and place
4) topics-each tem member should tell what happened yesterday, plans for today, problems and
issues(sm to interfere)

planning meeting-product planning (product owner and business owner develop product vision. Outside
scrum process) product vision should be short, distinct, clear, understandable and visible. Product
roadmap is developed which becomes input to release plan, release planning (product owner segments
vision into releases), sprint planning (select and commit stories for each sprint, story selection(done with
product owner. review backlog and select next high priority stories), plan confirmation. sprint duration
1-4 weeks. 4 weeks - 8hrs meeting). release equates to an implementation

stories are based on priority, consistency and importance.

business stories, team stories

Plan Confirmation:
1) Determination of done

2) enough detail
3) estimating effort
4) make trade offs
5) strategy to make it happen

Sprint Review: At end of sprint. short 4 weeks-4 hours

1) Inspect Results
2) Acceptance of done
3) Next Steps
4) Informal, no prep, show & tell

Sprint Retrospective: 1 day after sprint review

3-4 hours for 4 w, 1-2 hrs for 2w

1) Review process, tools, team

2) Identify improvement areas
3) create improvement plans

Scrum artifacts

user story
product backlog-work needed or remaining in total
Sprint backlog-work assigned to sprint
Progress charts-Burn down/burn up charts

User Story- fundamental artifact. represents all the work required. should be presented on an 3x5 index
card, hand written. 3 parts. 1 and 2 should be complete to include in the sprint
1) story-as a user, i need to do x so thay y is achhieved
2) definition of done-measure of user stories done
3) business value/priority- product owner assigns
this

Product Backlog: Contains

1) Sprint Ready Stories: As per product owner these stories contain all the details

2) Business Stories: Complete stories but need some work

3) Epics: Large and need to be broken down in user stories. Moved to Business Stories

4) Documentation: User guide, operations guide. Create a user story for this. Should have priority and
value

5) Training: User training on function

6) Technical Debt: Eg. Inefficient search

7) Team Stories: Eg. Need training, a new server. Permission to work in a sprint

Sprint Planning meeting creates sprint backlog. Show resource wise 'To Do', 'In Progress' and 'Done'

Progress Charts

1) Burn down charts - Work Remaining. Outstanding stories, Days in sprint

2) Burn up chart - Work Completed. Stories completed, Days in sprint

Completed Stories cork board

Scrum Master

1) Remove roadblocks
2) Ensure scrum principles are applied
3) No managerial authority but influencial authority
4) Not a PM
5) Not always a full time position

Characteristics
1) Trusted
2) Egoless
3) Commited
4) Good interpersonal skills
5) Knowledgable
6) Coach
7) Refree
8) Conscience

Other roles & responsibilities

1) Staff the team 5-7
2) Support the team
3) Work with the product owner
4) Instill scrum into the team
5) Enforce DONE
6) Keep the focus
7) Watch the product backlog. Ensure grooming. There should be 2-3 sprint ready stories
8) Ensure corporate policies are adhered to
9) Can be a team member
10) Own the sprint retrospective. There should be lessons learned. Process improvement should take
place

Product Vision & Product Backlog

Product Vision: Clear, consice, well articulated, understandable statement

1) Not truly scrum: All projects have a vision

2) Is critical to scrum
3) Business Owner "owns". Participates in creating.
4) Product Owner "delivers". Develops product backlog from product vision.

Product Backlog

1) Most important artifact

2) Defines the project

3) Evolutionary. Reflects current needs
4) dynamic
5) product owner only can remove items
6) product owner accepts all items

Grooming - Product owners responsibility

1) Add detail to stories

2) Definition of done
3) Business Value: Why should we do this story
4) Breaking down epics
5) Breaking down stories
6) Removing stories

keep 2-3 sprint ready stories only

Non Business Stories

1st approach
create story for each
1) Technical Debt
2) Bugs/Defects
3) Project/Team Requirements
4) Documentation
5) Training

6) Implementation Preparation
7) Implementation
2nd approach
Never plan a sprint with full capacity
5) Team "understands". Buy in to. Ensure every action supports the vision
11) Protect the team

Prioritization

1) Business need
2) Team need
3) Organizational need
4) Technical Prerequisite
5) Logical Progression

Selection for sprint

1) Prioritization
2) Sprint Capacity

What is done: Simple acknowledgement

Story, Sprint, Release, Product have done criteria

2 hr Design needs 5 min peer review

2 hr code needs 5 min peer review

Test Case peer review

Unit test coverage
Successful full build

What is done? at story level

1) Universal components
2) Story validated
3) Automated Tests
4) Non coding stories

What is done? at sprint level

1) Product owner review
2) Sprint review
3) Sprint Retrospective

What is done? at release level

1) Acceptance criteria
2) Implementation plan
3) Training
4) Support plan

What is done? at Product level

1) Product Vision satisfied

Release and sprint planning

1) Release planning
2) Sprint planning
- Story selection with product owner
- Plan confirmation product owner optional. At the end of this sprint planning meeting, we get the list
of all stories to be completed in the sprint
3) Story Points-Work/time required to complete a story
4) Velocity- story points within a story

Release Planning (open ended, guide, meant to change). Guide to selection of stories, prioritization of
stories and keeps the team focussed.

1) Optional but recommended

2) Medium term target-3 to 4 months.Sprint is 2 weeks. After 6-8 sprints, what business value do we
hope to present for realization
3) Goal is implementation
4) Based on product vision

Sprint Planning

1) Story selection-Sprint ready stories from product backlog are prioritized. Done with product owner.
Product owner reads out each story as part of story selection. Team discusses the story. What is "done"
should be done for each story. 2 weeks spint-2 hours story selection

2) Plan confirmation-2 hours for 2 week sprint. Who will do what. Will be entered in sprint backlog. Each
story assigned to resources. One person might do analysis, dev and testing for one story if it is small.

After the two hours, present the plan to product owner.

In the last 10 minutes of the total 4 hours, develop the sprint goal with the product owner. Posted in
workspace. "This sprint will deliver customer maintenance to the business by accomplishing all stories
for add modify delete customers in the system."

Story Points

1) Size of effort for each story. Can be broken into task and task points. Relative estimates.

Velocity: Standardized statement of teams capacity per sprint. # of story points per sprint.

Yesterday's weather-# of story points in last sprint

Scrum Estimating

1) Effort to complete a story

2) Story points - Effort to complete a story
3) Velocity - # story points in sprint
4) Estimating game
5) Planning poker
2) Confirmation of plan

Effort to estimate a story

1) Hours of work required to complete a story

2) Estimate Relative to others

3) Fibonacci Numbers - 1,2,3,5,8,13,21...

2 Exponential - 1,2,4,8,16....

4) non coding story

Story Point

1) 1 story point = "smallest story"

2) 1 story point = "average story"

Relative measure of amount of work to complete a story

Velocity - Standardized statement of team's capacity per sprint. # of story points. Not a performance
metric

Estimating game

Part 1- Assemble the team, take all stories.Split into simple, average and complex stories. Option of
challenging or (selecting & placing). Stories placed in ascending order of complexity

Part 2 Sizing 1,2,4,8,16. Select the ranges for all stories. We get 1story point stories, 2story point
stories.....

Planning poker

pick stories and hold up story point cards. Under agreement, put story under that story point column

A Sprint: 2-4 week repeating development cycle

Sprint Guiding principles

- Make it work - Minimum amount of work to complete the story

- Make it fast

- Make it pretty - gold plating

- Always produce working software

Sprint planning is part of a master release plan

Sprint review and sprint retrospective (lessons learnt) follows the sprint.

Sprint Artifacts-Sprint backlog, burn down chart (from daily scrum)

Sprint vision/goal is optional

Sprint Activities

1) Team swarm-Multiple members of a team helping/focussing on a story

2) Chores - 20%. Things that must be done but no one wants to do. Big chores are team stories. Eg.
Updating the burn down chart.

3) Team grooming - 10%. Includes product backlog grooming.

4) Estimating - Create an estimating story or estimate individually

5) Conversations - casual conversations With the product owner

Sprint Lenght - 1-4 weeks or 2-3 weeks

1) Short enough to be nimble. Longer the sprint, higher the likelihood of change
2) Long enough to deliver value
3) Pick a lenght and stick to it. Based on sprint retrospective change it

Changes to sprint

1) Too many stories. Work with product owner and select stories to be dropped.

2) Not enough stories- Work with product owner. Find the next high priority stories that can fit within
the remaining capacity

3) Changing a sprint - Negotiate in case not viable

4) Cancelling a sprint - Try to minimize such instances

Daily Scrum

Mandatory 15 minute standup held at a convenient time. Inspection & adoption review(what's going on,
what can we do to improve). Meant for team action and decision making. All team members (including
scrum master (ensures that this happens) & Product owner) attend. Non personal and story focussed.
Product owner has no rights to change the plan. Business owner, SME can observe

3 questions-What did I do, What am I going to do, Issues

What happens after daily scrum

1) Scrum master removes impediments

2) Detailed/Technical discussions
3) Sprint replanning sessions
4) Resolve other issues
5) Story additions/removals. work with product owner.

Tracking Progress

- Release burn down chart- least precise. stories outstanding for release v/s sprints in release
- Sprint burn down chart-stories outstanding v/s days in sprint. Instead of tracking stories, track story
points or task points. Story burn up for others, story point burn up for po and sm
- sprint burn up chart
- sprint done chart. No of dones v/s days in sprint
- Sprint backlog

- Product v/s done board(stories completed)

Dealing with changes

Changes can happen at

to the project-business needs

to the release-add,change, remove, cancel
to the sprint

changes to scope-add scope by adding stories

modify stories, remove stories

scrum is incremental development of business solution

we can cancel the project but need to decide what to do with existing code that has already been
written and in production

Changes to the release- medium term strategy 3-4 months What do I expect to deliver, implement

adding to the release-add more stories. If needed, Extend timeline of sprint by 1-2 sprints

Removing from the release-shorten the release

Cancelling the release-stop work. Look at the business value that the code already written has.

Changes to the sprint-minimal changes. PO has authority to change the sprint by adding stories. Team
should encourage PO not to change sprint.
Business changes
New stories-Add to product backlog
Changes to stories
Removal of stories

Team changes
New stories
Removal of stories
Cancelling a sprint-resist. If inevitable, request time for revert changes

The Product Owner

1) Owner of backlogs
- Product Backlog - No one adds stories without product owners approval. Single point of authority
- Sprint Backlog-Product owner owns stories. No one adds stories without product owners approval.
Accepts stories as complete. Reviews and expands stories with team
2) Groomer
- Owner of grooming
- Involves SMEs as needed. This is done quite often. PO must ensure SME work is ok
- Story details at a level to encourage future conversations
- Definition of done

3) Agreer of done
- Reviews definition of done evidence

- Reviews working code - Show tell Sprint review

- Validation of done
4) Relationship with team
- Is a team member
- Owns sprint backlog
- Understands and agrees with sprint plan
- Represents business
- Must be available 50% of time
- Drive the team to deliver results
5) Relationship with scrum master
- can be adversarial. Eliminate through education, proof of delivery, results, trust
- not same person

Sprint review and retrospective

Sprint review (immediately after last story is complete) - Show & tell, Commitment of done, develop
new stories if needed. 1 hour/1 week sprint
should be held in team space

Sprint retrospective (responsibility of SM) - Lessons Learned, Process improvement, after every sprint
after the sprint review 1hour/1 week sprint
who attends - only the team (po, sm, team)
held in team or neutral workspace

Agenda
1) Set goal

2) Focussed discussion
3) Discuss options
4) Develop action plans-10 mins roughly
5) Commit to improvements
Intraspective(SM) - on demand review of issues
Issue identification
Agreement issue exists
Honest discussion
Actions needed
Action plan

Backlog Grooming- Going through product backlog and making sprint ready stories

- Prioritization: Making sure the team, PO, SME are working on the right stories(the ones that we are
doing next

- Story Grooming- Adding details and what is done with focus of making stories sprint ready

- Epic grooming - decompose epics into stries

When is a story "well groomed"

- Less than 10 min conversation is needed. Getting final question answers

- What is done is testable and measureable. What is done should have a clear single statement of
completion. Need to know whether what is done was a success
- 2-3 sprints only should be well groomed in order to be prepared for changed

-Well groomed story are estimated for story points

When is a story over groomed

- No conversation is needed. every detail is mentioned

- end code is perfect

Prioritization - Product owners responsibility since he know business needs

- Ensure the right stories(immediate horizon) become sprint ready
- product owner owns priority
- team influences for technical dependencies

Story grooming (Built in the sprint)

- can be done by team, po or sme. Can happen dynamic and adhoc

- need to have story time/grooming party for grooming (10% time or 4 hrs per week)
- Involves PO, Team and SME 2 hrs at begining of week and 2 hrs at end. PO is the scribe
- Team raises stories needing more detail
- PO/SME provide story details, what is done

Epic Grooming(same time as story grooming)

- Breaks epics into smaller epics

- Breaks epics into stories - based on priorities
Epics are important to keep product backlog readable because detailed stories clutter the product
backlog

Make epics different with a different colored card

Writing User Stories

1) What is a user story

2) What is done

3) Characteristics of a good story

4) Type os stories

5) Examples of stories

6) Storeotypes-Template/Sample

7) Dont forget the back of the card-indicates what is done. Write notes

User Story - Plain index card 3X5. Bullet style

As a (user)
I need to(do something)
so that (a result is achieved)

Definition of done

Business value/Priority-added during grooming sessions. Priority does not get set until later

What is done
Written after the story is complete
Pass or fail criteria mesadurement
Translate into test cases (automated)

Type of stories

Business Stories
1) Coding Stories
2) Analysis stories-better understood something. descussion based. Time boxed
3) Exploratory Stories-experimental. often called spike. code based.Time boxed

Storyotypes - Templates, models, samples

Samples of good stories

analysis storyotypes
code storyotypes
Exploratory storyotypes
Templates for stories-model

Team and Business Dynamics

Understand the business structure-is business scrum ready?

-Supporters-Keep them close, uptodate
-neutral-convert to supporters
-opponents-try to convert
-find a senior champion
-Expect to give lots of tours
-Expect to educate
-Expect lots of criticism
-Product owner knows all
-Product owner and identified SMEs who have known area of expertise
-Product owner and unknown SMEs
Problems:
- SMEs(or team) bypass product owner
- Engaged Business owner running stakeholder interference
How to work with SMEs
-Engaging SMEs with POs knowledge
-Managing SMEs
-Trusting SMEs
SMEs have competing priorities and requirements-not part of the scrum team. They are part of the
product team or organizational team

Scrum master and Roadblocks: lot of roadblocks are often not project based, scrum master typically not
able to control: escalate to PO, BO

Traditional IT

roles threatened by scrum

PMs-dont fit
DBAs-Fit. Part time
Architects-Fit. Part time
BAs-Fit. Part time

Non scrum areas

-Traditional development because of legislative reasons etc. This will evolve.
Traditional PM
Package Implementation
Outside Vendors-Fixed Price
Ongoing Management Reporting
Look forways to be scrum like. Adjust expectations and contracts
Ongoing Management Reporting

Compliance and certification

ISO/CMMI/ITIL
Invite the auditors at the begining of scrum and get it preapproved
Look for creative solutions-photocopy the artifacts
checklists-build compliance in
scrum software
Bring in an ISO scrum expert

Technology and process debt

1) Technology debt-Fixing the code

2) Architechture definition
3) sprint zero-Getting ready
4) database admin
5) Refactoring

Technology debt is inevitable because we focus on just enough and we write some bad code, we wish
we could do better. This is the biggest enemy of scrum. Make commitment to fix technology debt. We
create a team story for fixing. Tech debt-kills productivity and quality. Takes longer to understand and
implement but is necessary

Sources of technology debt

1) Time-Minimal effort within SP estimates. Less than optimal code
2) Lack of automated tests
3) Scrum design-Just in time
4) Lack of documentation

Preventing debt
- commitment-team to do best
- create team stories
- Peer reviews
- adaquate testing(automated)
- Refactoring-code improvement

Archiecture Definition

- no big upfront definition

- just enough architecture

- Build it as you go
- Fearless foreward progression-dont worry about what's next
- just enough architecture

Sprint Zero no fixed lenght-Initial Architecture

-Project Infrastructure
- norms and processes
- minimal database
- story time

Database Admin
- Minimal database
- Be Prepared for change
- Watch Technology debt
- Be prepared to refactor
- can perform other activities

Refactoring
-continuous design for every story (code improvement). Take timeout and ask PO permission to refactor

Agile Development Techniques 1

1) Test Driven Development-Test cases first and then develop as per test cases
2) Pair Programming-One codes and 2nd inspects
3) Refactoring-Bad code made better

4) Collective Ownership-No one feels 'they should not change code'

Test Driven Development- Most recommended

1) Creates well defined & verifiable code
2) Write test cases(preferably automated) that satisfy requirements first then write code to ensure test
passes
3) Reduces defects 40-100%

Pair Programming-Most commonly know and most contentious

1) 2 heads working on 2 stories better than 2 heads working on same story. Better performance and
throughput
2) Self correcting process
3) Better knowledge sharing
Driver codes/Rider Validates & looks ahead. Driver & Rider switch as part of completing a story.

One person writes test/other writes code & then switch

Requires adaquate desk space

Refactoring-Takes bad code and makes it better. Rewrite complex code by breaking into structured
code. Ket agile dev technique. Done with confidence with automated testing

Collective Ownership
1) No one owns a piece of code
2) pair programming encourages
3) Peer reviews encourages

4) Automated testing provides confidence

Agile Development Techniques 2

1) Continuous integration-checking code in to build and test frequently

2) Spikes-exploratory investigation
3) Branches-refactoring
4) Cleanup stories
5) Release sprint

Continuous integration based on automated testing

1) Code/Build/Test-regularly. Segmented build/test
2) Nightly build-System wide test
3) No code checked out overnight

Spikes-donot produce prod ready code

1) Deliberate exploration-Try & Explore and find which way works best
2) Dynamic design
3) Progressive Architecture

Branches-Similar to refactoring but less urgent

1) Takes complex code and simplifies
2) Automated testing

Cleanup Stories

1) Implement change-Change request to existing story

2) Missed functionality-Falls short
3) Make it faster
4) Make it pretty

Release Sprint-2 week to made the code prod ready

1) Performance testing
2) User Documentation
3) Training
4) Operational readiness- Operation training

Delivering large projects with scrum

1) Scaling the team
2) Scaling the product owner
3) Scaling Product Backlog
4) Scrum of scrums
5) Synchronizing sprints & releases

Scaling the team

1) Multiple scrum teams-4 teams of size 6

2) Share team members frequently
3) goto each others daily scrum
4) Automate tools

5) Dedicated cross functional team

6) Co-locate teams

Scaling the product owner

1) Critical for large projects
2) Much more than an SME
3) Product owners scale differently than teams
4) Roles & Responsibilities must be defined
get multiple POs. Split the vision between the POs

Scaling the Product Backlog-Does not scale

1) epics are critical
2) automated tools are effected

Scrum of scrums-cross information sharing

1) Scrum masters attend, might bring along some technical person

2) Doesn't need to be daily
3) Doesn't need to be 15 minutes
4) Follow same approach
Scrum of scrms of scrums....are ok

Synchronizing Sprints & Releases

1) Sprints can be out of step. T1 can finish on Monday, T2 on Wednesday
2) Releases should be aligned

3) Virtually impossible to plan multiple sprints concurrently

Distributed Scrum-International, worldwide

- Distributed by team
- Distributed within teams
- Making it work
- Tools are key

Distributed by team (US, Canada). Each team works as a scrum team

- Very similar to large scrum. Harder to move team members around. Can move team members from
India to US for 6 months or so.
- Best to match SMEs with team

Distributed within team can have US, India and canada members
- Select teams carefully
- Organizational knowledge, culture

Making it work
- Everyone committed to make scrum work in distributed mode
- Understand cultural norms
- Face to face helps. Send the team to the meetings
- Develop team norms-honour time zones
- Ensure there is time for small talk
- Adjust to fit time zones

- Tools are key: Scrum tools for product backlog, product artifacts and progress chart, more
documentation likely needed

Scrum process improvement

- There are very few rules-Lots of room for innovation

1) Scrum rituals
2) Scrum artifacts
3) Agile Principles
- Sprint retrospective
1) Key process improvement process
2) Keep doing it
3) Keep looking for improvements
- Apply scrum incrementally
1) Find principles that will work
2) Fine tune first
3) Then select the next
- Do organizational retrospectives
1) Do scrum of scrum retrospectives
2) Talk to Business owner, SMEs etc
3) Query the executives
4) Take scrum refresher training
- Measure results
1) Capture metrics
2) Compare scrum to other projects
3) Quote industry stats

4) Toot your own horn

- Challenge team to try new agile techniques
1) Test driven development
2) Pair programming
3) Refactoring
4) Collective ownership
5) Continuous integration
6) Spikes/Branches
7) Cleanup stories
8) Release sprints

Dealing with organizational resistence

- Team Resistance
1) New/Change
2) Career Path
3) What if I dont like
4) What if I am no good at it
5) What if it does not last
- Business/Product owner resistence
1) No guarentees
2) No predictability
3) Time required
- Organizational resistence
1) Another IT Fad
2) Repeat from Business resistance

3) Executives fear anarchy

- Administrative resistance
1) Facilities-dont want to reorg the physical workspace, resists posting on the wall
2) Human resources- issue with leaderless teams. Work with HR to change annual review process.
- IT resistance
1) Architecture-Use JIT architecture
2) Database
3) PMO-large PMOs like weekly status reports. Change to scrum process groups
4) Business analysts
5) Traditionalists

How to get started with scrum

-Small(1 team)/Medium(6 teams) or large projects (All-In)

1) Small is cheaper but less noticeable
2) Success is easier but less important
3) Small should create champions
4) Small has less risk which position scrum correctly
5) Large removes "the competetion"
6) Large ensures "Full-cooperation"
-Grow/Hire or consult
1) Grow is slow but shows org commitment
2) Hire risks alienation
3) Cosultant walks out of the door after the KT is done
-Pulic or private

1)Private flys under the radar until "success is declared"

2) Public ensures everyone is watching. Public doesn't give an easy out
-Pilot-focussed attempt at showing results
1) Characteristics of a good pilot-should not be mission critical but should be important. Not too small,
not too large. Business/Product owner have to be onboard. Team has to be respected.
- Next steps
1) Repeat until everyone is a believer
2) Divide & Conquer
3) Education & Certification
4) Scrum Process Improvements