Re: AONW Day 2

First attempt rejected due to attachment size. See session notes below.

 

 

Eric Herr

Release Train Engineer | Membership

Nike Digital Engineering

503-310-1718

 

 

From: "Herr, Eric" <Eric.Herr@nike.com>
Date: Tuesday, February 6, 2018 at 12:51 PM
To: "sessions@agileopennorthwest.org" <sessions@agileopennorthwest.org>
Subject: AONW Day 2

 

Here are images and notes from the session I let today at AONW.

 

Title: Teaching Teams to say "NO"

 

Benefits:

• Reduce context shifting.
• Prioritize workload.
• Reduce stress/increase job satisfaction.
• The team knows how to do their work.
• Building trust and predictability.

 

Challenges/Obstacles:

• Developers that don't want to say "No". They want to be the super hero that saves the day. Diving catch mentality.
• There is not a safe space created for them to say "No".
• The request is coming from a company leader. "You don't say no to fill in the blank."
• Senior or Lead Developers take the work. Easier to do the work than to say "No".
• Deadlines.
• Team feels they can't defend "No".

 

Methods to Empower Team:

• Emphasize the "we" component of the team. Teams have verbal and/or written "contracts" at the beginning of every sprint to complete the work they agreed upon. When one dev or the PO accepts a story or issue mid-sprint they are breaking the contract with the team.
• Teach EVERYONE on the team to ask "Why?" Why are we building this? What is that stakeholder looking to accomplish with this request?
  • Request may end up NOT being critical and can delay until a future sprint
  • Dev team may know of another way the request can be met that no one else knew about?
  • Forces the next questions…What in our current sprint will not get completed if we do this work?
• Train the PO's in better behavior around dealing with requests.
• Use historical data to show the team that they have consistently not been making their start of sprint commitments. This is only NEWS. Not good or bad. What needs to change?
  • Over committing
  • Constant production support interruptions
  • Constant feature switching by leadership
• Saying "No" is ultimately the responsibility for the PO to address with Program leadership but the team needs to be empowered to say "No" to the PO and have a PO with enough trust in the team to socialize that message.

 

Thank you,

 

Eric Herr

Release Train Engineer | Membership

Nike Digital Engineering

503-310-1718