If agile is so amazing, why is it so hard to produce reliable results?
Most executives, managers, and team members get excited to adopt agile only to see it fall far short of expectations. This 500-page book has the answers to the team-level challenges that hold companies back, and includes all the content we teach in our six-figure agile transformation programs.
“This book describes not just every step of the agile process, but the entire process of becoming agile, the production of agile products, and how to deal with the changes that need to happen across an organization’s whole culture.” – Amazon Reviewer
In The Epic Guide to Agile, you’ll discover:
- Personal examples and anecdotes to tackle problems at their source
- Effective ways to introduce agile and Scrum into your organization
- The exact system to achieve productive sprint planning sessions and successful sprints
- The typical issues that can doom your team and how to conquer them
- The testing and source code control techniques your team needs to be successful
- Tricks to smoothly get your product into production and much, much more!
Ascendle CEO Dave Todaro has lived and breathed software development for over three decades. After running successful agile teams on a daily basis, he’s ready to share his insights and techniques to help your company reap the benefits of his experience.
Part I: Understanding Scrum Fundamentals
1 Introduction to High-Performance Teamwork
1.1 Creating Dream Teams
1.2 Why Does Scrum Work?
1.3 Is Scrum Just for Software Development?
1.4 How Agile Differs from a Traditional Waterfall Approach
1.5 Scrum Is for Any Complicated or Complex Project
2 Scrum’s 10 Guideposts
2.1 Three Roles
2.2 Four Ceremonies
2.3 Three Artifacts
2.4 This is Too Simple. How Can It Possibly Work?
3 The Product Backlog
3.1 The Single Shared Source of Truth
3.2 The Product Backlog Belongs to the Product Owner
3.3 Requirements Evolve Over Time
3.4 Discussing the Backlog with the Team is Important
3.5 Tracking the Projected Schedule with a Release Burndown Chart
4 User Stories
4.1 A User Story is a Descriptive Sentence
4.2 Details Are Added Through Conversations
4.3 What, Not How
4.4 Each User Story Has a Size Estimate
4.5 Additional Written Details Are OK
4.6 Some Traditional Specifications Are OK Too
5 The Sprint
5.1 Eliminating the Death March
5.2 The Imminent Deadline and the Power of Positive Stress
5.3 Everything is Done During a Sprint
5.4 Benefits of the Sprint Approach
6 Scrum Ceremonies
6.1 Sprint Planning
6.2 Daily Standup
6.3 Sprint Review
6.4 Retrospective
6.5 Other Optional Ceremonies
6.6 A Typical Ceremony Schedule
6.7 Aren’t All These “Ceremonies” Wasting a Bunch of Time?
7 Scrum Roles
7.1 The Product Owner
7.2 The ScrumMaster
7.3 The Development Team
8 The Sprint Backlog
8.1 Visualizing the Work of the Sprint with a Sprint Task Board
8.2 Keeping Track of Who’s Working on Each Subtask
8.3 Understanding How Much Time is Left for Each Subtask
8.4 Tracking Sprint Progress with a Sprint Burndown Chart
8.5 My Company Requires Creating Status Reports. Are We Allowed to Do That?
9 The Product
9.1 The Product is Built Iteratively and Incrementally
9.2 The Traditional Approach: Building 100% of Nothing
9.3 The Agile Approach: Building 100% of Something
9.4 The Definition of Done
9.5 Shippable vs Something You Would Ship
Part II: Understanding Agile Software Construction
10 Introduction to Agile Software Construction
10.1 What is “Software Construction?”
10.2 Why is Software Construction So Important in an Agile Context?
10.3 Why You Need to Know About This Technical “Stuff”
10.4 Agile Software Construction Concepts
11 Creating a Shippable Increment Requires Team Test Environments
11.1 Traditional Testing Approaches Don’t Work in an Agile Environment
11.2 Test Environments Eliminate “Works on My Machine!”
11.3 What the Scrum Team Needs for Test Environments
11.4 Providing Test Environments May Require Creative Thinking
11.5 The Scrum Team Needs to Control Their Test Environments
11.6 The Ability to Automatically Deploy Code is Critical
11.7 Tools to Manage Team Test Environments
12 Managing Source Code Properly Avoids Pain When “Life Happens”
12.1 Version Control Allows Effective Collaboration
12.2 Branches Isolate Code to Manage the Unexpected
12.3 A Distributed Version Control System Makes Branching Easy
12.4 Reviewing Code Before Merging a Branch Increases Quality
12.5 Git Flow Provides a Strategy for Branch Management
12.6 Keys to Avoid Merge Hell and Code Review Bottlenecks
13 Automated Unit Testing: The Foundation of Code Quality
13.1 The Problem with Relying Solely on Integration Testing
13.2 Automated Unit Testing: Ensuring Code Works All the Time
13.3 Running Tests Automatically Avoids Human Error
13.4 A Side-Benefit: Unit Tests Document Code for Future Programmers
13.5 Isolating Dependencies Makes Testing Easier
13.6 Test-Driven Development (TDD) Creates a Test-First Culture
13.7 Code Coverage Analysis Keeps Everyone Honest
13.8 Adding Unit Tests for Discovered Bugs Prevents Them from Coming Back
13.9 My Team Says We Should Use Integration Tests Instead of Unit Tests
14 Acceptance Testing: Making Sure Everything Works Together
14.1 Scenarios Allow Pre-Visualizing a User Story to Avoid Disappointment
14.2 Given, When, Then: Making Tests Understandable to Everyone
14.3 Write Acceptance Tests Early During a Sprint to Reduce Risk
14.4 Perform Acceptance Testing in Every Environment to Avoid Career-Limiting Moves
14.5 Create an Automated “Smoke Test” With the Most Critical Scenarios
15 Agile Architecture and Technical Design
15.1 Architecture Doesn’t Disappear with Agile: It Becomes “Emergent”
15.2 Avoiding YAGNI by Leveraging the “Last Responsible Moment”
15.3 Attaining Technical Excellence Without Telling the Team How to Do It
15.4 Development Teams Need to Consider the Big Picture
15.5 An Experienced Technical Team Member Can Embed Architecture Intelligence
15.6 Creating a Technical Design for Each User Story Encourages Collaboration
15.7 Coding Standards Are a Critical Success Factor
15.8 Technical Communities of Practice Encourage Both Innovation and Consistency
Part III: Laying the Groundwork
16 Here Be Dragons: Preparing for the Challenges You’ll Face
16.1 How Your Organization Will Change
16.2 How Project Managers and the Project Management Office (PMO) Fit In
16.3 How to Start: Pilot Team or the “Big Bang” Approach?
16.4 Success Factors to Guide Your Agile Adoption
16.5 How Long Will It Take to Adopt Agile?
16.6 A Sample Agile Adoption Timeline
17 Forming Your Pilot Scrum Team
17.1 Select a Team You Think Can be Successful
17.2 Select a Product Built Using Agile-Friendly Technology
17.3 Select Team Members Who Can Be Dedicated to the Pilot Team
17.4 Choosing the Product Owner
17.5 Choosing the ScrumMaster
17.6 Don’t Have One Person Be Both Product Owner and ScrumMaster
17.7 Assembling the Development Team
17.8 Seat Your Co-Located Team Together
17.9 Distributed Teams and Multiple Time Zones
18 Your Team’s Path to Excellence
18.1 Four Stages of Learning: The Conscious Competence Model
18.2 The Cognitive Apprenticeship Learning Method
18.3 Teaching the Fundamentals
18.4 Starting Your Team’s Experiential Learning
18.5 Agile Coaches
18.6 What About Agile Certifications?
19 Creating the Initial Product Backlog
19.1 The Backlog Creation Process
19.2 Create a List of Roles to Understand Your Users Better
19.3 Brainstorm Features for Each User Role
19.4 Convert Roles and Features into User Stories
19.5 Group User Stories into “Must Have,” “Nice to Have,” and “Someday Maybe”
19.6 Prioritize the Backlog by Business Value
19.7 Write Acceptance Criteria
20 Estimating the Size of the Product Backlog
20.1 The Power of Relative Size
20.2 Story Points: An Abstract Measurement of Size
20.3 Rapid Estimation with Planning Poker
20.4 Preparing to Estimate
20.5 Story Points Are NOT About Time
20.6 The Planning Poker Process
20.7 How Long Should Estimating Take?
21 Creating an Initial Schedule Projection
21.1 The Chicken and Egg Problem: What’s the Velocity?
21.2 Options to Predict the Team’s Velocity
21.3 Breaking Down Some Stories into Subtasks to Estimate Velocity
21.4 Using the Cone of Uncertainty to Anticipate the Unknown
22 Splitting User Stories for Increased Momentum
22.1 Avoid “Traveling” Stories by Splitting Them
22.2 The Six-Way Model for Splitting User Stories
22.3 SPIDR: An Alternative Method for Splitting Stories
22.4 Use INVEST to Ensure the Quality of Split Stories
22.5 Who Splits User Stories and When?
23 Final Preparations Before Your First Sprint
23.1 What You Should Have in Place Before Starting Your First Sprint
23.2 Complete Initial User Experience (UX) Design
23.3 Deploy Agile Tools
23.4 Define Scrum and Technical Standards
23.5 Configure Developer Workstations
23.6 Set Up Distributed Version Control
23.7 Create Initial Code Framework: The “Walking Skeleton”
23.8 Configure Continuous Integration
23.9 Provision Team Test Environments
23.10 Establish Continuous Deployment
23.11 Research Production Deployment Considerations
23.12 Should We Use a “Sprint Zero?”
Part IV: Building the Product
24 Determining Sprint Logistics
24.1 Selecting the Best Sprint Length
24.2 Picking the Best Day of the Week to Start a Sprint
24.3 Scheduling the Sprint Planning Ceremony
24.4 Preparing for the Sprint Planning Ceremony
24.5 A Sample Sprint Planning Agenda
25 Planning the Sprint
25.1 Setting the Stage for the Team
25.2 Estimating the Team’s Capacity for the Sprint
25.3 Determining How Much Work Can be Done and the Plan of Attack
25.4 Decomposing a Task or Bug into Subtasks
25.5 How Much of the Team’s Capacity Should be Planned?
25.6 What If There Isn’t Enough Time to Finish the Plan?
25.7 Scheduling Scrum Ceremonies for the Sprint
25.8 Finish Sprint Planning by Transitioning to Immediate Action
26 Orchestrating the Daily Work of the Sprint
26.1 Using the Daily Standup to Stay in Sync
26.2 Tracking Progress Against the Plan with the Sprint Task Board
26.3 Keeping the Sprint Task Board up to Date Every Day
26.4 Using the Sprint Burndown Chart to Stay on Track
26.5 Summary of Best Practices
27 A “Zero Defects” Approach to Dealing with Bugs
27.1 Fix Bugs Before Writing New Code
27.2 How to Create a Zero-Defects Culture
27.3 Effectively Documenting Bugs
27.4 How Nasty Is It? Using Priority and Severity to Classify Bugs
27.5 Handling Bugs Introduced during the Sprint
27.6 Addressing Newly-Discovered Bugs That Existed at the Start of the Sprint
27.7 Dealing with a Customer Issue Caused by a Critical Bug
27.8 Timeboxing the Bug Fixing Effort
27.9 What to Do with Bugs That You Won’t Fix
27.10 Handling Bugs That Can’t Be Reproduced
27.11 What to Do with a Legacy Bug List Inherited by the Team
28 Providing Transparency and Getting Feedback With the Sprint Review
28.1 Who Should You Invite to the Sprint Review?
28.2 Selecting the Best Sprint Review Duration
28.3 Preparing for the Sprint Review
28.4 Reviewing What the Team Worked On
28.5 Demonstrating New Functionality in the Product Increment
28.6 Reviewing the Projected Schedule
28.7 A Sample Sprint Review Agenda
29 Driving Continuous Improvement With the Sprint Retrospective
29.1 Is This Really a Valuable Use of Time?
29.2 The Art of Self-Reflection: Questions to Ask During the Retrospective
29.3 Leave Egos, Titles, and Experience at the Door
29.4 Set the Bar High
29.5 Don’t be Too Nice
29.6 How to Make Change Happen
29.7 Common Problems and Ideas to Address Them
30 Confidently Releasing Your Product into Production
30.1 A Tried-And-True Release Process
30.2 Test Environments Required to “Certify” the Release
30.3 The Five-Step Release Process in Detail
30.4 Triaging Bugs Discovered During the Release Sprint
30.5 Orchestrating the Work of the Release Sprint
30.6 But It’s Not This Easy at My Company
30.7 Life After the Release Sprint
About the Author
Programming since age 11 and shipping his first commercial application at 15, Dave Todaro has lived and breathed software development for the past 35+ years. He’s trained and managed teams responsible for building award-winning, mission-critical software in a variety of leadership roles.
Dave has a particular passion for predictable, repeatable, and consistent software development, and fell in love with Scrum when he adopted it over 11 years ago. He’s since refined the process with his teams and has traveled the world, speaking to thousands of software professionals about a variety of agile topics.
Dave is founder and CEO of Ascendle, a Boston-based firm that leverages Microsoft technologies to build web and mobile apps for the world’s leading companies.
Learn more about Dave on LinkedIn.
Sign Up For Bonus Content
Enter your information below to get free bonus content!