SUMMARY: 

Top 3 things I learned:

1. Part I, Chapter 1 has a very good discussion about success, which for a book on a methodology is a great place to start.  I like the triad of organization, technical, and personal success and how that compares to the traditional on-time, on-budget, and performance and the jab how that has not bearing on a successful project.
2. I loved all of Chapter 9, but I think what I really loved most was the TDD example.  I learned a lot.  I also really enjoyed the discussion on code smells and refactoring.
3. Part 3 did not have a lot of notable content, but did have the one thing that I will probably always take with me, a definition of Agile: Removing barriers between your team and the project’s success, fluidly adapting your approach as conditions change

Overview:

I only picked this book up because it was on the PMI-ACP reference list.  I went into the book with a lot of bias.  Much has been written on Agile so how would this book add to the conversation.  Also, “art”?  With an engineering background I am often skeptical of the “art” side of things, especially “technical” topics.  Oh and by the way this is an **old** book; things have changed.  Oh well.  WOW was I surprised.  This was a book I both couldn’t put down and a book I didn’t want to end.  Yes certain parts are dated, but the book is still relevant.  I learned more from this book than most other books.  Most books have a couple of good ideas that are presented about mid-way and the rest is just fluff to get to the number of pages the publisher wants.  Not this book.  I finished part 1 and felt I had learned a lot, that the authors had presented their most compelling topics.  Then I realized I was barely into the book, then came part 2.  I loved part 2 more than 1.  Finally I got to the biggest chapter in the book, on development which is at the end of part 2.  Wow.  Awesome stuff–I couldn’t get enough.  Part 3 was, well it was the shortest part and could have been even shorter.  Yes some of the topics are a bit dated and yes the book really only goes into one way to do Agile, XP.  But the attitudes and ideas really give you a flavor of Agile’s roots.  Then I noticed the publisher: O’Reilly.  My favorite technical publisher.  But this book didn’t have the typical line art cover.  What gives?  No wonder this book is so good.  Finally I read information on the covers and saw some pretty strong testimonials about the book from some folks who I respect.  I short–read this book.

---

Part I: Chapters 1-4: Getting Started

Chapter 1: Why Agile?

Paraphrase: What is Agile?

• Simplicity and feedback
• Communication and trust
• Delivering Value
• Courage to do the right thing at the right time

Concept: Practices change, principles remain

Idea: Traditionally projects measured by success if delivered on-time, on-budget, and according to specifications.  However with software that is rarely a definition of success.  Ignores user experience and business value.  Software success: Organizational Success, Technical success, and Personal success

Chapter 2: How to be Agile

Chapter 3: Understanding XP

Recommended Ratios / Size: 

• 2 on-site customers per 3 programmers.
• One tester for every four programmers.
• 4-10 programmers
• 4-6 programmers a good place to start
• 5-20 total team members
• 20 is really advanced

XP Concepts:

• Refactoring: changing structure without
• Technical Debt: the bill for this is higher maintenance costs
• Time-boxing: Specific block of time
• Last Responsible Moment: delay commitment
• Stories: self-contained, individual elements of the project
• Iterations: full cycle of design-code-verify-release
• Velocity: consistent not accurate
• Theory of constraints: usually programmers unless legacy has manual testing
• Mindfulness:  Embrace change

Chapter 4: Adopting XP

Concept: Projects with high technical debt, velocity is a polite fiction

---

Part II: Chapters 5-9: Practicing XP

Chapter 5: Thinking

Concept: 8 collaboration practices

1. Trust
2. Sitting together
3. Real customer involvement
4. A ubiquitous language
5. Stand-up meetings
6. Coding standards
7. Iteration demos
8. Reporting

Quote: “Things may come to those who wait, but only the things left by those who hustle.” — Abraham Lincoln

Idea: As the distance between people grows, the effectiveness of their communication decreases.  The Cocktail Party Effect

Concept: Daily standups

• Just a few sentences on status per person
• 30 seconds per person
• Brevity

Concept: Iteration Demo

• Is our work to date satisfactorily
• May we continue

Chapter 6: Collaborating

Concept: 8 Practices to increase collaboration

1. Trust
2. Sitting together
3. Real customer involvement
4. A ubiquitous language
5. Stand-up meetings
6. Coding standards
7. Iteration demo
8. Reporting

Quote: “Things may come to those who wait, but only the things left by those who hustle” – Abe Lincoln

Idea: As distance between people grows, the effectiveness of their communication decreases – see Cocktail Party Effect

Technique: Daily Stand-up

• Each person needs just a few sentences
• 30 seconds per developer
• 5-10 minutes

Further Reading: 

• Stand-up Meeting Antipatterns
• It’s not just standing up: Patterns for Daily Standup Meetings (martin fowler)

Concept: Iteration Demos

• Is our work to date satisfactory?
• May we continue?

Chapter 7: Releasing

Concept: 6 Release Practices

• Done Done: We’re done when we’re production ready
• No Bugs:
• Version Control
• 10 minutes build
• Continuous Integration
• Collective Code Ownership
• Post-hoc documentation

Idea: XP works best where you make a little progress on every aspect of your work every day

Concept: Done, done is a cornerstone practice of XP.  If you can’t get there in an iteration your stories are too big

Concept: How to write zero bugs

