Succeeding with Agile

Table of contents

1. Praise for Succeeding with Agile
2. Title Page
3. Copyright Page
4. Contents
5. Foreword
6. Acknowledgments
7. About the Author
8. Introduction
9. Part I. Getting Started
   1. Chapter 1. Why Becoming Agile Is Hard (But Worth It)
      1. Why Transitioning Is Hard
         1. Successful Change Is Not Entirely Top-Down or Bottom-Up
         2. The End State Is Unpredictable
         3. Scrum Is Pervasive
         4. Scrum Is Dramatically Different
         5. Change Is Coming More Quickly Than Ever Before
         6. Best Practices Are Dangerous
      2. Why It’s Worth the Effort
         1. Higher Productivity and Lower Costs
         2. Improved Employee Engagement and Job Satisfaction
         3. Faster Time to Market
         4. Higher Quality
         5. Improved Stakeholder Satisfaction
         6. What We’ve Been Doing No Longer Works
      3. Looking Forward
      4. Additional Reading
   2. Chapter 2. ADAPTing to Scrum
      1. Awareness
         1. Tools for Developing Awareness
      2. Desire
         1. Tools for Increasing Desire
      3. Ability
         1. Tools for Developing Ability
      4. Promotion
         1. Tools for Promoting Scrum
      5. Transfer
         1. Sources of Organizational Gravity
      6. Putting It All Together
      7. Additional Reading
   3. Chapter 3. Patterns for Adopting Scrum
      1. Start Small or Go All In
         1. Reasons to Prefer Starting Small
         2. Reasons to Prefer Going All In
         3. Choosing Between Going All In and Starting Small
      2. Public Display of Agility or Stealth
         1. Reasons to Favor a Public Display of Agility
         2. Reasons to Favor a Stealth Transition
         3. Choosing Between a Public Display and Stealth
      3. Patterns for Spreading Scrum
         1. Split and Seed
         2. Grow and Split
         3. Internal Coaching
         4. Reasons to Prefer Split and Seed
         5. Reasons to Prefer Grow and Split
         6. Reasons to Prefer Internal Coaching
         7. Choosing Your Approach
      4. Introducing New Technical Practices
         1. Reasons to Start Soon
         2. Reasons to Delay
      5. One Final Consideration
      6. Additional Reading
   4. Chapter 4. Iterating Toward Agility
      1. The Improvement Backlog
      2. The Enterprise Transition Community
         1. ETC Sprints
         2. Responsibilities of the ETC
      3. Improvement Communities
         1. Catalysts for Improvement
         2. An Improvement Community Sprint
         3. Focus on Goals with Practical Relevance
         4. Improvement Community Members
         5. Disbanding a Community
      4. One Size Does Not Fit All
      5. Looking Forward
      6. Additional Reading
   5. Chapter 5. Your First Projects
      1. Selecting a Pilot Project
         1. Four Attributes of the Ideal Pilot Project
      2. Choosing the Right Time to Start
         1. Impending Doom
      3. Selecting a Pilot Team
         1. What if a Pilot Isn’t a Success?
      4. Setting and Managing Expectations
         1. Expectations About Progress
         2. Expectations About Predictability
         3. Expectations About Attitudes Toward Scrum
         4. Expectations About Involvement
      5. It’s Just a Pilot
      6. Additional Reading
10. Part II. Individuals
    1. Chapter 6. Overcoming Resistance
       1. Anticipating Resistance
          1. Who Will Resist?
          2. Waterfallacies and Agile Phobias
       2. Communicating About the Change
          1. Hearing from Leaders
          2. Hearing from Peers
       3. The Hows and Whys of Individual Resistance
          1. Skeptics
          2. Saboteurs
          3. Diehards
          4. Followers
       4. Resistance as a Useful Red Flag
       5. Additional Reading
    2. Chapter 7. New Roles
       1. The Role of the ScrumMaster
          1. Attributes of a Good ScrumMaster
          2. Tech Leads as ScrumMasters
          3. Internal or External ScrumMasters
          4. Rotating the ScrumMaster
          5. Overcoming Common Problems
       2. The Product Owner
          1. Responsibilities of the Product Owner
          2. Each Team Needs Exactly One Product Owner
          3. Attributes of a Good Product Owner
          4. The ScrumMaster as Product Owner
          5. Overcoming Common Problems
       3. New Roles, Old Responsibilities
       4. Additional Reading
    3. Chapter 8. Changed Roles
       1. Analysts
       2. Project Managers
          1. Why the Title Change?
       3. Architects
          1. The Non-Coding Architect
       4. Functional Managers
          1. The Leadership Role of the Functional Manager
          2. Personnel Responsibilities
       5. Programmers
       6. Database Administrators
       7. Testers
       8. User Experience Designers
       9. Three Common Themes
       10. Additional Reading
    4. Chapter 9. Technical Practices
       1. Strive for Technical Excellence
          1. Test-Driven Development
          2. Refactoring
          3. Collective Ownership
          4. Continuous Integration
          5. Pair Programming
       2. Design: Intentional yet Emergent
          1. Getting Used to Life Without a Big Design
          2. Guiding the Design
       3. Improving Technical Practices Is Not Optional
       4. Additional Reading
