All posts by Antti Sulanto

About freedom of choice

In Finnish(*) there is a phrase which actually carries plenty of wisdom:

Nothing is mandatory except death and taxes.

Let’s first imagine something you’d rather not do, but someone is insisting you to participate. Take Christmas shopping for example. Your significant other would like you to join her in hours of wandering in crowded department stores, but you’d rather stay home in your pajamas and play Xbox.

Basically you have four different approaches:

  1. You go shopping, but you feel resentful and irritated. “Here I am, in this hullabaloo, even though I don’t want to, I don’t deserve this.. let’s go home already…” 
  2. You stay home playing Xbox, but you feel guilty and perhaps ashamed of yourself. “Here I am, kind of enjoying, but hey, I should be shopping… now I don’t have present for my godson… and my partner is probably angry at me..”
  3. You choose to go shopping, but not out of guilt, but perhaps because you want to spend time with your partner, and to attend to her needs of companionship and doing things together. Maybe you go shopping because you choose that your desire to buy a present to your godson is greater than your desire to relax on the sofa.
  4. You choose to stay home playing Xbox, but just because you chose to be honest to your need to relax. And at this time it was greater than your need to attend to your partner’s needs. Not because you have somehow deserved it or because your partner “doesn’t have the right to insist me to go shopping”.

At this point you probably know where I’m going with this. Whatever you do, choose either approach number 3 or 4. It may seem like a small thing, but the difference in attitude does have a big impact on your mood. And at the same time you’ll be more honest to yourself and the people around you.

The liberty to choose goes to all aspects of life. You don’t need to work for that stupid boss. You may choose to do so, but perhaps because you need the money. You don’t need to give your child a car ride to hobbies every night, but perhaps you choose to do so because you don’t want her to walk alone in the dark. Etc etc.

I know this is easier said than done, but it’s worth a try to change the attitude.

(*) And originally Benjamin Franklin said: “[…] but in this world nothing can be said to be certain, except death and taxes”

What is scope (baby don’t hurt me)

The other night in a pub, Neil and I (and @karhatsu ) had an interesting chat about what does “scope” mean. We kind of disagreed then and I think we still do:

Maybe it’s just semantics or because I’m not a native English speaker, but I don’t agree. Let’s dive into this a little bit by first exploring the most common use case of that term: “X is out of scope“. So what does it mean when you say that something is out of scope? To me, X in this sentence is:

  • A feature (“supporting single sign-on is out of scope for now”)
  • A hardware change (“hardware changes are out of scope for you guys, they’re handled by the HW team”)
  • A certain testing type (“I’m not doing performance testing yet, it’s out of scope for this story”)

Then again, when I hear “amount of work”, I’m immediately thinking hours or days as the unit. Amount of work could be 16 hours or 2 weeks for example. But, in my opinion it’s wrong to say that scope = amount of work. There is a correlation between the scope and the amount of work needed to deliver that scope, but they’re not the same thing.

scope

 

This image above tries to illustrate this difference. We have a “fixed scope” in our naive book store example but different amount of work needed between the two teams. You could also imagine that the amount of work needed to deliver that scope is variable to a single team as well.  Team A could reduce the amount of work needed by making the process better etc. You know, the usual inspect and adapt, but that’s not the point of this post.

So what, one could argue. Well, maybe it’s just semantics, but on the other hand it’s easier to communicate if the community shares same terms and concepts. At least I’m still going to be on my toes when discussing “scope” with Neil. =)

Do we need Scrum Masters?

Let’s first revisit what the Scrum Guide has to say about Scrum teams and Scrum Masters.

[…] Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. […]

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. […]

If you’re doing Scrum by the book, the Scrum Master isn’t part of the team, but stands between the outside world and the team. I’ve always found this a bit odd. When I’ve been working as Scrum Master, I’ve always wanted to take part in the development and be part of the team.

In my opinion, Scrum Master capabilities are part of that “competencies needed to accomplish the work”. In the team there should be someone who is naturally interested in agile stuff. Someone who is generally interested in continuously improving the workflow and promoting agile values around him/her. Someone who would be doing scrum mastering even without having an explicit role.

