Loading...
 
Location : AgileCoachCamp Wiki > Coaching Feedback Coaching Feedback

Coaching Feedback

Alternate title: Test Driven Agile Coaching
Moderator: Roger Brown
Participants: Jeff Grigg, Don Gray, Ken Ritchie, Alexey Krivitsky, Tom? two others? (please fill in)

When I teach TDD, I start the class by asking "When do you know you are done with something? How do you know what you did is good?" For example, when I mow the lawn, I know when I am done and I can tell if it looks good. Agile practitioners have the benefit of unit tests, acceptance tests and many types of feedback to tell them how the project is going.

So what about the agile coach? How do we know that we did are doing a good job? How do we know when we are done? How can we continuously improve our skills and service? What kind of tests can we establish for ourselves? What kind of feedback can we get? How much of this can we set up ahead of time, or early in an engagement.

I took some inspiration from Joshua Kerievsky's paper on Test-Driven Management.

We generated a surprisingly satisfying set of ideas. Here they are, neatly organized into three categories: forms of feedback, acceptance tests and definitions of "done".

Forms of Feedback
  • Make repeat visits (ex. 3 days each month)
  • Structure feedback into business relationships
  • Ping client afterwards
  • Get repeat business
  • Pairing/another coach observing
  • (internal) coach evaluations
  • Retrospectives with the team and/or sponsor
  • Evaluation forms? (thought to be low value)
  • Ask follow up questions, a day or two after a class/engagement
    • What value did you get?
    • What could we have done better?
  • Did something change?
    • Within 1 week?
    • 1 month?
  • Structure engagement for quality vs. quantity (set yourself up for success)
  • Offer free follow-ups
  • Ask someone on team for a before/after comparison

Tests (goals, success criteria)
  • Can we define up-front tests?
  • often don’t know what they are until you get there (situational)
  • Set goals in terms of trends (ex. # unit tests)
    • You can get data sooner than setting distinct targets
    • You can adjust towards success
  • Recurring pain (why does it recur? Why has the root problem not been solved?)
  • Some things are long term/big (ex. Agile adoption)
  • Keep records of achievment (As-built design doc, project charter, issue tickets, wiki, blog)
  • Can we write these into a consulting contract?
    • Get a bonus for achieving those over and above the basic contract
  • Goals evolve

When are we done (exit criteria, some happy and some not)
  • ask the the team if you are done
  • when you cost exceeds your value
  • when they don’t want what you offer (any more)
  • when they stop paying for it
  • when the team can do it alone
  • when the organization can do it alone
  • “pay it forward” model (when they can do what you can do)
  • When I stop growing
  • When project is over (full engagement)
  • Coach gets no credit, so what is his/her value?
    • See later session on agile coach ROI
Created by rwbrown. Last Modification: Tuesday, 03 of June, 2008 21:41:25 CEST by rwbrown.