Velocity is great but meaningless on its own

I just wrote a couple of entries on “velocity” and now I want to look at some of the implications of using it.

Here I will be looking at how we interpret velocity and how we can use it. In particular I will be looking at how it relates to concepts such as “done”, “regression testing” and “showcases.”

The story to date

If you have not read those articles then you should still be able to make sense of this entry, but you need to know I am using velocity as a planning tool in a classroom rather than the traditional 2 week IT sprint.

In order to track my progress, I have been using coffee points rather than hours or story points.  One coffee point is the amount of learning material I think I could get through over one cup of coffee.  I am assuming it will therefore be about 15-20 minutes of activity in the classroom.

If this does not make sense then skim the previous articles to get a feel for what velocity is.

To start with – velocity is great, but it is not velocity

Velocity is a common measure in both agile projects and physics.  But physicists know that velocity is different to speed.

“Don’t mistake activity for progress” – my grandma

Speed is a measure of how fast you are going, but it does tell you which direction you are going in.

Clearly if you are heading in the wrong direction or constantly changing direction then you are not heading towards the destination you hope to reach.

In physics, velocity is a measure of speed AND direction. So you might be heading due north at 20 kilometres per hour and getting closer to your destination than someone who is going 80 kilometres an hour due South.

In agile projects, a velocity chart shows speed without direction.

But there is another important issue.  In physics, people might debate whether we should measure velocity in metres per second, kilometres per hour or miles per hour, but they always know they can convert miles to kilometers by multiplying by a constant figure (1.6).

(Hmmm – is there a standard for metre or for meter?)

So when we measure velocity in physics we would state the measure we are using for speed and everyone will have the same understanding of our progress.

But in both the IT and process related projects I have run, I can say I have “finished 12 stories” or that “the current state analysis is complete” but this might mean different things to different people.

The rest of this entry just looks at these basic ideas by applying them to my classroom example.

Back in the classroom

Back in my classroom I am half way through day two of my three day training course.

We have been working for 3 hours and we are having a great time.  Now, as we approach lunch-time, people are starting to switch off as they think about the catering.

But I am not thinking about the food because I am a little nervous.  I had predicted that we would move at a comfortable 4 coffee points per hour but with the ongoing discussions and questions we are barely getting through 3.

Some simple maths shows me that I will not get through all the topics I want to cover (in fact I will only cover 75% or 3 quarters).  So I run a retrospective, hoping that people are so focussed on getting to lunch that they will just agree to anything I say.

Sadly they understand agile and take the opportunity to both discuss our progress and also the topics that are starting to interest them.  They come up with some more topics that they would love to cover today, or if necessary tomorrow.

I had already committed to 32 coffee points of awesome learning for the day but if I include their new requests that will mean “scope creep” or “evolving needs” depending on our attitude to change.

We compare their new ideas to my existing topics and agree I can do some adjustments to keep them happy.  They want to talk “MVP” and I can cover this in “Story Maps” without really adding to the time we take to get through the topic.

But some of their topics are going to blow my timeline quite badly. We roughly compare the size of the new topics to similar things we covered so far.  This suggests we would have 4 more points to cover.  At that rate we would finish the day pretty late.

I tell the team I already have an agenda but one of them asks me if I am going to “welcome changing requirements even late in the piece.”  I guess the question should be more about what value we can get from the afternoon rather than just whether we complete the agenda I wanted to cover before the students had any input to their learning.

So I tell the students they can head off to lunch and that when they get back we will have a quick collaborative planning session and confirm the afternoon agenda. Someone asks if that will put us further behind and I say that part of the agile mindset is a Zen like ability to make quick collaborative decisions so we will be fine.  Secretly I am not sure we will be Zen like or quick.

While they are gone I check my emails to postpone any decision and then eventually review my options before going to get some food myself.

Option 1 – We could finish late

“Running late is bad manners” – My grandma

