I am sometimes asked which books I would recommend reading. For the blog, this is generally not difficult — it’s enough to open all posts with the tag “I-recommend.” But since it’s been almost five years now since I revived my blog and began writing about the books I’ve read, I decided to put together a selection of non-fiction books I’ve read during this time that fall into the category of “you must read them.”
I have already written detailed reviews of all these books, so this time I’ve selected only the very best, grouped them by topic. For each book I give only brief recommendations on why they are worth reading, but you can always open the link to the full review. I hope this will be useful to someone. So, let’s begin.
One of the best books I read last year was a relatively short but incredibly useful guide by Konstantin Borisov on conducting interviews—“To Hire or Not to Hire? Or How to Interview a Developer.” I now recommend it to everyone, whether they are conducting interviews themselves or preparing to be interviewed. It gives you a much clearer understanding of what a potential employer is like and whether they are worth considering.
But Konstantin Borisov also wrote another book—“How a Good Developer Can Avoid Becoming a Bad Manager.” The topic may not seem obvious at first, but it’s actually incredibly relevant. In the IT industry, it’s well known that top specialists often get promoted simply because they excel at their tasks. One day, you’re a great developer, the next, you’re mentoring a couple of interns. Before you know it, you’re made a lead developer, then given a team to manage, and suddenly—you’re a manager.
I went through a similar path myself, though for a long time, I tried to balance both roles. I loved mentoring specialists and building teams, but at the same time, I still wanted to be a hands-on developer. Eventually, I realized that trying to do both was making me worse at each, and I finally made the decision to fully transition into management.
It’s impossible not to know about Agile development nowadays. Heaven forbid someone catches you unaware—it’s practically a career-ending move. I’m joking, of course, but the fact remains: every developer and manager in IT can talk at length about how they’ve implemented Scrum, Kanban, sprints, and plenty of other fancy terms in their teams. However, in practice, it turns out that very few people actually know how to make all this work properly (and the author of these lines harbors no illusions about his own expertise, even though I’ve been working in this field for a long time). While these methodologies have been actively used for many years, it eventually became clear that in their pure form, they work well for small teams, but when applied to projects with a large number of participants, the results are less impressive. That’s when the next wave of development began, as people started thinking and experimenting with how to scale these practices.
A lot of new methodologies emerged—some faded away, while others developed through trial and error and found their use. Among them are Scrum of Scrums, LeSS, and SAFe, though there are many others as well. It’s hard to say which one is clearly the best, but SAFe has recently gained a lot of followers and seems to be leading the pack statistically. At some point, I couldn’t ignore it because every methodology has its advantages. Even if it doesn’t fully take root for you or your team, you can always borrow some elements, implement them first, then move on to the next… and so on, as long as it genuinely improves quality, transparency, and, of course, the final result.
I have often heard opinions that the work of a consultant is useless and lacks prestige. Something like, “They show up, give a bunch of advice, and leave, without caring about what happens next.” Such an approach to work has always been unacceptable to me, and now that I myself work as a consultant, I want to briefly describe one type of task I have performed at the request of several CEOs, whose feedback on the results was positive.
With experience in both software development and operational management, I can take an external view of a business and evaluate different aspects of its work. As a result, analyzing existing processes—everything I can get my hands on—has proven to be in demand. (Sometimes this is called an audit, but I prefer the term “analysis” as this term has a less negative connotation.) I begin high-level examination of a company by interviewing its CEO: why they reached out, what they want to achieve, what they are dissatisfied with, and what their key products, departments, and people are. Then I compile a list of individuals and competencies that can provide insight into internal processes. It’s crucial to identify who will be available and as open as possible for discussions. During several interviews, I try to understand what the person’s work entails, what motivates them, how they interact with and perceive their colleagues, and so on. Simultaneously, I ask to join key meetings of managers and leads, simply to listen to how they discuss topics, set agendas, conduct meetings, and follow through on decisions. Of course, I also gather relevant documentation about products and processes for further study.
When I wrote about Alexey Krivitsky’s book Agile Retrospective Kickstarter a month ago, I mentioned that much of his work is based on the work of Esther Derby and Diana Larsen (as he openly acknowledges in his book). At that time, I also promised to write separately about the book by these women facilitators. So here I am, fulfilling that promise.
I read the book in English, although in 2017, it was also published in Russian by Dmitry Lazarev Publishing under the title “Agile Retrospectives: Turning Good Teams into Great Teams.”
Why do teams need retrospectives? I’ve already written about this in detail elsewhere, but here’s a brief reminder: retrospectives help teams learn from their mistakes and grow. Without them, no Agile methodology can operate at full capacity.
Esther and Diana explain how to make such meetings as productive as possible, drawing from their many years of experience and unique insights. It is in this book that they propose the five-stage format for retrospective meetings, which Alexey Krivitsky actively adopts and promotes in his own book.
Lately, I have been actively rereading various books and articles about Agile, and sometimes even exploring new material. In my opinion, Agile methodologies offer a lot of valuable practices, but one of the most useful ones is retrospectives—meetings where the team can look back, reflect on what has been done, analyze their experiences, and choose a few experiments to improve how things are done.
When people implement different Agile methodologies, they often forget that flexibility is not just about introducing daily stand-ups and breaking tasks into short sprints. It is fundamentally about learning from experience, adapting, and evolving. Without retrospectives, this does not work. That is precisely why retrospectives are so important. However, even these meetings can either be conducted properly and effectively or simply for the sake of formality (“because it is required”). For this reason, retrospectives are sometimes the subject of not only individual articles but even entire books.
Agile Retrospectives Kickstarter is one such book. Although it was written by a Russian-speaking author, Alexey Krivitsky, it was originally written in English, with the Russian version created later with the help of his colleagues.
The book itself is relatively short, just over 50 pages. The author, a practicing Agile coach, shares his experience in conducting retrospectives. However, he does not do this by providing an extensive set of examples or academic knowledge. Instead, he has compiled experiences from many sources into a highly condensed “retrospective cheat sheet,” offering a collection of possible exercises for conducting effective retrospective meetings. Alexey candidly admits from the outset that he did not invent any of these exercises (or at least does not remember inventing any) and even borrowed the methodology for breaking a meeting into several stages from other coaches. His contribution was to compile all of this into one relatively short guide that can be kept handy and used whenever preparing for a retrospective.
Not long ago, on the last day of 2020, I wrote a review of the book Kanban and Scrum — Making the Most of Both, which I highly recommend to anyone interested in implementing Agile methodologies. However, this book was not the first by the author, Henrik Kniberg. His first book, published in 2007, also drew on his personal experience with agile methodologies and was titled Scrum and XP from the Trenches. Kniberg himself admits that he wrote this relatively short book over a single weekend, when he felt a strong urge to share his experiences with others.
This time, I won’t delve into the specifics of agile methodologies or why I’m singling out Kniberg’s books in particular, as I covered that in my previous review. Instead, I’ll briefly describe the book itself.
It’s also a very concise account of how he and his teams implemented various practices from Scrum and Extreme Programming in their work, with concrete examples and specific descriptions of the pros and cons. He’s not afraid to admit mistakes and point out what can go wrong. This is quite normal for agile methodologies, where much is governed by the motto “experiment and see what works best for your specific team.” The key is to frequently evaluate what’s been done (unlike older methodologies, where you might work for a year only to realize that you’ve been doing it wrong all along).
Since the beginning of the 21st century, the software development industry has undergone a tremendous number of changes. Nowadays, if you aren’t familiar with Agile methodologies and words like Kanban and Scrum leave you puzzled, chances are you might hear, “Out of the profession!”
Many people now see Agile methodologies as some kind of panacea for all problems. It’s like, “Back in the day, everyone worked with Waterfall, so things were slow, expensive, and unpredictable.” And if you suddenly switch to modern agile methodologies, happiness will immediately follow. But there is no cure-all, and any methodology requires proper application. In my experience, I haven’t seen a single company that fully applies all aspects of agile methodologies, and that’s generally fine. Agile is more about approaches and practices that each team should try, experiment with, and find what works best for them. Of course, there are certain principles that need to be followed.
I also know several companies (fairly large ones) that became disillusioned with Agile after trying the wrong approach or implementing it incorrectly. Personally, I’m not an avid fan of every methodology, but I’ve worked extensively with Agile, tried different approaches with teams, and continuously read about implementation practices—regardless of the old saying, it’s better to learn from others’ experience.
And I must say, there aren’t that many good books on the subject. Many authors provide rather superficial descriptions of techniques, while some are more focused on selling themselves as trainers than on helping companies understand what to do and how to do it. I can say that even some official certifications from the Agile community provide very superficial knowledge, and people then flaunt an official certificate without any real experience or, at times, even a basic understanding of how to work with the methodology.
Kanban is a flexible management tool that originated from Toyota. Over the past few decades, it has become very popular in the IT industry, alongside other agile methodologies. David Anderson has worked in IT for 30 years and has been an advocate of the Kanban methodology for many years. The title of the book, Kanban: Successful Evolutionary Change for Your Technology Business, suggests that we’ll learn both about the methodology and the best ways to apply it. At least, those were my expectations. Especially since it’s praised by various experts in the annotations.
However, I found the book difficult from the very first pages. I pushed through to the end to form a complete opinion, but it only confirmed my initial thoughts rather than changing them.
The book Product Management with Scrum by Roman Pichler was recommended to me by some great colleagues with the comment, “it’s clear and to the point.” It’s hard to disagree with that assessment, but my expectations, based on such a recommendation, didn’t quite match the book’s content.
No, it’s not that the ideas or methods described in the book are wrong—everything is fine in that regard. However, I’m left wondering who the target audience is. Who exactly is this book for?
The book’s main goal is to explain Scrum from the perspective of the role of the Product Owner. It begins by describing who the Product Owner is, then goes on to detail what is expected from them at different stages of working on a product using the Scrum methodology.
