Velocity is one of the most commonly used - and abused - development metrics. Teams (and their stakeholders) often focus on “improving velocity” without either a proper consideration for root causes that impact velocity or a holistic view of a team’s outcomes. And that damn velocity metrics hammer can kill the culture of collaboration and experimentation that we all love.

Join Andy Cleff in a lively discussion that explores how we can remove perverse incentives from our environment and instead provide healthier ways for teams to gain meaningful insights into the outcomes of their experiments.

When you return to your team after the conference, you'll be able to put theory into practice to explore metrics meaningful to your ecosystem and culture of continuous improvement.

 
1 favorite thumb_down thumb_up 3 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/Structure of the Tutorial

TWELVE RULES FOR MEASUREMENT FROM M3.0

  • Measure for a purpose
  • Shrink the unknown
  • Seek to improve
  • Delight all stakeholders
  • Distrust all numbers
  • Set imprecise targets
  • Own your metrics
  • Don’t connect metrics to rewards
  • Promote values and transparency
  • Visualize and humanize
  • Measure early and often
  • Try something else

FRAMEWORK OF METRICS

  • Process Health Metrics - assess day-to-day delivery team activities and evaluates process changes.
  • Release Metrics - focus on identifying impediments to continuous delivery.
  • Product Development Metrics - help measure alignment of product features to user needs.
  • Technical / Code Metrics - help determine quality of implementation and architecture.
  • People / Team - reveal issues that impact a team’s sustainable pace and level of engagement.

GUIDELINES FOR HOW TO CHOOSE

  • Why “this metric?” – Why does it matter? Who does it matter to?
  • What insights might we gain from it?
  • What is expected to change? Are we looking for variability, consistency, trends or absolute values?
  • How might it be gamed, misused (or abused)?
  • What are some trade offs / costs of improvement?
  • How often would we like to “take a data point”?
  • How long will we run the experiment?
  • How when we know when we’re “done” with this metric?
  • How will we make our measurements transparent?
  • Is this metric a leading or lagging indicator?

WRAP UP

  • Q & A
  • Close

Learning Outcome

  • Walk away with a framework of key principles and measurement options that you can employ to build and refine team dashboards with useful metrics.
  • From those dashboards, you will be able to support a culture of transparency and collaboration, filled with feedback loops on your teams’ experiments impacting:
    • Process Health: by assessing day-to-day delivery team activities and process changes
    • Releases: by identifying impediments to continuous delivery
    • Product Development: by measuring the alignment of product features to user needs
    • Technical / Code: by determining the quality of implementation and architecture
    • People / Team: by revealing issues that impact a team’s sustainable pace and level of engagement
  • Those insights will then help not only maintain a culture rich in kaizen, it will also inform next steps for business strategy, organizational transformation as well as the next generation of instrumentation (ohhh a reinforcing loop!)

Target Audience

Team Leaders, Managers, Coaches, Scrum Master

Prerequisites for Attendees

  • You have a getting familiar with measuring things.
  • Maybe you've put a few metrics in place beyond velocity, or are ready to do so.
  • You aren't quite getting as many insights as you want from your continuous improvement practice.
schedule Submitted 9 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • George Dinwiddie
    By George Dinwiddie  ~  9 months ago
    reply Reply

    Looks like a lot of slides for 45 minutes.

    • Andy Cleff
      By Andy Cleff  ~  8 months ago
      reply Reply

      Indeed.

      The slides attached are from a 75 min version, with hands on workshop activities.

      I'd trim things down to fit a 45 min timebox for Agile DC.

      Would you like the abridged version for this submittal?

      • George Dinwiddie
        By George Dinwiddie  ~  8 months ago
        reply Reply

        No, I'm just glad to hear you'll trim it down. :-) Thanks!