11. Part III. Teams
    1. Chapter 10. Team Structure
       1. Feed Them Two Pizzas
          1. Why Two Pizzas Are Enough
          2. Small Team Productivity
       2. Favor Feature Teams
          1. Use Component Teams Sparingly
          2. Who Makes These Decisions?
          3. What’s Right Today May Be Wrong Tomorrow
       3. Self-Organizing Doesn’t Mean Randomly Assembled
          1. Getting the Right People on the Team
       4. Put People on One Project
          1. Time on Task Decreases with Too Many Tasks
          2. When Multitasking Is OK
          3. The Corporate Form of Multitasking
          4. Stopping the Treadmill
       5. Guidelines for Good Team Structure
          1. Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members?
          2. Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)?
          3. Does the structure maximize the amount of time that teams will remain together?
          4. Are component teams used only in limited and easily justifiable cases?
          5. Will you be able to feed most teams with two pizzas?
          6. Does the structure minimize the number of communication paths between teams?
          7. Does the structure encourage teams to communicate who wouldn’t otherwise do so?
          8. Does the design support a clear understanding of accountability?
          9. Did team members have input into the design of the team?
       6. Onward
       7. Additional Reading
    2. Chapter 11. Teamwork
       1. Embrace Whole-Team Resposibility
          1. Nurture Whole-Team Commitment
       2. Rely On Specialists but Sparingly
       3. Do a Little Bit of Everything All the Time
          1. Don’t Wait Until the End of the Sprint to Finish Everything
          2. Mix the Sizes of the Product Backlog Items You Commit To
       4. Foster Team Learning
          1. Ensure Learning Conditions Exist
          2. Eliminate Knowledge Waste
       5. Encourage Collaboration Through Commitment
          1. Involve widely
          2. Find an igniting purpose
          3. Tap into existing intrinsic motivation
          4. Beware the least motivated team member
          5. Help everyone understand their relevance to the goal
          6. Build confidence
       6. All Together Now
       7. Additional Reading
    3. Chapter 12. Leading a Self-Organizing Team
       1. Influencing Self-Organization
          1. Containers, Differences, and Exchanges
       2. Influencing Evolution
          1. Select the External Environment
          2. Define Performance
          3. Manage Meaning
          4. Introduce Vicarious Selection Systems
          5. Energize the System
       3. There’s More to Leadership Than Buying Pizza
       4. Additional Reading
    4. Chapter 13. The Product Backlog
       1. Shift from Documents to Discussions
          1. Written documents can make you suspend judgment
          2. With a written document, we don’t iterate over meaning as we would in conversation
          3. Written documents decrease whole-team responsibility
          4. Don’t Throw the Baby Out with the Documentation
          5. Use User Stories for the Product Backlog
       2. Progressively Refine Requirements
          1. Emergent Requirements
          2. The Product Backlog Iceberg
          3. Why Progressively Refine Requirements?
          4. Progressive Refinement of User Stories
       3. Learn to Start Without a Specification
          1. Specify by Example
          2. Cross-Functional Teams Reduce Documentation Needs
       4. Make the Product Backlog DEEP
       5. Don’t Forget to Talk
       6. Additional Reading
    5. Chapter 14. Sprints
       1. Deliver Working Software Each Sprint
          1. Defining Potentially Shippable
          2. Identifying Potentially Shippable Guidelines
       2. Deliver Something Valuable Each Sprint
          1. Unobservable Features
       3. Prepare in This Sprint for the Next
          1. Billiard Ball Sprints
          2. Only Pull into a Sprint What Can Be Completed
       4. Work Together Throughout the Sprint
          1. Avoid Activity-Specific Sprints
          2. Replace Finish-to-Start Relationships with Finish-to-Finish Ones
          3. Overlapping User Experience Design
          4. Think Holistically, Work Incrementally
          5. Architecture and Database Design
       5. Keep Timeboxes Regular and Strict
          1. Never Extend a Sprint
       6. Don’t Change the Goal
          1. Break the Habit of Redirecting a Team
       7. Get Feedback, Learn, and Adapt
       8. Additional Reading
    6. Chapter 15. Planning
       1. Progressively Refine Plans
       2. Don’t Plan on Overtime to Salvage a Plan
          1. Learning the Hard Way
          2. Getting There
          3. If Not Overtime, What?
       3. Favor Scope Changes When Possible
          1. Considering the Alternatives
          2. Project Context Is Key
       4. Separate Estimating from Committing
          1. The Right Data to Do This
          2. Going from Estimate to Commitment
          3. Historical Velocity Forms the Basis for Committing
       5. Summary
       6. Additional Reading
    7. Chapter 16. Quality
       1. Integrate Testing into the Process
          1. Why Testing at the End Doesn’t Work
          2. What Building In Quality Looks Like
       2. Automate at Different Levels
          1. The Remaining Role of User Interface Tests
          2. The Role of Manual Testing
          3. Automate Within the Sprint
          4. Sampling the Benefits
       3. Do Acceptance Test–Driven Development
          1. The Right Level of Detail
       4. Pay Off Technical Debt
          1. Paying Down Testing Debt in Three Steps
       5. Quality Is a Team Effort
       6. Additional Reading
