Learning Agile · Understanding Scrum, XP, Lean, and Kanban by Stellman, Andrew -- Read -- Imperial Library of Trantor

Index

Foreword Preface

Acknowledgments Safari® Books Online How to Contact Us

1. Learning Agile

What Is Agile? Who Should Read This Book Our Goals for This Book Getting Agile into Your Brain by Any Means Necessary How This Book Is Structured

2. Understanding Agile Values

A Team Lead, Architect, and Project Manager Walk into a Bar... No Silver Bullet Agile to the Rescue! (Right?)

Adding Agile Makes a Difference “Better-Than-Not-Doing-It” Results

A Fractured Perspective

How a Fractured Perspective Causes Project Problems Why Does a Fractured Perspective Lead to Just Better-Than-Not-Doing-It Results?

The Agile Manifesto Helps Teams See the Purpose Behind Each Practice

Individuals and Interactions Over Processes and Tools Working Software Over Comprehensive Documentation Customer Collaboration Over Contract Negotiation Responding to Change Over Following a Plan Principles Over Practices

Understanding the Elephant

Methodologies Help You Get It All in Place at Once

Where to Start with a New Methodology

3. The Agile Principles

The 12 Principles of Agile Software The Customer Is Always Right...Right?

“Do As I Say, Not As I Said”

Delivering the Project

Principle #1: Our Highest Priority Is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software. Principle #2: Welcome Changing Requirements, Even Late In Development. Agile Processes Harness Change for the Customer’s Competitive Advantage. Principle #3: Deliver Working Software Frequently, from a Couple of Weeks to a Couple of Months, with a Preference to the Shorter Timescale. Better Project Delivery for the Ebook Reader Project

Communicating and Working Together

Principle #4: The Most Efficient and Effective Method of Conveying Information To and Within a Development Team Is Face-To-Face Conversation. Principle #5: Businesspeople and Developers Must Work Together Daily Throughout the Project. Principle #6: Build Projects Around Motivated Individuals. Give Them the Environment and Support They Need, and Trust Them to Get the Job Done. Better Communication for the Ebook Reader Project

Project Execution—Moving the Project Along

Principle #7: Working Software Is the Primary Measure of Progress. Principle #8: Agile Processes Promote Sustainable Development. The Sponsors, Developers, and Users Should Be Able to Maintain a Constant Pace Indefinitely. Principle #9: Continuous Attention to Technical Excellence and Good Design Enhances Agility. A Better Working Environment for the Ebook Reader Project Team

Constantly Improving the Project and the Team

Principle #10: Simplicity—the Art of Maximizing the Amount of Work Not Done—Is Essential. Principle #11: The Best Architectures, Requirements, and Designs Emerge from Self-Organizing Teams. Principle #12: At Regular Intervals, the Team Reflects on How to Become More Effective, Then Tunes and Adjusts Its Behavior Accordingly.

The Agile Project: Bringing All the Principles Together

4. Scrum and Self-Organizing Teams

The Rules of Scrum Act I: I Can Haz Scrum? Everyone on a Scrum Team Owns the Project

The Scrum Master Guides the Team’s Decisions The Product Owner Helps the Team Understand the Value of the Software Everyone Owns the Project

How Product Owners, Scrum Masters, and team members can be better pigs No room for chickens

Scrum Has Its Own Set of Values

Act II: Status Updates Are for Social Networks! The Whole Team Uses the Daily Scrum

Feedback and the Visibility-Inspection-Adaptation Cycle The Last Responsible Moment

Wait a minute—can’t we avoid bottlenecks by planning up front?

How to Hold an Effective Daily Scrum

Act III: Sprinting into a Wall Sprints, Planning, and Retrospectives

Iterative or Incremental? The Product Owner Makes or Breaks the Sprint Visibility and Value

Elevating goals motivate everyone on the team

How to Plan and Run an Effective Scrum Sprint

Act IV: Dog Catches Car

5. Scrum Planning and Collective Commitment

Act V: Not Quite Expecting the Unexpected User Stories, Velocity, and Generally Accepted Scrum Practices

Make Your Software Useful User Stories Help Build Features Your Users Will Use Conditions of Satisfaction Story Points and Velocity

Why story points work

Burndown Charts Planning and Running a Sprint Using Stories, Points, Tasks, and a Task Board Generally Accepted Scrum Practices

Act VI: Victory Lap Scrum Values Revisited

