You are currently browsing the category archive for the ‘agile’ category.
The second aspect of data that caught my interest today was Harvard’s Library Innovation Laboratory. I must admit that when I saw the link to it I did wonder whether it was going to be a list of library tools aimed directly at users (I’m sure I’ve seen the name used elsewhere recently for just such a list). I know we are looking at redoing our library toolbox to update it and library lab or labspace sounded like a good name for something like that. But the Library Innovation Laboratory is much more interesting proof of concept for anyone with any interest in what you can do with library activity data.
Using library circulation data that has been contributed to the LibraryCloud there are some really imaginative prototype visualisations in the Stack View and Shelf Rank tools. Two values are shown instantly. The book width is determined by the numbers of pages in the book and the book colour corresponds to the volume of loans so the darker the blue the greater the traffic. 
Titles are then shown as a stack one on top of each other. It’s a really neat visualisation of the data and I’m already wondering if that approach would work equally well with visualising library data that is entirely electronic resources. [It's actually one of the big problems about anything to do with electronic resources - that there isn't really a universal icon or symbol that you can use that everyone recognises that it relates to stuff that is online and in electronic form].
There’s quite a lot of interesting stuff in the site and also in the LibraryCloud site at www.librarycloud.org. One of the things that particularly interested me (from experiences with the RISE Activity Data project) was the section about data privacy and anonymisation, as a key requirement always has to be that with any dataset where the aspiration is for open release, it must be prepared in a way that ensures that users are unable to be identified individually.
The checkout visualisation is also a neat way of showing that sort of data in a nice clear fashion. 
The feature that lets you sort the data by different schools is useful and slightly brings to mind one of the MOSAIC competition entries that used a graph-type visualisation that allowed you to navigate through library use data. It did amuse me though that ‘Headphones’ appears twice in the top ten with different numbers. The perils of libraries using their Library Management Systems to loan all sorts of other things!
The feature that lets you sort the data by different schools is useful and slightly brings to mind one of the MOSAIC competition entries that used a graph-type visualisation that allowed you to navigate through library use data. It did amuse me though that ‘Headphones’ appears twice in the top ten with different numbers. The perils of libraries using their Library Management Systems to loan all sorts of other things!
LibraryCloud currently has data from Harvard and Northeastern Universities and Darien, San Francisco and San Jose public libraries. A couple of sites to keep an eye on over the next few months.
Agile
For a new project we’ve just started we have been exploring using a set of agile methodologies. This is to see if we can find a more flexible method of building systems than our standard approach of trying to write a comprehensive set of user requirements, functional specifications and technical specifications to cover the whole of a new system.
From some of the projects that we’ve done in the past we’ve recognised that there can be a risk that requirements will change through the project. You can end up building something that at the start of the project, seemed to be exactly what everyone wanted, but by the time the project is well-advanced, you have realised that requirements have moved on. This either leads to projects delivering something that no one really wants, or ending up with massive scope-creep and you enter a never-ending battle to keep pace with an ever-growing list of new features. Agile development seeks to find a way out of that maze.
SCRUM and User Stories
One example of an agile methodology is SCRUM, a technique seen in software development where development phases are referred to as sprints. So a sprint is a development activity taking place over a relatively short period of time with well-defined and potentially quite narrow objectives. One of the techniques often used to define the user requirements is something called ‘User Stories’
A User Story is essentially as statement along the lines of:
As a … (user)
I want to… (something)
In order to … (benefit)
The process you follow is to get your user or users to write out a series of user stories that cover the new system that they want you to build. These user stories can encompass a range of different requirements, functional or technical for example. Once your users have written their user stories you then take them and group them together into similar features or functions. You can choose whether you get users to prioritise them when they write the original user stories or you can do the prioritisation with the user representative once they are put together and sorted. The idea is that at the end of the process you have a priority list that you can use to identify what development you should undertake as part of the first sprint.
Thoughts so far
It’s the first time we’ve tried this particular method and it takes a bit of getting used to. Writing the right sort of user stories is not as straightforward as we’d expected. They need to be really tightly focused on what users want to do with the system, not too aspirational, and there really needs to be a boundary or scope to what they are writing User Stories about. It also seems quite easy to miss out features of the system that are going to be needed but haven’t been mentioned in the User Stories. But we are learning more as we go along and realise that as we progress we will create new User Stories to fill the gaps. That seems to be one of the key aspects of agile.
