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, undertood 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.

This is my summary of Niclas Nilsson and Hans Brattberg’s “The Pair Programming Show”, 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.

This session was a live play showing pair programming in action – done right, and done wrong.

My opinion: Fun and relatively well done, but pretty basic stuff. The only thing it gave me was a reminder of the different roles that the two people in a pair should have. One to focus on the small, immediate stuff; the other to focus on the bigger picture – Are we doing the right thing? Are we doing it right? Could we do something else?

This is my summary of Udi Dahan’s “Intentions and Interfaces”, 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 core design pattern: intentional interfaces. Whenever you find yourself facing a design problem, tell yourself – “Make roles explicit”.

For example, a Customer class may be used to validate a customer before persisting it, for making customers preferred, and for adding orders to the customer. Making these roles explicit, the Customer class would implement IValidator, IMakeCustomersPreferred, and IAddOrders. Now that these are in place, we may use them, for example, to implement different fetching strategies for #2 and #3 – lazy vs eager.

Another example: there might be a CustomerService class for those same three tasks. Separating out the three responsibilities, the class might implement IMessageHandler, IMessageHandler and IMessageHandler. Now that this is explicit, we may split this into three different classes, which would (among other things) allow us to have several handlers for a single message, in a pipeline.

As a rule of thumb, define your interfaces starting from use cases. These tend to be a stable foundation to build on.

Often we think one interface – many implementations. With this pattern it’s the opposite: one implementation, many interfaces.

My opinion: This session is difficult to summarize without all the examples and step-by-step reasoning, so I’m afraid the blog post won’t do it justice. I found it useful, and the reminder to Make Rules Explicit will probably lead to better design with less sprawling classes in our code.

This is my summary of Chris Hedgate’s “Effective Retrospectives”, 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.

Note: In Agile development, a retrospective is a meeting at the end of an iteration (which a period of work, usually 2 to 4 weeks) where the team reviews the iteration together, and discusses possible improvements to their process.

A bad retrospective is: ad hoc, not prepared, with no structure.

The goals of a retrospective are two:

• participation
• decide on actions, what should we change (this is what new scrum masters often focus on)

Keys:

• Facilitation = planning, leading, setting a goal. Gives us flow.
• Framing = setting up and ending, making it focused
• Structure = ensures balance, gets everyone’s input

Facilitation

• Use an external facilitator. The person leading the meeting should not have an interest in its outcome. It is difficult to lead and participate at the same time. If not possible: be very clear about when you’re leading and when you’re participating.
• Work with the energy and the dynamics of the group. Take breaks; split into smaller groups when appropriate.
• Prepare. Think about what activities to use; when and where to have the meeting; is food needed, etc.

Framing

• Modify the retrospective according to its purpose
• Define the goal and agenda
• Not every retrospective needs to be about “how can we get better”
• Try retrospectives with specific themes: QA, communication, etc – gets you away from boredom and routine
• Start with a check-in: everyone says/draws something about the iteration
• Make it safe to participate

Structure
A retrospective should have three phases:

1. What happened? Why are we here? – In this phase we share context
2. Why did that happen? – In this phase we diverge, by brainstorming
3. what should we do? – In this phase we converge again, and decide on actions

Sharing context can include:

• Looking at raw data: burndown chart, story list, bug count chart
• Creating a timeline: write post-its with things that happened and stick them on the timeline (all at the same time or with individual preparation)
• An emotional timeline (a line chart scaled simply from – via 0 to +, and everyone draws their own line between these extremes)

During brainstorming, people write ideas and thoughts on post-its.

During the convergence phase, you can cluster the post-its, vote on them, discuss them in smaller groups, etc. At the end, the team commits to actions that are

• possible
• valuable/important
• someone who wants to do it

Finally, summarize: what have we learned, what are we taking with us.

My opinion: This was exactly what I needed. Chris’s comment about how inexperienced scrum masters always focus on “what should we change” really hit home. And our retrospectives have become relatively boring. This session gave me lots of useful, practical tips. I believe our next retrospective will be much better than the last one.