I was speaking with an ex-colleague of mine about problems they were experiencing at work.
They'd said: “Our teams are performing way below what we expect.”
So, I probed further: “Why?”
“Because our teams velocity has fallen over the last few weeks and we don't know why. We know they can do better. Management want something done about it. For example one teams velocity is significantly better than another's”
This got me thinking.
Do management often use velocity as a stick with which to beat development teams with? What is velocity, really? What are the problems that can cause velocity to dip? Finally, what can we do as a development team to overcome dips?
What is Velocity, Really?
Velocity can be a really great tool to help in identifying problems with a team as far as blockers, bugs and problems with the practices within the team.
Without looking at official definitions here's my definition of what velocity is:
Velocity is an abstract measure of a teams productivity towards delivering features over time.
We measure velocity by working out an average number of agile points delivered sprint-on-sprint and dividing the total number of agile points delivered over X sprints by the number of sprints it has taken to deliver them.
So velocity is:
Velocity = Total number of Agile Points Delivered / Number of Sprints
Let's break the velocity statement down. When we refer to velocity as an “abstract measure”, what do we mean? To answer this question, we need to understand what makes up velocity. We said earlier it's an average of the number of agile points delivered.
Agile points are measured on a Story-by-Story basis. Our current team like to break down stories to a really granular level with sub-tasks, so our Story is made up of the number of agile points against each sub-task.
We measure Agile points in a Fibonacci Scale where each number in the sequence representing an exponential increase. This is so we can emphasise the scale of tasks against other tasks in both time complexity and complexity of the task.
How Do You Assign Points to a Task?
According to the Agile Manifesto we should favour:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile points are an enabler for knowing what we deliver and how much we can deliver. It is the responsibility of the people performing the work (the “development team”) to estimate tasks.
Point estimating a task will involve the team discussing what they believe the task involves, then using their intuition and logic to work out how many points they believe a task will take in comparison with tasks of a similar nature. This will mean that estimates may be inaccurate at first but will increase in accuracy “over time” (another point mentioned in the definition).
Another side effect of this means that agile points associated to a task are a specific measure for that team only.
Coming back to the original story, it seems to me as though management were trying to compare velocity across teams -- this is an absolute no-no in the agile world. Management should in no way interpret velocity as a measure of performance across teams.
Why Does Velocity Slow Down?
When you aren't delivering for one sprint, you notice. When you aren't delivering for two sprints, your scrum master notices. When you aren't delivering for months of sprints, management notices.
A drop in velocity for an agile team can be a demoralising sight to witness for all of those involved. However, with careful analysis and investigation and open discussion amongst the team early on, you can figure out why it's happening.
One of the most important Agile Rituals is the Retrospective. It gives the Agile Team an opportunity at the end of every sprint to discuss how the sprint went, what problems they thought they had, and what they think they can do next sprint to help improve productivity and delivery of features.
Coming back to the story around this article, when I quizzed them about this they mentioned that “story points and velocity were never discussed in the retrospective”. This highlights a big cultural problem.
They feel like they can't discuss velocity because it's become a “taboo topic” and means we're ignoring the elephant in the room and hoping it'll just go away. In agile, we need to discuss what our problems are so we can understand why the velocity may have dropped in the sprint and why our burndown was effected.
Burndown: A chart of the number of points that were actually delivered against the number of points that formed part of the sprint contract
If we look closely there are a number of reasons why our velocity might be suffering...
How often have you been told this by a senior member of the team “yeah, we know it's not great but we don't have time to do it now, raise a ticket and we'll do it in another sprint.”
While this mentality is okay in the short-term, too many “let's do it later” decisions add up to a lot of tech debt that's often harder to sort later down the line because your mind isn't in the right context any more. As Uncle Bob said: “Keep the camp-ground cleaner than you last found it.”
If you tackle technical debt when you raise it, it'll affect you in the short-term but it'll help accelerate delivery long-term. You will obviously need to make judgement calls about when you leave Technical Debt for a later date but you have to remember if you do...
You pay the man eventually
If there are too many processes in the way of delivery, it makes it hard to deliver. Don't put too many barriers in the way for developers to deliver features. Agile is all about a lean methodology and that means having a minimal framework in place to help you deliver and adapt to change.
For example, some companies I've worked at in the past introduced sign-off forms for releases meaning we had to update documentation every time we had a release. This, in my eyes, should be automated or not done at all. Manual process will kill your delivery and cost your company a fortune. Whatever red tape can be automated, should be automated.
They also mentioned there was a ratio of 2 testers for 3-4 developers. Klaxons were going off at this point. This is absolutely insane.
On top of this, testers were the driving force behind sprints, demanding full testing suites of stories from the outset.
Testers were also saying their was too much to test in the testing column meaning developers had to hold up with their development mid-sprint.
There are several major problems here.
- The ratio of testers to developers appears to be too much. As a rule of thumb I would anticipate a ratio of 1:4 (1 tester to every 4 developers) is a sensible ratio.
- Testers, along with product owners should always be ahead of current sprints. Otherwise, as we can see here, they hold up sprints by trying to fully analyse stories during the sprint when the work is already due.
- Bottlenecking the sprint board by blocking progress of tickets because they can't get through the work fast enough.
My suggestions here would be to have fewer testers and to automate more tests so there is less of a need for manual testing the system. If more system tests are automated then there's less of a need to have an army of testers to keep on top of it.
Always make sure tickets that make it into the sprint are “ready for development”. What we mean by this is that there is no analysis that has to occur for us to start work on this story. This is how it should be in an ideal world but often isn't, even in agile processes that are working well - there are always outstanding questions.
Hiring on the Cheap
The company in question has a habit of hiring on the cheap. Perhaps this is because they mistakenly believe by hiring more junior developers they will get more work done because they have more bodies.
In reality though, this often isn't the case. As the old saying goes: “Too many cooks spoil the broth”. Junior developers and cheaper developers are, in general, less experienced. As a consequence, you'll build up technical debt over time or have solutions that are overly complex / difficult to adapt and change.
Much better to have a couple of experienced developers who are well paid (to attract the best talent). These developers help the Tech Lead steer the solution in the right direction. They also help the more junior software engineers learn by passing on their extensive knowledge. More experienced developers can then make better judgement calls on work done and peer review the quality of their colleagues work.
How Can We Speed Velocity Up?
We've hinted at a couple of things to speed up Velocity but here are a few other suggestions that might help you from slowing down...
Test Only What You Need
You may have been taught to have 100% test coverage, to test every line of code you write and to test absolutely every possible scenario you can think of.
In reality though (and from my experience), exhaustive testing is a sure fire way to destroy your productivity. Sure, test complex parts of your code and code that is likely to change and cause regression errors due to that complexity, but in the main if you want to release a product to market quickly, you can't always do that. Start-ups and some smaller businesses on a constrained budget, don't have the luxury of writing tests to produce 100% coverage.
What I would suggest on the other hand, is to test all the mission-critical stuff and code that's the most complex. Code that is core and critical should be covered, whereas obvious pass through code (like translators for example), may only need to be covered by one or two tests to cover some edge cases. Unfortunately, this is something you learn and fine tune with experience.
Pair Only Where Appropriate
I don't pair much these days, I used to, and in some teams all the time, but these days I don't pair much. Why you might ask? I wrote an article titled Is Pair Programming Worth It that highlights some of the pitfalls. I won't go into it here for fear or re-hashing old ground but I just don't find I pair on things unless it's complex because as a team we get more done.
Fix Your Culture
Culture should be the most important thing for a company to focus on. A companies culture defines how it's employees act and behave. Each member of a development team should be willing to ask for help and not fear reprisal in asking.
When you're stuck, and developers often are, look to others. This carries numerous benefits. Firstly, it disseminates knowledge. Secondly, it solves the problem faster and thirdly, because it highlights potential problems to the team early.
Part of the culture of your team should be that help should always be willingly given to those who seek it and you should never suffer in silence.
Finally, we come onto the point of meetings. Dreaded meetings.
Developers hate them but managers love them.
Meetings are important but only if they have a point. Steve Jobs wasn't the most tactful and personable of people at times but he was excellent at running meetings. The main point I gauged from his advice was that meetings should have a point, be “amazingly simple”, keep meetings as small as possible by inviting only those people who should be there and make sure someone is made responsible for each item on the agenda.
Always Keep Improving
Whatever you do, when you notice your velocity is tanking, make sure you at least do something about it! You must make changes in order to exact change.
So fundamentally, Retrospectives are a really important part of the teams reflection on previous sprints work.
I hope you've taken some inspiration from this.
I'd be really interested to know what your thoughts are in the comments below. How would you change a team around and improve it's velocity? What are the problems you've experienced? Have you seen any of the problems I've mentioned.
Interested in this article? Follow me on Twitter