In early 2010 the San Francisco Museum of Modern Art celebrated its 75th anniversary with a showcase of standout art and design. There I discovered vintage typewriters and the graphics that with them, and found I was in love. There were evocative Olivetti posters and strange, elegant typewriters from the 50s and 60s—Marcello Nizzoli designs and a fire-engine red ‘portable’ Valentine by Ettore Sottass.

Sottsas intended the Valentine “for use any place except in an office, so as not to remind anyone of monotonous working hours, but rather to keep amateur poets company on quiet Sundays in the country or to provide a highly coloured object on a table in a studio apartment.”

The Valentine was the typewriter made object of desire by pop design and inspired marketing—an association-driven name, a place on the shelves of upscale fashion houses, and a sophisticated poster campaign from the man and the company—Olivetti—who had employed writers, graphic artists, and advertising specialists from as early as 1930.

The lovely folks at the Powerhouse Museum have with them some much older specimens, among them a Blickensderfer 5 from 1893. The Blick 5 was light and inexpensive, and was the first truly portable machine with a full keyboard—an ancestor to the Powerbooks gathering in cafes from Brooklyn to Surry Hills.

As for love and typewriters, a few months later a good friend appeared at my house with a hard case of a curious shape, and with a bow about its handle. It was a dusky cyan Olivetti Lettera 32, the model that, despite the industrial good looks of the iconic Valentine, I’d loved the most (but had not said).

We love creative events around Sydney, so it was with great joy to go through the Creative Sydney 2010 newsletter which popped into my inbox this morning!

Being a mapping nut, I’m particularly interested in Networks + Clusters, and Creative for a Cause, and Technology + Behaviour for some socially-conscious food-for-thought.

Which look good to you?

Also check out Vivid Sydney 2010. Last year, Creative Sydney 2009 was a part of the same series of events as Vivid Sydney 2009, which we did the website for last year, along with our friends Toben.

Yesterday we organised another of our monthly workshops. Varied topics were presented and discussed.

• Brett presented his learning experience during his internship at the IxC.
• I presented ways for boosting one’s productivity with text expanding, apple scripts and automations.
• Thomas and Brett showcased some cool features respectively from the LESS CSS framework and Coffee script.
• George proposed ways for including javascript libraries into reusable Django applications.
• Greg organised a fun game, based on index cards and “rock-paper-scissors”-style plays, for the agile estimation of feature implementation. This is something we’re actually (seriously!) about to implement in some of our biggest client projects.

Those workshops are a great way for the team to share knowledge and good tips and to stay on the edge of all the cool things out there. We’re planning to make them public at some stage, so stay tuned!

At IxC, like in many other Web companies, we’re experimenting with all things agile. Today’s post is about one of our recent experiments concerning the way we’re using our ticketing system in our client projects.

Tickets and how we assign them

Tickets are at the core of our daily workflow. They allow us to coordinate our efforts and track our progress. However, it sometimes can be difficult to deal with their high volume (as I write we have 341 open tickets spread across 30 projects, all hosted at Assembla).

With all these tickets you can’t expect each of our staff to go through the whole list every time they are available to start working on a new task. That would be a waste of time. Instead, wouldn’t it be easier if one constantly had a pre-processed short list of things to work on? This is what we’re trying to achieve by assigning someone to every single ticket.

Two great benefits of that approach are that a) no ticket gets lost or forgotten and b) you can quickly figure out what to work on next by looking at your own short list (generally between 15 and 30 tickets at any given time). This approach also implies that every person assigned to a ticket is responsible for taking the next action and moving the corresponding task at least one step further – this can be either by writing a piece of code, answering a question, or generally making sure that the task is being looked after.

So, to sum up, our number one rule is that every ticket should be assigned to somebody at any given time. If a ticket is unassigned then everyone has the right to assign it to anyone else. Here are our guidelines for assigning tickets:

1. Every ticket needs to be assigned to the person you think is most appropriate to take the next action (sometimes this person might be you). The next action may be, for example, investigate a problem, implement some code, or answer a question. If you’re in doubt then assign it by default to the project manager. If possible, and unless it is absolutely obvious, try to write a short comment explaining why you’re assigning the ticket to that person.
2. If you create a new ticket, apply step 1.
3. If you get assigned to a ticket by someone else, and you think you’re not the right person to take the next action, apply step 1.
4. If you’ve completed the action you were supposed to do (e.g. investigated a problem or answered a question), apply step 1.
5. If you’ve finished implementing some code and that code needs testing before being committed, apply step 1.
6. If all else fails, apply step 1.
7. Otherwise, apply step 1.
8. Go to step 1.
9. If you have reached this step, you win a romantic getaway for two to the industry conference of your choice. Now apply step 1.

