Thinking Fast and Slow Perspective on Stand Ups and Iteration Planning

Introduction

Recently read Thinking Fast and Slow and it made me think of daily stand ups and iteration planning

When I became a software engineer no one explained to me what the point of stand ups were. I figured it was a way for my manager to make sure I was doing my job (since measuring productivity was harder than INO french fries per minute v. LOC). I made sure to exhaustively mention everything and be sure to convince folks I was doing “the most”. Iteration planning meetings seemed like a trick to make me sign up for more work than I otherwise would do (Silicon Valley clip).

Explain stand ups and iteration planning meetings

Fast and Slow Thinking

Describe fast thinking and slow thinking. Give examples from the book. Give examples from work.

The book describes a two-system model that explains how our minds are thinking. The two systems are the fast-thinking (“system 1” in the book) and slow-thinking (“system 2” in the book).

Fast Thinking

“System 1 operates automatically and quickly, with little or no effort and no sense of voluntary control.”

Fast thinking is our auto-pilot. It operates in the background and makes hasty biased decisions in situations that require quick reactions. It is the thinking that kicks in when:

• we hear a noise behind us and instinctively duck to dodge some object flying our way

• we are asked a mechanical math question, “what is 2+2?”

The pros for fast thinking are:

• its lightning fast

• its always running

• it often makes reasonable decisions

The cons for fast thinking are:

• it can’t be turned off

• it includes a lot of bias

• if it doesn’t have the answer, it will trick us with an answer to a simpler question

Explain the bias

Explain the simpler question thing

Slow Thinking

“System 2 allocates attention to the effortful mental activities that demand it, including complex computations. The operations of System 2 are often associated with the subjective experience of agency, choice, and concentration.”

Slow thinking is our thinking cap. We have to call on it, but it allows us to make decisions when our intuitions don’t have an answer. We can feel it kick in when we are asked to, for example, do two-digit multiplication. Take a second to solve this problem in your head: what is 28 x 47? Did you hear your system 1 say, “I don’t know.” Did you feel your brain shift gears and focus on all the digits you had to store in your memory and all the numbers you had to carry over?

Slow thinking requires concentration and discipline in order to override System 1’s constant interruptions.

The pros for slow thinking are:

• it allows us to reason correct answers when we don’t know them

• overcomes biases

• repeated slow thinking can modify fast thinking (make new habits)

The cons for slow thinking are:

• we have to focus to invoke it

• it takes more time

• it is a limited resource

Explain how we have a finite amount of slow thinking we can do in a day, we get fatigued, we burn glucose.

Stand Ups

Stand ups are frequent because they are low fidelity temperature checks. The goal is to uncover any blockers that haven’t been surfaced.

Meetings have a combinatorial number of communication channels.

In any meeting there are C(n, 2) communication channels when n is the number of people in the meeting. A communication channel is just the conveyance of information between two people in the meeting. In the diagram above, there are four people in a meeting so there are C(4, 2) = 6 communication channels. Combinatorial grows real fast, so the more people you add to a meeting the more likely there is for chaos to erupt in that meeting; if you are in a meeting with 10 people, whenever someone is talking, there are 9 other people who may need to activate their channel with that person to clarify what they mean or ask some other question.
A stand up should keep the number of communication channels low. The goal in a stand up is for each person to uncover anything blocking them so everyone in the meeting should be working closely on the same projects. In the stand up you want folks to quickly determine that what they are working on does or does not have dependencies on things other folks in the meeting are working on.

This makes stand ups perfect for system 1 thinking, namely to answer three questions:

• What did I work on yesterday?

• What am I working on today?

• Am I blocked?

These are all things that a system 1 thinking can answer. Other team members can help chime in on the last question; a team member actually broadcasts that question on all communication channels they belong to at once with that question. For example, Eric could be working on the Baz API and say, I am not blocked right now which would send the “I am not blocked” message on three communication channels: Nga-Eric, Eric-Qing, and Eric-Nicholas. Each other member of the team has a brief moment use their own system 1 thinking to verify that their work is not blocking Eric. Maybe the team is silent which means as a group we agree that Eric is not blocked. Maybe Nga speaks up in response, “Actually Eric, I am making changes to the Foo framework that Baz API runs on. You won’t be able to get tests passing until I am done.” Eric figures out that he can patch in Nga’s CLs and unblocks himself and you get to pat yourself on the back for being an awesome team lead who saved a couple days’ worth of productivity.

Iteration Planning

The goal of iteration planning is to pick the best set of tasks for each team member for the next iteration. An iteration could be 1 week, 2 weeks, whatever. It needs to adapt to reality and changes since the last planning meeting; if business partners no longer want to fund the foo feature request, then continuing to develop it doesn’t make sense.

In order to pick a number of tasks to assign to an engineer in a fixed time period, we have to estimate how long each task takes; engineering estimates are hard (and often inaccurate) so they are clearly not something we want to leave to System 1 thinking. Engineering estimates are easy targets for biases. <List the biases>. For example, level setting bias leads us to give tasks the same estimate we gave last time. But we really need to look back and see, did implementing the bar API really take 2 weeks like we thought? If it took twice as long, should we increase our estimate for the baz API that is clearly very similar in scope?

Describe how iteration planning (and I guess OKR+ planning) engage our system 2 brains. List the biases we should avoid and the problems we try to detect.