Two best books in 2019

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.

The challenge

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.

Read more

Agile IT Organization Design

General impressions

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.

Agile IT Organization Design

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.

Recommendations

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.

Key takeaways

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:

  1. End-to-end cycle time is more important than team development velocity.
  2. Doing sprints doesn’t make it iterative development.
  3. An engineering team without a clear leader may have trouble settling down on a solution design.
  4. The product is never mature; it is always maturing until it is finally obsolete.
  5. Move from a project centric model of execution to a product-centric model.
  6. Labeling people with job titles like an engineer, a manager, a QA, may have side effects.
  7. Spoken language influences the way we think.
  8. People say tl;dr to anything longer than a tweet.

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.

Review

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.

People

To begin with, you have to change your thinking about other people.

People:

  • are unique,
  • are creative,
  • are able to learn,
  • have different strong points,
  • have different needs,
  • like a challenge,
  • are capable of changing the environment,
  • are capable of making contribution,
  • can be trusted.

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?

Decision Maker

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.

Results of making decision

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.

Advisory process

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:

  • team members,
  • other people with experience,
  • subordinates and superiors,
  • anyone who can help.

But the Decision Maker should take the final call.

Silver bullet

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.

Photo credits:
Banner
Thumbnail

The Dream Team Nightmare

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.

5 days of team live

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:

  • decision making
  • dealing with situations under pressure
  • meeting techniques (e.g. retrospectives)
  • asking correct questions
  • self-organization
  • effective communication
  • good practices (or habits)
  • metering possibilities
  • planning
  • preserving an argument

Most significantly, you can clearly see all these techniques in the same order as in Spock testing framework

  1. Given - full specification of the problem
  2. When - action taken to resolve
  3. Then - result of those actions

Reading this book

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.

Outcome

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:

Me with chapters diagram

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. 

Photo credit

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 :)

Photo credit

Impact Mapping

Making a big impact with software products and projects - Gojko Adzic

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. 

Photo credit

Functional Programming in Java

Harnessing the Power of Java 8 Lambda Expressions

Venkat Subramaniam

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. 

Photo Credit

Groovy Recipes by Scott Davis

Commitment

My new year commitment is to read a book every month and write a review on this blog

Book

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.