These guidelines ensure that project management is more or less distributed amongst all of us, at least at the micro level: everyone can focus on the tickets that they’re assigned to and that have the closest milestones or the highest priorities. There still needs to be some management done by project managers at the macro level (i.e. defining the milestones and priorities across projects) but the effort is generally much easier to bear when spread across all of us that way.

Obviously, one might think that this system has some limitations (e.g. tickets might be assigned to the wrong people, or too many tickets might be assigned to one person and too few to another). However, I’m a firm believer that all these limitations can be avoided if you organise…

Weekly and monthly ticket reviews

Agile is all about the dynamic steering of the company’s business and operations. This means that nothing is set in stone and that everything should regularly be reviewed, taking the current situation into account. This applies to tickets too, which is why each of us does a quick review of all their own tickets at least once a week.

Weekly reviews themselves are not a new idea. They have been famously advocated by the famous David Allen and his famous Getting Things Done methodology. All we’ve done is to apply this methodology to our ticket workflow – after all, tickets are just a form of todo items. These reviews, which take about 10-15 minutes, give each of us the opportunity to reassess what they should be focusing on and to make sure everything keeps moving forward.

While weekly reviews are done individually and asynchronously at one’s personally convenient day and time, we also organise larger, monthly, ticket reviews. Monthly reviews proceed the same way and have the same purpose as weekly reviews, except for a few differences, as they are done:

• Synchronously: everybody reviews their tickets during the same timeframe (about 1 hour).
• Collectively: it occurs when we’re all at the office, at the same time. Those who really can’t be at the office may participate via Skype.
• Thoroughly: an update is posted in nearly every single ticket.

The monthly review takes the form of a sprint where everybody focuses their effort on the same thing, at the same time and in the same space (whether physical or virtual). One advantage is that everybody switches to intense review mode and achieves better and quicker results than if the review was done sporadically and interspersed with other unrelated tasks. Another advantage is that it’s easy to walk across the room or chat via Skype to ask a quick question about a ticket to another person, because that other person is in ticket review mode as well. And it’s also more fun for all of its social values: “We’re all in this together!” :-)

It is worth noting that since we intentionally keep it limited to a short timeframe, we try to avoid any distractions, for example by switching Twitter off. Skype is OK. Email is OK too but only if it is to check the ticket update notifications.

For each ticket that is reviewed, one should ask - is there anything, no matter how big or small, that could be added to this ticket to help it move forward? More specifically, here are the questions that should be pondered (and the corresponding actions that one should take):

• Have I already started working on this? If so, then give a quick report on what you’ve done so far. Otherwise, say honestly if you’re planning to start working on it soon or not. If it is soon, then this would provide reassurance to the people interested in this ticket that the work is being looked after. If it is later, then potentially someone eager to get it fixed may be interested in grabbing the ticket from you.
• Was there no work done since the last update? If there’s a reason for the work not having made any progress, then mentioned what it is.
• Should I really be the person dealing with this? If not (e.g. because you don’t have time or do not have the appropriate expertise), then reassign to who you think is the best person, or to the project manager by default.
• Is it clear what it’s about? If not, then ask for some clarification and reassign to the person you’re expecting to get the answer from so that the question falls under his/her radar. That other person might be the original reporter, the project manager, an expert in the area the ticket is tackling, or sometimes even the clients if they have access to the project’s ticket space.
• Is it really relevant? If you’re absolutely sure that it’s not (e.g. the bug is not reproducible any more, or the feature request has been dropped), then explain why and close as invalid. If not entirely sure, ask and reassign to the original reporter or the project manager.
• Has it already been fixed? If so, then close it as fixed and, if possible, give a link to the changeset or explain when and how it was fixed.
• Is there any caveat that people who may be interested in this ticket should know about? If so, then say it! It is useful to write it down for yourself and for others so it won’t be forgotten when someone starts working on this again later on.
• Does something need to happen before I can start working on this? If so (e.g. another bug needs to get fixed, or some info needs to be provided), then say it, and possibly reassign the ticket to the person who should actually take the next action. Also use ticket relationships (e.g. parent, linked) if there are any.
• Has the ticket now become a high (or low) priority? If so, then change the priority.
• Should the ticket be attached to a different milestone? If so, then change the milestone.
• Is there any general useful piece of information or advice that I could share here? If so, then say it! The more relevant information is provided, the better.
• Is there really nothing to say at all? If so, then that’s cool. But are you sure there’s really nothing to say at all?

