Home → Agile-Book → trust

(book cover)

Buy it now!

Welcome to the The Art of Agile Development website. Here, you'll find a cornucopia of bonus material, such as downloadable posters, behind-the-scenes material, and new insights.

Starting in 2010, you'll also find the full text of the book, conveniently cross-referenced and hyperlinked. A new section will be released every Friday, starting with the practices in Part II.

For more, see the table of contents.

 Print

The Art of Agile Development: Trust

by James Shore

09 Apr, 2008

in 99 words

For maximum productivity, team members must rely on each other for help. They must take joint responsibility for their work. Trust is essential. To improve trust, foster empathy. Learn about your teammates' joys and concerns. Sitting together helps, as does eating together. Preserve productive teams by keeping them together for multiple projects.

Organizational trust is also essential. Be energetic, deliver on your commitments, and be honest about problems. Show that you care about your stakeholders' goals. Promote your work through friendly openness. Always be honest about your achievements. Avoid the temptation to whitewash problems or misrepresent partially-done work.

as haiku

Tadpole gazes up:
"Will the sun ever return?"
"Ribbit," replies Frog.

Exercise

An Exercise About Trust

Section Outline

  • Trust
  • Team Strategy #1: Customer-Programmer Empathy
  • Team Strategy #2: Programmer-Tester Empathy
  • Team Strategy #3: Eat Together
  • Team Strategy #4: Team Continuity
  • Impressions
  • Organizational Strategy #1: Show Some Hustle
  • Organizational Strategy #2: Deliver on Commitments
  • Organizational Strategy #3: Manage Problems
  • Organizational Strategy #4: Respect Customer Goals
  • Organizational Strategy #5: Promote the Team
  • Organizational Strategy #6: Be Honest
  • Sidebar: The Challenge of Truth Telling
  • Questions
    • Our team seems to be stuck in the "Storming" stage of team development. How can we advance?
    • Isn't it more important that we be good rather than look good?
    • I thought overtime didn't solve schedule problems. Why did you recommend overtime?
    • Why bring big problems to stakeholders' attention before smaller, already-solved problems? That seems backward.
    • You said programmers should keep jokes about the schedule to themselves. Isn't this just the same as telling programmers to shut up and meet the schedule, no matter how ridiculous?
    • What if we've committed to finishing a story and then discover that we can't possibly finish it this iteration?
  • Results
  • Contraindications
  • Alternatives
  • Further Reading

Full Text

This section will go online later this year. In the meantime, why not buy the book?


Loading...

Home → Agile-Book | Comments (...)

Loading comments...