Monthly Archives: October 2013

Scrum Master? Transponster?

I love Friends. In one episode there is a scene where Rachel and Monica are competing against Joey and Chandler. If they know Joey and Chandler better than vice versa, they get rid of the duck. Or win the apartment. Don’t quite remember. Anyway, there was one question that I find especially funny:

Ross: Correct! What is Chandler Bing’s job?
Rachel: Oh! Oh gosh, it has something to do with numbers.
Monica: And processing!
Rachel: Oh, well… and he carries a briefcase!
Ross: Ten seconds. You need this or you lose the game.
Monica: It’s, um, it has something to do with transponding.
Rachel: Oh, oh, oh, he’s a transpons… transponster!
Monica: That’s not even a word!

I sometimes feel like Chandler. Hell, it’s hard even for me  to describe what do I do for living. So I decided to gather different kind of activities from past few weeks. As background information, my role is Scrum Master in a team which is building software(*). Half of the team and PO are located outside of Finland. So this is what I do:

  • Have one-to-one video calls with PO about XX
  • Have an initial planning session where we select a baseline story for estimation and arbitrary story point value for that
  • Have planning sessions with smaller groups of people
  • Have a three-way session where we try to solve a technical problem that one person is having
  • Create a single-pager about the sprint goal and stories and attach it near team room door
  • Create tasks for a user story with a smaller group of people
  • Go to Verkkokauppa to get a team room TV, conference microphone etc.
  • Going through backlog and modifying user stories by myself
  • Code a new feature
  • Create unit tests
  • Peer review other team member’s code and documentation
  • Preparing for sprint planning meeting by going through the assumed user stories
  • Write and update a bunch of confluence pages
  • Ad hoc discussions about testing in our project
  • Getting familiar with Git and bunch of other technologies
  • Ad hoc discussions about application architecture and technology choices
  • Have daily standups
  • Have knowledge sharing session where we go through one person’s code
  • Writing instructions about JIRA usage
  • Preparing for sprint review session
  • Facilitating sprint review session
  • Having a sprint retrospective with the team and coming up with a bunch of improvements
  • Participate in session where we go through user personas of the product we’re building
  • Have sprint planning meetings
  • Have sessions about the user interface of the product
  • Have Scrum of Scrum’s meeting
  • Participate on other team’s sprint reviews

…and most likely something that I cannot even remember. So based on this list my job is to talk with people and occasionally produce some code. We’re in quite early stages of the project, so if I would write this list in 6 months from now, the list would probably be a bit more compact.

*) Gosh this is boring as I cannot really tell what we actually are doing. Oh well, at least I can come back to this post after a couple of years to refresh my memories!

PS. Here is a totally not-related nice picture from Pyhä-Luosto 😉

The reason I don’t like #NoEstimates

Based on the first post of my blog one could think that I’m a strong advocate of estimating.  I don’t blame anyone who does, since the title was little provocative and exaggerated. But I don’t have any strong feelings about estimating — the reason I wrote that post is because I have negative feelings towards single-issue groups and hype.  Not just in the field of software engineering but in general, too.


What is common with the above listed(*) items is that they imply that thing X is categorically bad and you should get rid of it. I have one thing to say about that:

Bullshit. It all depends!

It depends on the problem domain, product, organization, team, stakeholders,  process, “agileness” of the people, phase of the project etc etc. I even claim that waterfall model would be perfectly suitable in certain situations and projects.

So, while I agree that planning and estimating are very common areas where there is waste and frustration in projects, I don’t like how that idea is represented and marketed. I say marketed, because the people that seem to be most loud about #NoEstimates seem to be people who get paid for talking, not walking.

(*) I’ve just heard of the first one, made up the rest of them. But if I had to guess, the next hype would be about product owners being evil and you shouldn’t have them. #NoBacklog would be my second guess.

How to deal with angry people

So we continue with kitchen psychology. This post is a sequel to this post.

brainThat is the human brain. Yes it is. Roughly it can be divided into three areas:

  1. Lizard brain. Handles the most primitive needs, like being angry, hungry and horny.
  2. Limbic system. Emotions and feelings.
  3. Neocortex. High level thinking, speech, logic.

As I said in the previous post, the lower levels of the brain get priority over the higher parts. So if you’re hungry and anxious, you can’t just think straight, let alone solve complex problems.

So lets imagine a situation:  you have a meeting with a client. When he arrives to the meeting, it’s obvious that he’s in a bad mood. He’s clearly upset about something. (You can replace “client” with wife or husband coming to home.) There are a lot of things you can do, but I can tell you what not to do: whatever the problem is, don’t try to solve it for him. Solving problems requires the neocortex of the brain, and because this person is all “limbic”, he can’t think logically. It’s not his fault, that’s just how the brain works.

As an engineer is tempting to try to solve the problem, but chances are that you make things even worse.  The same goes when you’re self upset about something. For example, you’re trying to solve a problem that should be easy. But you just can’t figure it out and you get frustrated. At this point there are two primal reactions that are natural to us:

  • Fuck this! Why can’t I solve this stupid thing?! I just try harder graaaaah! (Fight)
  • Ah nevermind fuck this I quit I’m bad at everything screw this why did they ever hire me.. (Flee)

