niksilver.com

…which are a top navigation level of guardian.co.uk. However the navigational structure was designed to be quite fluid, and the concept of a zone is really more of an internal reference point than a phrase that’s intended to be used by our site’s users.

The ebb and flow of the online media marketplace meant that while we were working on R2 Times Online in the UK launched a redesign of their own. At the time I was interested to read an interview with their Information Architect who said that they had constructed a three-level navigation hierarchy. For guardian.co.uk we had considered and rejected implementing such an explicit scheme for three primary reasons.

First we recognise that the breadth of our content wasn’t equal across all subjects — we have many more journalists working on news stories than travel stories, for example, so a second-level of navigation under news might have a couple of dozen subjects, which is impossible to display conveniently on a navbar. Second not all subjects break down neatly into three levels — some topics have more depth and complexity than others. Third, Guardian values mean that certain subjects need to be given more prominence than a formal encyclopaedic breakdown allows — for example, in any formal scheme environmental issues would be part of the news or the science section, but the reality is that our planet’s environmental state is far too important to relegate to anything but the highest level.

So R2 was designed to allow fluidity and flexibility in our navigation, and we created words to describe its different aspects. A zone is one of the top-level categories that appear along the top navigation bar: News, Sport, Comment, Culture, etc. At the bottom level of categorisation are very specific subjects such as interest rates, war crimes, Kate Moss and thousands of others. If you’re reading about one of these subjects it doesn’t matter how many levels deep you might be as long as there’s some clear signposting to find your way to your next point of interest. The navigation should give you some kind of orientation, and importantly act as a guide to jumping off to similar subjects or to begin a new journey elsewhere entirely. But exposing any internal classification system is less important. R2 has given us a system that separates the visual navigation from the way content is organised internally.

…which stands for “you ain’t gonna need it” and is an important principle of Agile development, with strong benefits for the business.

The basis for YAGNI stems from a failure common in many software development projects: that when a developer creates a component of a system they tend to give it more flexibility than is immediately necessary, so that it can be reused in more contexts and provide more value. But the result in practice is almost always over-engineering: the component costs more to develop, the suspected additional use rarely materialises, when it does materialise it has requirements that don’t quite match the actual implementation, and the component as a whole is more brittle, less comprehensible to successive developers and more difficult to maintain.

By contrast YAGNI says “you ain’t gonna need it”: develop the absolute minimum to get it working for the immediate problem, and extend it later only if another specific needs arises. This works in Agile development because there is a wider supporting structure which enables changes to be made with minimal cost.

An excellent example of YAGNI in action was our implementation of content workflow. There are lots of things you could do with workflow. You can lock content to ensure that only one person can edit it at a time; you can branch content so that different versions can be worked on simultaneously; one of our senior stakeholders was keen on allowing numbered versions which she had seen elsewhere, allowing individual changes to be tracked and traced, and even allowing someone to switch back to a previous numbered version — but she did say that the feature was almost never used.

What we did in practice was a minimal workflow with minimal cost: we built in the ability to have content as draft and live, and very little more. That was sufficient for the staff who we knew would be using it. It seems like we could have taken the opportunity to build more, in case more people with more needs would use it. But you know what they say — you ain’t gonna need it. In the months following that very early stage in the project the company changed a lot, and among other things this included much more integrated working between editorial teams who were previously designated “web” or “print”… these days that distinction has diminished. The technological impact is that many editorial staff are using an integrated front-end, sitting outside the web system, and that’s where the workflow is handled now.

The industry-wide drive for integrated publishing changed our working environment; if we’d have developed elaborate workflow in the web system it would have been wasted effort, and a large wasted cost for the company.

…which was a size of problem we noted but wouldn’t tackle.

When we estimated the work for R2 up front we used t-shirt sizes for each feature: S, M, L and XL. The largest single task the team would tackle was an L, which was the equivalent of five days’ work. We felt this was a good maximum for two reasons: first, it delivered something of value within a reasonable space of time and what should have been one iteration; second, if we could imagine developing it within five days then it was probably sufficiently understood, whereas anything bigger risked being too complex to estimate without a lot more thought.

However, during the time-limited initial planning period we were required to estimate things that needed more analysis than we had time for. These features we labelled XL and gave a nominal equivalent size to: 10 days’ work.

However, we would never actually start a task that was labelled XL. We would always break it down before the event into smaller parts. The aim was that although individual estimates might be over or under, on average they should balance out and the total size of the project should remain constant.

Of course, for XL tasks it was quite possible that a more thoughtful estimate would produce a total that was far too big to be able to be balanced out by other tasks. In these cases we would have to reconsider our options and think about dealing with the problem in a different way — most likely by having a less comprehensive solution. However that didn’t tend to be too much of a problem. In many cases by the time we got to the XL task our stakeholders’ needs and priorities had changed so much that there were a lot of new options and directions that people wanted to explore, and ones that they would not have thought of in those very early planning stages.

This is an example of why planning was important, but very detailed planning would actually have been quite wasteful.