Velocity at scale - principles to live by

schedule Nov 28th 03:55 - 04:25 PM place Grand Ball Room 1

Like most of you, I've been a student and practitioner of improving the velocity of product / service teams for my 20 years in the industry. We'd all agree velocity is important, but there are many ways to define and improve it. Is it story points? Is it successful feedback or metrics? Is it the popular developer vote? How does it scale to a cross functional team and a growing organisation?

This session will be practical. I'll share anecdotes, principles and practices on team velocity that I've picked up over years of hard lessons and different contexts. We will look at velocity from the angles of technology, process and culture. We will consider how velocity changes in environments of significant architectural change, organisational change and team growth. Ultimately we'll define a balanced view of velocity as it relates to customer value and summarise principles for effective and sustainable improvement.

 
 

Outline/Structure of the Talk

  1. What is Velocity to you?
  2. Velocity from a process perspective:
    1. Velocity is predictability (i.e. a lack of velocity is missing dates).
      1. Anecdotes from my time as a delivery leader on several enterprise projects.
      2. Focus on predictability - reliable estimation, remediation tactics, scope management and expectation management.
    2. Velocity is lean (i.e. reducing wasted time and errors).
      1. Anecdotes of my time studying lean and improving a bank's process.
      2. Anecdotes of improving Cloud release frequency from every two weeks to multiple times a day.
  3. Velocity from a technology perspective:
    1. Reuse and the platform vs fork spectrum (with Netflix and Atlassian fork example).
    2. Tech debt and the rewrite vs incremental change spectrum.
    3. Balancing measures and developer sentiment.
    4. Can you measure dev speed?
  4. Velocity from a culture perspective:
    1. What is "execution with urgency" to you?
    2. Empowering autonomy with guard rails on outcomes and priorities.
    3. What part does stretch play in improving velocity?
      1. Anecdotes: OKRs and milestones.
    4. How does a sense of belonging and motivation impact velocity?
      1. Anecdotes of a team change announcement and impact on velocity.
  5. Velocity from a customer value perspective:
    1. Fundamentally velocity is sustainable time to value, all other perspectives of velocity lead to this.
    2. Projects can ship on time but the customer needs to be happy (example of customer beta program).
    3. At scale qualitative feedback is important, but data becomes even more so. It avoids significant waste.
    4. How measurement driven development is increasing velocity at scale (example of growth platform).
    5. Sustainability - that's where tech debt management comes in. How can you connect this to customer value (Confluence example).
  6. Principles to take away:
    1. Think about velocity from multiple angles and the tactics that apply to your context.
    2. Velocity improvement is often costly and often fails. Fall in love with the problem not the solution.
    3. Velocity is ultimately time to customer value. Increment size and validation is critical.
    4. Velocity must be sustainable to be real, this is where as engineering leaders we can align technology with customer value.

Learning Outcome

  • Different perspectives on velocity in different software scenarios and at different levels of scale.
  • Principles for more effectively improving team velocity.
  • Pitfalls to avoid when attempting velocity improvement.

Target Audience

Technology and delivery leaders

schedule Submitted 1 year ago

Public Feedback

comment Suggest improvements to the Speaker