I knew about this book from a colleague's recommendation. I read it through very fast though it has a massive content of almost 800 pages. It's hard to see the book's genre just by reading its title. Usually it can be found in a philosophy shelf.

Gödel's incompleteness theorem, Escher's paintings and fugues of J.S. Bach are its main items. Based on these items from very different areas of math, fine art and music, it tells about what 'intelligence' is very intelligently. Between each chapter, it places a fable which previews the theme of the next chapter... The harmony of its form and meaning is so exquisite that one can easily miss inner meanings and puns in them unless read it mindfully.

I have read a saying that 'Alice in Wonderland' is one of the must-read for programmers before. After reading this book, I can understand that saying now.

It hasn't been easy to apply the agile methodology. Every participant should understand its purpose and be enthusiastic about it. Each practice should be performed consistently until it becomes a habit. In the meantime I discovered this book.

Basically it's about XP with some Scrum stuff. There were still many things for me to learn. Followings are the most touching items within my context.

• Ubiquitous Language
  
• It's far from easy that people from different disciplines communicate. A game designer, a programmer and an artist each can have her own understanding of a single word. It can be helpful to have a page of common vocabularies in a team wiki. The most important is the frequent communication with each other.
  
• Done Done
  
• This practice is one of the most hard things for me to follow rigorously. It's really done when the end-user(this can be a game designer in the game dev) has reviewed it. Just being successfully compiled or being code-reviewed cannot be "done done"!
  
• Vision
• This is essencial for a project to get to a goal though various hindrances. But it's not easy to share this.
  
• Risk Management
  
• A schedule estimation would be not-too-hard only if you had redone the same project you've done previously. Important is the 'planning', not a 'plan', but sometimes even planning can be difficult. This item shows how to measure various risk factors which makes the estimation difficult.
  
• Slack
  
• All developments have minimum overheads like abrupt meetings, hardware failures, etc. It's easy to be ignorant of this, but you cannot ignore its result, a missed milestone.

I will have to be more mindful ever.