Generally it is great to say something, even if it is really small and apparently insignificant at the time. The ticket may remain open for a long time beyond that point, and you (and everybody else) will likely be very glad to have access to all those pieces of relevant information when the ticket is worked on weeks or months later.

Results of the experiment

Ten of us gathered last week for our first monthly review and it has been tremendously productive. 45 tickets were closed (some had become irrelevant, some had already been fixed and others could be fixed right on the spot), 8 new tickets were created and a total of 250 ticket transactions were recorded.

After this first experiment we have already observed the following benefits:

• Increased confidence that we’re on top of things – Everybody gets a general awareness of where things are at, what the new priorities are and what we need to focus on.
• Better assessment of everyone’s workload – People realise if there are too many or too few tickets assigned to them.
• Reassurance that each task is assigned to the best person available at the time – The person assigned to a ticket is (hopefully) the most able to take the next action and take the work further. If not, then the review is a great opportunity to make sure the right person will actually get assigned to the task.
• Elimination of irrelevant tickets and refresh of all the stale tickets.
• Overall reduction of the time spent in project management since the system is more or less self-sustained.

This approach probably would not suit large open source projects but I think that it suits client projects really well. It does require some rigour but the results for us so far have been very positive. I’ll post again later on this topic to report on how it works out in the long term. In the meantime, let us know what you think and if you apply similar methods in your workflow!

Last week we launched an extension to Australian Screen Online. As well as video titles, it now includes sound titles, including music, speeches, radio and poems from the National Film and Sound Archive’s Sounds of Australia Registry of Recorded Sound.

Discover the Sounds of Australia collection or view the official announcement on the ASO blog.

First of all, let me say that I represent the least-expert view here at IxC regarding programming! But newbie or not, coding in Python has been such a breeze in contrast with my previous experience with mostly Java and PHP.

It’s already been discussed on the interwebs, with most agreeing that:

• Types: Java makes you define a type for everything, but Python doesn’t force you to declare types; instead, they are dynamic. This also means no class-casting when you have things in lists.
• Compile: Java has a compile-step, Python just runs. The interactive shell also makes testing mini-bit of code so easy and effortless.
• Tabbing: Java = curly braces and semi-colons. Python = indents. Not only does indenting make documentation of structure completely implicit and painless, it also means there less code to do the same thing. (Amongst lots of other things).

Positively The Most Exciting Thing I’ve found with Python versus Java is the dictionary. Oh! The joy of being able to do this:

cupcake_ingredients = {"flour": {"cups": 2.5},
"butter" : { "grams": 200 }, "caster sugar": {"cups" : 1 },
"eggs": { "" : 3 }, "milk" : {"cups": 0.5 } }

Contrast this to Java’s HashTables (or HashMaps, or other Dictionary objects), which would take way too long to define that nested HashMap.

Anyway, this is just a very small snapshot: you’ll see the more thorough and expert discussions linked above.

At the end of the day, Python has been very easy to pick up; it’s intuitive and logical, which then makes it really easy to read existing code, and doesn’t take as long time to type out as Java would! This means development time is faster, bugs are easier to fix, and collaboration has a very sound platform to launch from.

Apart from GLAMkit, we have rarely mentioned our open-source projects. I wanted to quickly show three which were recently open-sourced by IxC contractors in the course of their work for us:

django-nose-lite, by howthebodyworks - a lightweight nosetests runner for Django projects. My favourite is to run it with —pdb, which drops into pdb on test failures.

django-smuggler, by semente is fairly simple. It adds a button to Django’s admin interface which dumps and loads fixtures to your (local) computer - for superusers only.

django-hashtags, also by semente, converts Twitter-esque #hashtags in text fields into a link to search for items with those hashtags - recent tweets included.

Feel free, of course, to reuse, fork and contribute changes. There are more releases in the works.