Book review: TMap NEXT in Scrum

One month ago I enthusiastically anticipated the book release of TMap Next in Scrum. After reading the book I walked away disappointed and wondering what the fuss was all about.
One third of the book consists of the description of Agile, Scrum and all of its facets. Helpful for someone who does not know anything about the subject matter but in my opinion it is illustrative that a fair portion of this book is sheer repetition of what can be read about more extensively in other books.
The combination of TMap and Scrum is sensibly explained. Yet, much of what is said is about the “what” and not about the “how”. For instance, the authors should have explained how to avoid the pitfalls they describe. Secondly, most of the observations are quite obvious.

So was the content worthy of publishing in a book? In my humble opinion: no.

Tagged on: ,

5 thoughts on “Book review: TMap NEXT in Scrum

  1. Thomas

    This review is a little short of content as well, David. Maybe you can give some examples of obvious observations and unavoided pitfalls?

    1. David Post author

      Well, at least we agree on one thing, that the book is short of content 😉
      But before I answer your question, did you read the book yourself?

        1. David Post author

          Well, I’ll skip the first 34 pages because it’s all regurgitation of what can be read elsewhere.
          Page 37, 39 (4.2):” testing is part of the DoD (..) nothing is done till testing is completed.” Duh…that’s kind of obvious why mention it twice.
          Page 40 (4.4): This list of advantages is not unique for TMap, but can also be achieved with other structured approaches. Secondly, test cases are not necessarily reusable, especially because things tend to change (drastically) in an Agile environment.
          5.1.1 needs practical examples of the adaptability of TMap in Scrum in more than one aspect.
          5.1.2 sells TMap rather than shedding new light on TMap in Scrum.
          Page 45: so what’s the added value of a test plan? what does a planning or a budget mean when it’s all subject to change anyway? How is that BDTM when there is no real grip on the when or the costs?
          Page 51, 52: Not much different from the classic risk analysis
          5.3.1/5.3.2 Leave out the RFC’s, not an aspect to be discarded lightly.
          5.3.3 No different from traditional software development.
          5.3.5/5.3.6 So which propositions for test automation does the author suggest?
          5.3.6 TDD is a subject on its own. Unit testing (BDD/TDD) is not a trivial subject and needs more than 14 lines. Some examples (Cucumber, Ruby and such) would have helped to see it’s a path not every tester can go down.
          Page 64 Last few lines are pretty much a repetition of lines in a previous chapter.
          Chapter 6 repeats much of what has already been written. The addition of DoR or DoS could have been in previous chapters. in fact, it doesn’t make sense not to write it in previous chapters but to make a separate chapter which refers to the previous chapters a lot and add DoR and DoS.

Leave a Reply

Your email address will not be published. Required fields are marked *