Practices Do Work Without the Values (Just Don’t Call It Scrum) Is Your Company’s Culture Compatible with Scrum Values?

6. XP and Embracing Change

Act I: Going into Overtime The Primary Practices of XP

Programming Practices Integration Practices Planning Practices Team Practices Why Teams Resist Changes, and How the Practices Help

Act II: The Game Plan Changed, but We’re Still Losing The XP Values Help the Team Change Their Mindset

XP Helps Developers Learn to Work with Users Practices Only “Stick” When the Team Truly Believes in Them

An Effective Mindset Starts with the XP Values

The XP Values Paved with Good Intentions

Act III: The Momentum Shifts Understanding the XP Principles Helps You Embrace Change

The Principles of XP XP Principles Help You Understand Planning XP Principles Help You Understand Practices—and Vice Versa Feedback Loops

7. XP, Simplicity, and Incremental Design

Act IV: Going into Overtime, Part 2: Second Overtime Code and Design

Code Smells and Antipatterns (or, How to Tell If You’re Being Too Clever) XP Teams Look for Code Smells and Fix Them Hooks, Edge Cases, and Code That Does Too Much

Wait a minute, what’s wrong with reusable frameworks? What’s the difference between a library and a framework?

Code Smells Increase Complexity

Make Code and Design Decisions at the Last Responsible Moment

Fix Technical Debt by Refactoring Mercilessly

Isn’t refactoring rework? And isn’t rework one of the biggest sources of bugs? Isn’t it better to prevent this sort of problem by doing good design up front, at the beginning of the project? Isn’t it safer to build the code right the first time?

Use Continuous Integration to Find Design Problems Avoid Monolithic Design

Incremental Design and the Holistic XP Practices

Teams Work Best When They Feel Like They Have Time to Think Team Members Trust Each Other and Make Decisions Together The XP Design, Planning, Team, and Holistic Practices Form an Ecosystem That Spurs Innovation Incremental Design Versus Designing for Reuse When Units Interact in a Simple Way, the System Can Grow Incrementally Great Design Emerges from Simple Interactions

Act V: Final Score

8. Lean, Eliminating Waste, and Seeing the Whole

Lean Thinking

You Already Understand Many of These Values Commitment, Options Thinking, and Set-Based Development

Scrum teams commit to delivering value, but give themselves options for how to do it Incremental design, set-based development, and other ways to give your team options

Act I: Just One More Thing... Creating Heroes and Magical Thinking Eliminate Waste

Use a Value Stream Map to Help See Waste Clearly

Gain a Deeper Understanding of the Product

See the Whole Find the Root Cause of Problems That You Discover

Deliver As Fast As Possible

Use an Area Chart to Visualize Work in Progress Control Bottlenecks by Limiting Work in Progress Pull Systems Help Teams Eliminate Constraints

9. Kanban, Flow, and Constantly Improving

Act II: Playing Catch-Up The Principles of Kanban

Find a Starting Point and Evolve Experimentally from There

Wait a minute. So Kanban doesn’t tell me how to run my project?

Stories Go into the System; Code Comes Out

Every software team follows a system, whether they know it or not Kanban is not a software methodology or a project management system

Improving Your Process with Kanban

Visualize the Workflow

Use a kanban board to visualize the workflow

Limit Work in Progress

Why not make the WIP limit 1 and meet all the time? Aren’t shorter feedback loops better?

Measure and Manage Flow

Use CFDs and WIP Area Charts to Measure and Manage Flow

How to build a cumulative flow diagram and use it to calculate the average lead time Use a CFD to experiment with WIP limits and manage the flow

Little’s Law Lets You Control the Flow Through a System

If the team still has to do all of that production support work, then what happened to the other work they were doing? Won’t it accumulate somewhere else?

Managing Flow with WIP Limits Naturally Creates Slack Make Process Policies Explicit So Everyone Is on the Same Page

Emergent Behavior with Kanban

10. The Agile Coach

Act III: Just One More Thing (Again?!)... Coaches Understand Why People Don’t Always Want to Change

Coaches Listen for Warning Signs That the Team Is Having Trouble with a Change

Coaches Understand How People Learn

Use Shuhari to Help a Team Learn the Values of a Methodology

Coaches Understand What Makes a Methodology Work The Principles of Coaching

Index

← Prev
Back
Next →

← Prev
Back
Next →