Either way you probably can’t solve the problem at hand. Your neocortex is shut down because you’re having an extreme limbic reaction. So what to do then? The main idea is to get away of the limbic reaction. Here are a couple of things to try:

  • If you notice that you self are frustrated/angry/upset: don’t fight it. Take a break, have a snack, go to a walk. Say aloud “I’m frustrated”. Even that helps.
  • Angry client/wife/child: don’t try to solve their problems. Help them to express their feelings. “Are you upset because XX?” and then just listen them ranting. Don’t say “What’s the matter with you?” because that’s an open invitation to a fight.
  • You get pissed at someone because he jumped the queue / almost crashed you in the traffic / any other reason:  try to think yourself in the other person’s position. Maybe he’s in a hurry because his child got to a hospital? In reality he might just be an asshole, but thinking the best of him helps you to calm down.

Here’s the tricky part: At first remembering all this requires the neocortex, and by now you know what happens to the neocortex when you get upset. I personally suck at this, but I guess what can be done is to practice and practice, so that little by little these behaviors become natural to you, so that even in “limbic crisis” you can act by them.

Don’t step on my scarf

Imagine yourself trying to remove a CD from its plastic wrapper. You just cut your nails and there are no scissors nearby. So almost a mission impossible. Then someone comes to you, blurts “let me”, takes the CD away from your hands and opens it. Problem solved, CD removed from its evil wrapping,  everything is fine, right? If you are like most people, probably not. You feel irritated.

I’m going to tell you why.

To put it short, in addition to scanning the environment for physical dangers, our brain is also constantly observing the social environment around us. A “social threat” creates same kind of fight-or-flee response as a physical threat. I guess this is because our ancestors had not only to dodge the attacking mammoths but also to get along with the tribe. And getting along with the tribe requires reacting to social threats.

These social threats (and rewards), can be divided into the following domains: Status, Certainty, Autonomy, Relatedness, Fairness. SCARF. This stuff is being handled by the limbic system, a.k.a. the lizard brain, so we can’t turn this off.

Status is our relative importance in a group. Pecking order, if you like. Our brain is constantly figuring out what is our status in any human interaction. Status can be threatened easily when giving instructions or advice too easily, or hinting that someone is ineffective in his task.

Most arguments start when someone hurts one’s status, which creates a fight or flee response. Especially in internet forums it’s so easy to fight that the result will nearly always be a battle for status.

Our brain likes to know what happens next. It hates uncertainty. We don’t like going to a meeting without an agenda, not just because it might be waste of time, but because we don’t know what is going to happen.

One of the good sides of Scrum is that it brings a lot of certainty to developers’ heads. There are clear roles, meetings have a clear purpose and sprints are protected from sudden functional requirements. (Sidenote: not going into detailed analysis of school book Scrum and its problems here.)

We like to be in control, or at least have an illusion of it. Classic example of threatening autonomy is micro-managing — telling people what to do instead of letting them decide themselves what to do.

If you’re helping a co-worker, try not to threat his autonomy. Instead of intruding by saying “let me help”, ask “do you need help?” or “You seem frustrated, do you want to talk?”. This way your co-worker gets to choose if he wants help or not, and his autonomy isn’t hurt.

This is our perceived feeling of whether we’re “out” or “in” the group — sense of belonging. I think this is why we feel so bad if someone doesn’t get our joke. Or just doesn’t understand what you’re saying.  In a way you feel that you’re out of that mini-group, and this causes threat to relatedness.

Our brain likes fairness. Sense of unfairness activates the same part in brain as when we feel physically disgusted. If your co-worker gets “unfair” promotion, you feel like you’ve eaten spoiled food. Yuck.

Being aware of this stuff helps you understand the situations where you get irritated and upset. And more importantly, you can do your best to avoid stepping on someone else’s scarf. And if you happen to be a Scrum Master, you should look after your team scarf.

And here’s perhaps the most important part: if any one of those five areas is threatened, your capability to think reduces significantly. Your prefrontal cortex gets second priority because the limbic system is handling with primitive threats.  There was a study where two groups had to solve a labyrinth, group A had just the labyrinth in their papers, group B had the same labyrinth, but in addition a picture of a spider in the corner of the paper. Group B solved the labyrinth slower, because just the picture of a spider triggered a threat in their limbic system, which hindered their thinking.

If you’re interested, here’s the scientific article about SCARF.  For example I didn’t cover any of the reward side of the SCARF. And I have to mention that this post was greatly inspired by this great two day course. It’s worth the money.

PS. If you read this far, you probably can guess what irritated you when opening the CD wrapper —  most likely your autonomy was hurt, maybe even status as well.

We need estimating!

#NoEstimates seems to be the thing  to practice if you want to be The Cool Agile Guy in 2013. For example Henri Karhatsu has written a great article about estimating and how they ended up in #NoEstimates.

Don’t get me wrong. Most of the posts written about #NoEstimates are solid, golden stuff. It’s just that they quite often miss one quite important perspective:

Estimates = bad. Quite often misused.
Estimating = (usually) good! Can also be misused.

estimatingWhat do you do when you estimate? You create mental models of the possible solutions in your head. You notice too large entities and break them down into smaller pieces. You think about possible pitfalls. Which tools to use. External interfaces. You know, the usual stuff that matters.

I’d like to think that the time spent to think about these things isn’t going to waste.

So if you think about it, estimates are just a by-product of an important process — estimating. You can call it grooming, if you like. Or whatever substantive that best fits your organization. If estimates are required by your boss/organization/PO, just make the journey to estimates worthwhile!

Using the estimates as the basis of decision making is a whole different story, which I don’t dare to cover.