Although I’m a voracious reader, the books are mostly urban fantasies. I’ve challenged myself to read more agile-related books over the next year. Join me!
My goal is to read twenty books in the next 365 days. I challenge you to join me on this continuous learning journey. I started my challenge on 10/08/2022, and if all goes well, I will have read all of these books by 10/7/2023.
There are two main reasons for the challenge. First, I’m oddly competitive, so if I imagine that I’m racing other people, I’ll be more likely to achieve my goal. Second, this challenge will serve as a source of accountability. The fact that I’ve publicly committed to reading these twenty books next year will motivate me to stick with it lest I be embarrassed by my hubris.
This list is in no particular order. I curated the list from my Goodreads to-read shelf and selected books based on my interest in the book and whether I believed they would help fill a current deficit in my knowledge. Various peers recommended all books that seemingly fall into a business genre as a resource to solve common problems of agile teams.
I’ve read several books from Mike Cohn’s signature series, and out of curiosity, I checked to see what additional books in this series might be worth a read.
In my experience, the primary threat to agile transformation has been stamping out the deep-rooted command and control leadership styles.
I’m adept at recognizing activities that don’t align with an agile mindset, but I’m less skilled at helping peers develop leadership skills that are more agile-friendly methods.
I hope this book will arm me with tactics to help leaders adopt the agile mindset. Waiting for obstructionists to retire or die, as suggested by a trainer I once had, seems like an inefficient plan.
While initially researching the Scrum values, I found an article referencing radical candor. Intrigued by the term, further research led me to discover the following YouTube video and, subsequently, this book.
For me, one of the most challenging responsibilities of the Scrum Master role is having the courage required to have difficult conversations.
“When you don’t want to have a difficult conversation, you need to ask yourself: Is it because it will hurt them or hurt me? If it is because it will hurt you, then you’re being selfish.”
- John C. Maxwell
I hope this book will help me finalize my paradigm shift and grant me some tactics to be more comfortable with these conversations. Logically I understand why difficult conversations are essential, but I still approach them with reluctance.
It’s been on my list to learn about some of the other agile scaling approaches. I have picked up a SAFe Scrum Master Certification, so I’m somewhat familiar with SAFe, though I’ve never formally practiced it.
I believe there is value in branching out and gaining knowledge around additional agile scaling frameworks. Now that I’m working with a larger company with more agile teams, I’m looking to pick up more agile practices to help me navigate this complex environment.
The author of this book was my trainer when I took the Certified Scrum Master Course through Mountain Goat Software. He referenced this book several times in class as a source for additional information.
I like troubleshooting books, especially from people with industry experience. It’s easy to find books describing how Scrum should work in a perfect world, like an agile textbook. But I suspect that The Scrum Field Guide is a different type of text that will dive more into understanding the root cause and resolution of common problems.
While researching the Scrum values, I came across Gunther Verheyen’s blog, which led me to discover that he had a book, and I immediately added it to my to-read list.
I’ve read several of Gunther Verheyen’s blog posts, which resonate with me. If there are 97 things he thinks I need to know as a Scrum Practitioner, I want to know them.
While researching the origins and anti-patterns associated with the sprint commitment, I stumbled upon this book. While it is one of the agile values that we find more value in responding to change over following a plan, that doesn’t mean that planning isn’t still important.
I’m interested in potential psychological reasons why plans fail. I hope that by learning why they fail, I can account for that and drive team behavior in a more appropriate direction. I recognize that simply “planning better” is likely not the correct answer for agile environments, and I hope this book points me in the right direction.
The Agile Mentors community recommended this book at some point, and I added it to my to-read list.
My current role as a TPM blends the roles of the Scrum Master and Product Owner. Requirements gathering is a growth edge of mine. Thus, this book piqued my interest as it appears to fill a gap and be recommended by an agile community I respect.
This is another book recommended by the Agile Mentors community. Anytime someone I trust recommends a book, I add it to my to-read shelf and assume that future me will find it again when it’s the right time.
One of the bonus takeaways from my SAFe Scrum Master course was the concept of powerful questions. It’s been on my research backlog since taking that course. Powerful questions are a common technique used by agile coaches to lead teams to the correct answer.
Lately, I’ve felt like I’ve been dictating to my teams instead of helping them uncover their proper process. I hope this book will help me move back into facilitation instead of management.
This book has been on my radar since I first learned about story mapping in a Better User Stories course. It has also received recommendations from a fellow TPM and the Agile Mentors community.
When a resource continually comes to my attention, ignoring it seems foolish. Also, my teams are currently working on complex projects with many moving parts, and I suspect that proper usage of story maps could help us visualize how all of the pieces fit together.
According to a former developer I worked with, a Microsoft technology team touted this book as their savior from communication struggles. When our team struggled with communication, they agreed to read the book based on his recommendation.
It’s been several years since my first reading of this book. Given that communication is always a struggle for all teams, a refresher on this book seems prudent. Also, a second read will allow me to incorporate my notes into my second brain.
I’ve been reading about Extreme Programming since I started reading about agile. This agile approach crops up here, there, and everywhere.
Extreme Programming was foundational to the agile movement, yet I’ve never taken the time to familiarize myself with the details of the agile methodology. I wanted to read at least one definitive resource on the approach, and this seemed to be the right book.
I can’t recall the first time I came across this book. Anyone working in agile project management and not hiding under a rock will come across this best seller several times in their career. If agile coaches fail to fix some of the underlying team dysfunctions, an agile transformation will not thrive.
I read the first half of this book several years ago but never got around to finishing it. It’s been long enough now that I’ll start from the beginning. I found the book’s first half so enthralling that I could barely put it down, and that is not something I’d expect from a career-related book. This book is such a staple in the literature I can’t pass up finishing it.
Yet again, another recommendation from the Agile Mentors community.
Such a large portion of my work week is spent in meetings that it becomes demoralizing if they all feel fruitless. Staying on top of my facilitation game is a mechanism to avoid the perpetuation of meeting cycles.
The first meeting derails, and the team has just enough time to discuss the problem. Someone schedules a follow-up meeting to get a decision, but by the time we regroup, everyone has forgotten the problem statement. Then the vicious cycle begins.
I hope this book will provide some techniques to reach decisions more efficiently and help me short-circuit meeting cycles.
A recent article referenced this author as a resource for more information. When I followed the link to her Twitter page, I realized I’d read one of her retrospective books. Checking to see what other books she’d written, this one stood out to me, so I added it to my to-read list.
Although I wrote this article on accountability in agile, I’m still somewhat conflicted. I fear my piece is a little too nonchalant about the need to get work done.
The relationship between accountability and blame is so muddled in my head that I cannot separate the two. Of course, I want my team members to feel a sense of ownership and urgency in completing their work. Still, I don’t want teams to be punished for missing arbitrary deadlines when circumstances were out of their control.
I’m hoping this book might hold the missing link of how you build teams with a sense of ownership and responsibility about their work, a culture that lacks blame, and a process that enforces a sustainable pace.
If you had to guess, where would you say I got this book recommendation from? You’d be correct if you thought the Agile Mentors community.
This one is probably obvious, but many teams went fully remote during the pandemic and will never return to working in a co-located fashion.
Many essential early agile books were written assuming the teams would be co-located. Though I’m a massive fan of working from home, I can admit there was some value in being co-located. How does one replace the inherent value of information radiators and whiteboards? I hope to learn some tricks and tactics for building efficient distributed teams.
This one has dual sources. One is… you guessed it, the Agile Mentors community. The second source for this book was a blog post I mentioned earlier. When I was checking Diana Larsen’s books, this is another one that caught my eye.
The book’s description gives me hope that it covers how to boot up teams and get them going quickly, and it seems like it might also cover project kick-offs. These topics are relevant because I have a few teams with no actual process going through agile training soon. Some tactics to use to get them off to a good start and set a strong foundation would be helpful.
Okay, I’m only realizing now that I’m fleshing out this post that it’s starting to sound like an advertisement of the Agile Mentors community, which was not my intention. I have found membership to that platform to be helpful in the past. It’s just simply that every time I saw someone suggest a book there, I added it to my to-read list. Now that I’m doing this reading challenge for agile project management books, it’s a coincidence that all of the recommendations I picked were from the same place.
Recently I’ve been involved in a lot of transformation projects. With these types of projects, change management should be a consideration.
A previous co-worker always used to preach the importance of change management, an area in which I don’t have much experience, and I’ve decided I’d like to learn more about it.
This book was another resource recommended by the the daily standup questions article.
How can you not want to read this book with a title like this? I appreciate unique titles, maybe too much. Also, risk management is a growth edge for me. Agile processes innately manage a large portion of risk; thus, to this point, I’ve not focused on diving deep into the topic. Given that risk is such a crucial agile project management topic, it’s worth having a resource that covers it more in-depth.
I purchased this book in July of 2013, and I’m a bit embarrassed that I never got around to reading it. I’ve seen this book and its successor reference from several places over the years and procrastinated on reading it.
There is a lot of confusion around the testing role in agile teams. From the myth that agile projects no longer need testing to the stories of hasty layoffs of QA engineers. Then there’s the age-old favorite question - “what are test engineers supposed to do for the first half of the Sprint while the developers are developing the code?”
I expect that this book will cover all of those anti-patters. To this point, I’ve been fortunate to work with QA engineers who were secure enough in their positions that these common issues weren’t a huge problem, or at least weren’t the most urgent problem to solve on the teams I’ve worked with in the past.
But it’s better to prepare now instead of waiting until I find myself in situations where I need this knowledge but don’t have time to read a book to get it.
I happened upon the Nave Blog while researching alternative agile methods for forecasting delivery dates. This blog reignited my interest in Kanban. Realizing that I had only a cursory understanding of the agile approach, I felt it was worth giving the original book a read.
Kanban’s methods for predicting delivery dates speak to me. Especially after reading some of Sonya Siderova’s posts highlighting the inherent issues with story points.
When I’m learning something new, I start with the foundational knowledge and then do specific research to fill in any remaining gaps.
Well, this post turned out to be twice as long as expected. I appreciate your dedication if you’ve made it to this point without falling asleep like the dog in the header image.
Please join me in this reading challenge. Can you read these twenty agile project management books in 365 days?