Alison with the draft navigation for the new external website.

The development team have successfully managed two software development projects with Scrum (news & prospectus); now the front-end team (responsible for information architecture, usability, design, development and content editing) is trialling it to manage redeveloping the University’s external website.

Liam and Yvonne are working on both the news and the external website projects, so are in a position to compare how Scrum performs for two very different goals.

Yvonne: The main difference is that so far on the external website project, we have mainly been researching the information architecture and design of other sites, in order to establish best practice, and finishing off other smaller projects.

The first phase of building the external website is to describe user scenarios and develop the navigation; after that, we will assign content to the different areas of the site.

This is clearly different from the process of developing software and transactional websites.  However, the project can still be broken down into tasks (which are called stories in Scrum).  It’s just that it’s harder to decide when a task is actually complete, because the boundary between done and not done is fuzzier than it is in a development project.  For example, if you are doing research, it is an open-ended process; if you are writing content, it changes; whereas if you are developing a feature on a piece of software, it is built, tested and reviewed, and then it’s done, at least for that release.

Liam: Another thing is, whilst Scrum has great value for development, it can be detrimental to the creative process. When a project includes getting feedback from the end user, it take measurably longer to allow for subjective decisions based on visual elements, than on purely functional determinations.

As Yvonne states, the nature of the external website project also meant that we had longer, harder-to-quantify tasks.

External website project broken into smaller tasks. Photo by Anil Herat.

Yvonne: Still, the majority of the tasks for the external website can be broken down into tasks and subtasks, and I’m finding the Scrum approach useful.

For example, the photo (right) shows a series of subtasks for a ticket.

As you can see, we have broken the main story (Build and test HTML navigation prototype) down into ten distinct parts, including the creation of user stories and personae, reviewing the information architecture, and usability testing.

Liam: My concern here is that Scrum is intended to promote agile development, and we are having to break everything down in a very procedural way for the external website. It’s practically a waterfall. I think however that for this kind of project this is a necessity. The positives from Scrum (the daily stand-up meeting for example) are benefiting the project regardless, so the framework is beneficial in lieu of anything else.

Yvonne: The members of the front-end team tend to be more specialised in our particular areas (design, usability, writing), so it can mean that we have to wait longer for some tasks to get done.  But the Scrum approach also means that different people can pick up these tasks without feeling that they’re treading on someone else’s toes, which is good.

Liam: As a non-developer I found that the news project involved few tasks that I could take on – I’d argue that they were more specialised than those of the front-end.

I can really see the value of Scrum as a management tool for software development, and am pleased that elements of it can be successfully employed to manage a project that is predominantly led by design (in all its flavours).