In this article, part of my series explaining better ROI from software development, I’d like to look at the productivity and flow.
This isn't new news.
The UK has been falling being in Productivity for quite some time.
If you look at this article, you’ll see that (as a nation) we are second only to Japan in the world’s richest nations.
And while the nation isn't fairing well; it is a fair assumption that the majority of UK organisations have a similar productivity picture.
There certainly will be some organisations that are streets ahead (in the same way there will be some that are streets behind) – but Productivity should be interesting to every organisation.
It is a fairly obvious correlation of better Productivity to overall organisation financial performance.
Organisational Productivity can be improved through technology.
Be that better, faster computers, smarter more intelligent software or deeper insights into data.
I’ll pick up the “anti-Productivity” principle of “sweating the asset” with regards to ageing computer hardware (and software) in a separate article (hint: it’s a really stupid idea).
Software Development however should be providing your organisation something. It is creating revenue, saving on costs or protecting existing revenue. If you can’t tie that software back to one of those activities – then why are you doing it?
Normally, even in the most informal of environments, then you should have an idea of how any piece of development work effects productivity and the bottom line – even if it is only a theory.
And in most cases it will only be a theory.
Until such point as you have seen the benefits, it remains a theory. The operating of the software is the testing of the theory. The end financial result is the proof (or disproof) of the theory.
In a future article I discuss why it is healthy to think about any software development (or project) as an experiment to prove a theory AND that there is as much value in disproving a theory as proving it – possibly more.
But for now, focus on Software Development being a great way to improve Organisational Productivity.
When you start thinking about Software Development packages of work as Productivity improver, then you soon see that it makes sense to think about which of the packages you do and in what order.
There are various ways of facilitating that process. I’ll not dig into here, but one of the most important things to get right for is to make sure we are working on the right thing.
Again, referencing previous articles, this is about the system – not the development team.
I've touched on this in a number of my articles so far and will continue to do so over the series. After all, the whole point is to get the best ROI from your investment.
Once the development team have the right work to do, they need to organise as a team to be Productive in their efforts.
I've touched briefly on this in the articles on Agile. In future articles I will look at process frameworks and various techniques which assist.
For this article, however I want to skip to the individual.
Before we talk about the individual, I would stress again that the Productivity of an individual is not as important as the Productivity of the team. And that Productivity of the team is not as important as the Productivity of the organisation.
Ultimately it doesn't matter how productive an individual or team are if the organisation is going in the wrong direction.
That being said, you struggle to have a Productive organisation without Productive teams. And you struggle to have Productive teams without Productive individuals.
For the rest of this article I will cover off some topics which effect individual Productivity.
Ok, so we know Software Development is a problem solving activity – it involves using a lot of thought.
As with any activity that requires concentration, then achieving Flow is exceptionally beneficial for productivity.
“In positive psychology, flow, also known as the zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does” Wikipedia
We should all have experienced Flow. Any time that you are involved in a creative process (writing an email, problem solving, etc); achieving that Flow enables us to probably be our most Productive on that given task. And we generally enjoy it (we can link that back to the Zeigarnik Effect and Intrinsic Motivators) – so all good.
It stands to reason that if we are paying Software Developers large sums of money to solve problems, then we want them to be in the zone for as much of their working day as possible. That is where they are going to be their most Productive.
The modern world however (as I'm sure you know) doesn't lend itself well to achieving and maintain flow.
For me, there are two key things that effect Flow:
Let’s focus distractions.
Multitasking isn't a Productive way of getting things done.
There are plenty of studies which show that splitting focus between activities ties up cognitive capabilities – see my previous article on the Zeigarnik effect.
The problem is that it is very easy to force someone into multitasking without knowing it.
If I'm working on a project, then I'm made aware of a bug and I'm being asked to estimate a piece of work – my focus has then been split across multiple activities. Largely having a negative impact on getting them all completed.
Look at ways of limiting those possibilities. Avoid having your team taking phone calls, answering emails, etc while they are trying to achieve flow. Make sure that they are as singularly focused as possible.
There are plenty of personal productivity techniques to help with focus. Some are down to disciple – simple acts of ignoring Facebook, emails, etc. This can be a difficult personal disciple to stick to.
Some of these will work better if “socially acceptable”. For example, so many personal productivity experts will recommend switching off email and only checking 2-3 times a day. How acceptable is that going to be to your organisation?
Logically, I doubt any business would struggle without immediate email response. Emotionally however it can cause all sorts of concerns and panic. People can get really upset if you aren't providing them with a response – even if they don’t need it straight away.
I've had phone calls chasing a response to an email an hour after it was sent. Surely if the email was that urgent, then it should have been a phone call in the first place.
It does however show that you need to think about the cultural effects and align them to helping the team achieve focus.
Another technique that I’d highlight is the Pomodoro Technique.
“The Pomodoro Technique is a time management method developed by Francesco Cirillo in the late 1980s.[1] The technique uses a timer to break down work into intervals, traditionally 25 minutes in length, separated by short breaks. ” Wikipedia
This is great for personal disciple and works well with company culture if expectations are set correctly.
Basically, an individual will focus on something for 25 minutes. Just that one thing. They remove all distractions (turn of email, Skype, phone, etc) and just focus.
After the 25 minutes they then have 5 minutes to check on emails, skype, phone, get a drink, etc. Anything urgent then they can deal with, anything else is simply left till an appropriate time (worth scheduling 2-3 email/ admin Promodoro’s per day). Then on to the next 25 minute Promodoro.
This can be an exceptionally powerful personal productivity tool if used right.
Ideally you start (or end) the day with a planning Promodoro. That will map out the rest of the day into 30 minute blocks (25 minute Promodoro & 5 minute breaks) and ensure that you have everything you need to start each (or a plan to get them). Have a couple blocks for email/ admin.
Again I would stress that the organisation culture may need to adjust to support anything like this.
I would also stress that this technique (or others) should be sold into the team rather than directed. An individual needs to see this as being beneficial to them – not just a management tool to bully them into more work.
The last thing that should be happening is a manager insisting on see or creating the Promodoros. They are not a commitment which can be measured - except by the individual using them.
I’ll end on a repeat of advice I've given previously;
Ask the team and listen to the response.
They will know what is causing them distractions. Empower them to resolve those distractions.
I can’t stress enough that this has be a culture change. Simply doing it for two months, getting frustrated at no obvious results and then reverting everything is probably worse than starting in the first place.
Give them time and trust.