This article got triggered by reading this article; and I’ve come to the conclusion that I spend way too much time thinking and reading about improvements in my daily work as scrum master and software writer, where I actually could do something about it.
Productivity, efficiency and effectiveness
How do you measure productivity? How many lines of code you write each day, or the amount of bugs you solve? How many impediments you resolve for the development team? As a software writer, a task can take you a few minutes to figure out, yet it can also take over a day to figure out the solution for a problem. Are you then productive?
According to Google “productivity” is:
the state or quality of being productive.
Or even more specific:
the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input.
When you’re spending a day in producing code that resolves a bug or writing a new feature, you are productive that day. Yet are you spending that productivity on the right thing?
Efficiency
Being efficient is a different matter; Wikipedia mentions the following:
(Efficiency) is the ability to do things well, successfully, and without waste.
So, we have to measure whether we’re doing things “well”, “successfully” and “without waste”. What is “well” in terms of your profession, that you’ve written a piece of code that does not break the (unit) tests? What is “waste”, any code that you have written that does not contribute to the overall functionality, or any piece of the application that isn’t being used?
Over-engineering software with the notion that you probably will benefit from it in the future is considered waste, within the agile software development view. So only write small pieces of software that just do what it should do, and no more.
Effectiveness
Definition according to the Oxford dictionary:
the degree to which something is successful in producing a desired result; success.
This definition doesn’t say anything about time, only the results of what you are doing counts. So in the example I set in the beginning of this article, yes, you are effective when it takes you a day to figure out a complex problem.
My perspective
Although there are quote some authors to be found that write a lot on this topic (I personally liked Edmond Lau’s book ‘The Effective Engineer’ and Stephen Covey’s “The 7 Habits of Highly Effective People”), I’ve found that the practice of prioritising what you want to accomplish at the start of the day works for me. Sometimes I manage to prioritise it already the day before, yet usually I find it to work better at the start of the day.
For that purpose as well, I have delayed reading email to 11am, of which I’ve informed the people I usually communicate with (I do have two time-slots in which I handle email, 11am + 4pm). Does that mean I don’t write emails before then? No, I do sometimes have planned to write an email outside the designated time-slots I have created for myself to handle incoming email, yet I then refrain from looking at my inbox. Incoming emails usually do not contain fires that need to be solved immediately, those most of the time come via our Slack channel or via Skype call (yes, they sometimes come also via email, and I’ve found that they are then 99% of the time no actual fires nor have the immediate need to act).
On some days I can schedule some uninterrupted hours of deep work (a reference to Cal Newport’s book, and I find that those blocks usually work best when not working in an office setting, yet when working from home. So yeah, Jason Fried’s TED talk does apply.
As a scrum master I tend to lead by example, and coach my team members to do the work in the best setting they find works best for them, given that they are providing some result. Sometimes this does conflict with my software writing role, as my schedule for deep work can conflict with a team member needing help in something. That is still a thing I’m struggling with. Disabling all notifications at moments of deep work for now does work for me, yet I’ve found that that sometimes has created impediments for team members to do their work.
P.S. If you’ve enjoyed this article or found it helpful, please share it, or check out my other articles. I’m on Instagram and Twitter too if you’d like to follow along on my adventures and other writings, or comment on the article.
Buffer
Tweet
Share