How would you plan to make a website? Traditionally, a business would spend a lot of time planning out the whole thing in detail. Then someone would take away those instructions and appear 6 months later with a site. If you were extremely lucky, this would be a decent approximation of what you actually wanted. Probably, though it would be nothing like what you initially hoped for. And in fact, once you saw the site you realised you actually wanted something different anyway. This is the challenge of trying to solve what are usually complex problems at the time when you know the least about them. i.e. the beginning of the project.
Mosaic presented us with a perfect opportunity to try something different; what’s formally known as “Agile project management”.
One of defining features of Agile is that it allows you to develop the website in an iterative way, breaking the project down into digestible chunks. The team works in “sprints” — short bursts, usually two to three weeks in length, focusing on particular features of the website within that time. Baked into this process is plenty of openness and plenty of reviewing to enable the team to adapt according to what’s been learned along the way.
The team wouldn’t normally change direction or requirements within a sprint, but it’s ‘agile’ in the sense that it can easily change direction with subsequent sprints (we’ll share more about how we’ve actually done this in later posts). This also means that only minimal effort is wasted in the process i.e. you only throw away some of your work from previous sprints.
Team working – with Post-its
One of the most satisfying (and envy-inducing) aspects of Agile is that it puts a team of experts (in our case a user experience specialist, a digital designer and a web developer) together and has them work exclusively on only one project at a time. It’s a luxury that many of us don’t ever get to enjoy. Productivity, and more importantly, collaboration, are improved as the team don’t have to deal with the usual plate-spinning of day-to-day work. I’m sure that making this one change would help a lot of people to do their job, but it’s particularly helpful for creative, complex or problem solving work - like building websites..
To help make this happen we took over a meeting room and made the space our own, transforming it into a veritable palace of Post-it notes.
Putting the user first
So why all the Post-it notes? In Agile, we describe the things a website needs in terms of ‘user stories’. These are framed in terms of what the user actually wants to get out of the site (i.e. what they want/need to do). It’s important that it doesn’t describe the solution — it’s the team’s job to come up with that.
User stories have three component parts; who wants it, what they want and why. I’m proud to say that these user stories are, as they should be, based on real data. They’re taken from research we undertook done at the beginning of the Mosaic project, interviewing people who we thought might be potential users of Mosaic. Here’s an example:
The beauty of the user stories is that it breaks down requirements into discrete parts, and we then tackle each of their requirements organised through a “scrum board”. It’s a really simple lo-fi way for the team to keep track of what everyone’s doing. Here’s one of ours:
On the left hand side are all the stories that we’re working on at the moment. These are shown in yellow. Once the team has decided how they’ll tackle each one, they break them down into tasks (shown on the pink post-its) that are very specific. For example, “Draw a wireframe for the page header; markup a page to show who a writer is”.
The board shows what’s in progress, what’s left to do, and – most satisfyingly – what’s already been accomplished. Anyone dropping into the room should be able to make sense of the board at a glance And plenty of our colleagues have dropped in over the last few months to see our progress. The result has been an ever-changing, but focused website that we hope will make reading Mosaic’s stories a pleasurable experience. And if it doesn’t work, we’re agile enough to change it.
Angie is Web Project Manager at the Wellcome Trust.