Is velocity a good proxy for productivity?
Welcome to part 4 in our scrum master interview questions series where John McFadyen answers common questions asked of scrum masters and agile coaches in interviews and client engagements.
Let’s stop for a moment and explore what is meant by the term velocity.
Velocity
Think back to your science classes in school and you should remember that velocity = speed and direction.
That’s what velocity means.
It is your speed, in a particular direction.
A lot of people think that velocity means speed, and miss the point of direction of travel, but in the Agile world we aren’t purely concerned with speed, we care a great deal about the direction of travel too.
The agile world picked the term velocity because we are interested in the speed of delivery in the context of a specific product, vision, or purpose.
If we deliver things that have no value to customers or don’t move the needle on metrics that matter to the organization, there is no value in the work produced.
Value
So, yes, velocity can be a fair measure of ‘productivity’ if we are focused on the speed of delivery relative to the degree of value that is being created for customers and the organization.
In the agile world, we measure work by the perceived effort rather than the perceived value.
Why is that?
Because value is incredibly hard to measure and is equally hard to define and articulate upfront.
Sometimes, a little bit of effort can produce huge amounts of value, whilst at other times, a huge effort produces little to no value whatsoever.
If the product has never been built before or the problem has never been solved before, we don’t know how much of an impact it is going to have nor can we estimate the value it will create for customers.
We are, however, pretty good at rough estimation and estimating effort empowers us to move forward with a rough idea of how long this should take us, and based on past efforts, estimate how much work we can produce in the short-term future.
Productivity
This is an interesting one.
In the traditional management and project management space, productivity is incredibly important.
A team of people have estimated how long something will take, how much that will cost, and the focus lies on delivering against the plan as efficiently as possible.
In Agile, and the world of product development, efficiency is important, but our focus lies on delivering the most valuable work rather than ticking off a checklist.
We might find that 80% of the value is delivered to customers within 20% of the work produced, and the customer may decide that they want to focus efforts on a new requirement or solving a problem that has cropped up.
In agile, we embrace this change, and pivot to where the most valuable work needs to be done rather than following a rigid plan because that is what we all agreed to month, even years, ago.
Productivity is simply our ability to deliver an outcome.
We don’t know if that outcome creates value for anyone nor do we know if it helps us move closer to achieving our goals. It is simply a task that is completed, as efficiently as possible, with the sole purpose of checking that item off the task list.
So, in the context of an agile environment, it is odd that the focus would be on productivity rather than effectiveness. You may find that the interviewer doesn’t have much experience with Agile or they come from a project management background, and as such, are concerned with productivity.
That said, it is very seldom that you will work in an agile that is purely agile from the top down.
Often, there will be pockets of agility surrounded by traditional management and project management environments, so you will be working with people and managers who think in terms of efficiency and productivity rather than effectiveness.
So, it’s a good idea to think about how you will inform, educate, and empower others to understand the difference between productivity and effectiveness. The difference between product development that delights customers and project management that delights managers.
Summary of Velocity as a proxy for Productivity
Yes, velocity is a good proxy for productivity, but it isn’t a great metric if you are focused on creating a strong, hyper-collaborative and effective team. Velocity is often abused by managers seeking to place pressure on scrum teams and in the wrong hands, does more damage than good.
Use velocity as a metric that you keep an eye on but consider other metrics in conjunction with velocity to help you keep a firm finger on the pulse of the team.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster