What we’re looking for is a reasonably senior web developer. We’re a small software company with just a handful of developers, so we need someone who can pull their own weight, with no hand-holding or detailed management. Everyone is expected to not just code but also contribute meaningfully to discussions about design and architecture. They also need to share our values and mindset – to value code quality, maintainable code, good design.

The interview is complemented by a coding task, where I email the candidate a 1-page specification for an application and evaluate the code they send back. I therefore spend very little of the interview talking about detailed technical matters. The interview is for me to judge their aptitude and attitude at a higher level.

This is not an interview script. I wouldn’t ask these questions top to bottom. It’s more of a checklist for areas that I try to cover during an interview. This is also not a prioritized list.

For the rest of this post, “you” refers to the candidate.

1. Fit

What kind of a job are you looking for? What kind of company would you like to work for? What is important to you in your work? Why are you looking for a new job?

What I’m trying to establish here is whether the candidate would fit our firm. If they are looking for a fast-paced competitive environment, or a firm with international opportunities, they’re not for us.

What would you like to be doing in 5 years’ time? What do you enjoy most about programming? Have you been involved in requirements or testing in your previous projects?

This is to detect the wannabe project managers and business analysts, and people who are aiming for a managerial role. Nothing wrong with those, but we won’t be able to offer them a meaningful career path in our company. This is also to detect the pure programmers who have no interest in anything outside of code, who will consider testing and requirements work and usability studies to be “not their job”.

2. Passion, learning, interest

How do you keep up with current topics within the industry? Do you read any books? Blogs? Do you do any programming in your spare time? What’s your favourite tool?

Here I try to figure out whether programming is “just a job” for them, or whether they are truly interested in and passionate about writing software. It isn’t necessary for the candidate to do all of this, to read books and blogs and have hobby projects – but if they do none, it’s a great big warning sign.

3. Technical insight, critical thinking, big picture thinking

Explain the purpose of a recent project you worked on. Explain the design and the architecture. What choices and alternatives were considered? Why did you make the choices you made? What would you do differently if you had to do it again?

This separates the “drones”, the passive followers from the active minds. Even if the candidate wasn’t in charge of the project they describe, they should be aware of design choices and trade-offs.

Did you use an Agile process? What were the advantages and disadvantages? Did you use test-driven development, or unit tests or automated tests of any kind? How did that work?

If in this day and age the candidate has nothing to say about unit testing, they are not for us.

4. Some technical questions

This is a bit of a smorgasbord; I pick the areas that are relevant for the candidate’s area of strength. SQL and OOP for back-end developers and JavaScript and CSS for front-end candidates.

The home coding task tests general programming skills. Here I focus more on the specific technologies we work with. This whole area also ties in with #3, i.e. their ability to make trade-offs and informed choices.

OOP: Explain to me a design pattern that you have found useful. Why? Explain to me the purpose of the Single Responsibility Principle.

ASP.NET: Explain to me some different ways to save state between page requests. What are the pros and cons of each one? Which ones did you use in your last project? Why?

SQL: I give them an example table and ask them to write or dictate to me some simple queries against that table.

JavaScript: Explain callbacks, and why they are useful. Explain closures, and why they are useful.

CSS: Tell me about what you would use to build a page. Divs or tables? Why? How can you position a div – how can you center it, put it in a specific position on the page, etc.

5. Leadership and self-leadership

What was your role in the project? What were you responsible for? What are your weaknesses?

We need people with drive and initiative, who are able and willing to take on significant responsibility. The weaknesses question is mostly a basic indicator of self-insight.

ReQtest, the company I work for, is looking to add two more developers to our team, one for front-end work and one for the back-end. The foundation for our application is ASP.NET and C#. On top of that the front-end guy needs great JavaScript and CSS skills; the back-end developer needs experience of database development.

We’re a small and growing company so we offer lots of responsibility and variety in the daily work, and a say in just about all matters regarding both the product and the company. We use an Agile development methodology, and we value code quality and usability highly. It’s a great place to work.

Read more on monster.se: front-end developer, back-end developer.

