Scrum for interviews

8/18/2019 Scrum for interviews

1/38


2/38

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. discussissues/problems

1) planning meeting-first half: product owner selects stories for next sprint second half:team validateswhether 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


3/38

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 teammember. 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


4/38

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


5/38

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 andissues(sm to interfere)

planning meeting -product planning (product owner and business owner develop product vision. Outsidescrum process) product vision should be short, distinct, clear, understandable and visible. Productroadmap is developed which becomes input to release plan, release planning (product owner segmentsvision into releases), sprint planning (select and commit stories for each sprint, story selection(done withproduct owner. review backlog and select next high priority stories), plan confirmation. sprint duration1-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


6/38

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


7/38

User Story- fundamental artifact. represents all the work required. should be presented on an 3x5 indexcard, 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 andvalue

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'


8/38

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


9/38

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 takeplace

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


10/38

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


11/38

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


12/38

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


13/38

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 listof 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 ofstories 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. Eachstory assigned to resources. One person might do analysis, dev and testing for one story if it is small.


14/38

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 inworkspace. "This sprint will deliver customer maintenance to the business by accomplishing all storiesfor 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


15/38

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 performancemetric

Estimating game

Part 1- Assemble the team, take all stories.Split into simple, average and complex stories. Option ofchallenging 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 pointstories.....


16/38

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


17/38

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 withinthe remaining capacity

3) Changing a sprint - Negotiate in case not viable


18/38

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 (includingscrum 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 storypoints 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


19/38

- 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 beenwritten 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.


20/38

Changes to the sprint-minimal changes. PO has authority to change the sprint by adding stories. Teamshould 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


21/38

- 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, developnew 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


22/38

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 aredoing 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 ofcompletion. 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


23/38

-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 productbacklog


24/38

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)


25/38

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


26/38

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 theproduct team or organizational team

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

Traditional IT


27/38

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


28/38

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 wishwe could do better. This is the biggest enemy of scrum. Make commitment to fix technology debt. Wecreate a team story for fixing. Tech debt-kills productivity and quality. Takes longer to understand andimplement 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


29/38

- 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


30/38

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 testpasses

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 andthroughput

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 structuredcode. 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


31/38

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


32/38

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


33/38

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


34/38

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 fromIndia 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


35/38

- Tools are key: Scrum tools for product backlog, product artifacts and progress chart, moredocumentation 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


36/38

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


37/38

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


38/38

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

Documents

Scrum for interviews