Home :: Agile-Book :: trust

(book cover)

Order it now!

Welcome to the The Art of Agile Development website. Think of this as the "special features" DVD for the book, only without the DVD. (If you haven't bought the book yet, that's okay... we won't tell if you don't.) Here, you'll find a cornucopia of bonus material, such as downloadable posters, behind-the-scenes material, and new insights.

For more bonus material, see the table of contents.

(If there's nothing else on this page, this chapter has yet to be posted. Try the table of contents instead.)

 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

Inside the Book

  • 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


Loading...

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

Loading comments...