Speed vs Velocity

Speed vs velocity title image

This year at Scrum Day Europe I participated in a workshop for videoscribing, a really simple way to try and make your story engaging. I came away from that workshop buzzing with energy and with a few idea of what topics I would love to try with the technique.

Unfortunately, my Inkscape skills (needed for creating the SVG images used in the videoscribes) are not yet up to scratch 🙂 However, I really wanted to do something whilst learning to make sure that I keep my energy levels up.

And so here is my first attempt! Not a videoscripbe, but rather using its sibling, Tawe. Please ignore the rather poor sound production – at the moment I am using what is to hand to make the recordings – this will change with time…

So, onto the topic! Speed vs velocity. My thoughts on why we as teams should not be celebrating our outright speed, but rather using our velocity to provide insight into progress instead…

Repaying the Debt

It is a truth universally acknowledged that a developer in possession of a codebase must be in want of refactoring time.

Technical debt is built over time – the newer your codebase, and the more quality focused you are, the less you may have, but I still think that you have some. Maybe there are some obsolete interfaces used previously? Maybe what was a good idea 6 months ago just isn’t any more? Maybe the functionality has morphed over the last years and the existing base does not allow easy expansion for the future?

Or maybe there was simply too much time pressure in the past and not enough focus on ensuring that the code was up to standard!

Where I work at the moment we have a lot of technical debt. With over five years of waterfall development where delivery time was pushed over quality, and the time spent starting Scrum and trying to change this mind-set, have not been kind. But we are improving! And of course, knowing you have a problem is part of the solution, burying your head in the sand never solved anything!

I have never seen a company where technical debt is not a difficult subject between developers and stakeholders. The conflict between trying to get new features and making sure that things are maintainable and scalable are always hard to balance. The question is just how do you fight the technical debt whilst still providing business value during your sprints. If you are a developer and you find bad code then you want to fix it – but at what cost?

Where to Start

Before you start you have to ensure that you are providing value to the business whilst you are cleaning the codebase. Simply spending all your time refactoring to clean up the code will lead to two things:

  • Zero value for the product owner: Cool! The code is clean and looks great, but it had been running without a problem for a number of years now, and we were not planning on changing it any time soon so where is the current value?
  • New technical debt: with the time needed to clean the whole codebase you will still have old code when you are done. Just new old code.

A colleague who proof read this for me when I first wrote it came up with a couple of questions he asks himself before refactoring. This is the one that I think people maybe do not ask themselves enough:

  • Which changes are needed to make the implementation of the user story quick and successful?

In order to try and make sure that you can clean code whilst providing value there are three stages of refactoring that I see (feel free to correct me in the comments if you see it differently ;p).

Quickly Refactor the code

Firstly, if you are working on code and it needs minor refactoring (let’s say 20% of the story time) then just do it and make the code a nicer place. I would like to hope that all developers feel that they have the mandate for doing this!

Serious Refactoring of the Current Code

Secondly, if your code is going to touch old code and make it worse due to the (poor) existing structure then it needs changing full stop. This is included in the points assigned to the story and when the product owner asks why some simple stories are so complex you can explain.

At this point they can decide what the ROI is on the story – is it really worth investing all of the time on making it correctly, or should the story be delayed until stories with a greater ROI are complete. One thing we try not to do here is make the existing poor code really poor by hacking away!

Of course there can also be the times when you need to work on some terrible code, but not in a way that makes it any worse. If all you are doing is adding a few extra lines of code without affecting the complexity or maintainability then I feel you should be asking yourself if the refactoring is really needed at that time.

Time for a rewrite!

Thirdly, when it’s known that a project is going to need some serious refactoring before we start, ask for explicit stories to do it. A couple of examples of this where I work were related to web services used for a couple of product groups that we have. These had been quickly changed again and again in waterfall projects and never cleaned up (the time to clean up that was promised never quite materialised! Sound familiar?). Duplicate, dead and unused code was spread like spaghetti and adding anything new was both dangerous (you never knew what was going to break) and time consuming trying to pick apart the paths through the code. Here we offered two options to the product owner. Give us a story (or multiple stories) to rewrite the service from the ground up to support the functionality you want and need, or simply accept the limitations of the service and leave out some of your front end functionality.

One time the product owner decided that the whole functionality was really important and we had the stories to write the functionality that was needed. Another time it was decided that the ROI was not there for the extra work and the scope was reduced to only use existing functions in the web service.

Using these options I would hope that the transparency is there to allow the product owner to make informed decisions about the work that the team does, and that value can be given to the business and at the same time the codebase can be cleaned up and improved. Communication is key in making this work, as is building trust – starting refactoring projects without telling the Product Owner and having stories carried from sprint to sprint does nothing to make the teamwork easier!

What and How

When I’m not busy playing with computers, being a little evangelical about Scrum or reading a book I’m something of a petrol head. I watch F1, Superbikes and watched MotoGP until the BBC lost the rights at the end of last year…

What does this have to do with Scrum you ask?

Well… With all of the uproar about the noise in F1 (no pun intended…) since the start of the season I was wondering what could have been done differently. And thought about the “how” and “what” problem.

It’s something that our teams have certainly had to deal with, and I think that the FIA has had the same problem.

