Thursday, February 9, 2017

Preventing Measurement Dysfunction in Large Organizations - James Shore

~33 people 20-minutes in.


Dysfunctions - from the audience...
Fatique - cycle time down, fatigue up
Release buggy software
Teams gaming story points, unreliable estimates
Tried to unify the metrics means that things don't translate up (e.g. Story points didn't scale)
Unnecessary competition - e.g. Story points again
Adversarial relationship between QA and Dev - QA rewarded by finding bugs

Next steps 
  • Assume positive intent
    • Well-meaning managers
    • Hiring is good
  • Take forecasting off the table 
Who has influence?
  • Dev 6
  • COE 7
  • Other 3
    • Working on metrics
    • Floating "jack of all trades"
Rob Austin book reference
  • Call center hang up example - only measuring what is easy to measure.
  • Examples from the audience
    • Measuring utilization (Harold)
    • Feature delivery time/quality (Jim T, Lorrie G)
    • Velocity/value
  • Balanced scorecard - measure every single variable
    • Systems that are not supervisable - this won't work (Robert Austin)
Deming quote
Drucker - first role is relationships with people

There are things you can't measure...

Individual write down something that you'd like to manage but isn't totally supervisable
  • Long-term student success
  • Expectations
  • Time to resolution for troubleshooting
  • Code quality
  • Effectiveness of Agile Coach

Transition - measuring things when you can't be present
Tying back to conference theme: the "why" is management, not measurement

Delegative vs. supervisory...
  • Provide businesss context "we're losing market share"
  • Work with the team to contribute/generate ideas 
  • Devs responsible for release schedule and support
  • Make teams responsible for dashboard
  • Collaborating with end users
  • Give them market data (+ help to understand it)

Tied the examples to Agile Fluency Model...

Lorrie G.: A basket of team-level measures...the team conversations were good. 
Jim: Informational vs. motivational.
Code coverage as informational vs. for assessment
Velocity can be this. 

How do you make them informational and prevent it being mis-used? 
  • Not reported, not rewarded.
  • No comparisons between individuals and teams
  • Anonymous self-comparisons. 
  • Provide guidance on what to pay attention to - and say why
  • De-emphasize competition
  • [Watermelon projects: Green on the outside, red on the inside]

What is the role of management? To provide context/framework...


--
Adam Light
+1-503-522-1499
Adam@AgileFluency.org

No comments:

Post a Comment