My first day back at work. It wasn’t a good day for going back to work: Adrian’s teething cough transformed into a plain and simple cold during the weekend and he was feverish and unwell all day yesterday. Neither of us got much sleep during the night. And he was totally not interested in food and just wanted to nurse, so I left Eric and him with a bottle and a heavy heart – and hurried back as soon as I’d finished my half-day of work.

In the end they managed pretty well of course, and Adrian had accepted the bottle, but he was happy to nurse when I got home.

At work I spent most of the day getting my new computer up and running and installing Windows. Installing stuff is, I think, my least favourite task at work. I’d rather scrub the kitchen than battle with network card drivers or look for the right download files on MSDN. A gazillion flavours of Windows 7, all of them with long names that look almost identical at a glance, so finding the right one is a real chore.

By the time I left the office my lower back hurt. Even though I only worked a half-day, and I do not sit still when sitting in front of a computer. I am just not used to this much sitting any more.

I had also forgotten that it is a good idea to bring something to read on the train.

Ingrid uses me as a random number generator occasionally, although she doesn’t of course know that that’s what it’s called. “Gold star or gold heart?” she asks me, or “Dora or Bolibompa?” – and then makes some sort of decision based on my answer. Last time I think it was to decide the order of eating her breakfast.

Ingrid is good at keeping Swedish and Estonian apart. When she mixes, it’s mostly semi-intentional: if she doesn’t know the right word in one language, she may borrow from the other.

But then there are some cases where she’s picked one word and keeps using it in both languages, even though a word with the same sound exists in that language and means something completely different. She does it very thoroughly and uses the grammar of the “surrounding” language, which makes it sound even more surreal, and even harder to figure out unless the listener knows both languages.

Thus, we have doppa (to dip) in Swedish – often used at mealtimes because she likes dipping bread in soup, dipping pasta in ketchup, dipping carrots in milk etc. No matter how many times I refer to it as “sa kastad” in Estonian, she keeps saying “ma topin”, which means “I’m stuffing”.

Sticking/piercing (as in sticking a needle in something) is called torkama in Estonian. Ingrid keeps saying torka in Swedish sentences, too, but torka means to dry in Swedish. So when she wants to say “I want to stick the potatoes” (to see if they’re done) she says “I want to dry the potatoes”.

A mug is called kruus in Estonian, and Ingrid keeps calling mugs krus in Swedish, too – “pappa kan du ge mig den blommiga krusen”. But krus in Swedish means ripple, crimp, although there is also an older word meaning large jug. An arrow is called nool in Estonian, and Ingrid uses that in Swedish, too (“vi ska gå dit nålen pekar”), but nål means needle in Swedish.

This is sort of funny to hear, but it is also interesting to observe, because in most cases, when I think about it, the words may mean different things in the two languages today, but they probably share a common root and origin. Needle / arrow is an obvious pair, mug / jug likewise. The Estonian language has gotten a lot of words from its various Germanic neighbours and conquerors, and it’s interesting to see just how deep such loans go, how common and quintessentially Estonian the words now feel. (The homophony of pierce / dry, however, looks to me like a total coincidence.)

While I was away in Estonia, SIFO (a Swedish polling / market research firm) sent me their Sverige Nu 2010 questionnaire (Sweden Now 2010). A few days ago I finally finished filling it in.

Filling in the questionnaire took a while – the questionnaire is 40 pages, all of them packed with checkboxes. There are so many boxes it becomes physically tiring to check them. Not all of the boxes need to be checked, of course, but I counted 87 checks on the center spread, which is reasonably representative of the whole thing.

I like questionnaires. I like seeing what kind of questions they ask. What is important to these people? What do they care about? And I like answering them, because I think in many respects my answers are different from the average respondent’s. I feel like I provide some balance and perspective to their data.

In this case, the focus of the questionnaire was on two things: what do I consume (and what could I be induced to consume), and what does my media consumption look like. On the whole, I got a distinct impression that this data will primarily be used by all kinds of firms to plan their advertising strategies.

How much do I earn? How much do I spend on clothes? Which hobbies do I have? What capital goods do I have in my household?

