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…

Team Efficiency

Over the last couple of months I have been working with a new team. One of the things that we have tried to embrace as a team is constant experimentation. Not just talking about where we can improve, but coming up with short term experiments that we can implement to try and do something about it.

One such experiment was looking at the relationship between personal efficiency and team efficiency.

Having three team members working on three (or more) stories as we could zip between them personally and work on something that was the most efficient for us at the time.

The problem was that our board was not moving very quickly. We had tasks in progress for too long, meaning that our tester – who is, of course, in our team was struggling to do something for the team and then in one swoop got everything at once, big bang style.

I won’t speak for the team, but this was a cause of stress for me. Working really hard, but taking a long time to see something move to completion.

So, in our retro it was discussed and we decided that we were going to ensure that we worked together.

  • Step 1: In sprint planning we looked at how we could split the stories into tasks in a way they fostered collaboration. This included looking at how stories themselves were split, a process that is ongoing!
  • Step 2: At the point where we hit a choice between easy street and taking something totally separate or picking a task with close collaboration we made a deliberate effort to go for the latter. This is a hard to keep up!

When we tried this we found that we were stepping on each other’s toes too often, and so in subsequent discussions (why wait for the retro next week if you have pain today?) we refined our process a little to come up with ways to mitigate this

  • Keep you files small and functional.
  • Check in fast, and oftenAt least daily.
  • Spend the time in planning to ensure that you have a good split and that everyone has a good understanding of the tasks

After running this experiment for a couple of sprints we have found our collaboration has improved, we can pick things up from each other with more ease and we have less tasks being developed simultaneously. Getting it working has been hard, and we are still working on it but don’t get discouraged by the difficulty. If it was easy to start then we would all be doing this already! And the results have, for us, been worth the effort J

Folding wood

Whilst sitting having lunch today (yes, I stopped long enough to eat away from my desk!) I noticed another tree trunk stool in the corner of the canteen.

Whikst chatting I started to look at the way the wood had grown folding in onto itself. So, apologising to my colleagues, I went across and tried to get low enough to grab a shot. I think with a movable light source I could spend hours and fill a months pictures from the it 🙂

Oops, this have appeared on my photo 365 blog picturesinpassing.wordpress.com – never mind, glad people enjoyed it anyway!

Reboot! (And Rename)


After trying to fit everything into my life for a while, and of course seeing that you can’t do everything, I took stock at the end of last year and made some changes.

In the first 1/4 of 2016 I dropped my team lead role from my job. It was costing more energy than it was delivering and it was stopping me from doing the things (both inside and out of work) that I wanted, and needed to do.

I went back to near full time development, with an eye on helping the remaining team leads with our continuing agile journey. But, whilst I was busy bringing my development skills back up to scratch I put the agile work on the back burner so that I could give that my full attention. After working with AngularJS and .Net Web API for  6 months I can say that I am nicely recharged and really enjoying my work again!

So, time to get the agile work back up to speed. High on the list of things to do here is getting this blog back up and running, and sharing the lessons I learn in my life now that I’m back in the middle of a Scrum team!

And, as I foresee the focus as less technical, a new name: Seeking agile

I am looking use an agile (with a lowercase a) mindset to make our product development as efficient (read giving customers what they need, with as short a lead time as possible) as we can.


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!

Printing work items with Team Foundation Server

After our Product Owners were complaining a whole lot about not being able to print the backlog this post from Rene is more than welcome!

The Road to ALM

With the introduction of TFS 2012 Web Access we lost the possibility to print work items from the web. The experience wasn’t great in the first place but now it disappeared.

Also in Visual Studio we do not have great printing possibilities. For some teams this is a big issue. They like TFS but also like paper. For example they want to print the User stories for use during the Sprint planning. They have the most relevant information on paper, they can write on it etc.

But how to print to an acceptable format…Not out of the box.

Power of office

After thinking a while about this issue and some brainstorming with my customer, we came up with a simple but effective solution. We use Office. No plugins, just MS Office….and we use………Excel and Mail Merge.

Since VS 2005 we can use Excel to export Work Item Queries to Excel…

View original post 217 more words

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!

Time flies when you are changing nappies

Hmm…  Great idea to start a new blog about a subject I am passionate about and where I am constantly learning new things, but a terrible idea to start at a point where your life is being turned upside down and you run out of time constantly!

I’ve been away dealing with family things over the last months, including having our family expand and needing to expand our house to cope, and it kind of took a lot of my time!

But, things are starting to settle and I have a few thoughts that are being worked into real blog posts and so this will get back on track!

Hopefully see you soon!

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!