As part of my current job, I’m expanding my study of project management from traditional PMI practices to agile methodologies and the Scrum framework. Being the academic I am, I turn to books for a lot of my education and exploration, and reading through blog posts and reviews pointed me to Coaching Agile Teams as a good place to start. I’ve been reading this book for about two weeks, and it has resulted in adding two other books to my wishlist, but that’s for later.
The sub-title of this book is, “A companion for ScrumMasters, Agile Coaches, and Project Managers in Transition.” I was exposed to agile at least a year or two ago, but I’ve only really begun to study it over the last six months, and only received some formal training in it a month ago. I’m nowhere close to being a ScrumMaster, let alone an Agile Coach, but I think “Project Manager in Transition” might work for me.
This book was truly excellent, but I think that sub-title is really important. It identifies a target audience, and if you’re not part of that audience, Coaching Agile Teams may have limited benefit for you.
Despite being just over 300 pages, I felt like this book was a quick read. Lyssa Adkins is an excellent writer, and I was impressed with her prose and structure. Every chapter was well-organized, and the concepts flowed from one to another effortlessly. There was a good mix of text, diagrams, and tables, and the book was the best blend of anecdotes and lecture-style advice. If Ms. Adkins can present half as well as she writes, that alone may convince me to attend a conference where she is speaking, because she would be excellent.
As someone coming out of a command-and-control environment, the concept of agile is as much a breath of fresh air for me as it was for Lyssa Adkins, and she communicates well both the guidance the coach will need to provide for his or her team and the guidance the coach will need for themselves. While Coaching Agile Teams has a lot of great guidance for you to use with your team, it’s really a guide for how you, as a coach, need to behave and treat people. It is full of examples, suggestions, and tips for working with your team to help them become excellent with agile.
Notably, it is not a book about Scrum or XP, it is a book about agile. And it may be a bit over-the-top at times; Adkins is in love with agile, and it shows. There are times when Adkins refers to agile in the manner I am used to seeing deities or other worldviews referred to in theological texts. She believes that agile is not just a methodology for working better, but rather it can improve every aspect of our lives, and she views agile coaching (distinct from agile training or agile teaching) as a means of helping people become better “agilists.”
I don’t think she’s wrong, though. While Adkins borders on waxing poetic, she doesn’t go too far, and she builds a strong case for the values of agile being excellent values for our lives both outside and at work. Even better, the book is peppered with additional resources and references that are listed in a very readable format at the end of each chapter, and which will help the reader find even more examples, tools, and books.
Who should read this book?
If you work in an agile environment and are or will be a team lead, ScrumMaster, or have an interest in coaching agile teams, this book is an absolute must. I think it would also be extremely helpful for people working in a consulting role with agile teams, or teams that aren’t agile but want to be. It is stuffed with fantastic advice and examples, and I would rate this book as my second must-read so far, along with The Mythical Man-Month.
Who shouldn’t read this book?
If you don’t want to be an agile coach, an agile manager, or a ScrumMaster, then there’s not much to be gained here. There are tips on inter-team-communication that are helpful, but you can find far less expensive books that spend more time on that subject than this book does.
In regards to audience, I don’t think this book will be helpful if you’re unfamiliar with agile. Adkins regularly makes references or statements that assume at least a cursory knowledge of agile and software development. This is something I didn’t pick up on until around chapter eight or nine, though; because I’ve been in IT so long, and study conflict resolution, and have a background in project management, and have been studying agile for half a year, I had a contextual knowledge that gave me a strong foundation for this book. But a phrase somewhere in those later chapters made me sit back and think, “Would someone who isn’t familiar with agile know what that example means?” and I realized they wouldn’t.
If you want to read this book but aren’t sure if you have that foundation, I think it can be quickly gained. Go read the Agile Manifesto and the 12 Principles behind the manifesto. I would also suggest you read the Scrum Guide, which is just 18 pages long. If the Scrum Guide leaves you with questions, you may find the Extreme Programming pages enlightening. Really, if you’re the type of person who would be interested in reading this book, there’s a good chance you have sufficient background to understand it; it certainly doesn’t require experience in IT, even if that’s where agile began. And Adkins does an excellent job of generalizing examples so they can be used in multiple disciplines.
How should I read this book?
I think it flowed very well reading it beginning to end, but the chapters are designed to be modular so they can be consumed individually. Where appropriate, they refer to each other, which will be helpful when scanning back through the book in future years. This book is so well organized it would make an excellent text for a college course.
Where can I get this book?
I suggest getting it in paperback from Amazon.com, or at least that’s the route I preferred. It is available on Kindle as well, and would read just fine on a computer screen, but I suspect the tables and diagrams wouldn’t translate to an e-ink screen very well.