Not everyone has to be heavily interested in soft stuff. The team benefits if there are members with diverse interests. Perhaps one server admin guru,  one front-end wizard, one math expert with algorithm experience — whatever is needed to accomplish the work.

So let’s assume we have perfect set of capabilities in our team. That team has needed capabilities and intrinsic motivation to get stuff done.  Leadership emerges as it’s needed. In these kind of teams we don’t need labels — we don’t need Scrum Masters. Or technical leads. Or server architects. Or … Product Owners?

On the other hand I can come up with reasons to have assigned Scrum Master for the team:

  • If there is no assigned person to fulfill a certain role, groupthink might happen. Difficult questions might not be raised or group handles them ineffectively while trying to avoid conflict.
  • In practice there are always gaps in the team’s competencies. If no-one is interested in process improvement, how does the leadership around that area just automatically emerge? Some issues may not even be handled at all, since everybody assumes that it’s someone else’s responsibility. And nothing happens.
  • It’s might be easier for outsiders to find correct person to talk to. I need to talk about features… I go to PO. I need to ask about sprint reviews… I go to SM.

To conclude: We don’t need Scrum Masters. We need someone (or multiple persons) who has got intrinsic interest in people and process. However, if someone likes to call that person a Scrum Master, that’s fine.

PS. I prefer to call myself Scrum Shepherd. IMO it’s more descriptive. =)

The reason why you should have picture of a sunset as your desktop background

Back to kitchen psychology!

There was a group of psychologists (*) who conducted an experiment on a group of people. The participants were divided into two groups and they had to play a game (rules irrelevant here). Group A played the game in a room with a briefcase and a fancy business pen. Group B had neutral items in their room, like backpack and a wooden pencil.

Results? Group A played the game in significantly greedier and competitive way. They were merely exposed to “business items”, which affected their thinking unconsciously. When they were asked why did they played the game the way they did, they made up an explanation and believed it was true.

Pretty amazing and also scary. I guess this is why advertising works.

So how does this should affect you? Firstly, I would suggest being exposed to end users as much as possible. I guess it might trick your brain into thinking their needs, even though you would maybe just see them passing by. If you ever have seen those standing real-sized cardboard user personas, they might do the same trick.

Secondly, even though you can’t prime yourself consciously, you might consider surrounding your life with people and items that supposedly create positive rather than negative primings. Soothing desktop background image, clean desktop, being nice to each other… I know that sounds awfully tacky, but hey, I’m allowed to be tacky in my own blog!

Thirdly, when creating presentations, you can slip in slides that contain subliminal messages. For example if you’re presenting something to your boss, you can add words like RAISE, MORE MONEY, PROMOTION there. Just remember to show those slides just like a couple of milliseconds so that your boss doesn’t realize he saw those slides. Profit!

Ok, the last one was a joke. Kinda.

(*) 2003 Kay, Wheeler, Barghand, Ross. Sorry no proper reference.

Reasons why I like end-of-sprint Retrospectives

There are people who think that retrospectives should be stopped. I guess the idea would be to have continuous reflection on work processes, in the same way that daily meetings have continuous reflection on the product itself.

I think we should have both. If you have a rock in your shoe, you just remove it. You don’t need retrospectives or reflection for that. If something bugs the team’s work process, just change the process.

On the other hand, I like the idea to have a retrospective at the end of each sprint for the following reasons:

  • For some changes it takes sprint or two to see if it works or not. If you keep changing too rapidly, you might not have big enough sample to really know if the change is needed.
  • People like predictability. As a scrum master I wouldn’t want to shout “hey, let’s have a 15 min extra reflection!”. There is a time and place for people to bitch about the process and make some changes. During the sprint people can expect just to deliver kick-ass software.
  • I prefer to have sprints ending at Friday, and have a retrospective on afternoon. I like the idea of cleaning the table, perhaps even let some steam out, perhaps have a beer afterwards and then starting a fresh new sprint on Monday.

The way I see it, a sprint is lot like a hockey or football match. During the match you concentrate on the game, maybe do some small tactical changes.  After the match there is time and place to watch the game video and make larger changes.

 

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 😉

http://www.pyha-luostovesi.fi/galleria1.htm
http://www.pyha-luostovesi.fi/galleria1.htm