Peter May

The SCAPE project is into its final 6 months and with that came our final developer workshop. The main focus of this event was demonstrations, productisation and sustainability, however with everyone together it provided an opportune time to make progress with other SCAPE related activities. With nearly 30 people there, there was a lot going on and so the agenda needed to be flexible to enable productive working, but managed to ensure the workshop’s overall goals were achieved. This post discusses our use and experience of kanban as a means to manage such workshops.

Kanban is a visual way of managing tasks through a workflow. It is lightweight, applicable to whatever process you have today, and doesn’t require a lot of overhead. It is based on three principles (some say 6): visualise, limit Work in Process (WIP) and manage flow, which serve to ensure tasks and processes are brought into the open for discussion, that lead times are reduced and that the workflow is understood and continually improved through monitoring. For the purposes of this SCAPE workshop the main priority was visibility of the work.

Visualising Tasks

Typically a workflow is represented on a kanban board along with the work items that move through this workflow. Placing such a board on the wall enables everyone to see what’s being worked on, who’s working on it, and at what stage in the workflow it’s at. There is a minimal overhead – creating work item cards and moving them through the workflow stages – but this is manageable with short, regular update discussions.

Task Boards

Using large sheets of paper stuck to the meeting room walls, we created a primary board with 3 main columns: To Do, Doing, Done. After introductory presentations recapping the purpose of the workshop and the main goals, participants were urged to consider tasks they needed to do and to write them on sticky notes, whilst further presentations were given about specific activities that needed doing (e.g., generating microsite documentation for each tool). This worked really well as it got participants thinking about and writing down what they needed to do whilst discussions were happening.

It is important to note that a fair amount of pre-work was performed in the lead-up to the workshop. For example, gaps in tool documentation and tool installation issues were both identified prior to the workshop. These were then introduced in the initial presentations (and discussed further during the remainder of the workshop) and provided a valuable initial set of tasks that quickly got the workshop moving. The motivation for this pre-work was driven primarily by the desired overall goals of the workshop.

Tasks

One sticky note equated to one task. We made no distinction between different coloured notes, although the colours could have been used to indicate categories of work, e.g., bugs, development, documentation, etc. This does add another level of complexity into visualising the work and given the workshop was only 3 days long, not giving meaning to the colours kept things simple.

Similarly, it is useful to know who is working on a task. We pre-printed everyone’s names onto white stickers which could be affixed to the sticky notes. Being white on coloured notes emphasised the names, making it easier to see which tasks were ownerless. Avatars were considered, however given the short duration of the workshop and the fact that few people pre-selected one, we didn't use them (they were film character based and so didn't relate to any specific individual at the workshop, meaning it probably would have been harder to work out who the task "owner" was anyway).

"Why does this tool have its own board?"

Beyond the main board we also had several smaller boards for individual software tools being worked on. These had the same 3 columns as before, but also including “Waiting for Feedback” (queue) and “Feedback” columns between ‘Doing’ and ‘Done’. These two additional columns were motivated by the work on documentation, where checks were thought necessary to ensure documentation completeness. I didn’t see these columns used much, and they could have equally been replaced by creating “Check documentation for tool X” sticky notes once the “Do documentation” task had been completed.

We never had any logic or consistency in which tools had their own board and which didn’t, which resulted in some confusion; a few times I overheard questions such as “why does this tool have its own board?” to which there was no obvious answer. In many ways these smaller boards acted as swim lanes for those tools, the lanes just happened to be separated out into their own boards. Separate boards highlight the work on a specific tool/topic, but perhaps unnecessarily isolate that work from the rest. If a clear distinction between work item “topics” is needed, different coloured sticky notes could always be used instead (this wasn’t the case for us though), but caution should be used to avoid making it too complex (e.g. through use of too many colours).

Work in Process – What to look out for

The emphasis for taking a kanban approach was to bring the tasks being worked on out into the open. It can often be hard to manage workshops with 30 people all working on different things and ensure that the workshop’s goals are met. However, having tasks visible on the board with people’s names attached to them means no-one can hide.

No emphasis was placed on limiting the amount worked on by one person, although people naturally tended towards only working on one or two things at a time. Progress was simply monitored through ad-hoc group discussions centred on the boards and going around the table asking each participant how they were getting on. This sometimes resulted in the need to move a sticky note from one column to another, but forgetting to do this can be excused by unfamiliarity with the kanban approach. A number of times, people were working on things that didn’t have a sticky note at all; asking them to create one then and there was the easiest approach to ensuring it happened, and also encouraged a few others to slyly put up other missing notes!

Another thing to look out for are ill-written tasks – tasks descriptions that are either too vague to be understood (by anyone other than the task owner) or too high-level that they encompass many individual tasks. A big factor in using kanban is to bring the work out into the open so everyone can become familiar with what’s going on. If the actual things being worked on are hidden behind vague descriptions then nothing is communicated and you may as well not have had the note at all.

Lessons Learned

Kanban was a very effective approach to managing the wide variety of tasks going on at the workshop, and recommended for such meetings. The following bullets summarise the discussions above, reflecting our experiences with the technique, and are directed at the use of kanban in short workshops (i.e. the recommendations may be different if applied to a long-running project, for instance).

Preparation:

• Understand what the key goals are that need to be achieved at the workshop and prepare accordingly; from this it is likely that an initial set of tasks can be created (or at least hinted at) to help get the workshop up-to-speed quickly.