The “how” and “what” problem is how I see responsibility split across a Scrum team. The PO is responsible for the “What”: which stories are going to be picked up and in what order. This gives the Development team the goal. The development team is responsible for the “How”. Just how are these goals going to be worked into a potentially releasable increment? When these start to get mixed up bad things can happen to the value that the whole team provides, and the quality of code that the team generates.

So, back to 4 wheels. F1 has had a problem for a while now. The cars are very technologically advanced, managed to produce amazing amounts of power from relatively small engines and had enough down force to drive on the ceiling.

But… The aerodynamics were so impressive that the cars could not run within a couple of seconds of each other for long periods of time – otherwise the tyres and engines overheat, and slip streaming was a thing of the past as the cars had no grip whilst running in dirty air. After all of the cost cutting measures put in place over the last decade the spending of the teams has got to the level where the lowest teams spend as much as the top teams did when the cost cutting started. And the top teams are spending obscene amounts of money to put two cars into 19 races. And, of course, having cars that burn 150kg of fuel per car for less than 2 hours of racing was not really PC.

So the FIA did something about it – but where they should have given the teams the “what” of needed to be achieved, they gave them the “how” to do it. This means that the teams couldn’t come up with their own “how” and had their hands tied by the new rules.

So…  How would I have done it differently (and what does this have to do with software development?)

Firstly, I would try to get the goal of what I wanted across. The FIA does not need 1.6l V6 Turbo Hybrid engines (I hope, otherwise I would like to ask “why?”). That was a “how”. What they wanted was “An engine that lasts for x races, and uses no more than 100kg of fuel in a race and at a rate of no more than 100kg per hour”. This would have allowed the teams to come up with their own solutions and really moved F1 back to the technological pinnacle of motor sport.

My second PBI would be for the aerodynamics. The FIA has increasingly introduced more measures to reduce the down force – making the wings smaller, reducing the elements that teams can put on the wings etc.

The problem is that this has achieved nothing for racing. The designers have worked around the rules to produce cars that can drive on the ceiling and still cannot follow another car.

Again, they gave the teams the “how”. How about you swap this around? The goal is “make cars which can work to x% aero efficiency behind a standard model, and allow the standard model to work to x% efficiency behind the car”. Sure, testing this would be more difficult – but the racing would be so much better! No more DRS to allow drivers to overtake, no more push to overtake electric motors. Imagine cars slipstreaming around corners and the straights, pulling out to overtake before the next one.

This is overly simplified I know, but hopefully you can follow my thoughts!

Back to software development again! When a PO starts to think for the development team there is a very real danger of the development team not thinking about the problem, but just implementing the solution provided. This means that the PO may miss the best solution, and the development team may struggle to implement a solution that is less than perfect technically (as the team tries to keep within the confines of the solution provided to them).

Let developers think with the business, let them find the best solutions to problems (but this means you have to tell them your problems :p). The resulting solution will be output from the entire Scrum team with all the expertise that is contained therein, and not just one person’s view of a possible solution. You may even find that your problem isn’t actually what you thought it was and get something far outweighing what you though was possible!

Sprint Review – What’s in a name?

Since we started using Scrum, something that has been difficult is getting people to use the correct name for the Sprint Reviews. Now, I should explain that this is not the same issue as the one that comes up in the Scrum certification exam about using existing names for Scrum events in order to try and make the change smoother (bad idea!). This is about people not fully understanding why the events are named as they are.

People seem to insist on calling them ‘Sprint Demos’, something which seems innocuous enough on the surface.  After all, half of the review is set aside for the demo of what has been ‘done’ during the last sprint.

The problem, though, is that people forget that it is just half of the review. In other words by focusing on the demo aspect you miss 50% of the meeting and information! The review is intended to show the stakeholders, and other interested parties, just what has gone on in the last sprint:  what was the sprint goal; what noteworthy things have happened in the last Sprint; what stories were on the Sprint forecast; and of course the vision on the future – what is the team expecting to pick up in the next sprint?

All of this information is missed when you focus purely on the demo aspect of the review.

And, as we found out a while ago, focusing purely on the demo can have other implications.

We had a team working on a new product for the site. There were a lot of technical challenges that had to be overcome in order to bring the project to production and these stories were the main focus for the first Sprints. And so there was very little to demonstrate – there was a lot of work ‘done’ by the team, but nothing that could be shown on a big screen. And so the team took the decision to cancel the Sprint review.

I had a chat with the Scrum Master for the team about why it was cancelled, and it quickly became apparent that they were struggling with the question ‘How can you have a sprint demo when there is nothing to demonstrate’.

We discussed that it’s not a ‘Sprint Demo’, but a ‘Sprint Review’ and all of the connotations that come with it.  The team had been working so hard over the Sprint in order to finish the stories, they made big advances in removing technical obstacles to the project and there was plenty that could be communicated to the stakeholders. All of this was rather important in ensuring transparency to those outside the team.

The review was rearranged for the following day and was one of the best that we have had since starting Scrum.  A large turnout, with people standing in the doorway so that they could hear the progress the team made. The team had a very good presentation about progress, from the technical back end to the design for the front end, and there were lots of questions and ideas that came from those present that the team could take into the following Sprint.

Ever since then, that team has never made the mistake of calling a ‘Sprint Review’ a ‘Sprint Demo’, and that review in particular is used as an example of why we need to stick to the standard Scrum naming in the future!