Book Review: Quick Glance At: Agile Engineering Practices

 I don't usually read books that are focused on development of software. However, each year I go to Turkey on vacation, I read something I usually would not, and then take a picture on the balcony of the book I am reading. This time it was for David Tanzer's engineering book. 

Without going much into the content of the book, I found it helpful to have all basic practices in one place. There's stuff about pure functions, side effects, Mikado method, and so forth. There are code examples of not-so-great tests and how to refactor them, reading the book feels like you have an instructor sitting on your side. Even for a person who does not write code for a living, the examples made perfect sense and the refactoring made it obvious how good code needs constant bettering. 

I did not have much expectations when I started reading the book, but going through it has made it evident David Tanzer is a phenomenal character in our profession. Just the fact that he condensed about 7 books into one coherent piece is an example of the clarity of his thinking. And it does come with a price. For the most of it, I had to take a few min break after each chapter just to let the information sink in. 

I think this is a great book for any practitioner and also any middle manager thinking how to get the teams trained up. Especially the ending part about mental health and slowing down resonated with me. After all, even if we know all the best engineering practices, what are we to ourselves if we don't take care of ourselves.

Scrum Master Interview Questions

I contributed to a blog post on Luis Goncalves' Blog. Check out the scrum master interview questions right here.

Luis Goncalves is an Organisational Transformation Coach and he loves to write about Agile Retrospectives, Scrum, Scrum Master, and Agile in general.

Luis has created Scrum Master Training for the agile community. If you are interested in knowing more or even working with him you can take a look into his page here.

Scrum Is and Scrum Is Not

I  was talking with Luis Goncalves about "What Is Scrum" and how to learn it. That discussion inspired me to write a few working notes to refine my thinking around Scrum.

Scrum is a widely misunderstood framework for managing certain kinds of risks. The very fact, that many people don't see it as risk management, makes me believe the essence of Scrum is difficult to understand and ever more difficult to apply. When something is commonly done "wrong" or people don't "get it", is usually a signal that something has problems. It might be too complex or for example there could be too many variations of it. Neither of those apply with Scrum; it's well-defined and there is just one way to do it. Well, just one way to do it, but that way gives liberty for interpretation. 

For example, the official Scrum Guide tells "The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals." This doesn't mean that PO needs to control the (technical) details of what the Development Team does. It doesn't mean, in fact, that there would ever be two teams working in the exactly same way.

But the PO selects stories based on velocity! - he shouted. Not quite. Firstly, the PO doesn't select the work items for a Sprint; the Development Team accepts what *they* think they can accomplish during the Sprint. Secondly, "user stories" come from XP, not from Scrum. There is no reference to User Stories in Scrum Guide. As you might guess, there is absolutely no reference to velocity, either. "So what about Burndown charts", they surely are Scrum! No, they are not.

It's easy to mix this stuff. Continuous Integration, Flow Control, Unit Testing, TDD, Relative Story Points ... none of those are Scrum! It does not mean that one is forbidden to use them, though. Kind of like in marathon it's a good idea to keep being hydrated during the competition, but it's not about the Marathon (rules) in itself.