The Conference Archive is a small application, written in Ruby, running on “the Cloud”. I hope people attending Agile2012 check it out often after the conference is over, and attendees of past conferences too.
The app is meant to be, well, agile – a minimal feature set, a design responsive to future changes and feedback from users. There were a few judgment calls there too, between including features that were not strictly necessary but that were fun to do, and excluding features that made sense but didn’t really justify the design costs.
An example of the former is the “Related sessions” feature, which for the session you’re displaying shows other sessions that share a similar set of keywords. This was basically an excuse to play around with some advanced features of the full-text search engine powering the app.
But it obviously had some immediate practical applications – for instance, if you’re wondering about a session you might like to attend this year, but confused about what the topic is going to be, you can check out similar sessions from previous years. (You can also see a list of all sessions from the same speakers.)
Two examples of the latter are tag clouds and a “top speakers” list.
You see, the whole point of collecting a lot of information about past conferences in one and the same place is to be able to analyze that information. Each session is one data point, possibly anecdotal, answering in its own way the question “what do people think this Agile stuff is all about”. So, tag clouds might make sense, to get an idea of the topics that are foremost in the minds of speakers at the conference when they propose a session.
That particular feature didn’t make it into the first release, not because it’s hard to implement but because it’s too easy to implement badly – I wanted time to think about how to do it right. Many of the top keywords extracted by the search engine are common English words, like “and” or “the”. Even after filtering those, the top word turned out to be “agile” – well, big surprise. Possibly the first non-obvious term to top the list was “team”. The second highest was “teams”. That hints at one more difficulty – it’s really topics we’re interested in, not mere keywords.
Number three or four or something like that was “process”. That shows a different issue: “process” can be used in a session description in several ways; it can refer to the concept of a software development process, as in “Agile process” or “predictive process”. But in many session descriptions, it’s a section header that precedes an outline of how the session will use its time – the session’s “process”. By that point it had become obvious that looking at tag counts for analysis was fraught with multiple issues; tag clouds have their limits. So I shelved this one, interesting as it seemed at first.
Another feature that’s still in the hopper is a “top speakers” list. Here again, the motivation was “I suddenly have this longitudinal data about Agile20xx, for instance it becomes easy to count who spoke how many times in total”. There are some design implications – getting this feature’s code just right would take some effort; but the database query for this is quite straightforward.
Notice, though, how this is an example of looking for your lost keys under the lamppost – of looking at the data that’s easy to get, rather than at the data that answers the interesting questions. (What are the interesting questions? That’s the interesting question to ask in the first place; I haven’t even fully figured that out yet, though I have my ideas.)
It’s also the kind of thing that might have social consequences – you can easily convey the message that the conference is a sort of contest where the goal is to place in the “leaderboard”. I don’t think that’s the point of the conference at all.
Conversely, though, it can be quite useful to know who’s been a common sight at the conference; we can check for instance whether the original Agile Manifesto signatories have been “hogging the stage” (they haven’t) or whether other influential figures emerged (they have).
Or you could look at gender diversity within these hard-worked speakers. I was quite surprised to see that of the list generated by my database query, the top 10 is evenly balanced between men and women.
On balance, I decided not to have this feature yet. On the other hand, I couldn’t resist running the query – and I can’t resist sharing the results with you in an upcoming post, if only because it gives me an excuse to show a little appreciation for some of my favorite people in the community.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