A lot of projects out there in the real world simply run late to get through their changing scope.  I guess their customers and business partners are always happy to wait.

But my team of students is not likely to stay much beyond 5pm.  I could possibly push them to stay until 5:30pm or 6pm but going until 8pm is not an option.

In fact many already have plans based on leaving the course at 5pm and it would cause a lot of disruption if we start shifting our finish time on them.

They agreed to start the day at 9 and finish at 5 and this is the expectation they always have in training. In fact I would allege that most customers want you to keep to the committed delivery date, because otherwise there is a lot more happening outside your project.  Delivering a project two weeks late is annoying for the team, but the replanning among back-office teams, trainers, sales people and end customers can cause substantial turmoil.  So sticking to a committed date is far less complex and costly than running late each time things get hard.

Also – if you project is adding value then delaying the delivery of the value you have already created is wasteful.

Option 2 – We will cover the extra topics tomorrow

“If you don’t have time today, what makes you think you will have time tomorrow?” – My grandma

In Australia there we sometimes use the phrase “Release 2.” It is similar to the phrase “Manana Manana”, and means “one day soon but not today.”  Strangely people still believe you are going to deliver something when you say release two, but it often transpires that tomorrow was as hard as today and we don’t get around to things then either.

In fact, usually when we say “release 2” we usually mean “after the budget has run out you can get some more money for that if you want to.” In other words – “No – that is another project”.

In training we have a similar term too – “the parking lot.”  We put things in the parking lot so people feel good and they can stop worrying about things.  People raise a topic or subject we won’t be covering and we write it down so that we know we “have it covered”. Then at the end of the training course we review the contents of the parking lot and confirm we will not cover them.

This is not quite the same as “welcoming changing requirements” or “adapting to change.”

So if I simply say we will cover all the topics we don’t get to at the end of our 3 day course is not going to cut it.

Maybe I can simply stop at 5pm and then start again tomorrow at 9am, keeping all the items in scope and seeing how we go.

Well I know how we will go – a lot of the topics scheduled for tomorrow afternoon will drop out of the course.  This is a good option if I have structured my course so that the least important things are at the end.  In fact that would be great because if people have a long lunch tomorrow or leave early tomorrow then they will miss the most boring things.

In many real projects this is a good and valid option. Cover the most important things early and then get to the rest if things go according to plan.  Assuming of course you are doing the most important things early and have the discipline to do the right amount of each before moving on.

But in this case there is an issue – my 3 days cover different material that is important for different reasons.  In fact each half day is a different “learning objective” that is constructed as a cohesive set of activities and concepts to achieve a goal.

If I shift things to day three, I need to confirm with the class that we will actually change our goals (learning objectives) for day three and therefore for the course.

Option 2a – We can re-plan using goals and not stories

“It doesn’t matter what you do, it matters what you achieve” – someone other than my grandma

In agile it is easy to plan in stories, which is one of the things I love about them.  But that does not mean all our planning is at the story level.

In the same way it is easy to plan and explain a training agenda in terms of topics or activities. But in fact we should be planning based on the learning objectives we set and how we assess that we have achieved them.  This is harder to explain to a class at the beginning of a course but if you share the learning goals and objectives as a class you are planning what the team want to learn rather than what they will do.

In the agile projects I run, we always have a project charter and in the courses I run there is always a course charter.  We also set a “sprint goal” each sprint, or plan to achieve epics, sagas and heroes journeys (I mean customer journeys) rather than individual stories or partial journeys.

Similarly, each training day has a lesson plan or set of outcomes for the group.  These sometimes help us to prioritise work.  Sometimes they even help us clarify that we set the wrong goals.

So rather than asking the class which cards they want to complete in the afternoon, a better approach will be to slow down and confirm the goals we want to achieve and then the stories that will best achieve our confirmed or refined goals.

If I reprioritise the goals for today and tomorrow then this will help us assess where to spend our energy.

