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.

Comments