Loading...
 
Location : AgileCoachCamp Wiki > SuccessAndFailureAsACoach SuccessAndFailureAsACoach

SuccessAndFailureAsACoach

Success and Failure as an Agile Coach


Facilitator: Dan Puckett
Saturday, 9:30am

Summary


If you want to succeed as an Agile coach, some of the most important things you can do are:
  1. Allow the team to fail in situations where failure is non-catastrophic and educational.
  2. Work to neutralize performance and compensation issues that undermine teams.
  3. Have team training or workshop before starting.
  4. Slow down to engage resisters. Wait for their buy-in, and keep working on it.

If you want to fail as an Agile coach, doing the following things may help you attain your dubious goal:
  1. Past the novice stage, allow the team to remain dependent on you telling them what to do.
  2. During the novice stage, confuse the team by giving them advice that conflicts with the advice of other Agile coaches who are helping them.

Session goal


To find a few things that we Agile coaches can do or not do to improve our practice.

What we did


For the purposes of this session...

  • "Success" was defined as lasting, positive change in the organization.
  • "Failure" was defined as a lack of success.

Everyone worked individually on Post-It notes. Participants were asked to think about what they did or failed to do in their coaching that contributed to success or failure, as defined above. Lasting, positive change can be at many levels (team, personal, and so on)--actions affecting all levels were to be considered.

As notes were created, people stuck them to one of two sheets on the wall: "Success" and "Failure". Once the flow of Post-Its subsided somewhat, the notes on the wall were read out loud to stimulate more thinking. A few additional notes came in.

The group used dot voting to determine the most important actions. The actions deemed most important were then discussed in more detail until our time expired.

Practices contributing to coaching success, most important first:

  • 5 — Let team fail on their own.
  • 4 — Neutralizing performance & compensation issues that undermine teams
  • 3 — Team training/workshop before starting
  • 3 — Slowing down to engage RESISTERS
    • Wait for buy-in
    • Keep working on it
  • 2 — Focus on people & team dynamics
  • 2 — Called chickens out during meetings to teach team to do the same
  • 1 — Accomplished: Brought ahead of budget, behind schedule project into an under budget, ahead of schedule project. How: Started daily scrum & extended code planning sessions daily.
  • 1 — Established a transition team w/representation from most stakeholders to address impediments
  • 1 — Encouraged team to make all decisions
  • 1 — Outside training reinforced message
  • 1 — Improved team morale in broken environment
  • 1 — Hosting Open Space for entire org. to gauge adoption, re-invigorate and cross-learn
  • 1 — Built solid relationship with Dev Mgr to make comfortable in Chicken role
  • 1 — Instituted Value Points for stories to highlight and drive value delivery
  • 1 — Delivered solution to meet customers' key requirements
  • 1 — Support Product Owner to define & share "big view"
  • 0 — Used Agile evaluation framework (Shodan / XPef) for retrospectives
  • 0 — Gave a beacon of hope in a dark ocean
  • 0 — Created internal resources for sharing info (wiki, "Agile weekly" mail list)
  • 0 — Coaching up and down.
  • 0 — Focus on biz value and success outside core team.
  • 0 — Did value chain Map which resulted in org resolving a critical bottleneck
  • 0 — Introduced 50 person distributed team to agile practices

Practices contributing to coaching failure, most important first:

  • 9 — Telling versus mentoring versus coaching (tendency to tell!)
  • 3 — Incoherent message from different coaches.
  • 3 — Did not push for real user stories
  • 3 — Lack of trust between teams
  • 2 — Failed to transfer agile knowledge to Quality Team
  • 2 — No exec buy-in.
  • 2 — Business not engaged--no Product Owner training or engagement plan.
  • 2 — Failed to realize client's constraints essentially political
  • 1 — Failed to identify and work on/with RESISTANCE
  • 1 — Did not have technical solutions for TDD on legacy code
  • 1 — Kicked up too hard
  • 1 — Give in to temptations when "they" dictate "this is how you should do it"
  • 0 — Not enough time & energy to shift organization/group.
  • 0 — Lack of cohesion on agile rollout team.
  • 0 — "Leaned in" too far.
  • 0 — Mass CMS training, letting dev managers appoint those for training.
  • 0 — Not having the ability to "remove" people who aren't "working out".
  • 0 — How Scrum teammates communicate when other teammates are out due to scheduling issues. I deal with interns a lot.
  • 0 — Didn't plan for what would happen when I stopped coaching the team.
  • 0 — Gave up on management.
  • 0 — Neglected team due to lower priority activity.

Created by MichaelSahota. Last Modification: Sunday, 21 of March, 2010 02:44:54 CET by puckett.