Brujo has been a programmer since the age of 10 and he has more than 15 years in the industry. He was a VB, .NET, Java and Haskell programmer until he found Erlang 8 years ago. He’s now Inaka's CTO and Erlang Solutions’ Tech Lead and Trainer. He’s an active member of the open-source community and his blog (Erlang Battleground on Medium) was the most active Erlang blog of 2016.
19 September 2016
Software Testing - Protecting your time
Last night I attended a software testing meet-up where Örjan spoke about his experiences in Managing Quality in an Agile team. He raised a few interesting points from a management perspective - but it was one in particular that caught my attention: protecting time.
In order to help his team achieve the tasks they planned in sprints, he would try and stop people hindering his team unnecessarily. He wanted to help make it easier for his team to work. And I get that. I've been on both sides of the equation - I've been the person trying to ask a developer questions only to be blocked by their dev team lead and I've also been the person who's been "protected" by their team lead so I can focus on my work and reach a deadline. From both perspectives I've been able to appreciate both the frustrations and the benefits of such an approach.
But what interests me - is the different ways people go about protecting their time.
Blocking off certain periods of times for meetings
At a recent project, they protected their time by blocking off meetings on Tuesdays and Thursdays. If you wanted to have a meeting on one of those days, it'd just have to wait until the following Wednesday and Friday (this has been going on for almost a year now)
A guy in the meet-up said that his team tried to block off meetings in the afternoons and asked for advice from the meet-up group on how to go about achieving that, as that approach only worked for a few months. A few people encouraged him to get "buy-in" from different members of the team. In retrospect, I wish I asked him a few more questions about his situation instead of just giving him my thoughts on the matter. Lesson learned.
Designated question person
Two people in the meet-up had a similar approach to protect their time and that was to have a designated question person who would answer questions/deal with issues from people outside of the team. The role would rotate on a regular basis (whether that be daily or weekly).
They also elaborated on the benefits of this role - other than having less people being interrupted, it meant that the designated person probably knew when was the best time to ask questions etc. from a member of their own team (to minimise the risk of disrupting their flow).
The identity of this person would be communicated to other teams affected, for example - through a sign that says "Support" on their desk.
Do not Disturb
I worked at a company where headphones worked as a "Do not Disturb" sign. It meant that if someone had them on, then it was best not to interrupt them unless it was particularly urgent (you could've also just pinged them on Slack). To be honest, I'm not entirely sure how I feel about this approach. While I understand that headphones are a great way of tuning everyone out so you can focus on your work, I felt it didn't always mean I was in a condition to not be disturbed. For example: I like to listen to music when I'm testing, but that doesn't mean it's a bad time to ask me a question while I'm doing that.
A guy in the meet-up said that his team has 3 hourglasses for his team of 9. When you had the hourglass on your desk, it worked as a Do Not Disturb sign. I quite liked that approach (made me think of that old soap Days of Our Lives).
Make meetings less appealing
I'm sure a lot of people can relate to being in meetings that went on for way too long or they thought at some point "why exactly am I here? The subject of the meeting doesn't quite match what is currently being discussed"
Face to face communication is awesome - don't get me wrong. But often a quick chat, email or IM would also do.
Last night, two approaches were discussed that strived to reduce the appeal of meetings.
The first approach was to calculate a rough estimate of the cost of each meeting. That is, estimate the average per hour salary of each attendee (this doesn't just apply to consultants, but employees as well) and display it at the meeting. This seemed to help people stay on track and make sure only the people necessary were there.
The second approach was to set a weekly time budget for meetings for each person. At the person's company, they have an allocated budget of 5 hours a week (I don't know if this differed slightly depending on the role each person held) At his company, there is a designated minute taker for each meeting so that the meeting notes could be shared with all the relevant people.
That discussion at the meet-up has given me a lot to think about. Not only when it comes to coming up with ideas in how to protect your time, but also in communicating those to your team, to your manager or to people who your work impacts.
Saying no to meetings and bringing these ideas up can be a somewhat intimidating experience. Even worse, being in a meeting, then 10 minutes in thinking "Can I leave? Does the law of two feet apply here?".
25 Jul 2016
A video exploring the potential of fast simulated...
08 Aug 2016
Gradle did come to stay with us. Although...
22 Aug 2016
Software Testing is not for Attention...
19 Sep 2016
New video from #droidconpl2015 is out!...
19 Sep 2016
Last night I attended a software testing...
21 Oct 2016
A summary of my visit from SystemD Conference...
24 Oct 2016
Up until yesterday, I had only gone...
24 Oct 2016
Updating sources (versions, revisions, tags)...
14 Nov 2016
Elixir is a joy to work with, an easy...
16 Nov 2016
A few weeks ago I attended Mobiconf, one of...
20 Jan 2017
When you can’t bang! This story...
26 Jan 2017
I have been using Ruby/Rails for 8 years and...
07 Feb 2017
I am an old Java man, I never allocated many of...
07 Feb 2017
Earlier today, Dorothy Graham presented...
07 Feb 2017
I have seen great posts about Elixir release...