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.

Deploying a bot with the Microsoft Bot Framework


So far in my posts/videos on the bot framework we have been using the emulator to communicate with our bot. To finish off the basic tutorials for the bots we are now going to connect our bot to another channel, in this case Slack.

Connector Service

The Bot Framework’s Connector Service allows us to easily integrate our bots with various applications. To do this we need to register out bot on the Bot Framework site. In this post we will just be setting up our bot for dev purposes so wont worry too much about Icons and site details for help etc.

The first thing we need to do is host our application somewhere. I am just using a basic Azure App for this. We will need the endpoint details shortly when we register our bot.
Azure Publish
When you register a new bot you need to give it a name and handle. I am just going to use the same for both here.
Next we configure the endpoint ensuring to add api/messages on the end. For the App ID and password press the button and you will be taken to another window to access/generate these.
Bot ID and PW
One important note when generating the password is that you will not be able to access that again. If you don’t save the password immediately in your bot you will need to regenerate a new password.

Just like many app stores you will need to provide some details on the publisher such as support details and terms of use. These are important when you are pushing out a live application, for development purposes we just need to ensure they are in the valid formats.
Publisher Profile
If you intend to use App Insights then you can configure this at the end of the form. Then all that remains is confirming you have read the terms and privacy and then press Register. Capture7
You will now be navigated to your apps page. You will notice that the channels for Skype and Web Chat are already enabled. You don’t need to press the Publish button when working in Dev so this can be left for now. You can press the Test button on the right of the page to confirm connectivity to your published bot.


When you have registered your bot you will be able to see a list of available channels. Each one has different configuration steps based on their own systems requirements. We are going to go through using Slack for this demo. Slack is a great chat application that works great if you need to section people into teams.  Capture9To publish your bot to Slack you need to setup a Slack account so you can administer your team and also have an account in which will allow you to develop Slack applications.
When you choose to connect to a Channel you follow a basic set of instructions from the bot framework site. These are usually just steps on what to do in the other application. For Slack you are asked to create a new App which is what we do here.
Capture11The bot framework wizard shows you what information you need to input into Slack. So in our case we need to copy the redirect uri into the appropriate part of the Slack configuration form. Capture12Once we have done this we need to create a bot user, this is the handle we are going to use to invite and call our bot .
Capture14The next step is to copy the App Credentials into the appropriate boxes in the form on the bot framework site. When you authorise the bot, you will be prompted by Slack to confirm that you are happy for the bot framework to make these changes.
Capture18Capture19You will now be able to use your invite your bot into your group on slack and ask it your normal questions. In slack all bots are considered non-sentient users, so they respond to you but don’t initialise conversations.
We now can test this by asking a couple of our bot questions.
Capture22One problem we encounter is that if you have prompts, you need to configure slack to allow interactive messages.
If we go back to our app in we can enable interactive messages.
Capture24 We can now run our commands which contain prompts without problem.
What next?

I see this as the last of the basic tutorials for the bot framework, we can now build bots using dialogs, LUIS, prompts and publish them to a channel. You can experiment with other channels and the process is quite straight forward for each of them.

Here we go

Well this is the start of my blog! I’m a software developer who has worked across a number of technologies including desktop, web, mobile and cloud. Also covering everything from user entry systems to applications that manage and update networks, along with lots of other projects in between.

In my blog I will mostly be covering C#, but will look at various other languages and technologies as I use them for my projects.