Velocity can help goal level planning be showing trends in the work (we get through 3 points not 4) and relative effort of different things (stories, experiments) that help us achieve our goal. It helps us allocate our effort effectively but is not a goal in itself.

In fact in some agile teams the goal seems to be to maximise velocity and the team have become a bunch of tools that are used to make the graph look nice.  But velocity is not a goal, it is a tool to help us understand where we can spend our energy from here, in order to achieve our goals.

This is even in the famous agile manifesto – processes and tools (including velocity) support the people and their interactions.  People are not meant to become tools who are trying to make the process work or stick to a plan that is not supporting them.  Although perhaps I am misquoting the intent there, I will you to interpret the manifesto J

Option 3 – We can work through lunch and skip the coffee breaks

“Energy is a resource and needs to be managed effectively” – Actually I don’t know if anyone said that

A common approach on projects is to get the team to work weekends.  This is great if the weekends were boring anyway but causes some suffering if people wanted to do something other than work.

But in my training course it is not just about having a nice lunch when they have a break.  When we train people they need to have breaks on a regular basis to absorb what they are learning and reboot their brain to learn more.

Some people go as far as running intense training in “Pomodoro” units and weaving different topics together to help people context switch more easily or make connections they would not otherwise make.

So the class might be willing to go from 9am to 5pm without a single break but the learning will be practically zero in most cases. Even what they learned at 9am will be lost.

I could have cut the lunch from 1 hour to half an hour if they group were happy to do so, or I could have split the lunch so students interested in different topics could stay for mini-remedial classes.  But I didn’t do this here.

Rather than less breaks, I might even give the team an additional break or a chance to wind down between topics at some points where needed between breaks.  In fact, when our velocity is dropping during the day, it might be actually be time to take a break to refresh ourselves, rather than try to smash through more points to catch up.

This is the same for agile teams too, I guess.  Sometimes I am an advocate of long hours because it will put us in a better position and be better for the team and client in the long run. But just adding hours to each day usually slows down the work or sucks quality and goodness from the product.  You can often tell when you use a product delivered by a tired team.

Velocity can be a great tool here to help us notice and manage our sustainable learning pace.  Again it can help us make choices (maybe come back from lunch early, maybe drop a topic, maybe skim these two and see where we are at before replanning).  But again the goal is not to maximise our learning velocity in coffee points per hour, it is to maximise our learning in the time we are together.

Option 4 – Why can’t we go faster?

 

“I really need the team to move to warp speed around now” – my old product owner

All our problems are fixed is we can learn faster.  Then we can get through the topics quickly and achieve our goals.

In order to speed up, we could stop the interaction and the questions.  I can just smash through slides and we will get through all our cards by 5pm, while still having time for muffins at afternoon tea time.

You can see where I am going with this though.   Speeding through coffee points per hour is not the same as speeding through the actual learning.

But there is no doubt waste in our course so far.  I am telling long stories that I think will get a laugh for example.  This helps engage the class and also helps give them a break from the hard learning.  But if we do retrospectives the class might share that they are not laughing and the long stories about my pet beagle are not really helping.

Or we might observe that certain people dominate the conversation and ask all the questions.

I guess the point is this – If we stop and check in during the day, we can improve both the speed and the quality of learning across the crew.

Even over 3 days, I have noticed that slowing down to both check understanding and discuss the style of our delivery will make for a substantially better class.  This is a short period of time to form a team and really get our rhythm, so for the average project we should see even greater benefits over time.

So when we measure velocity and look at it in the retrospective, it can help refresh our memories.  We might remember that we found the morning hard, or that it flew through. But if we can see where we went fast or slow AND compare this to what we covered then this helps us really dig into what is working for the class and what is not.

In training we have “low stakes assessments” which means the class assess their progress but there is no impact on any formal assessment.  It is important to include these during the learning.

