Just at the end of April, just before the long May weekend, a book with an interesting title “Scrum and more. Theory and practice in Agile” methods by Krystian Kaczor. I knew that the position has been on our publishing market for some time now and I was sincerely interested to join the group of readers, finally I succeeded. I read the book in instalments within five days. Somebody will think, 5 days for this on installments is not good? Not really, it was mainly due to the limited amount of time I could spend on reading.
Why the first contact with the book and the immediate review
I didn’t let myself be asked for a long time by PWN publishing house and I committed myself to review several positions from the market dedicated to IT, for the first time, for known reasons, a book about Scrum went on fire, for the second time you will probably wait until next month. I would like to mention that the review I am writing is fully objective, built solely on my own observations and feelings after reading the book. Probably not without significance for the description will be the experience gained in working on large and medium agile projects in various roles. Over the last 8 years I have been able to rewind several projects in different industries where I worked, as a member of a development team in the domain of tester, product owner or recently in parallel, as scrum master in 2 international teams. Since this is my first review I can only hope that you will like my style and at the end of the day it will simply come in handy.
Who is this book for?
I think that everyone will find something interesting for themselves, I’m talking about theoreticians, but above all Scrum practitioners. Yes, I’m writing Scrum on purpose, and in a moment I’ll explain why. Being an experienced person, practitioner and advocate of agile approach to project management, I found almost everything important in this book. There were also issues that I read with particular interest, i.e. agile contracts and agile coaching. Some of the issues were briefly presented, not very precisely. For me it wasn’t a problem, but I think that beginners who don’t know the broader issues may sometimes have trouble understanding a piece and weave it into a larger whole.
What we have to give the author is that he described the Scrum framework, which is the basis of this book, well, comprehensively and meticulously. For those who are interested in this topic and want to expand their current knowledge it will certainly be good material. However, for those interested in knowing about other approaches under the agile umbrella I suggest looking for dedicated items, apart from Scrum, there are 6 different agile methods described here, accumulated on 40 pages. It’s pretty hard to read, especially when you have a specific terminology for each of them. It was the only moment during reading that bored me for a while.
Method
I don’t want to go through the book chapter by chapter and point out or praise each one of them, instead I want to look at the book from above as a whole. If necessary, I will jump to a specific topic and comment on it. In my opinion, the author was right to start by describing the classical approach in order to show how it all started and shaped over the years. What I missed was to present the key differences between the classical and agile approaches in the conceptual sense, to crystallize the unique values of both approaches or finally to suggest when the described approaches should be used.
Unavoidable points
An interesting idea is the bulleted sections to think about after each chapter. What is important is always embedded in the subject matter of the chapter and can naturally complement the reader’s thoughts, often indicating areas or problems that can be thematically linked and verified.
The author from time to time asks questions in style, what is it like in your design team? I like this approach because it indirectly forces the reader to translate the acquired knowledge into current team practices, can spark ideas for potential process improvements and translate into a better understanding of the described issues.
What could be better?
The chapters are not consistent in terms of the amount of information they contain, some of them describe in detail the headers of their data and others are only a few-page “placeholders”. While reading I sometimes had the impression that the author did not want to stop writing the book and at a later stage wanted to return to certain chapters, but he did not do so. I am referring here primarily to chapter seven, which deals with the extensive subject of problems with requirements. An important topic, certainly deserves special attention of the reader, while the form (3 pages) leaves much to be desired. Personally, I think that the definition of requirements and related problems should have a separate chapter, in which the issues of staff building and the User Story method could be linked. The topic of the requirements definition divided into three chapters seems to be not fully considered.
As a certain inconvenience I have also received a not always consistent language of expression, the author uses abbreviations and colloquialisms, which I think were supposed to refresh the message and introduce intellectual relaxation and sometimes simply disturb, not always everything is ‘cool’. It’s also a pity that the drawings and diagrams don’t have signed sources, only at the end of the book we have an accumulated bibliography: a list of books, web links, blogs and videos on YouTube.
From time to time, stylistic errors and typos are also visible, here the final proofreading before the book was submitted could certainly be a little better…
Conclusion

Of course, it is not easy to create something yourself, it is easier to point out mistakes. Taking into account the pros and cons presented personally I would recommend reading this item, it has its drawbacks while the advantages prevail. This is a book by a native author, which can be read in Polish and quite a lot can be learned from it. It is a pity that the author sometimes describes the issues raised too superficially, perhaps some topics were too obvious to him? Perhaps he has not entered into the shoes of a potential reader enough ??? Check for yourself and do not forget to share your opinions.
1 Comment