According to The National Library of Poland research, only 10% of Poles read at least 7 books per year. I know that we are not reading a lot, and it was no surprise for me. Conversely, this fact motivated me to investigate to do some health-check about my reading.
At the beginning of 2019, I thought that I read approximately about 10 books a year, but I wasn’t sure. My regular peace is one book a month, but I didn’t measure it in any way. I’ve decided to change it.
Agile promises to deliver solutions through collaborative effort, cross functional team design, modern programming methods and probably many more things. Because of that, it is hard to distinguish between part and parcel of Agile, and optional techniques that were developed over time. Agile IT Organization Design by Sriram Narayan is a bird’s eye view on Agile topics and tries to organize them.
As the author mentions multiple things that are somehow related to Agile, starting with project estimations, through project finance and software development practices, ending with team room layout, the reader should be ready to jump over the wide variety of topics. Putting so many subjects in one book causes that specific aspects are discussed from time to time without any case-studies or detailed guidance how to kick start those ideas. It is valuable if you want to get a general idea, but mediocre if you want to get in-depth knowledge. There is nothing to worry about, because there are a lot of references to other publications or books, which may help you to explore more.
The good thing is that at the end of each chapter there is a summary, which after short skimming, helped me to create my own book reading order.
Author very often, explain reasons for doing things in a certain fashion. This approach helped me to reflect what and how I did in the past, and hopefully, it will help me make better decisions in the future.
This book is written for people from all walks of life. You can read it if you are a leader, a product owner, a software engineer or a stakeholder. It would be favourable if every person read that book, but it is not possible. If you work in a modern organization and you have the general understanding of bolts and nuts of Agile processes, you will probably not lose much by skipping that book. It is a good book for someone who would like to take a break from technical books and read something without code listings inside. Also, I would recommend this book to reach out for a particular chapter which are in the area of your interest.
I have highlighted over 50 sentences in this book. Some of them to remember, other to think about or to discuss them with colleagues. I have selected 9 that stuck in my mind:
Lessons learned from Decision Maker
In the past few weeks, I’ve read Getting Things Done, Technical Leadership, Elon Musk Biography and The Decision Maker.
Each of these books was good. But “The Decision Maker” is a game changer and I can’t stop thinking about this book. It was worth reading - for sure. I’ve decided to write a short book review and note the most important facts that I’ve learned from this book.
This book is a story about a company and its new owners who have left the corporation and decided to build a great place to work. It is full of dialogues, issues, and situations.
By observing those scenes, the author presents ideas and values that matter when you have to lead the team or the company.
Is this book only for managers or bosses? Certainly not. If you work with other people or deal with non-trivial tasks, this book is for you. For me, it is an appropriate supplement for any “Agile” book.
Blueprint presented in this book is a good starting point for setting up company culture.
The story did not take place in reality. Each scene looks genuine, but as a whole, it seems artificial. Like a romance from 90’s, when you know they will live happily ever after.
To begin with, you have to change your thinking about other people.
People:
Among some people, you can see those values. Among others, you have them hidden, and you have to unlock them.
But there is always somebody who disagrees with it and this is important to remember it. Do you see any similarities with Theory X and Y employees?
Secondly, you have to choose the Decision Maker. It is a person who makes a decision. How to find them? It is simple.
The Decision Maker is a person, who is closest to the action. Bosses or leaders are not often deeply familiar with the situation. Usually, team members are often closer to the problem.
The Decision Maker has to be capable of listening and understanding other people. Making a decision is a process, in which you have to talk and listen to the others.
The Decision Maker should be aware of what is going on. Awareness of facts and consequences is crucial. If the person does not have basic data for making decisions - like company current finance status - you are responsible for unlocking that data.
Wisdom and knowledge are desirable qualities of that person.
It is a leader’s job to choose the Decision Maker. The leader should also observe and monitor the Decision Maker to see if he makes good decisions. If not, something should be done by the leader.
It turns out that your employees’ decisions are often as good as or even better than yours can ever be.
People who are allowed to make the decision feel the ownership, because of that they will do everything to make the best possible decision.
The purpose of the advisory process is to look for a wider perspective.
The Decision Maker should ask at least a few people what they think about the decision.
He or she should ask:
But the Decision Maker should take the final call.
The decision maker process is not a silver bullet. It is only one tool or technique. The bigger picture is not straightforwardly visible in the book.
Between the lines, you can see many behaviours and dialogues which look familiar in “Teal Organizations”. If your organization is not ready, the decision maker process is definitely not the road to follow.
My previous experience with agile books was not so good. For one thing, they’re overfilled with advices and strategies, often without context. Put differently, it always required some additional effort, to imagine newly discovered strategies in my past experience. As a consequence, it may not be properly understand and implemented by my.
Main character of this book is a agile coach. He is hired by a company to help with underperforming team - the Dream Team. The book is sliced into about 250 chapters. In addition, every chapter is a new chance to learn something new. I’ve marked 26 notes, related to:
Most significantly, you can clearly see all these techniques in the same order as in Spock testing framework
You can find it, in a book category on amazon. But it is really a book? I do not think so. It was more like game for me.
Every ~10 chapters you have to made a decision. Every decision you made may lead to fail or success of your mission. At first I was confused about this approach and I came back to previous choices and where they lead me.
After reading a about 50 pages I decided to draw a chapter graph (with decision), and come back to paths that I not chosen when I read the whole book.
As a result, I’ve managed to made only good choices and lead the team to happy ending. The graph was on five A4 pages. It looks like this:
In contrast to good choices, failure paths showed me where the team my end. Learning from someone else mistakes is most important lesson for me.
I would like to thank Wojtek Erbetowski for recommending me this book.
Photo credit: Nightmare
Zen and the Art of Motorcycle Maintenance by Robert M. Pirsig
This is not a book about motorcycle maintenance. This is not only a book about the zen. This is not only a novel. This is mostly a book about philosophy. But philosophy is served in nice form.
This book took me to journey though a USA. I was feeling that I was an passenger of this journey. I was feeling that I was traveling with author that talks to me about philosophy.
During this journey, the idea of quality and value was assembled and dissembled many times, like motorcycle parts. It was mostly presented in straightforward form and readable manner. It has a good points to think about it. But, some parts were misleading for me.
I read this book because I need a change from normal technical book. My score for that book is 4 of 5 points.
Sam Newman - Building Microservices
Two days after the ending of GeeCON, I’ve managed to read „Building Microservices” by Sam Newman Book. It is in Early Release stage, so half of the chapters were missing.
The first chapter about concept of microservices is very good. It determines the direction of thinking. It relates to SOA, OSGI, and many know to me aspects and problems. If you do not know what microservices are, read only this chappter.
The rest completed chapters were good. I had a feeling that those chapters were written not only for architects, but for developers in the first place. There were funny sentences like „Big Scary CRM”. I was also enjoyed because there were many real life system described.
To summarize. I am looking forward for the finished book, to read it again. Also I would like to try to implements some solutions in microservices way :)
Before I read this book, I was on Impact Mapping workshop by Krzysztof Jelski on Agile By Example. I knew the concept. I practiced it in my company in one internal project. I am going to use it in next project with client.
But now. About the book. The book is very good. The knowledge in this book is very concise. Which was good for me, but may be problematic for person who does not know the topic, because important parts may be missed. Because the book has a lot of condensed knowledge, I’m going to read it again.
I found things not directly related to impact mapping. For example chapter about iterative and incremental software building process. I liked chapters, which were abstracts of other peoples thoughts, for example Tom Gilb about metrics. It is an advantage.
I like the idea that the concept of impact maps has been described without going into unnecessary detail. This book is some kind of guideline, blueprint. And this is good.
And the most important chapter for me was “Typical mapping mistakes”. It allowed me to find a place, where I do something bad (I was unaware of it).
Apart from book. I asked myself, why we do impact maps? One of the main reasons is to create good channel of communication. To create a big picture view for technical and business people. Second reason is to decide, what should be built to achieve our goal, to reduce waste and over-engineered solutions.
I strongly recommend this book and to try this technique.
Functional Programming in Java
My new year commitment was, that I read one book each month. I don’t predicted an unexpected events that may me slow down :( I do not give up. Next book review will be in 16’th of April.
About the book. I’ve read a beta 6 edition from 13 of January, but I think that final version is very similar to the this beta version. It is not the book about Java 8. It is a book about Lambda Expressions in JDK8. The title says that. In JDK8 there are for example changes in GC. I was missing at least one chapter or few pages about it.
It was book easy to understand. I have Groovy and Scala experience, so there was nothing new to me. All the time I was mapping Java code to Scala code :). It was good for me.
Next good thing is that it reads like a group of blog posts. We have some examples of imperative style, then we move to declarative or functional style. Size of chapters was appropriate for me to read before sleep.
I didn’t like code examples (not in book, but downloadable code). Code examples was without tests and assertions. Just run and print output. I like BDD tests, and it will be great to read examples that are combined with BDD tests.
I would recommend this book to a friend, because it is focused on good developer practices.
My new year commitment is to read a book every month and write a review on this blog
So the first book is Groovy Recipes by Scott Davis. This book was easy to read. I read it fast. Very fast. Mostly because I know more or less about Groovy. There was one maybe two things that was new to me. So I think this book w is not good for developers with some Groovy experience.
Besides that book was very well organized. In each chapter we could find answer to to the problem related to chapter title.
This book need an update. It was written in 2008. A lot changed since then. For example maven building style.
I will definitely recommend this book to my friends who would like to start using Groovy quickly.
My rate is 4 of 5 starts.
