The Art of Agile Development


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


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: 

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

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s