I was going to list Ingrid’s favourites but then I realized that she loves almost all of them. Some days she plays one, then another day another app gets more time, and after a few days she comes back to the first one again.

Toca Tea Party

There’s Birthday Party and Tea Party, where you start by setting a table, choosing plates and cakes, and then proceed to eat the cakes and drink the tea and lemonade. These have great multi-touch support and work very well for several players. I believe that kids are supposed to invite their stuffed animals to the tea party but Ingrid usually plays with me instead.

Then there’s Toca Store, which is sort of similar but more clearly meant to be played together. One person takes the role of shopkeeper, the other is the customer. The shopkeeper chooses which items to sell, sets their prices, rings up the items on the till. The customer picks items to buy, counts up the coins, puts the stuff in their bag.

Of course you could play those things without an app, with actual physical items – and we have. But the app is 5 seconds away whereas setting up a tea party with real toy plates and cups takes time, so Ingrid is infinitely more likely to use the app than the real thing.

A bit similar is Toca Robot, where you build a robot by picking body parts for it. The graphics are well made and fun to look at: the robots can have arms with propeller attachments and a body like a fridge. When the robot is done you can fly it through a simple maze to pick up gold stars. Updates to the app have brought new varieties of each body part, as well as new mazes, so Ingrid keeps returning to this app.

Toca Robot

Toca Hair Salon and Toca Kitchen are two of a kind – you get some materials and can perform some actions on them. Cut, blow dry, comb, wash, colour hair; chop, fry, boil, mince food. I’ve found these somewhat disappointing – they sound like more fun than they actually are. In Toca Kitchen the choices are too limited, and they’ve skimped on the graphics: the results look dull. Frying things just makes them brownish, for example, so frying an egg doesn’t actually result in anything that resembles a fried egg. In Hair Salon the hair is difficult to control and the results are all too similar to each other, except for the colour and accessories, so what sounds creative boils down to a painting app.

Paint My Wings is actually a painting app where you paint the wings of a butterfly. The wings are mirrored, so whatever you paint on one wing also turns up on the other. There are other nice touches such as the butterflies talking to you (“that tickles!”) and using berry juice for the painting, making this a bit more interesting than just a plain drawing app.

Less open-ended is Toca Doctor which consists of a bunch of puzzles and mini-games. Ingrid liked these to begin with but they’re too simple for her now.

The building works here may be done but that doesn’t mean we’ve run out of work. We have painting to do, lighting fixtures to buy (there’s currently no lighting in the entry hall, or the stair hall, or the walk-in closet), books and bookshelves to move from the bedroom to the office/library…

This evening, after both kids were asleep and our productive time began, we got started on laying stone on the flat bit of ground between the garden stairs and the stairs to the porch. It was already paved before, but when the new porch got built, the upper flight of stairs became wider and moved slightly, so we ended up with an unpaved gap.

We chose paver blocks that come in a mixture of sizes, Fantasi Antik. We spent an hour and a half this evening designing a layout for the stones that we can live with.

Both Eric and I are “pattern people”: if there is a visual pattern, accidental or intentional, we cannot help noticing it. And if that pattern is in a place where there isn’t supposed to be one, it will keep catching our eye and irritating us. Like a visual itch. It often happens with cheapish printed products – cheap laminate flooring, fabric, wallpaper – where the pattern repeat is too short.

So we wanted to make very sure our paving is sufficiently random. In particular, no too-long unbroken lines, and no too-large rectangles of blocks. For example the long unbroken line down the middle of that marketing photo above would be a clear no-no.

It was almost like a computer game. Except with pixels of 70x70mm, weighing over half a kilogram each. And instead of trying to make order, we tried to make randomness. Sort of an anti-Tetris.

I tried a few random Wikipedia articles (a random link from the Wikipedia front page, cucumber and Georgia) and it worked in all cases. The tendency became obvious after just a few hops: we skirted linguistics, science, then information, and via quantity on to philosophy.