• Write fewer bugs using best coding practices: TDD, Done Done
• Eliminate bug breeding grounds by refactoring: Pay down your debt
• Fix bug quickly to reduce their impact: Longer you wait the more it costs, write an automated test
• Test your process by using exploratory testing
• Fix your process through root cause analysis

Idea: Recommend teams new to XP don’t create a bug database

Chapter 8: Planning

Concept: Practices to control the chaos of possibilities

1. Vision
2. Release Planning
3. The Planning Game
4. Risk Management
5. Iteration Planning
6. Slack
7. Stories
8. Estimating

Idea: Vision

• What should be accomplished
• Why it is valuable
• Projects success criteria

Idea: 2 different types of projects: Scopeboxed or timeboxed — fix both and expect tears

Ideas:  Planning Horizon starting points:

• Define vision
• Define release date for 2 releases
• Define Minimum Marketable Features (MMF) for current release
• Define all stores for the current feature and most of the current release
• Estimate and prioritize current iteration and the following three iterations
• Determine detailed requirements and customer tests

Idea: No aspect of agile development challenges organizational culture more than the transition to adaptive planning

Concept: The planning game

• Customers own value
• Programmers own cost
• Customer owns priorities

Concept: Risk Identification and Management

• What keeps us up at night
• Imagine a year after a disastrous failure and you are being interviewed about what went wrong, what happened
• Imagine your best dreams for the project, now write down the opposite
• How could the project fail without anyone being at fault
• How could the project fail if it was the {stakeholder | customer | tester | programmer | management } fault
• How could the project succeed but leave one specific stakeholder unsatisfied or angry
• Now: brainstorm scenarios that led to the above
• Estimate probability: {low | medium | high }
• Specific impact to a project if it occurs
• Now ask what do I do {avoid | mitigate | contain | ignore}
• Okay now do the following
  • Transition indicators
  • Mitigations
  • Contingency
  • Risk exposure

Reference: Waltzing with Bears: Managing Risk on software projects

Concept: Iteration Schedule

• Demonstrate previous iteration (30 min)
• Retro (1 hour)
• Plan (30 min – 4 hours)
• Commit (5 minutes)
• Develop (all remaining time)
• Prepare release (< 10 min)

Concept: Splitting Stories

• Split around data
• Split around operations
• Split around CRUD
• Take out cross-cutting items and make 2 stories
• Split functional and non-functional
• By priorities

Concept: How to improve velocity

• Pay down technical debt
• Improve customer involvement
• Support energized work
• Offload programmer duties
• Provided needed resources
• Add programmers (carefully)

Chapter 9: Developing

Concept: 9 practices to keep your code clean and allow collaboration

• Incremental requirements – define requirements in parallel with other work
• Customer tests – implement tricky domain concepts correctly
• Test-Driven Development – produce well-designed, well-tested and well-factored code in small, verifiable steps: Key is to work in small increments
• Refactoring – Every day, our code is slightly better than it was the day before
• Simple Design – Our design is easy to modify and maintain
• Incremental Design and Architecture – We deliver stories every week without compromising design quality
• Spike Solutions – Perform small, isolated experiments when we need more information
• Performance Optimization – Optimize when there’s a proven need
• Exploratory Testing – We discover surprises and untested conditions

Concept: Test-Driven Development (TDD)

1. Think
2. Red Bar
3. Green Bar
4. Refactor

Tips: TDD

• Work in small increments
• 3 strikes and you refactor– refactor tests after 3 cycles
• Tests take under 10 seconds to run

Idea: Unit test run fast.  If they don’t run fast, they aren’t unit tests

Idea: Legacy code is code without tests

Concept: Code Smells

• Divergent Change (Unrelated Change affects a class) and Shotgun Surgery (modify multiple classes for a single idea)
• Primitive Obsession (High-level design concepts with primitive types) and Data Clumps (several primitives represent a concept as a group)
• Data Class (only getters and setters) and Wannabee Static Class (no meaningful per-object state)
• Coddling Nulls (Don’t allow null as a parameter, throw an error)
• Time Dependencies (methods called in a specific order) and Half-Baked Objects (first must be constructed)

Idea: Tests should test the behavior and not the implementation

Concept: Simple Design

• YAGNI – You Aint Gonna Need It – avoid speculative coding
• Once and Only Once – Don’t Repeat Yourself
• Self-Documenting Code – Try to to have to comment
• Isolate 3rd Party Components through the Adapter Pattern
• Limit Published Interfaces – Don’t commit to an API until its time
• Fail fast

---

Part III: Chapters 10-15 : Mastering Agility

Chapter 10: Values and Principles

Idea: Definition of Agile: Removing barriers between your team and the project’s success, fluidly adapting your approach as conditions change

Chapter 11: Improve the Process

Idea:  Understand your project, tune and adapt, finally break the rules

Chapter 12: Rely on People

Idea: Build effective relationships, let the right people do the right things, build the process for the people

Chapter 13: Eliminate Waste

Idea:  work in small reversible steps, fail fast, maximize work not done, pursue throughput

Chapter 14: Deliver Value

Idea: Exploit your agility, only releaseable  code has value, deliver business results and deliver frequently

Chapter 15: Seek Technical Excellence

Concept Universal Design Principals

• The source code is the final design
• Don’t repeat yourself
• Be cohesive
• Decouple
• Clarify, Simplify, and Refine
• Fail Fast
• Optimize for Measurements
• Eliminate technical debt