At the Workshop:

• Briefly explain the kanban process and give everyone sticky notes so they can write tasks as soon as they think of them; do this up front before main presentations.
• Keep any introductory presentations short and directed towards encouraging task identification around the main workshop goals; aim to swiftly move on to the "doing".

Visualise, but keep things simple:

• Keep everything on the same board; 3 columns (To Do, Doing, Done) is often enough.
• Don’t give meaning to sticky note colours unless there’s a good reason to; if there is a good reason, create a key to ensure everyone understands each colour’s meaning.
• Use stickers with people’s name on. These are more obvious than handwritten names, and easier to recognise who they refer to than avatars (given the short duration of the workshop). If using avatars, consider just using people’s photo (perhaps also with their name).

Tasks:

• Ask for note rewrites or breakdowns into multiple notes where task descriptions are vague or too high-level.
• Encourage ownership of tasks by getting the person whose task it is to write the note.

Manage the boards:

• Hold ad-hoc group discussions centred around the boards.
• Ask for status updates by person rather than task, so that missing on task notes can be identified (this favours having all the tasks identified over an exact status for each).
• Understand that people (especially those new to the process) forget to create/update tasks; encourage note creation as soon as the gap is recognised; if necessary, move tasks appropriately during the ad-hoc recaps.
• Don’t move tasks to “Done” until they truly are done; “I’ve just got to push the code back to the repository” means it’s not finished.

Job Done!

It was great to see everyone participate in the approach – I was expecting reluctance from people to get involved, but was surprised by the level of enthusiasm; I even noted someone exclaim at completing a task before jumping up to triumphantly move the sticky note to the done pile! With a variety of tasks, progress across the board can often be seen quickly (for us, things were complete by the end of the first day), and at the end of the workshop hopefully you end up with a “Done” column full of sticky notes and (if anything’s left) a “To Do” column with follow-up actions.

After a year predominantly focussed on external SCAPE events (Open Research Challenges Workshop @ iPres, the First SCAPE Training Event in Guimarães) we finally organised another project internal scenario and developer’s workshop. As always, the event provided a great opportunity for developers and SCAPE scenario holders to get together and talk face-to-face.  It also gave those new to the project an opportunity to meet some of those people who they’d only spoken to over Skype (or even only over email!).

Flexibility in the workshop agenda enabled each day’s activities to be adjusted slightly so that everyone had opportunity to discuss and gain awareness of important topics at this point in the project.  Main topics focused on were the scenario status updates, refining scenarios, policy representation work, and the functional review criteria; enabling team members to have an appreciation of these subjects will be important in helping to improve project-wide understanding and communication, especially as the project steps up integration of the various components we have been working on.

The first day started by reviewing the existing scenarios. Plenty of excellent work has gone on across the project, and much of this is driven and directed by content holders who express their needs and assess solutions through the various Scenarios. From assessing this list, it was clear that we have a good spread of Scenarios underway, and completing these should form the focus for upcoming work. As it stood at the meeting, across the three TestBeds (Large Scale Digital Repositories, Web Content, and Research Datasets), we have 11 active scenarios, 7 just starting to be worked on, with a further 10 not started, postponed or unknown (2 unknowns due to no feedback before the meeting).

Understanding the breadth and status of scenarios helps us understand and prioritise forthcoming work. Combined with the recent gap analysis and the scenario refinement work, which aims to succinctly identify the issue with each scenario and the associated solution’s requirements, it will also help make on-going development work clearer, better directed and easier to measure.

Catherine Jones (STFC) presented an overview of the policy representation work going on within the project. This aims to break down organisational high level policies into low level machine actionable policies which can be monitored and reacted to by the automated watch component (for example, reacting to risks and constraints derived from policies), as well as used by preservation planning to ensure that Preservation Plans meet institutional needs and requirements (for example, using institutional policies to select appropriate plans or components for plans). As a means to understand this better, the group worked on developing example policies for the three defined policy levels (High-level guidance policies, Preservation policies, and Control Level policies) using an existing scenario (TIFF to JPG2000 migration).

On the final day, a couple of demonstrations were given to the group.  One focussed on the development of the Component Plugin functionality in Taverna (to enable the creation and use of SCAPE Preservation Components within the Taverna Workbench) and the associated Component Catalogue APIs for storage, access and discovery of these components within the web based catalogue. The second demo was of Matchbox, a tool for detecting near-similar images, for example where one image is a rotation or scaled transformation of another.  In particular this demo focussed on the detection of duplicate images from a collection of content, with excellent results.

To wrap things up, Carl Wilson (OPF) gave a presentation surrounding the Functional Coding Review aspects of the project which serves to ensure that the software we produce is of good quality and easily maintainable. He covered many related aspects such as documentation, licensing, unit tests, bug tracking and packaging. He also discussed the need for a team of developers who will be responsible for reviewing code against our coding guidelines (as well as reviewing and iterating the guidelines themselves) – if you can spare some time to help with this, please get in touch.

On the whole the workshop was very successful.  Flexible arrangements allowed a lot of important work to be covered, with the participants I spoke to all having positive things to say about this approach and the meet-up in general. Ultimately, the benefits of such flexibility is probably reflective of the fact that it is constructive participation which is important in setting the direction and success of any endeavour.

On this note, if you have a scenario with a scalability challenge which SCAPE should be working on, are able to help with functional review, or have feedback on SCAPE outputs (especially from those external to the project) then please get in touch.