An agile teams has showcases and retrospectives where they stop to assess their progress before planning the next step (sprint) or their work.

This is what velocity is designed for. The real measure of progress in agile is the retrospective and the showcase. The velocity chart is actually a tool or input into the discussion, not a standalone measure on its own.

It is nice to know we are covering topics quickly and depressing to know we are going slowly. But going fast without learning or delivering value is pointless.

Our goal is actually to go as fast as you can by

• Removing impediments and understanding constraints (covered in the retrospective); and
• Understanding the value of what is being done (the showcase or ideally customer analytic and feedback).

Here velocity is a useful tool to help guide our conversations.

It is hard to argue a team should go slower than their sustainable pace. In fact I get feedback sometimes that we are moving too slowing through topics.

It is also hard to argue that the team should rush about faster than their ability to actually produce valuable outcomes. And in my class I sometimes get feedback that people feel rushed and are not keeping up.

The challenge is to measure and learn what the right pace is to get the best outcome and this is what velocity is for.

Option 5 – stop doing all the assessments and just cover the material

“You are not done if you are not finished” – My grandma again

When under pressure I sometimes see teams cut back on testing. This is a natural solution to maintaining “Velocity” if you are only measuring speed.

But to know if you are really moving at 3 coffee points per hour, or 10 kilometers per hour, you need to understand what you are measuring.

There is an international standard for “kilometer” and for “hour”.  There is also a measure for “mile”. But how do I know we have completed a coffee point of learning?  Merely reading the slides is not sufficient.

Sometimes one of the participants will suggest that we drop some of the interaction or games I include in the class in order to cover more material.

Sometimes I am happy to do so. But sometimes I will fight hard against this because the game or activity is actually confirming the things we learned, connecting things together or even challenging what students think they know.  So assessing learning is actually part of the learning. It both closes and changes the learning we have done.

In a lot of my courses the assessment is light and breezy, but it is still there.  In other courses we need to actually work out a detailed assessment to ensure when people leave the room they really are capable of performing an activity.

Similarly in agile teams, the team define “done”.  This means we have finished a story when “we are done”.  This often feels painful and pedantic to me but is very important.

When we define done and test for it, we change our understanding of what we build.  Testing is not just validation in training or agile, it is also learning.  Testing evolves our understanding of what we do.  But just as stories align to goals or user journeys, so do tests align to an agreement about what we mean when we say we are done or when we say “yep that is good.”

So I can’t really count coffee points in a class and claim we are making progress unless I

• Define what we mean when we say we are done with a topic;
• Define the quality and expectations we have for our learning; and
• Test or validate or assess that we are done each time we say we are moving on.

So I can de-scope my topics for the afternoon or even redefine what we will access as “done”.  But I need to do so deliberately and it needs to be transparent.  The whole class need to understand what they are agreeing to.

The outcome

In the end I have to have the re-planning session after lunch.  It puts us further behind.

We reconfirm our goals for the day and agree not to impact our plan for day 3.  We capture some nice to haves but agree if they are not done then we will instead agree some books, YouTube videos or blogs to have a look at.

Then we decide to structure our sessions a little better with no stories about beagles and with a 5-minute rule for distractions and questions.

Finally we prioritise what we have left on the basis that we will cover 3 points per hour until 3 pm and then check again to see we are on track.

We actually get through quite a lot –and more importantly we get through the things we really want to learn as a crew rather than the topics in the agenda.

If day 3 goes well and the catering is good I am looking forward to some good feedback.  But even if the class does not say they liked what they covered at least I can blame them.  The decisions we made as a team were based on their opinions, my experience and assisted by the velocity at which we were getting through things.

In all honesty, I did run velocity in a class to demonstrate it but did not think it would have a big impact on the interaction or flow of the course. But I have found that even in a three day class measuring our progress in units per hour helps with the facilitation (I really use coffee points to compare topics).

So this was a long article but hopefully you found something useful among all the comments and stories.