niksilver.com

…which are a fact of life — certainly if your life revolves around developing software. During R2 there was a 40% churn on requirements. That means by the end of the project 40% of the work we had done had not appeared in our initial plan — some things were dumped, new things were introduced, and much was significantly altered.

The Agile way is to embrace change, and more than that it’s to structure your working practices around enabling and encouraging it. There are several ways we make this happen. One is to make sure that every task has tangible value to the end-user. Another is to prioritise the tasks so that the highest value work is delivered first. The second follows from the first: only if the tasks are individually valuable can they be arranged and rearranged.

One example of handling changing requirements is how we introduced keywords. We always believed these were important to our work, so we developed them very early — other elements of our plan were less certain and so might change, but we could safely defer such decisions until closer to the time we’d have to build them.

Managing keywords would require some slick tools if they were to be rolled out to more than a couple of staff. But our first cut was very primitive: it involved someone typing data into an Excel spreadsheet and then uploading that to a web page which would digest the spreadsheet and either process the data or report errors. It was not user-friendly. But this approach did have many virtues:

• It was relatively quick to develop;
• It was sufficient to enable just one person to manage the keywords, which was all that was needed then;
• It allowed us to build further things based on keywords, such as a little component next to an article which listed the keywords associated with it;
• It showed up real, unexpected problems arising from real-world use, that we would not have foreseen during planning;
• It showed us what really was and wasn’t going to be important when we built a slick tool for wider use.

A 40% churn on requirements doesn’t mean there was a 40% budget overrun or time overrun, by the way. We came in on time and on budget. That’s another consequence of having working practices that embrace change rather than merely tolerate it.

…which means different things to different people. In our case it meant extracting requirements and turning them into something that could be implemented.

Business analysis is often misunderstood when it’s used in an Agile context. Agile people often think it’s not necessary — after all, they say, the analysis is best performed by the developers working closely with the customer as they go along. Many non-Agile people often think the analysis should be done up-front, written down, and then the workload on the business analysts (BAs) eases off as everyone else goes off to implement what they’ve written.

In fact business analysis was one of the most demanding jobs on R2. Analysis was indeed done up-front, at the start of the project, but only to a level sufficient to estimate the work, not to a level sufficient to implement it. Ahead of each fortnightly iteration the BAs would specify the forthcoming fortnight’s tasks in much greater detail, sufficient to be implemented. At the same time they would be dealing with queries about the iteration currently in flight. Thus at any one time they had to deal with work being planned and work being implemented.

In both cases they would be working with a very diverse group of people. For work being detailed the business analyst would take requirements from our business users and present them to the technologists for estimation; for work being implemented they would often take queries from the technologists and present them to the business users for guidance.

You could say the process of business analysis was often like being piggy in the middle, yet the personal skills of the individual business analysts (technical insight, strategic understanding, and not a little diplomacy) was key to the success of the project. The cohesiveness of guardian.co.uk — both from the outside and the inside — is in no small part due to the talents of our business analysts.

…which is one of the first tools we built as part of the project. And it’s a lot more complex that most people expect, especially if their main exposure to a content management system is through blogging.

The main reason there’s so much to it is that there’s so much to the organisation it operates in. On a blog, if you write an article then you don’t need to worry about people finding it, because it will appear at the top of your homepage, which is more or less the only page that people will be watching if not the RSS feeds. Furthermore, a blog is really just a single stream of articles. So when you write a blog post you really only need to worry about the headline, the body text, and maybe an extract to entice people in — and you certainly don’t need to worry about the environment that the article appears in.

On a large website such as guardian.co.uk, by contrast, an article generally won’t appear on the homepage, and it has a less than 1% chance of appearing at the top of the homepage. But it will be linked from many other pages. It will also most likely be only one part of a whole mesh of other pieces of content, all touching on different aspects of that and much bigger stories (plural), so it’s important to link all these together. (This is part of what Lloyd Shepherd calls “slow news”.) Therefore the article editor has lots of boxes to fill in which ensure the article fits in properly with the rest of the site’s content. Keywords are central to link to and list it on appropriate subject pages; an alternative headline is essential to allow the article to be linked to from those subject pages and elsewhere (many newspaper headlines only make sense on the printed page with a particular layout and don’t translate to the web); a one- or two-sentence explainer is similarly important to go underneath the alternative headline.

And side from the importance of maximising cross-linking, there are other factors that explain the differences with an article editor for a blog post, but they are still all consequences of working in serious organisation. Rights issues mean the writer has to be identified exactly; design requirements will mean that different parts of the article (most obviously the standfirst) need to be separated so that they can be displayed differently; print publication times mean you’ll need to identify the print publication date and the web publication date separately; marketing decisions may mean you need to give a particular article a specific URL.

A while back, Martin Stabe lamented “Why can’t a newspaper CMS be as user-friendly as a blog?” I’m sure our article editor could be more user-friendly, but I doubt we’ll get it to be quite as user-friendly as many blog editors simply because it does a different and more complex job — a job in an organisation with hundreds of people and very sophisticated media and presentational requirements.