Vaamo Dev Team Meeting - Cognitive Biases & Expectations around communicating
Every other week the complete vaamo development team gathers and talks. Sometimes we talk about general things like workflow optimizations, other times we do agile-style retrospectives, then again we talk about what comes to our mind. Whatever it is, it must be about how we as a team can improve in our work.
The last times I’ve began to send a summary of the meeting to the team afterwards. When doing that for our latest Development Team Meeting, I realized that those summaries might be interesting to other teams and people too, so that’s why I’m sharing them verbatim here.
here’s a short recap of today’s development team meeting.
Response Time Expectations
We shortly talked about expectations around getting responses on HipChat
Messages and Emails.
We all agreed, that no one should expect immediate answers from anybody, when sending them HipChat messages (not even 1-to-1 messages) or Emails. Rather everybody should consciously decide for themselves when they respond to messages when it fits their work load and -plan best.
Cognitive Bias of the Month: Planning Fallacy
We discussed the first in our series of Cognitive Biases of the Month, for which we chose the Planning Fallacy.
As reference/reading material we had:
- Eliezer Yudkowsky about Planning Fallacy on lesswrong.com
- Wikipedia on Planning Fallacy
- Jonathan Klein’s talk “Cognitive Biases in Engineering Organizations” at Velocity Barcelona 2014
The following are general comments/observations we made about the Planning Fallacy:
The fallacy is not only a problem that happens during planning, but also during execution. Because people tend to do more compared to what was originally planned. Which also contributes to the fact that tasks take longer than originally planned.
- We encounter the fallacy in our daily work in different, non-obvious ways:
- While planning our own personal work and schedule. We expect to complete tasks in a certain amount of time and may end up not meeting that expectation. This then can lead to frustration, that only stems from the fact, that we measure ourselves against irrational expectations. Which obviously is not helpful.
- Even though we don’t openly estimate work items in our backlog, we still inevitably have estimated expectations toward the duration of the tasks. Sometimes we even communicate those within the team and use them as “usual” estimates, even if we don’t accurately track the time spent on the task and reflect on how to get better at estimating (a prime example of this being the recent extraction of the web-frontend out of the backend-repo; which took way more than two days, with an initial estimate of ~1h).
- Ways around the Planning Fallacy:
- The above mentioned article on lesswrong.com uses the term outside view, which means to deliberately look at situations from the outside, with as few “internal” knowledge and details as possible. So, when planning one can take the outside view which, counterintuitively, makes an estimate more accurate.
- Another approach is to put more emphasis on past experience with similar tasks and efforts, when planning. Instead of planning efforts with detailed inside knowledge, rather base your estimates on actual time spent on analogous endeavours.
- Another countermeasure we came up with is, while working on something, to deliberately think about if one is still working within the initially planned scope, or if one silently expanded the scope.
- Finally as a rough but likely effective measure for catching yourself when falling prey to the Planning Fallacy is when you think something like: “Oh, I’ve done this before and this time I’m doing it right. It’s different this time.” Situations like this should send off a very bright and very loud red flag in you head. Put differently: You’re wrong!
Looking forward to talking more about this in the future and hearing about your experience with this bias, now that you think more about it.