From philosophy it’s six hops back around to science and you can go another round. The full loop is Science > Knowledge > Fact > Information > Sequence > Mathematics > Quantity > Property_(philosophy) > Modern_philosophy > Philosophy > Existence > Sense > Organism > Biology > Natural_science > Science. So you could equally well argue that all Wikipedia queries have their root in Existence, or in Knowledge, or in Information. Whatever you think is the most fundamental of all – take your pick.

Now some developer has actually made a tool for you to try this on your own: xkcd wikipedia steps to philosophy.

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.

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.)

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.

[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.

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.

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.

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.

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.

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 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?

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.

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.

Why split user stories? A story may be too big to manage. Or different parts of it may have different value. Or some parts may be better understood than others. We’re looking for bargains: best value for least cost.

There are 4 categories of splits:

• high-level splits that get rid of lots of work
• “ilities” – non-functional splits
• UX splits – simplify the user experience
• behavioral splits – simplify behaviour

Technical splits are not recommended. Stories still need to make sense and be valuable to users.

High level splits include: research; partly manual process (instead of full automation); buying instead of building; deferring features.

“ilities” splits include: static data instead of dynamic (a “refresh” button instead of constant automatic refreshes); simplified persistence; lower fidelity; lower reliability; lower performance.

User experience simplifications include: batch processing instead of immediate response (generate reports off-line overnight); single user (instead of multi-user); API only (UI can wait); simplified UI style; a generic UI (textboxes in a grid instead of nicely aligned dropdown boxes etc).

Behavioural splits include: happy path first (ignore alternative flows and exception cases); fewer choices (0 or 1 instead of many, e.g. fonts in a text editor); base case first (wait with a more general solution); collect less data.

My opinion: Pretty basic stuff rather dully delivered. I could have just taken the one-page handout and not missed much.

There is a core in agile that is going missing now that Agile is going mainstream and crossing the chasm.

A problem with Agile is its name. Of course everybody wants to be agile. Look up the opposites in a dictionary: sluggish, torpid, immobile. Who wants to be sluggish and torpid?

So I came up with a description of Agile that is weird enough that nobody is going to immediately, before they’ve had time to really understand it, react with “oh yes, that’s me”: Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism.

1. Anarcho-syndicalism:
   • Worker self-management – no managers
   • Direct action. To take an example from the original anarcho-syndicalism, say you have a strike, and those opposing the strike are attacking you with clubs and guns. The standard approach would be to vote to elect a congressman who passes laws that prohibit violence against strikers. The AS approach is to get your own clubs and guns and protect your strikers. Don’t try to get into management to fix your problems, fix them now.
   • Worker solidarity: the team fails together and succeeds together, we’re all in this together
2. Team-scale: we’re not revolutionizing society, just helping your team
3. Artisanal: people on the team care deeply about the product and its users, sometimes more than the business. Counteracts the risk of becoming so infatuated with our process that we lose sight of our aim.
4. Retro-futurism: 1930s futurism pictured all sorts of nice things for the future, i.e. for now. Orbital cities, clean cheap urban transport, underwater cities, personal jetpacks. We didn’t really get much of any of that. The same happened with Agile. In the early days agile projects were few and far between, but everybody hoped that the idea would spread and make all developers happy. Instead we now have lots of teams doing Agile in name only. People on “agile” projects are saying “at least my job doesn’t suck as much as it used to” instead of “this is the best project I’ve ever worked on,” which is how it should be. Retro-futurism reminds people of the possibilities. Don’t accept things as unchangeable, change your circumstances to get where you want, keep that gosh-wow spirit.

To summarize the spirit of Agile:

• scrappy – we are trying to do something here, get out of my way
• care – for the product, the users, the process
• naive optimism

My opinion: Inspiring! Brian was an enthusiastic, passionate speaker who delivered a thought-provoking speech. New ways to think about old things. Conference sessions tend to fall into two categories: those where I learn new facts, and those that simply energize me and make me want to get back to work and improve everything. This is a prime example of the latter kind.

If you find this interesting, there is a bit more information at ARxTA.net, including a video of Brian delivering a similar talk some years ago at some other conference.