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. Becoming Agile is Hard
2.1. Why Transition is Hard
2.1.1. Successful change is not entirely top-down or bottom-up
2.1.2. The end state is unpredicatable
2.1.3. Scrum is pervasive
2.1.4. Scrum is dramatically different
2.1.4.1. Emergent Design vs Waterfall
2.1.5. Change is coming more quickly than ever before
2.1.6. Best practices are dangerous
2.1.6.1. Each business has different needs, thus different practices
2.1.6.2. Cannot plan every project with a rule book or best practices
2.2. Why it's worth the effort
2.2.1. Higher Productivity and lower costs
2.2.2. Improved employee engagement and job satisfaction
2.2.3. Faster time to market
2.2.3.1. Could go to market after every sprint if desired
2.2.4. Higher quality
2.2.5. Improved stakeholder satisfaction
2.2.6. What we've been doing no longer works
3. Spreading Scrum
3.1. Split and Seed
3.1.1. Split a team after a few sprints into two teams, mixing the new teams with 'other' (new or otherwise) team members
3.1.2. Can add teams quickly
3.1.3. But destroys teams just starting to jell
3.2. Grow and Split
3.2.1. Grow a team into a large team, and then split the team into two teams.
3.2.1.1. Continue to grow those teams and split again
3.2.2. Keeps teams together (mostly)
3.2.3. Most natural
3.2.3.1. This would happen as projects grow
3.3. Internal Coaching
3.3.1. Successful team member helps another team while continuing to work on the original team
3.3.2. Keeps teams together entirely
3.3.3. Coaches can be hand selected
3.3.3.1. Can move from one team to another
3.3.4. Attends:
3.3.4.1. Sprint Planning
3.3.4.2. Review
3.3.4.3. Retrospective
3.3.4.4. 1 Daily Scrum a Week
3.3.4.5. 2 hours a week for other help
4. Iterate Toward Agility
4.1. Use Scrum to Apply/Adopt Scrum
4.2. Improvement(Product) Backlog
4.2.1. Example Items
4.2.1.1. Enable teams to implement CI
4.2.1.2. Create Awareness of Scrum on each Team
4.2.1.3. Figure out how to make sure each team has a PO
4.2.2. Multiple backlogs for large companies
4.3. Enterprise Transition Community (ETC) (The Team)
4.3.1. Daily Scrums encouraged, not as important as development scrum teams
4.3.2. Responsiibilities
4.3.2.1. Articulate the context
4.3.2.2. Stimulate Conversation
4.3.2.3. Provide resources
4.3.2.4. Set appropriate aspirations
4.3.2.5. Engage everyone
4.4. Sponsor (PO)
4.4.1. Probably an experienced PO, this is new
4.4.2. Doesn't have to be the sole PO, the ETC can help heavily
4.4.2.1. Does need to be committed and apply time
4.4.3. Needs to be senior management/partner/co founder to help adoption
4.5. Form Improvement Communities
4.5.1. Like sub ETC teams where the/an ETC member is the PO
5. Pilot Project
5.1. Pilot != to decide to do it
5.1.1. Pilot = forge the way to understand the best approaches at the company
5.2. Picking best pilot project
5.2.1. Duration
5.2.1.1. Whatever is near the 'middle' of what is normal
5.2.1.1.1. Ideally ~3-4 months
5.2.2. Size
5.2.2.1. Single Collcoated Team
5.2.2.2. It may grow over time
5.2.2.2.1. Keep growth under 5 teams
5.2.3. Importance
5.2.3.1. Choose an important project
5.2.3.2. Gives it best chance to over come roadblocks and not be called a unique/special case
5.2.4. Business sponsor engagement
5.2.4.1. A good sponsor can help overcome external roadblocks
5.2.4.2. Can champion the successes across the company
5.3. Manage Expectations
5.3.1. Most teams will over commit
5.3.2. Most teams will be more useful
5.3.3. Poor teams will get good fast
5.3.3.1. Good teams may slow down at first, and be great in the end
5.3.4. Initial predictability will be poor
5.3.4.1. Estimates will start out poor
5.3.4.2. Teams take a few sprints to find a sustainable pace
5.3.5. Level of involvement
5.3.5.1. PO and stakeholders have significant roles for the team to be successful. Don't underplay their need.
6. Overcoming Resistance
6.1. Skeptics
6.1.1. Provide training
6.1.2. Solicit peer anecdotes
6.1.3. Appoint champion skeptic
6.1.3.1. Acknowledge the skeptic and go to him for alternate views to further conversation and tackle issues
6.1.4. Push the issue
6.1.4.1. Challenge the skeptic to come up with iterative steps to solving the skeptic outlook
6.1.5. Let time run its course
6.2. Saboteur
6.2.1. Success
6.2.1.1. Prove success on diverse projects
6.2.2. Reiterate and reinforce the commitment
6.2.3. Move them
6.2.3.1. To a different project
6.2.3.2. To a different type of role
6.2.3.3. bye bye
6.2.4. Fire them
6.2.4.1. bye bye
6.3. Diehards
6.3.1. Align incentives
6.3.1.1. They are diehards for a reason - use that
6.3.2. Create dissatisfaction with the status quo
6.3.3. Acknowledge and confront fear
6.4. Followers
6.4.1. Change the composition of the team
6.4.2. Praise the right behavior
6.4.3. Involve them
6.4.4. Identify the true barrier
7. Roles
7.1. Scrum Master
7.1.1. Personal Trainer Analogy
7.1.1.1. They have the authority to keep you on the right track with the right exercises
7.1.1.2. Ultimately has no authority over you. You make your own decisions on what to do
7.1.2. Keep team focused on goal
7.1.2.1. "we're supposed to deliver potentially shipable software. What do we need to do next time to get that?"
7.1.2.2. CAN'T tell the team what to do
7.1.2.2.1. Not - "Tod reviews all code from now on"
7.1.2.2.2. Therefore is not responsible if the team fails
7.1.3. Attributes of Good Scrum Master
7.1.3.1. Responsible
7.1.3.2. Humble
7.1.3.3. Collaborative
7.1.3.3.1. Needs to create a collaborative environment for the team
7.1.3.4. Committed
7.1.3.5. Influential
7.1.3.5.1. Clever and effective influence to get a team to try new things
7.1.3.5.2. Influence others outside the team to help overcome roadblocks
7.1.3.6. Knowledgeabble
7.1.4. Tech leads != Scrum Master
7.1.4.1. teams should not have tech leads
7.1.4.2. tech leads often make better team members
7.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
7.1.4.4. "my way or the highway" leads are bad Scrum Master candidates
7.2. Product Owner
7.2.1. Responsibilities
7.2.1.1. Providing Vision
7.2.1.2. Providing Boundaries
7.2.1.2.1. Need x by June
7.2.1.2.2. Needs to run at twice the speed
7.2.1.3. Focused on Return on Investment (ROI)
7.2.1.3.1. Represents the interests of the stakeholders
7.2.2. Each team needs exactly one product owner
7.2.3. Team of Product Owners for larger projects
7.2.3.1. Needs to be one person per team, not a committe
7.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
7.2.4. Attributes of Good Product Owner
7.2.4.1. Available
7.2.4.2. Business-savvy
7.2.4.3. Communicative
7.2.4.4. Decisive
7.2.4.5. Empowered
7.3. Team Member / Programmer
7.3.1. 'OK' to have specialists, best to have the team work across the board
7.3.2. Need to become active participants in product requirements
7.3.2.1. No longer being told what to do, need to understand what needs to be done
8. Technical Practices
8.1. Test Driven Development (TDD)
8.1.1. Evidence it takes 15% longer
8.1.2. Initial bugs reduced by over 25%
8.1.2.1. long term bugs reduced ~ infinte
8.1.3. Try 'gang programming' for training
8.1.3.1. 4-8 devs, 1 laptop, projector, pass the laptop every 15m
8.2. Refactoring
8.2.1. Objections
8.2.1.1. If written/designed well wouldn't need it
8.2.1.1.1. like saying if cars were made better, wouldn't need an oil change
8.2.2. Opportunistic Refactoring
8.2.3. Always leave the code better off than you found it
8.3. Collective Ownership
8.3.1. Ensure no dev becomes to specialized he can contribute only in one area
8.3.2. Make certain that no area becomes so intricate that it is understood only by one dev
8.3.3. Good ideas in one part of the application are more quickly proagated to other areas
8.3.4. Objections
8.3.4.1. Development is faster if each person owns one part of the system
8.3.4.1.1. in a very short term project - probably
8.3.4.1.2. long term project - not true at all
8.4. Continuous Integration
8.4.1. Nightly builds 100% essential
8.4.2. Continuous nearly a must have
8.4.2.1. no manual effort
8.5. Pair Programming
8.5.1. Objections
8.5.1.1. Costs two devs to do the job one one
8.5.1.1.1. Costs are deceiving
8.5.1.2. In a hurry, we can't pair
8.5.1.2.1. this is the most important time to pair then
8.5.2. Two team members at a single computer actively working tasks
8.5.2.1. Can increase time to complete tasks by 10-15%
8.5.2.1.1. Number of bugs reduced by over 50%
8.5.2.1.2. Takes longer to do a task correctly than incorrectly
8.6. Design: Intentional yet Emergent
8.6.1. Emerging design is more productive than waterfall design
8.6.2. Requires rework often
8.6.2.1. With sound technical practices like TDD, rework is easy and fast
8.6.2.2. Rework leads to a best design to the project while upfront design can't successfully change without rework
8.7. Quality/Testing
8.7.1. Why testing at the end doesn't work
8.7.1.1. It is hard to improve the quality of an existing product
8.7.1.2. Mistakes continue unnoticed
8.7.1.3. State of the project is difficult to gauge
8.7.1.4. Feedback opportunities are lost
8.7.1.5. Testing is more likely to be cut
8.7.2. Test Automation Pyramid
8.7.2.1. UI
8.7.2.1.1. Brittle
8.7.2.1.2. Expensive to Write
8.7.2.1.3. Time Consuming
8.7.2.2. Service
8.7.2.3. Unit
9. Team
9.1. Two Pizza Team
9.1.1. Smaller Teams
9.1.1.1. Less social loafing
9.1.1.2. Constructive interaction
9.1.1.3. Less time spent coordinating
9.1.1.4. Higher Participation
9.1.1.5. More satisfying to the team
9.1.1.6. Less chance for harmful over-specialization
9.1.2. Productivity
9.1.2.1. Small teams are much more productive
9.1.2.2. Large teams complete projects on average 12 days sooner than small teams
9.1.2.2.1. Costs a lot more money and has a lot more defects
9.2. Favor Feature Teams
9.2.1. Feature Team Benefits
9.2.1.1. Better able to evaluate design decisions
9.2.1.2. Reduce waste
9.2.1.3. Ensures the right people are talking
9.2.1.4. Less risk to the schedule
9.2.1.5. Keeps focus on delivering features
9.2.2. Consider Component Teams ONLY if
9.2.2.1. Component team will build something that will be used by multiple feature teams
9.2.2.2. Desire to reduce the sharing of specialists
9.2.2.2.1. Often feature teams run specialists thin they can't really be utelized in code
9.2.2.3. Risk of multiple approaches outweighs disadvantages of component teams
9.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
9.2.2.4. You can see an end to the need for component teams
9.3. Right People on the Team
9.3.1. Include all needed disciplines
9.3.2. Balance technical skill levels
9.3.3. Balance domain knowledge
9.3.4. Seek Diversity
9.3.4.1. Don't want teams that come to quick conclusions
9.3.4.2. Want teams that think through their conclusions thoroughly
9.3.5. Consider Persistence
9.4. Try not to multitask teammembers
9.4.1. Total work decreases the more required to multitask
9.4.2. Better to have a few members multitask a lot, than have the whole team multitask a little
9.5. Don't start a new project until it can be fully staffed
10. Product Backlog
10.1. Written Document Negatives
10.1.1. can make you suspend judgement
10.1.2. Leads to lack of conversation over meaning and overuse of assumptions
10.1.3. decrease whole-team responsibility
10.2. Use User Stories
10.2.1. As a <type of user>, I want <some goal> so that <some reason>
10.2.2. Promise to have a future discussion; not every detail required
10.2.2.1. Team should practice communication skills w/ PO to speak about business not all technical
10.2.3. Add detail over time
10.2.3.1. Conditions of Satisfaction
10.2.3.1.1. Acceptance Criteria
10.3. Emergent Requirements are encouraged
10.4. Iceberg
10.4.1. Tip is known
10.4.2. Everything under water we know is there and its a lot but its not very detailed, we will get to it later
10.5. Grooming
10.5.1. 10% of effort in each sprint
10.6. Why progressively refine
10.6.1. Things will change
10.6.1.1. Priorities shift
10.6.1.2. New needs are discovered or solved
10.6.2. There's no need
10.6.2.1. Items may be obsolete or unnecessesary as the project progresses
10.6.3. Time is scarce
10.6.4. Allows decisions to be made at the optimal time
10.6.5. Allows to make course changes
10.6.6. avoid falling into trap of believing our plans
10.7. Should be 'DEEP'
10.7.1. Detailed Appropriately
10.7.2. Estimated
10.7.3. Emergent
10.7.4. Prioritized
11. Sprint
11.1. Keep Timeboxes
11.1.1. Teams benefit from a regular cadence
11.1.2. Sprint planning becomes easier
11.1.3. Release planning becomes easier
11.2. Never Extend
11.2.1. Discourages the commitment
11.3. Don't Plan on Overtime to Salvage a Plan
11.3.1. Leads to poor quality
11.3.1.1. Developers are forced to cut corners to meet poor estimates
11.3.2. Work a Sustainable Pace
11.3.3. XP Rule:you can't work a second week of overtime
11.3.3.1. If needed, the project has a big problem
11.3.4. The only acceptable overtime is team concluded and desired overtime
11.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
11.4. Add Energy vs Overtime
11.4.1. Increase the passion around the project
11.4.2. Pomodoro technique
11.4.2.1. 5 min breaks to every 25 min of work
11.5. Favor Scope Changes
11.5.1. Alternatives
11.5.1.1. Cut Quality
11.5.1.2. Add Resources
11.5.1.3. Extend the Schedule
11.5.2. Shrinking scope is often acceptable to everyone and can have huge benefits and keep a project productive
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