1. Leading a Self Organizing Team
1.1. Containers
1.1.1. Change containers
1.1.1.1. How does the team make decesions, change it
1.1.1.2. Phyiscal space of the team
1.2. Differences
1.2.1. Ensure teams are diverse - amplify differences
1.3. Exchanges
1.3.1. Change how an exchange occurs
1.3.2. Add or remove people from exchange
1.3.3. Different meetings between different people
1.4. Influencing Evolution
1.4.1. Select the External Environment
1.4.2. Define Performance
1.4.3. Manage Meaning
1.4.4. Energize the System
1.4.4.1. Give clear and elevating goals
1.4.4.2. Crerate Project Charter
1.4.4.2.1. Write product review and eleveator statement
2. Roles
2.1. Scrum Master
2.1.1. Personal Trainer Analogy
2.1.1.1. They have the authority to keep you on the right track with the right exercises
2.1.1.2. Ultimately has no authority over you. You make your own decisions on what to do
2.1.2. Keep team focused on goal
2.1.2.1. "we're supposed to deliver potentially shipable software. What do we need to do next time to get that?"
2.1.2.2. CAN'T tell the team what to do
2.1.2.2.1. Not - "Tod reviews all code from now on"
2.1.2.2.2. Therefore is not responsible if the team fails
2.1.3. Attributes of Good Scrum Master
2.1.3.1. Responsible
2.1.3.2. Humble
2.1.3.3. Collaborative
2.1.3.3.1. Needs to create a collaborative environment for the team
2.1.3.4. Committed
2.1.3.5. Influential
2.1.3.5.1. Clever and effective influence to get a team to try new things
2.1.3.5.2. Influence others outside the team to help overcome roadblocks
2.1.3.6. Knowledgeabble
2.1.4. Tech leads != Scrum Master
2.1.4.1. teams should not have tech leads
2.1.4.2. tech leads often make better team members
2.1.4.3. Scrum Master does not have authority of the team so don't try to keep that authority by becoming the scrum master
2.1.4.4. "my way or the highway" leads are bad Scrum Master candidates
2.2. Product Owner
2.2.1. Responsibilities
2.2.1.1. Providing Vision
2.2.1.2. Providing Boundaries
2.2.1.2.1. Need x by June
2.2.1.2.2. Needs to run at twice the speed
2.2.1.3. Focused on Return on Investment (ROI)
2.2.1.3.1. Represents the interests of the stakeholders
2.2.2. Each team needs exactly one product owner
2.2.3. Team of Product Owners for larger projects
2.2.3.1. Needs to be one person per team, not a committe
2.2.3.1.1. If a PO team members feels uncomfortable answering, there has to exist a PO lead to make the decision, not a committe
2.2.4. Attributes of Good Product Owner
2.2.4.1. Available
2.2.4.2. Business-savvy
2.2.4.3. Communicative
2.2.4.4. Decisive
2.2.4.5. Empowered
2.3. Team Member / Programmer
2.3.1. 'OK' to have specialists, best to have the team work across the board
2.3.2. Need to become active participants in product requirements
2.3.2.1. No longer being told what to do, need to understand what needs to be done
3. Technical Practices
3.1. Test Driven Development (TDD)
3.1.1. Evidence it takes 15% longer
3.1.2. Initial bugs reduced by over 25%
3.1.2.1. long term bugs reduced ~ infinte
3.1.3. Try 'gang programming' for training
3.1.3.1. 4-8 devs, 1 laptop, projector, pass the laptop every 15m
3.2. Refactoring
3.2.1. Objections
3.2.1.1. If written/designed well wouldn't need it
3.2.1.1.1. like saying if cars were made better, wouldn't need an oil change
3.2.2. Opportunistic Refactoring
3.2.3. Always leave the code better off than you found it
3.3. Collective Ownership
3.3.1. Ensure no dev becomes to specialized he can contribute only in one area
3.3.2. Make certain that no area becomes so intricate that it is understood only by one dev
3.3.3. Good ideas in one part of the application are more quickly proagated to other areas
3.3.4. Objections
3.3.4.1. Development is faster if each person owns one part of the system
3.3.4.1.1. in a very short term project - probably
3.3.4.1.2. long term project - not true at all
3.4. Continuous Integration
3.4.1. Nightly builds 100% essential
3.4.2. Continuous nearly a must have
3.4.2.1. no manual effort
3.5. Pair Programming
3.5.1. Objections
3.5.1.1. Costs two devs to do the job one one
3.5.1.1.1. Costs are deceiving
3.5.1.2. In a hurry, we can't pair
3.5.1.2.1. this is the most important time to pair then
3.5.2. Two team members at a single computer actively working tasks
3.5.2.1. Can increase time to complete tasks by 10-15%
3.5.2.1.1. Number of bugs reduced by over 50%
3.5.2.1.2. Takes longer to do a task correctly than incorrectly
3.6. Design: Intentional yet Emergent
3.6.1. Emerging design is more productive than waterfall design
3.6.2. Requires rework often
3.6.2.1. With sound technical practices like TDD, rework is easy and fast
3.6.2.2. Rework leads to a best design to the project while upfront design can't successfully change without rework
3.7. Quality/Testing
3.7.1. Why testing at the end doesn't work
3.7.1.1. It is hard to improve the quality of an existing product
3.7.1.2. Mistakes continue unnoticed
3.7.1.3. State of the project is difficult to gauge
3.7.1.4. Feedback opportunities are lost
3.7.1.5. Testing is more likely to be cut
3.7.2. Test Automation Pyramid
3.7.2.1. UI
3.7.2.1.1. Brittle
3.7.2.1.2. Expensive to Write
3.7.2.1.3. Time Consuming
3.7.2.2. Service
3.7.2.3. Unit
4. Team
4.1. Two Pizza Team
4.1.1. Smaller Teams
4.1.1.1. Less social loafing
4.1.1.2. Constructive interaction
4.1.1.3. Less time spent coordinating
4.1.1.4. Higher Participation
4.1.1.5. More satisfying to the team
4.1.1.6. Less chance for harmful over-specialization
4.1.2. Productivity
4.1.2.1. Small teams are much more productive
4.1.2.2. Large teams complete projects on average 12 days sooner than small teams
4.1.2.2.1. Costs a lot more money and has a lot more defects
4.2. Favor Feature Teams
4.2.1. Feature Team Benefits
4.2.1.1. Better able to evaluate design decisions
4.2.1.2. Reduce waste
4.2.1.3. Ensures the right people are talking
4.2.1.4. Less risk to the schedule
4.2.1.5. Keeps focus on delivering features
4.2.2. Consider Component Teams ONLY if
4.2.2.1. Component team will build something that will be used by multiple feature teams
4.2.2.2. Desire to reduce the sharing of specialists
4.2.2.2.1. Often feature teams run specialists thin they can't really be utelized in code
4.2.2.3. Risk of multiple approaches outweighs disadvantages of component teams
4.2.2.3.1. Multiple feature teams may need to solve the same problems in a sprint and thats a big risk of duplicated effort
4.2.2.4. You can see an end to the need for component teams
4.3. Right People on the Team
4.3.1. Include all needed disciplines
4.3.2. Balance technical skill levels
4.3.3. Balance domain knowledge
4.3.4. Seek Diversity
4.3.4.1. Don't want teams that come to quick conclusions
4.3.4.2. Want teams that think through their conclusions thoroughly
4.3.5. Consider Persistence
4.4. Try not to multitask teammembers
4.4.1. Total work decreases the more required to multitask
4.4.2. Better to have a few members multitask a lot, than have the whole team multitask a little
4.5. Don't start a new project until it can be fully staffed
5. Product Backlog
5.1. Written Document Negatives
5.1.1. can make you suspend judgement
5.1.2. Leads to lack of conversation over meaning and overuse of assumptions
5.1.3. decrease whole-team responsibility
5.2. Use User Stories
5.2.1. As a <type of user>, I want <some goal> so that <some reason>
5.2.2. Promise to have a future discussion; not every detail required
5.2.2.1. Team should practice communication skills w/ PO to speak about business not all technical
5.2.3. Add detail over time
5.2.3.1. Conditions of Satisfaction
5.2.3.1.1. Acceptance Criteria
5.3. Emergent Requirements are encouraged
5.4. Iceberg
5.4.1. Tip is known
5.4.2. Everything under water we know is there and its a lot but its not very detailed, we will get to it later
5.5. Grooming
5.5.1. 10% of effort in each sprint
5.6. Why progressively refine
5.6.1. Things will change
5.6.1.1. Priorities shift
5.6.1.2. New needs are discovered or solved
5.6.2. There's no need
5.6.2.1. Items may be obsolete or unnecessesary as the project progresses
5.6.3. Time is scarce
5.6.4. Allows decisions to be made at the optimal time
5.6.5. Allows to make course changes
5.6.6. avoid falling into trap of believing our plans
5.7. Should be 'DEEP'
5.7.1. Detailed Appropriately
5.7.2. Estimated
5.7.3. Emergent
5.7.4. Prioritized
6. Sprint
6.1. Keep Timeboxes
6.1.1. Teams benefit from a regular cadence
6.1.2. Sprint planning becomes easier
6.1.3. Release planning becomes easier
6.2. Never Extend
6.2.1. Discourages the commitment
6.3. Don't Plan on Overtime to Salvage a Plan
6.3.1. Leads to poor quality
6.3.1.1. Developers are forced to cut corners to meet poor estimates
6.3.2. Work a Sustainable Pace
6.3.3. XP Rule:you can't work a second week of overtime
6.3.3.1. If needed, the project has a big problem
6.3.4. The only acceptable overtime is team concluded and desired overtime
6.3.5. If a commitment has too much focus the team will not commit to what they can do but often much less to confidently commit
6.4. Add Energy vs Overtime
6.4.1. Increase the passion around the project
6.4.2. Pomodoro technique
6.4.2.1. 5 min breaks to every 25 min of work
6.5. Favor Scope Changes
6.5.1. Alternatives
6.5.1.1. Cut Quality
6.5.1.2. Add Resources
6.5.1.3. Extend the Schedule
6.5.2. Shrinking scope is often acceptable to everyone and can have huge benefits and keep a project productive
7. Becoming Agile is Hard
7.1. Why Transition is Hard
7.1.1. Successful change is not entirely top-down or bottom-up
7.1.2. The end state is unpredicatable
7.1.3. Scrum is pervasive
7.1.4. Scrum is dramatically different
7.1.4.1. Emergent Design vs Waterfall
7.1.5. Change is coming more quickly than ever before
7.1.6. Best practices are dangerous
7.1.6.1. Each business has different needs, thus different practices
7.1.6.2. Cannot plan every project with a rule book or best practices
7.2. Why it's worth the effort
7.2.1. Higher Productivity and lower costs
7.2.2. Improved employee engagement and job satisfaction
7.2.3. Faster time to market
7.2.3.1. Could go to market after every sprint if desired
7.2.4. Higher quality
7.2.5. Improved stakeholder satisfaction
7.2.6. What we've been doing no longer works
8. Spreading Scrum
8.1. Split and Seed
8.1.1. Split a team after a few sprints into two teams, mixing the new teams with 'other' (new or otherwise) team members
8.1.2. Can add teams quickly
8.1.3. But destroys teams just starting to jell
8.2. Grow and Split
8.2.1. Grow a team into a large team, and then split the team into two teams.
8.2.1.1. Continue to grow those teams and split again
8.2.2. Keeps teams together (mostly)
8.2.3. Most natural
8.2.3.1. This would happen as projects grow
8.3. Internal Coaching
8.3.1. Successful team member helps another team while continuing to work on the original team
8.3.2. Keeps teams together entirely
8.3.3. Coaches can be hand selected
8.3.3.1. Can move from one team to another
8.3.4. Attends:
8.3.4.1. Sprint Planning
8.3.4.2. Review
8.3.4.3. Retrospective
8.3.4.4. 1 Daily Scrum a Week
8.3.4.5. 2 hours a week for other help
9. Iterate Toward Agility
9.1. Use Scrum to Apply/Adopt Scrum
9.2. Improvement(Product) Backlog
9.2.1. Example Items
9.2.1.1. Enable teams to implement CI
9.2.1.2. Create Awareness of Scrum on each Team
9.2.1.3. Figure out how to make sure each team has a PO
9.2.2. Multiple backlogs for large companies
9.3. Enterprise Transition Community (ETC) (The Team)
9.3.1. Daily Scrums encouraged, not as important as development scrum teams
9.3.2. Responsiibilities
9.3.2.1. Articulate the context
9.3.2.2. Stimulate Conversation
9.3.2.3. Provide resources
9.3.2.4. Set appropriate aspirations
9.3.2.5. Engage everyone
9.4. Sponsor (PO)
9.4.1. Probably an experienced PO, this is new
9.4.2. Doesn't have to be the sole PO, the ETC can help heavily
9.4.2.1. Does need to be committed and apply time
9.4.3. Needs to be senior management/partner/co founder to help adoption
9.5. Form Improvement Communities
9.5.1. Like sub ETC teams where the/an ETC member is the PO
10. Pilot Project
10.1. Pilot != to decide to do it
10.1.1. Pilot = forge the way to understand the best approaches at the company
10.2. Picking best pilot project
10.2.1. Duration
10.2.1.1. Whatever is near the 'middle' of what is normal
10.2.1.1.1. Ideally ~3-4 months
10.2.2. Size
10.2.2.1. Single Collcoated Team
10.2.2.2. It may grow over time
10.2.2.2.1. Keep growth under 5 teams
10.2.3. Importance
10.2.3.1. Choose an important project
10.2.3.2. Gives it best chance to over come roadblocks and not be called a unique/special case
10.2.4. Business sponsor engagement
10.2.4.1. A good sponsor can help overcome external roadblocks
10.2.4.2. Can champion the successes across the company
10.3. Manage Expectations
10.3.1. Most teams will over commit
10.3.2. Most teams will be more useful
10.3.3. Poor teams will get good fast
10.3.3.1. Good teams may slow down at first, and be great in the end
10.3.4. Initial predictability will be poor
10.3.4.1. Estimates will start out poor
10.3.4.2. Teams take a few sprints to find a sustainable pace
10.3.5. Level of involvement
10.3.5.1. PO and stakeholders have significant roles for the team to be successful. Don't underplay their need.
11. Overcoming Resistance
11.1. Skeptics
11.1.1. Provide training
11.1.2. Solicit peer anecdotes
11.1.3. Appoint champion skeptic
11.1.3.1. Acknowledge the skeptic and go to him for alternate views to further conversation and tackle issues
11.1.4. Push the issue
11.1.4.1. Challenge the skeptic to come up with iterative steps to solving the skeptic outlook
11.1.5. Let time run its course
11.2. Saboteur
11.2.1. Success
11.2.1.1. Prove success on diverse projects
11.2.2. Reiterate and reinforce the commitment
11.2.3. Move them
11.2.3.1. To a different project
11.2.3.2. To a different type of role
11.2.3.3. bye bye
11.2.4. Fire them
11.2.4.1. bye bye
11.3. Diehards
11.3.1. Align incentives
11.3.1.1. They are diehards for a reason - use that
11.3.2. Create dissatisfaction with the status quo
11.3.3. Acknowledge and confront fear
11.4. Followers
11.4.1. Change the composition of the team
11.4.2. Praise the right behavior
11.4.3. Involve them
11.4.4. Identify the true barrier
12. Scaling Scrum
12.1. Scaling the Product Owner
12.1.1. Keep a PO responsible for no more than 2 teams
12.1.2. Scaled Roles
12.1.2.1. Chief Product Owner
12.1.2.2. Product Line Owners
12.1.2.3. Product Owners
12.2. Working w/ a Large Product Backlog
12.2.1. One Product, One Product Backlog
12.2.2. Keep to a Reasonable Size
12.2.2.1. 100-150 responsible items
12.2.2.1.1. Robin Dunbar research
12.2.2.2. Use eipcs and themes
12.2.2.3. Use different views
12.2.2.3.1. Can have more than 150 but not in a single responsible view
12.3. Proactively Manage Dependencies
12.3.1. Do Rolling Lookahead Planning
12.3.1.1. At the end of Sprint Planning
12.3.1.2. Spend a few minutes discussing what each team will do in the next couple of sprints
12.3.1.3. Help identify dependencies early
12.3.2. Hold a Release Kickoff Meeting
12.3.2.1. Roughly plan 3 months out and discuss those goals with all teams so that everyone starts out on the same page
12.3.3. Share Team Members
12.3.3.1. Part time team members
12.3.4. Use an Integration Team
12.3.4.1. Best on projects with ten or more teams
12.3.4.2. First goal is to analyze nightly build and solve any nightly build problems with the teams involved
12.3.4.3. Integration Team Member at every other teams standard meetings
12.4. Coordinate Work Among Teams
12.4.1. Scrum of Scrums Meeting
12.4.1.1. 1 team member chosen by the team
12.4.1.1.1. if small # of teams perhaps 2 from each team
12.4.1.1.2. chosen members can rotate
12.4.1.2. Recursive; multiple levels of scrum of scrums
12.4.1.3. Frequency
12.4.1.3.1. Don't need to be daily
12.4.1.3.2. Dont need to be timeboxed to 15min
12.4.1.3.3. Are problem-solving meetings
12.4.1.4. Agenda
12.4.1.4.1. What has my team done since we last met that could affect other teams?
12.4.1.4.2. What will my team do before we meet again that could affect other teams?
12.4.1.4.3. What problems is my team having with which it could use help from other teams?
12.4.1.4.4. No personal names used during this part
12.4.1.4.5. As needed: Resolve problems and discuss items on an issues backlog
12.4.2. Synchronize Sprints
12.4.2.1. Staggering sprints are a horrible idea
12.4.2.1.1. Never a time when all teams are done
12.4.2.2. 2 or 3 day stagger is acceptable on a large project
12.4.2.2.1. Allows members to attend multiple meetings
12.4.2.2.2. Remote members can attend all potentially useful meetings
12.5. Scaling Sprint Planning
12.5.1. Stagger by a Day
12.5.1.1. Works for projects up to 9 teams
12.5.2. The Big Room
12.5.2.1. Big room with all teams split into their own 'corners' and have normal individual sprint planning meetings
12.5.2.2. Use nautical singaling flags for communication
12.5.2.2.1. Need architect
12.5.2.2.2. Need PO
12.5.2.2.3. Time to order Lunch
12.5.2.2.4. On a Break
12.6. Cultivate Communities of Practice
12.6.1. 'Test Community', 'programming community' 'ScrumMaster community', 'UI Community'
12.6.2. Virtual Architecture Team (VAT)
12.6.3. Can span more than one project
13. Distributed Teams
13.1. Create Coherence
13.1.1. Acknowledge Significant Cultural Differences
13.1.1.1. Power Distance Index (PDI)
13.1.1.2. Individualism (IND)
13.1.1.3. Achievement Orientation (ACH)
13.1.1.4. Uncertainty Avoidance Index (UAI)
13.1.1.5. Long-Term Orientation (LTO)
13.1.2. Acknowledge the Small Cultural Differences
13.1.3. Strengthen Funcationl and Team Subcultures
13.1.4. Communicate and Establish a Shared Vision
13.1.5. Reach Agreements
13.1.6. Build trust by emphasizing early progress
13.1.6.1. Focus on tasks first
13.1.6.2. After learning about eachother with task progress and completion focus on relationship building
13.2. Get Together in person
13.2.1. Seeding Visits
13.2.1.1. Maybe even seeding the first sprint
13.2.2. Contact Visits
13.2.2.1. Focus around a task but the goal is relationship building
13.2.2.2. One week visit for every couple of months
13.2.3. Traveling Ambassadoors
13.2.3.1. Semi Permanent team member
13.2.3.2. Stays for several months
13.2.3.2.1. Rarely used this way so settle for shorter but more often visits
13.2.3.3. Communicates Gossip
13.2.3.3.1. Not malicious rumors
13.2.3.3.2. Personal details that which aren't discussed in formal meetings
13.2.3.3.3. 'Fernando's baby took her first steps last night'
13.2.3.4. Communicate lessons learned
13.3. Change How You Communicate
13.3.1. User Stories
13.3.1.1. Supplement with some more detail
13.3.1.2. "Send a long a test"
13.3.1.2.1. Add a high level test case that indicates if the story is complete
13.3.2. Encourage Lateral Conversion
13.3.2.1. Combats the 'mum' effect
13.3.3. Include time for small talk
13.3.3.1. Start telecons with chit chat
13.3.3.1.1. Encourages culture and a better mood for the call
13.3.4. Telecons
13.3.4.1. Share the pain
13.3.4.1.1. Change meeting times monthly to make it fair among team members
13.3.4.1.2. Have some meetings all by telecon, even the local members to show how difficult the phone call can be to stay engaged
13.3.4.2. Tell Everyone who is talking
13.3.4.2.1. State your name before speaking
13.3.4.2.2. Have low-fidelity video conferencing
13.3.4.3. Sprint Planning
13.3.4.3.1. The Long Phone Call
13.3.4.3.2. Two Calls
14. Outside Development Affects
14.1. Human Resources
14.1.1. Performance Reviews
14.1.1.1. Eliminate individual factors
14.1.1.1.1. how did the individual effectively manage tasks within budget and timeline
14.1.1.2. Include teamwork factors
14.1.1.2.1. Helps the team finish tasks within the timeline
14.1.1.2.2. effectively applies retrospective items and helps others do the same
14.1.1.3. Review more frequently than anually
14.1.2. Career Paths
14.1.2.1. Scrum masters may rotate through different teams of importance
14.1.2.2. Development team members may also rotate through different teams to share technical knowledge
14.1.2.2.1. Role may also change on the team and initial tester/designer may rotate to bigger architectural inputs and implementation later on in the team