Agile Discovery & Delivery Outline

Photo by Eden Constantino on Unsplash

Last week, I announced that my new book, Agile Discovery & Delivery, will be arriving in June! I heard from many of you last week and was so, so happy to hear that you see an important gap for this book to fill too. With it, I aim to help engineers become high-performing agile team members early in their careers. The book is focused on the collaboration side of software development. It contains the basics I wish every computer science student knew when they graduated. This week, I’ll take you a bit deeper and share the high-level outline for the book.

Agile Discovery & Delivery: Introduction

As I mentioned above, this book is for early-career software engineers or entrepreneurs new to the software scene. I want to help readers avoid pitfalls and build great software development habits from the start. In the Introduction, I tell a story about a project I led personally at National Geographic…that went terribly. It sets the stage for why the concepts in this book are so important. Then I talk a little bit about my background and how to navigate the rest of the book.

Part I: Agility Overview & Agile Teams

There are two chapters in Agile Discovery & Delivery: Part I. The first is about the agile principles, the foundation of everything else we talk about in the book. The second is about agile teams and what makes them high-performing.

Chapter 1: An Agile Software Development Overview

In Chapter 1, I talk about agile as a culture and a mindset. I touch on waterfall simply to juxtapose it with the agile principles and describe what problems we’re trying to solve with them. The story of Eric Yuan, a Cisco WebEx executive-turned founder of Zoom is the perfect story about how paying attention to the agile principles can propel you past your competitors (or, in Yuan’s case, his former employer).

I, of course, discuss the agile manifesto and then go over a curated list of agile principles that I believe form the backbone of every successful agile team:

  • Focus on creating value for the customer
  • Incorporating customer feedback
  • Continuous Improvement
  • Iterative development
  • Responding to change
  • Empowered, dedicated teams
  • Simplicity
  • Eliminating waste / lightweight processes
  • Technical Excellence 
  • Sustainable Development

Out of these principles, frameworks like scrum, kanban, lean start-up, XP, etc are born.

Each of my chapters has a Key Concepts section like this one that explains the basics of any given topic. Then, there is a Reality section where I talk about how these basics actually show up in the “real world”. Most of us know that sh*t hits the fan when we apply theory to practice. This section is to talk about some common things engineers may see in the wild. The final section of each chapter is my Survival Tips section. It’s a bulleted list of advice that should help make new engineers’ lives easier or better.

Chapter 2: Agile Teams

Great agile teams are small, cross-functional, dedicated and empowered. In this chapter I dive into what that means and readers get a preview of the various roles we might find on an agile team. I don’t go into self-selection very much in this chapter, but I do mention it and include an appendix section on it. It’s way too near and dear to my heart to leave out of my first book. 🙂

Part II: Discovery

Linking discovery (“how you figure out what to build”) and delivery (“how you build it”), I believe, is one of the best parts of this book. So many others focus on one or the other, but I wanted to give new engineers the complete picture of how to build great software. Everything from start to finish.

Chapter 3: Finding Product-Market Fit

So, I talk about product-market fit. Then, the role engineers can and should play in the discovery process. I talk about figuring out who your target audience is before diving into three discovery frameworks: lean start-up, design thinking, and google design sprints.

Part III: Delivery

Delivery is the section where I describe the agile frameworks new engineers are most likely to encounter. I finish with a chapter containing various other gems that can be applied no matter what framework you’re using.

Chapter 4: User Stories

For any of these frameworks, teams need to know how to write great requirements. User Stories describe a slice of value we can deliver to a customer. Here, I offer many examples of user stories and acceptance criteria, including how to break a large story into smaller stories.

Chapter 5: Scrum

Scrum is the most popular framework in use today. In this chapter, I describe its principles, roles, sprints, artifacts, events, metrics, and then dive into estimating. There is a robust Survival Tips section in this chapter given that many computer science graduates will encounter Scrum in their careers.

Chapter 6: Kanban

I like to describe Kanban as the gateway drug to agility. It’s a nice way to slide into agility. In this chapter, I discuss Little’s Law and why Work in Progress (WIP) limits are so important. Then, I talk about principles, artifacts, events, more metrics, and Scrumban.

Chapter 7: More Key Concepts & Survival Tips for Engineers

This is my random section. I talk about pair / mob programming, branching & merging code, feature flagging, test-driven development, DevOps, and agile @ scale. A few of these topics are merely introduced here and are fleshed out more in the appendix.

Conclusion

Honestly, what’s the use of having an engineering degree if you’re not planning to use it to change the world? Life tends to be better when you enjoy the people you work with and the way you work. So, if you don’t like how your team is working, get out there and change it!

That’s the gist of the book. If you’re interested in pre-ordering or learning more, please follow my blog! I’ll be sharing a lot more in the weeks to come.