The categories for my spending were a bit odd: very detailed in some cases and yet not comprehensive. But when seen from an advertising angle, the questions all started to make more sense.

(First they ask me how much I spend on women’s clothing. Then two rows further down they ask specifically about underwear. Or, to take another example, there are separate categories for each of wine, spirits, and beer, and a category for weight loss products – but none for food, or household products.)

Which newspapers and magazines do I read? How often do I watch TV? Which channels? Which programmes? Which time of the day? Which Internet sites do I visit? (Some of this was spectacularly boring to answer. I watch no TV, I read a single Swedish newspaper and a single Swedish magazine, and visit almost no Swedish web sites. Swedish ones were the only ones they cared about, and a few large sites like Google and Facebook. Swedish companies aren’t going to advertise in the Economist or on NYTimes.com after all.

There were also some questions specifically about my opinions about advertising – what are my views on ads on TV, Internet, radio; do I open unaddressed mail, etc.

The other interesting thing about this questionnaire (apart from its unstated and yet clear focus on advertising) was its unevenness.

Some questions are very broadly applicable and SIFO will likely be selling those data to many of their customers. Other questions appear to be included by request of some specific company. (“How often do you visit Casino Cosmopol?”)

The questions appear to be designed by different people, with no one person responsible for co-ordinating the entire thing. Many questions have a scale of responses: how often do I do something, or how much do I spend on something. The questions will naturally have somewhat different scales – some things you do frequently, others less so. But the scales sometimes differed in detail when the overall range was similar. E.g. one question might have the alternatives “never, a few times per year, a few times per quarter, a few times per month, every other week, every week, daily / almost daily”, whereas another would have “never, a few times per year, a few times per quarter, a few times per month, 1-2 times per week, 3 times per week or more”, and a third would have the same as the second but add even more detail at the end. A few more hours of work would have made the whole questionnaire easier to use. At least they had a clear layout guideline – the smaller amounts always came first.

Some questions had noticeably badly designed response ranges. “How many times have you used the following sections of the Yellow Pages during the last 12 months? None, 1-2, 3-4, 5-6, 7-8, 9-11, 12-14, 15-19, 20-29, 30-49, 50+”. Who could possibly recall if they opened the Yellow Pages 6 times or 9 times in the past year? It’s going to be pure guesswork, and not very reliable data.

This is my summary of Nathaniel Schutta’s “Making web apps suck less”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

[various examples and illustrations of bad usability]

What does usability include in web apps?

• Learnability
• Efficiency
• Memorability – how easy is it to pick up an application again after a few months’ absence
• Handling errors
• User satisfaction

How much should you focus on each of these? As usual in software development, the answer is “It depends”.

• How many users will the system have?
• How often will they use it?
• Will they get training?
• Do they have alternatives to using your application?

How do you find usability problems?

• Ask users
• Watch them
• Try doing it yourself
• Just as comments are a code smell, (the need for) documentation is a usability smell. Warning signs include post-its stuck to the screen, looking things up in the manual.

Paper prototyping is a powerful tool for evaluating usability. Test them with actual users!

My opinion: A good intro for those who have never given usability much thought. Luckily we’ve come a bit further than this with our application.

This is my summary of Brian Marick’s “Seven Years Later: What the Agile Manifesto Left Out”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

The Agile Manifesto has an outward focus: it tells the business how the development team will work with it. What it does not talk about is how the team must work within itself and with the code.

What should the team keep in mind?

• Joy
• Naivete: ignore the people and books who say that it’s impossible
• Ease: tools should work as if they are a natural extension of your hand. Pay attention to what it feels like to work. Spend time fixing the annoyances.
• Reactive: ignore the future. Don’t back up – change your course forward instead. This forces you to make your code easy to change.

Being wrong: is an opportunity to learn.

My opinion: Nice words and nice thoughts, but what do I actually do with them? Less inspiring than Brian’s first talk at ScanDevConf; rather vague and fluffy.

This is my summary of Thomas Lundström’s “BDD approaches for web development”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

Development should start with user stories.
Then break these down into acceptance criteria:

• Given «situation»
• when I «do this»
• then «this happens»

This should be done before the sprint planning meeting. Know what you commit to!

The rest of the session was a demonstration/walkthrough of automated BDD.

My opinion: The non-automated part of the session was a somewhat useful recap of BDD. The automated example involved, as usual, an extremely simple application and extremely simple user stories. While I understand that it will work in that case, I have great difficulty envisaging how we could possibly use it in our system.

This is my summary of Diana Larsen’s “Creating a Climate for Project and Team Success”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

What is a team? A group of people with…

1. a common purpose, understood and committed
2. interdependent work and skills
3. a shared approach to this work
4. joint accountability
5. small size
6. a mutual history (at day one, you are not yet a team)

How do you achieve these? What do these imply?

1. A project kickoff, project charter; reminders and mini-re-kickoffs
2. Think about what skills are needed before you select people for your team
3. Have a working agreement – “we aspire to work this way”. Make implicit norms explicit.
5. If the team is too large, it will break into sub-teams.
6. Common adversities and successes; stories to tell about the team; knowing each other.

My opinion: Basic stuff. I guess there are groups out there that need these tips but they were not of much use to me.

This is my summary of Henrik Kniberg’s “Kanban and Scrum – making the most of both”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

A supershort summary of Scrum:

• Split your team into small parts
• Split your product into small parts
• Split your time into small parts

… i.e. instead of a large team working on a large product for a long time, you have small teams working on small pieces of the product for short periods of time.

Kanban is:

• a signalling system
• with visible indicators
• that are limited in number.

Kanban in software development includes:

• visualizing the workflow (with columns on a whiteboard)
• visualizing the stuff in workflow
• limiting work in progress (WIP)
• measuring and optimizing flow
• explicitly defining your policies – the definition of done, WIP limits etc

How do the two differ?

• Scrum has more rules than kanban. On a scale from prescriptive to adaptive, the order would be
  RUP > XP > Scrum > Kanban > do whatever works.
• Scrum defines roles while Kanban doesn’t. In practice they might look the same.
• Both are empirical and measure things (velocity, lead time, quality etc). Kanban gives you more knobs to twiddle to change the outcome.
• Scrum has one cycle: planning and committing, releasing, and retrospectives, all three are done on the same cycle. Kanban does not tie these together; you could have a different cycle for each one.
• In Scrum, items must fit within a sprint. Kanban allows long-running tasks, limited only by WIP limits.
• Both limit WIP. Scrum limits by velocity, per time; Kanban limits by column in the workflow.
• Scrum discourages mid-sprint change: “We want to work in peace and quiet for a few weeks”. In Kanban, you just need to wait for a slot to become available.
• In Scrum, the board is reset between sprints. In Kanban the board has a long life. Scrum gives you closure and a feeling of success, but also some waste.
• Scrum prescribes one team per board, cross-functional. Kanban is more permissive of specialist teams.
• Scrum prescribes estimation and calculating velocity. In Kanban both are optional.

For more information, read the free PDF minibook.

My opinion: Well-structured and informative. I’d been curious about Kanban, wondering if it might be worth trying instead of Scrum (which we use now). After this presentation I have a good grip on the differences between the two and know that Scrum suits our needs better.

This is my summary of Diana Larsen’s “How Can You Manage New Organizations in an Old Way?”, which was the keynote speech for day 2 ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

The short answer is, You can’t.

Before discussing the differences between the old and the new, it’s useful to remember that the “old” way of work, command and control, has only existed for the past 80-100 years.

Now the old kind of work is being replaced by knowledge work, where the workers know more about their job than their manager does. The old kind of management no longer works.

Old management activities are: planning, organizing, budgeting, monitoring, directing, supervising, evaluating, controlling, commanding.

New management: managers focus on flow, people and value, and continuous improvement. Their job is to enable and facilitate.

New management activities include mentoring, mediating, protecting, advocating, acquiring and allocating resources, tracking and reporting metrics, supplying a good work climate, supporting learning, improving systems.

The people working are affected by the system they work in, and that is the reponsibility of management. Behaviour is a function of person and environment.

My opinion: This all seemed pretty self-evident to me.