Impacts on Productivity

It was after reading the excellent book Soft Skills: The software developer’s life manual by Jason Sonmez that I decided to push forward with furthering my career by starting a blog and creating YouTube videos. I did a number of posts and episodes of a web series, before intentionally taking a break to analyse what I was doing and look at how I could improve. Over the last couple of months I have spent time planning projects and reading various books on development processes as opposed to specific technologies. So before I start writing my next series of posts covering specific coding projects, I wanted to get my thoughts down on a topic that I can often find both interesting and frustrating and that is Productivity.

Almost all companies developing software follow one of the development methodologies. I have never experienced one that didn’t, but I’m sure they exist and they are probably quite chaotic. Having a defined method helps maintain control and ensures people are following the same processes. But just saying you are following Agile or Scrum or even Waterfall, does not say that it is helping you be as productive as possible within your chosen methodology.

I have heard of places “rigidly enforcing agile”. This doesn’t even make sense to me. Agile allows you to quickly adapt and adjust, so by rigidly following processes you can very easily end up stifling the qualities that you are trying to instil in your teams. I previously worked in government where following the processes appeared more important than the products being delivered. We even had far more people managing and being processes than we ever had in the development teams. This didn’t help with delivery, in fact it was rare for us to complete a product and when we did teams were more relieved it was over than happy with the quality of work.

I was looking at productivity from a work perspective but after reading another great book this one Scrum by Jeff Sutherland I decided to look at myself and where I reduce my own productivity in general. It turns out that the reasons and results between personal and work aligned quite well.

At times I have a short attention span. My long suffering partner may say that’s more often than I would, but its just part of who I am. One of the results of this is that I will often have several books on the go at any one time, along with other projects and even video games. To me this has always been normal and I didn’t see a problem with it. So I carried out an experiment and chose my reading as what I would work on first. Over a year I will read on average 2 books a month and I would be reading 2 different fiction books, 1 non-fiction such as biography or popular science and 1 related to technology and software. I often would read in the evening after 9pm and I would jump in and out of the books depending on my mood. Over the last couple of months I have set a new rule, only read 1 book at a time. I am no reading 3-4 books a month, so about double if I keep to this over a year. And it comes down to the simple fact that I remained engaged on the same book, I didn’t have to remember where I was, or get back into the story or subject as I was already there. Its not that I sped up my reading, it was just more focused so I didn’t have to pause when I started and also I read for longer in each session.

In work we will often switch between projects based on work items in our sprint. Our work items are based on priorities of how important they are to the product and the impact on the customer. Often the priorities are based on bugs first, then other backlog items. At face value this makes perfect sense, why create a new feature when your old ones are broken. So I did another experiment. I reordered the items in my sprint to be based on product areas, I did all the backup bugs and features first, then looked at a group of caching bugs and features. By doing this I ignored my normal prioritising order and it my velocity increased. However, later in the sprint due to various things going on I moved between different areas repeatedly. Guess what? My velocity dropped like a stone. My takeaway from this, was that I need to come up with a prioritisation system that takes into account the potential drop of productivity. If I can do more, quicker then delaying that priority 2 bug to later in the sprint is not really going to impact on its delivery date. While I’m talking about priorities, take a look at how you prioritise bugs. On a 1-5 scale people seem far more confident to assign a 1 or 2 to a bug than a 5. Is that typo that doesn’t change the meaning of the message really a 3 or 4? Be honest, its probably a 5 as its been there for a year and nobody has noticed.

My next observation on productivity was another from my personal life, smart phones and internet. Now I work in technology and am a big fan of what is now available on the internet and the information I can access on my phone, but it has its place. How much time do people spend on their phones at home? Just sitting there looking at Facebook as if somebody would have done something spectacular in the last ten minutes. I have an odd and unpredictable group of friends, but still the vast majority of the time nothing would have happened. Or looking up one thing on Wikipedia and then ending up reading about something really random and unrelated. I ended up on the Salem Witch Trial a few weeks ago, which while very interesting didn’t provide any help with developing for Google Home, which was what I was supposed to be doing. So now, I am trying to turn off the phone at home for a few hours when I’m working, so far its working and not just with my development projects, but also stopping me missing out on jobs round the house.

Now I’m a professional and I’m not going to sit at work just playing on my phone, but that 1 minute check every half hour to an hour is disruptive to the flow of work. People have gotten so used to checking that it is becoming a muscle memory action. I forgot my phone one day last week, I didn’t miss it. In fact when I got home I had 10 emails on my personal account, all marketing emails and 1 text message, ironically from my girlfriend letting me know I had forgotten my phone. But going back to my earlier point about losing productivity by switching focus, not having my phone did help as I wasn’t distracted. In the Soft Skills book I mentioned at the start, the author talks about batching tasks and specifically focuses on emails. When an email comes in you get a notification and a little icon and you have to check in case its something important, it rarely is, but since your there you reply, do what was asked, or even just think and plan what you would need to do. Again with my experiments I tried the batching approach and it worked. I only checked and responded to emails in 3 blocks during the working day, start of the day, after lunch and before I left. Not only did I find this approach helped me focus and be more productive, I realised something else, nobody noticed that I was doing it. When I started I expected emails saying “do you have an update on my last email?”, but it turns out that not replying for 3 hours doesn’t bring the building down.

My final observations for this post are specifically regarding Scrum. Now I am a big fan of Scrum, quite simply it works, my caveat for this is that it works when followed sensibly. Just having daily stand-ups and sprints does not mean you are following Scrum or aiding productivity.

I once did a sprint at home. I had let a lot of DIY jobs build up to the point that I didn’t want to face any of them, so I wrote a list that ranged from grout at tile and replace light fitting tasks to re-plaster a wall and then prioritised it. I originally planned to do it in 1 week before I was laughed at and told I should probably make it 2. But it worked. I’ve seen sprints in software where the key concept of having a demonstrable product is not adhered to. The team works on features and items slip between sprints, often the QA type tasks that are moved to the next sprint and even beyond that. Every few sprints a nice feature can be presented. The problem I see with this is that you are adding the retrospectives and planning meetings as if you were in a sprint, but not providing the deliverable of the sprint. In reality you are just reducing your productivity by adding processes for the sake of them. If this is the case then you should reassess and work on what you can deliver in a sprint.

Stand-up meetings are another essential part of a sprint, these meetings should leave you energised and ready to take on your tasks knowing that blockers are being addressed. These meetings should also be short. A 10-15 minute stand-up is in reality a 15-20 minute break in work, people have to get up from the desk and move to the meeting etc. Now if you make this meeting 30 minutes, it gets worse. If your stand-ups are going to be that long, watch how many people get up and go get a coffee before or after the meeting (in some cases both). A 30 minute meeting is an investment in time and you will see people treat it as much more than just an update. Not by way of the content the provide in the meeting, but how they prepare for attending. So now you are at 40-45 minute disruption to work, or over a working week is over 3.5 hours, or half a working day for each person attending.

This was quite a long post really and I have purposely not tried to provide solutions to the problems, most of what I have looked at were things I noticed by looking at my own productivity and how this can change through various factors. But what I want to get across is that we should look at our own actions to see if we are doing something that reduces our productivity. We should also look that when we are following a methodology, that we really are following it and not just following the processes for it. If you are putting more effort into being Agile than being Agile, maybe some adjustments are needed.