Introduction

You know your current approach to managing projects isn’t working. Your releases are too slow. The products have too many defects. People are multitasking all over the place. It’s a mess. Is an agile software product-development solution the answer?

Maybe.

Agile solutions come in many flavors. You can even combine some of those flavors to create your own agile context for your project inside your organization. Don’t fall prey to the notion that you can “just” adopt one agile product-development approach or framework wholesale, regardless of your context. That approach ignores your organizational, project, and team contexts.

I have yet to see a project team that could not adopt an agile approach. And I have seen many successful teams that have created their own agile approaches. These teams rejected the idea of “agile” by framework or book. They found the agile principles and practices that work for them.

You might be a project manager, a technical lead, a manager, and yes, even a Scrum master. Whatever your role, you are an organizational leader, trying to discover how you might use agile principles in your project. Your job, as an organizational leader, is to understand the agile and lean principles. You can then use those principles to improve your projects. Even if you don’t fully embrace all that an agile approach delivers, you can still improve your projects with frequent delivery, feedback, and collaboration.

When you improve the projects, you can see more value from the products your organization delivers.

This book focuses on the team—the product-development team—and ways the team can learn to deliver value, over and over again. The book is divided into three parts:

• Part I addresses the creation of the agile team and how teams can learn to work together. If you are team lead of some sort (project manager, Scrum master, coach, technical lead, first-level manager) do start here. If you are a mid- or senior-level manager and are wondering why agile teams are different, this part will help you learn why.

• Part II addresses the options your team has for designing its agile approach and delivering value throughout the entire project. This is where you can design your agile project. This part includes how to charter a project, plan the work, visualize the work, build in quality, use velocity to guide estimation, know what “done” means, add value to your project meetings, and report progress outside the team.

• Part III addresses agile approaches outside the project team. Work groups often design a different agile approach than project teams. In addition, managers are key to helping an agile team succeed. And if you or your team aren’t sure where to start, I have some suggestions in the last chapter.

If you are a manager, you might want to start with Chapter 1 to better understand the agile and lean principles, continue to Part I, and finish with Part III.

If you are part of a geographically distributed team, read this book and determine what you can use and where your problems arise. Pay special attention to Chapter 8, ​Visualize Your Work with a Board​, to develop a cadence for retrospectives and learn as you experiment.

Scaling is the big idea now in agile approaches. My suggestion is to have each team learn how it can create a successful agile approach first, and then consider what needs to scale. I do not recommend every team use a “standard” agile approach. Each team is unique and can select from alternatives, as long as the team delivers value often.

If you want agile approaches to creating a program, where several teams collaborate to achieve one business objective, read Agile and Lean Program Management [Rot16]. If you want to understand how to manage the project portfolio in an agile way, read Manage Your Project Portfolio [Rot16a].

If you need more ideas, please read my six-part series about what scaling agile means. (The summary post is “Defining ‘Scaling’ Agile, Part 6: Creating the Agile Organization.”^[2]) Remember that scaling is not creating or using a prescriptive framework, but instead is the ability to deliver value across the organization, every day.

To solve the problem of the individual team being able to use agile approaches to reliably and consistently deliver features, read this book. Let’s start the fun.