12. Part IV. The Organization
    1. Chapter 17. Scaling Scrum
       1. Scaling the Product Owner
          1. Sharing Responsibility, Dividing Functionality
       2. Working with a Large Product Backlog
          1. One Product, One Product Backlog
          2. Keep the Product Backlog to a Reasonable Size
       3. Proactively Manage Dependencies
          1. Do Rolling Lookahead Planning
          2. Hold a Release Kickoff Meeting
          3. Share Team Members
          4. Use an Integration Team
       4. Coordinate Work Among Teams
          1. The Scrum of Scrums Meeting
          2. Synchronize Sprints
       5. Scaling the Sprint Planning Meeting
          1. Stagger by a Day
          2. The Big Room
       6. Cultivate Communities of Practice
          1. Formal or Informal
          2. Creating an Environment for Communities to Form and Flourish
          3. Participation
       7. Scrum Does Scale
       8. Additional Reading
    2. Chapter 18. Distributed Teams
       1. Decide How to Distribute Multiple Teams
       2. Create Coherence
          1. Acknowledge Significant Cultural Differences
          2. Acknowledge the Small Cultural Differences
          3. Strengthen Functional and Team Subcultures
          4. Build Trust by Emphasizing Early Progress
       3. Get Together in Person
          1. Seeding Visits
          2. Contact Visits
          3. Traveling Ambassadors
       4. Change How You Communicate
          1. Adding Back Some Documentation
          2. Adding Detail to the Product Backlog
          3. Encourage Lateral Communication
       5. Meetings
          1. General Advice
          2. Sprint Planning Meeting
          3. Daily Scrum
          4. Scrum of Scrums
          5. Sprint Reviews and Retrospectives
       6. Proceed with Caution
       7. Additional Reading
    3. Chapter 19. Coexisting with Other Approaches
       1. Mixing Scrum and Sequential Development
          1. Three Scenarios of Interaction
          2. Three Areas of Conflict
          3. Can Scrum and Sequential Coexist Forever?
       2. Governance
          1. Running Scrum Projects with Non-Agile Governance
       3. Compliance
          1. ISO 9001
          2. Capability Maturity Model Integration (CMMI)
          3. Achieving Compliance
       4. Onward
       5. Additional Reading
    4. Chapter 20. Human Resources, Facilities, and the PMO
       1. Human Resources
          1. Reporting Structures
          2. Periodic Performance Reviews
          3. Removing Team Members
          4. Career Paths
          5. With People Involved, There Will Always Be People Issues
       2. Facilities
          1. The Space
          2. The Furniture
          3. Items That Should Be Visible in Your Workspace
       3. The Project Management Office
          1. People
          2. Projects
          3. Process
          4. Renaming the PMO
       4. The Bottom Line
       5. Additional Reading
13. Part V. Next Steps
    1. Chapter 21. Seeing How Far You’ve Come
       1. The Purpose of Measuring
       2. General-Purpose Agility Assessments
          1. Shodan Adherence Survey
          2. Agile: EF
          3. Comparative Agility Assessment
       3. Creating Your Own Assessment
       4. A Balanced Scorecard for Scrum Teams
          1. Constructing the Balanced Scorecard
          2. Favor Simple Metrics
       5. Should We Really Bother with This?
       6. Additional Reading
    2. Chapter 22. You’re Not Done Yet
14. Reference List
15. Index