But then he asked in a different way: what were my experiences as a project manager before and after implementing Agile? What differences might he expect? That was a great way to look at it. Here’s a little of what I said…

Less waste

Before Agile I would find myself running projects with wasted activity. We’d spend the first few days creating the database schema and libraries. And then by the time we got to the end some features would have been dropped — maybe because we had to go live sooner than we’d have liked, maybe because requirements were explicitly descoped. And looking back we’d realise we spent days implemented the underlying functionality for those unused featured. Similarly I would have specified interfaces to high level of detail, and yet those interfaces would have changed during implementation. Again, wasted time up front.

After Agile, that doesn’t happen. If a feature is needed it’s implemented top to bottom in one task. If it’s not needed none of it is implemented.

Better software

Before Agile, if that library or database schema was still in use, then often it was in use poorly. We’d implemented it based on expected requirements, but when the day came those requirements turned out to be slightly different. Maybe because of a lack of understanding, maybe due to an actual change. But there wasn’t time to change the earlier work, and we could still manage with a workaround, so that’s what we did. And the result was software that worked, but included serious compromises, to the extent that it was really difficult to evolve beyond the original launch.

After Agile that doesn’t happen. Well, not so much. I’m not sure I’ve ever delivered perfect software, but I’ve certainly — consistently — delivered software that can continue to grow with the requirements of the client and their business.

Fewer difficult change conversations

Before Agile, conversations around mid-project changes were very difficult. If the client wanted a change then they they would hear me act like an unhelpful car mechanic. I’d suck my teeth, exhale, and say “We-e-e-e-ll, it’s gonna cost you….”. We’d worked so far based on a different assumption. So, yes, they could have what they wanted, but at significant cost. Or they could have a compromised version at a reduced cost. What was it to be? Significant cost or compromise? Not a great decision.

After Agile, change is the norm. If you want a change (which might be a new feature, since that’s a change to the software we’ve delivered to date) then we’ll prioritise it appropriately. If it’s going to take 8 days and you don’t want to increase your budget then just take out something else, that’s less important, that’s also 8 days. All features should be interchangable, so you can change your mind a very short notice.

It’s not a perfect world

I was at pains to add that I’ve still had difficult projects before and after Agile. Agile isn’t perfect, and neither am I. (“And,” said my friend, “you’re still dealing with people.”) But undoubtedly the chances of success are much greater, and the general level of satisfaction is much higher.

“It’s a mix of ignoring them [non-Agile managers] & making shit up” #ProductTank How is this consistent w/ Agile values of openness & trust?

There’s a conference-worth of material to unpack from that question. You can make up your own responses, whether cynical, pragmatic, witty or all three. I wasn’t at Product Tank, so I can’t take issue with that in detail (though I would caution readers: I know Tom, and his presentation will have been as much about entertainment as education and information, so take that statement with some amount of salt).

However, regardless of its literal truth about alphagov specifically, there is a truth in there about projects in general: if the idea of agile is used as a trojan horse to allow bad behaviours, then any success will be shortlived. That thing masquerading as agile won’t scale to other teams; it certainly won’t scale to larger projects. Agile might be seen as the success factor in the initial project, but the inevitable failure of future projects will ensure its adoption is halted pretty quickly.

This is true for small and large organisations of all kinds, and is one thing that James Yoxall touched on in his presentation to the 2011 Agile Business Conference.

When I manage development teams I see one of my responsibilities as being the angel on the shoulder of those developers, urging them to “do it right” in the face of the project manager who’s urging them to “do it now”. But project managers can be angels, too. Some will be interested only in the success of their own project. And some will want to ensure that good practices are recognised, learned and adopted by others. Unfortunately those two views are sometimes at odds.

Rimonov’s tower of activity

Rimonov’s tower of activity is such a model. It describes the path from initial observations to project activity, and thus enables us to check how our current activity relates to any other activity in and around a project — whether it’s a future, current or past project being reviewed. It’s loosely related to the ladder of inference and Maslow’s hierarchy of needs. Evgeny Rimonov was a professor of computer science who I’ve just made up off the top of my head because “Silver’s tower of activity” sounds too pompous.

The model tells us that from observable data we can infer needs; needs can be packaged and met by a product; a product can be expressed as a collection of requirements; and requirements can be packaged conveniently as projects.

A simplified example: cars are desirable but expensive, and mass production can reduce costs (observable data); people will value owning cars if the cost is lower, even if the product options are limited (needs); a mass-produced car will meet these needs (product); we have the design of the car and the factory (requirements); we will approach investors with this packaged proposal so that we can implement it and deliver returns to them within a given timeframe (project).

Each layer is smaller than the one below because it does not seek to address everything it might be based on. So: we observe lots of data, but filter out the the irrelevant data when deciding what needs we might address; users may have many needs, but they won’t be univerally met by the product; the product may be have a grand vision, but we will only capture what’s practical for now in the requirements; various projects will deliver the requirements, but inevitably some will be descoped.

Using the tower

Projects, then, are based on several foundational layers, and if any one of the lower layers is flawed, or found not to exist, or becomes detached from the others, then it undermines the validity of the higher layers.

If you find yourself working on project requirements that seem questionable then it’s worth testing the basis of those requirements. A quick question to the right person may reveal immediately the research the requirements were based on — maybe even a video showcase from one of the user experience team. Or maybe the underlying need is less clear, in which more difficult questions need to be asked.

Even an architecture can be considered a product: if it needs to support multiple projects in a shifting business environment, then explicit care needs to be taken over monitoring that shifting environment, identifying needs, and evolving the architecture so that it stays ahead of the projects’ needs. The person who does this may be (or be labelled as) an architect or a product manager.

But in any of these examples if the lowest (data) layer changes — e.g. updated data comes in contradicting earlier findings, or the business environment changes — then the project should be rethought and perhaps terminated.

It’s interesting to note that lean startups and agile development methodologies both aim to eliminate the risks that derive from the reliance of each layer on the one below it. They seek to dramatically tighten the feedback loop so that requirements are much more tightly linked to observable data.

Additionally, since the project layer is a often a form of packaging to satisfy budgeting, it’s possible to do away with that layer entirely and instead implement some kind of flow of continuous delivery.

Overall, the model is a useful way of quickly checking that any current or potential activity is based on the right foundation.

This came up last week talking to someone about yet another almost-failed project, where in that case it was the wrong choice of supplier. In other conversations it’s been the wrong technology, or the wrong contractual arrangement with (what otherwise might have been) the right supplier. Sometimes it’s been a complete failure to understand what the customers wanted.

So to the first question: why are the key mistakes seemingly made so early? I think the answer has to be that the impact of any decision grows with time, so the earliest bad decisions will be the ones with the biggest impact.

Typically a decision or action is built on over time: Our strategy will be this, so we’ll do X, which means we’ll do Y, and so onto Z. If we now discover it’s a bad strategy we’ve got to undo X, Y and Z. The impact of a decision over time (which can be measured as the cost of undoing it or changing it) typically looks like this:

Sometimes it’s more significant. A legal contract may have termination penalties in force the moment it’s signed. In that case the impact looks more like this:

We may also find ourselves making a decision with an impact that looks like this:

That will be when we’ve made the decision long before it’s ever actually needed.

Given this, let’s take the second question: How can we reduce the impact of mistaken decisions?

Ideally we’ll want our impact curve to look like one of these:

or any other shape where any possible negative impact is contained. Here are some options as to how to achieve this:

1. Make decisions as late as possible. This has two benefits. First, there is less time for dependencies to grow around the decision. Second (and more significantly) it gives provides us with the best context in which to make the decision: the most up to date market information, the experience of everything else learned so far, etc.
2. Include a mechanism to handle change gracefully. For example in a contract make sure the cost of termination is proportionate to the time and effort the other party has committed (or better, of course). Software development has evolved its own system of tools and practices which ensure the cost of change there can be minimised.
3. Work with alternatives in mind. For example, if your supplier is developing an application for you to run, make sure they’re not relying on any secret sauce that you can’t find elsewhere.
4. Break up decisions into smaller ones, in parallel. AKA spread your risk. AKA don’t put all your eggs in one basket. E.g. if there’s a risk of becoming too dependent on a single provider of widgets then split the supply over two providers. They don’t even need to be placed in competition, and you can rebalance your supplier portfolio continually.
5. Break up decisions into smaller ones, in serial. For example, very often deciding what’s to be done is important for early planning, but deciding a lot of how it’s to be done can be delayed. If we’re thinking about marketing it might be useful to start working up concepts early, but the company which creates those ideas need not be the company that produces the final material, and that selection could be made much later.

You can probably think of more ideas. By all means throw them into the ring.

The most significant lesson for me, though, is to have a mitigation strategy for all decisions — particularly those that are made early on.

• Trust = 0
• Trust with tasks
• Trust with milestones
• Interlude: Where we don’t want to innovate
• Trust to define projects

Trust = 0

Let’s start at the very beginning, where trust = 0 and hence freedom = 0. “I don’t trust you to work by yourself; everything you do must be done in conjunction with me.” This is micro-management and generates nothing unexpected whatsoever. The only opportunity any team member has for creativity is during their bathroom break. We can do better.

Trust with tasks

Let’s extend trust a little bit: we allow our team members to complete individual tasks or deliverables that we specify — but let them determine how each task should be completed. This is work to a tightly-defined plan, and so any innovation will be under the hood — the internal architecture, the software design, and so on. But what you’ll see is what you expect. The tangible product, and every visible aspect of the product, is exactly what you imagined.

Trust with milestones

We can extend trust further still: we allow our team to deliver to clear product goals and trust them to work out the details of those product goals. This is where we start seeing innovation — as opposed to having innovation under the hood. Innovation of this kind is driven by project milestones or product principles, like “We want some personalisation features” or “The user must be able to share their work”. We want the development team — the programmers, user experience people, designers and so on — to be free to determine how to achieve this because it’s they who have the most intimate understanding of the product, how it fits together, what it’s capable of, and what it might be capable of.

In this scenario those project milestones or product principles come from outside the development team. It’s what they rely on product managers or other senior stakeholders for. Amazon does this with a press release: a description of the product in terms of end-user benefits, written to inspire and guide the development team.

Interlude: Where we don’t want to innovate

If you’re thinking that this amount of freedom, from this amount of trust, is just hippy nonsense that leads to escalating budgets and timescales, then let me bring us down to earth.

One area where we almost certainly don’t want to be innovating is project management. There are plenty of good project management methodologies out there, one or two of which will be good enough for us, and we don’t need to be inventing any more. So we may not go in with a detailed task list and instead trust the team to define the tasks themselves; and we may not go in with any predefined product features and instead trust the team to work out for themselves what features will achieve the stated aims of the product; but to not go in with any idea of how we might responsibly spend our budget, manage risks, showcase progress, communicate with stakeholders, meet timescales, and adapt to feedback is downright irresponsible. And to generally deprive the team of project management expertise is foolish. Unless we explicitly want to invent a new project management methodology we really should ensure the team picks one of these tools and has the wherewithal to use it well.

Trust leads to innovation, but let’s be clear about where we want to innovate.

Now back to our regular programming.

Trust to define projects

We can extend our trust even further if we allow our team to define not just product principles or milestones, but entire products or projects. We can set an organisation-level goal such as “we want to double our revenues” or “we need to make our service a social experience” and then see how our team can achieve it.

A goal like this is important for two reasons.

First, it eliminates irrelevant ideas. Anyone in an organisation can have ideas, but we really want ideas that push our business forward. If my media company specifies that our goal is to make what we do more social then an interesting idea like making an iPhone game will be considered irrelevant because it doesn’t meet the goal of making our existing work more social. In other circumstances it might be promising, but our current circumstances are about being more social and that’s what we need to focus on.

Second, it allows us to compare alternate ideas. I might propose that people could be given virtual biscuits every time they share an article. Already this is more relevant than the iPhone game idea thanks to having to focus it on our organisation-level goal. But if someone else has a proposal to create common interest groups around our content then I’d say my virtual biscuits are looking pretty poor, relatively speaking. Our organisation-level goal has provided a scale of comparison.

And round again…

We’ve just extended trust to enable people to envisage an entirely new project. This is the very first stage of development — the concept. We also have to implement it. And this takes us right back to the beginning: how much trust do we want to give to the team? None? Just enough to complete a series of predefined tasks? Or do we trust them to devise the most appropriate means to meet the principles of the product? This is our chance to inject innovation again.

The usual approach is to track time spent on tasks or on a project. This is equivalent to filling in a timesheet. Let’s say that on Monday, Tuesday and Wednesday we work on Task A for 2 hours and Task B for 3 hours. That completes Task A, and a 3 more hours on Task B on Thursday finishes that. We record

Task A: 6 hours

Task B: 12 hours

Or we might be recording effort at the project level (Project X: 6+12 = 18 hours’ effort).

An increasingly common alternative is to measure duration, also known as cycle time. In the example above, and assuming we are only working at the granularity of days, we would record

Task A: 3 days

Task B: 4 days

Cycle time generally isn’t captured at the project level, but at the task or feature level.

If you come from the effort-measuring school then measuring duration looks peculiar. By contrast, if you’re measuring duration because you’re using lean processes then the effort-measuring school looks positively archaic. Either way, the difference between the two records above is striking.

In the end, neither one is right or wrong per se. What’s important is: What do we want to achieve?

Capturing measures or metrics is often for a number of purposes: financial matters, tracking progress, and improving efficiency. Let’s look at each one in turn…

Financial

There are a couple things here: capitalisation and billing.

Capitalisation is the process of representing newly-written software as increasing the assets (capital value) of our company: by having this software we are now worth more. The accepted method is to take the asset value to be the people-cost of building the software, i.e. the salaries or fees of those involved divided across the various projects. There are clearly shortcomings with this approach, but that’s a discussion for another day.

By measuring effort we discover how we divide our time across our various projects and therefore how to split our people-costs proportionally, which becomes our capital value.

Measuring duration is not so obviously appropriate, but it can work. To see it working, it helps first to see where it doesn’t work in a deliberately unrealistic example. Suppose over the course of a year we run 250 tasks of duration five days each, plus one task which we spend a bit of time on on the first day of the year, but which then gets kicked into the long grass until the last day of the year when it’s finished off. If we capitalise by duration that single long-running task would bias the capital costs inappropriately for whichever project it was part of.

So that looks unhelpful. However it doesn’t have to work like that. In particular if we forcibly limit the number of tasks in play (aka work in progress, aka WIP) at any time then long-running tasks will be exposed and people’s natural desire to get things done should ensure they are dealt with and not forgotten. Also, a long-running task can be just taken out of the system, regarded as waste, and started afresh at another time if necessary. More generally, tasks won’t drag on as long as they might otherwise and over the course of several weeks the measurement of duration will be as just as good (and just as as imperfect) as measurement of effort.

So for capitalisation both effort and duration are plausible measures.

For the purposes of billing clients measurement of effort is ideal when charging time and materials. Lawyers, consultants and contractors all do this. Charging clients by task duration isn’t likely to go down well, and I can’t imagine how to make a itemised breakdown look palatable on the invoice.

If, however, we’re the ones being billed then we need to track effort (=spend) and match that against progress.

Tracking progress

Tracking progress (and therefore assessing completion date) is not about tracking effort, it’s about tracking when features are completed. If we’re 25% of the way through the project we want to know that we’ve completed 25% of the features; how much effort we’ve expended doesn’t tell us that. Tracking duration also doesn’t help us, but it is usually a by-product of tracking start date and end date of each feature, and it’s the end date we’re interested in here. If we’re tracking effort then the end date just one more data point we need to collect for each item in play.

Efficiency

If we want to improve efficiency then we have to track metrics (so that we can tell when efficiency has improved). But again, what we want to make efficient will determine whether we track effort or duration.

If we want to improve the single activity of writing software then tracking effort is the thing to do. However, that’s not usually that useful: single activities can almost always be made more efficient, but the most significant gains tend to be found elsewhere. Improvements in writing software will produce very small gains compared to everything else that makes up the process of delivering software: analysis, design, development, third party integration, functional testing, user testing, deployment.

If we want to improve software delivery then tracking duration is what we want. Duration of that sequence includes, and therefore exposes, all the delays. If we aim to improve our tracked metric then one major gain is to eliminate those delays; eliminating the delays then exposes the inefficiencies in hand-offs between teams, which we can then work on. At the end we have improved our overall process, not just a single activity.

There are more…

There will be more reasons to track data, but I hope it’s clear that what we should track depends on what we want to achieve. Tracking cycle time is increasingly sexy (it’s lean, it’s kanban, it’s systems thinking… we’ll forget that it’s Six Sigma, too), and there are real advantages there, particularly when it comes to improving efficiency. But plain old tracking of effort isn’t entirely redundant yet.

Contents

• Definition
• Purpose
• Varying communication
• Traceability
• Success factors are relative
• Leaders are responsible for balance
• Application to the financial year

Definition

Critical success factors are those factors on which a project’s success is judged. These may include reducing a costbase, increasing efficiency, opening up a new market, etc. Knowing what they are, and putting them to work, become especially important in complex projects where there is the potential for so much noise and error.

Purpose

Critical successful factors can be used for two things: governance (ensuring the programme develops in the right direction) and communication (keeping everyone focused on the right thing).

Of course, there is an interplay between the two. Using CSFs as a framework for communicating to the steering group ensures better leadership (governance). Using CSFs as a framework for communicating to the operational team means better decision-making (prioritisation) on a day-to-day basis.

Varying communication

How CSFs are then communicated will vary, dependent on the audience. For the governance group it can be part of a formal process. For the operational team it might be cards stuck on a wall.

During the Guardian’s R2 programme we stuck the CSFs on a wall, ensuring everyone who cared to look knew exactly what our priorities were. At the time we called them key performance indicators (KPIs), although I think that was wrong: KPIs are usually regarded as continuously measurable healthchecks. I think “critical success factors” would have been a better name.

Traceability

Communicating a project’s critical success factors helps traceability, which I interpret as being able to trace the line from what I am doing now to what this programme is all about. However, it was pointed out that traceability does not appear in traditional agile literature. I think that’s because agile literature tends to start with software development and peters out as you go up the management stack. It’s a failure of the literature, and a reminder that no methodology at any level should exclude good management and leadership.

Success factors are relative

Any individual’s personal success factors are going to be based on their work and influence. A project manager will be concerned about budget and deadlines even though those factors may be secondary (non-critical) to delivering a particular capability or enhancing brand reputation may be more important. The project manager is focused on budget and deadlines because they feel that all they have the authority to influence. That’s clearly not ideal.

For the R2 programme removing legacy systems was an acknowledged success factor. Unfortunately for many technical people it was also acknowledged not to be critical. This certainly influenced prioritisation, and we ended up not decommissioning as much as we’d have liked. A shame for the techies, but we knew we had achieved success overall.

Leaders are responsible for balance

Given that individuals have their own success factors, it’s a leadership responsibility to ensure the right balance is achieved, particularly when there are obvious conflicts. A team lead must balance between feature delivery and test time. A project manager must balance between supplier responsibility and internal effort. A programme manager must balance between budget pressure and ease of business change. The governance group must balance between stated objectives and new opportunities.

Throughout the work there will be conflicts of objective, and the entire project depends on those individuals sitting above the level of the conflict to make a decision and keep it going in the right direction. This is a responsibility of leadership.

Application to the financial year

We’ve been focused mainly on critical success factors for projects: time-limited activities with ringfenced budget. But critical success factors can equally apply to a company’s financial year. If you’re budgeting for something shouldn’t you be defining success criteria for it? And if you’re budgeting for a 12 month period, shouldn’t you be defining success criteria for that 12 month period? If not it’s a gift, not an investment.

So, a lot to think about. But perhaps one thing stands out among all these: actually knowing what your success factors are is the essential first step.

1. It only exists when it’s live

The point here is that you can’t get people’s full attention unless it’s actually live. That’s virtually a law of physics. The way to fight this is to deliver early and often: start making it real for people as soon as possible, get something out there quickly so they can use it and feel what it’s like, and then build up.

2. It’s nobody’s fault but yours

This is a law of the land, and you can get a change in legislation. If people work in silos then it’ll be easy to finger-point when things go wrong. If people are brought together from across the organisation and are jointly responsible for the project being a success, then there’s a much better chance of success happening. This is because there is much greater cohesion between people with different expertise, which means more fluid communication and much less loss of understanding. So problems are less likely. And when they do happen then you can expect a much more productive reaction from all involved.

3. No-one has thought about [some critical function]

Again, this is a law that can be changed: find out early who all the stakeholders are, and make sure they’re involved. This is a pain, because it’s much easier to get a project going when there are fewer dependencies or teams involved. But inconveniently projects are judged a success at the end, not at the start. So it’s worth foregoing a bit of pain at start — socialising the ideas, seeing who needs to be involved, involving them, listening to them, changing your thinking accordingly — to avoid a lot of pain at the end.

4. [Team which does unglamorous but critical work] is always the last to know

Yes, it may be easier to involve some people only at arm’s length, but the inconvenience you’re avoiding early on will have to be repaid with interest. As before, discovering and involving all the stakeholders early is key.

5. Things you want to change are always hard-coded — and vice versa

You can’t please all of the people all of the time. But you can choose a small number of people and make the system flexible for them. And then you can extend your system a bit so that it pleases a few more people. And then you can continue to extend and expand, including more and more people, and adding more and more flexibility in just the right places to please them, until… well, hopefully everyone agrees it’s okay to stop.

For this approach to work you do have to make sure you have the capability to adapt your system. If you’ve chosen to buy then you need to know it’s sufficiently flexible for your needs, and where it doesn’t flex (or you’ve chosen not to flex it) then you need to make sure you communicate the limitations to all the relevant people. If you’ve chosen to build then you need to make sure you have the skills to build effectively.

6. Your system will always be out of date

Every project is a response to the wider business environment. And the business environment will never stop changing. So the question to ask is: If this project is a response to business change, and the business environment is changing constantly, what resources do we need to continue to put into this system after the project is complete to ensure it continues to keep pace with the moving target it was aimed at in the first place?

I’d say almost any answer is acceptable, including “We’re happy for it start falling behind the moment it goes live, because that bit of our business isn’t the most important part”. That particular answer will probably upset some staff, but the main thing is it’s a conscious decision. What will lead to problems is not answering the question at all.

Mind you, it’s also possible to get that answer wrong. Or, more likely, to incorrectly predict the pace of business change. If that’s a possibility then acknowledging the risk should help secure additional resources in the future.

It became apparent to me that much digital media advice for non-technical people really needs to come with a very strong health warning. Here’s one taken from a prescription medicine I’ve just retrieved from my bathroom. It needed only very light editing and seems quite appropriate:

REMEMBER this advice was prescribed only for you. Only a digital professional can prescribe it. NEVER give it to someone else to use even if you think their project is similar.

Looking at Ryan’s blog the advice is for “dealing with developers and choosing a platform for your [Knight News Challenge] project”. As a previous winner of the KNC he should know what he’s talking about here. Unfortunately in the process of being prepared for the KNC blog its intent seems to have been overstated. It is not, unfortunately, advice on “how to manage technology decisions in 5 easy steps” — which is a shame, because I and a lot people I know could do with easy answers to hard technology decisions. Nor does it provide guidance on “How to hire developers”, as the intro suggests, unless you’re hiring one or two developers specifically for the KNC.

This may sound flippant (perhaps, admittedly, because it is) but there is a serious point here. I suspect there are going to be many more people following the KNC than there are participating, and I think a lot of those followers will be people in the process of embracing digital media projects for the very first time, and will be looking for guidance. Perhaps they are just starting on digital projects within their current traditional media companies. They will need good guidance so they can make a reasonable success of their early projects and so feel confident about getting more involved. The media industry needs those people to be successful.

But taking the right advice for the wrong project will lead to problems. Here are some instances of Ryan’s advice and where your (or a colleague’s) situation might require something different…

1. Learn a little bit about any one Web framework, standard, or programming language

If you’re leading a 2 or 3 person team then it’s a good idea to understand the technologies your team members are using. But you may find yourself in a slightly different position in a larger team. In that case the level of conversation you need to have with people will be different. If the technology being used is fairly complex then deep-diving into a particular web framework or programming language is going to be far less useful than having, say, a good overview of the technologies involved and why they’re important — if only so that you can ask appropriate questions and deal with the answers appropriately.

2. Choose the people you want to work with and spend an ample amount of time telling them what you want.

I’d never disagree with the “ample amount of time” part — if you don’t dedicate a lot time to your project don’t expect it to go the way you want. But the “telling” part will only get you so far. It will probably work very well if you’ve become an expert in a particular web framework which is the basis of your project, and if you’ve hired someone with less experience there. But if your situation is different your approach should be different. For anything ambitious or complex or imaginative the development will be an evolving two-way conversation, not a one-way monologue in which you’re telling someone what to do.

So, lots of good advice on the KNC blog for participants of the Knight News Challenge. But if you’re sitting on the sidelines you should not mistake the demands of the Challenge as being the same as the demands of whichever project you happen to be working on next. Get advice that’s been prescribed specifically for you.

This information has been provided free of charge under the National Digital Health Service.

Actually, it wasn’t that indirect. In January and February 2007 planned all the work that was to follow the launch of the Travel section, which had gone out in November 2006. From our senior stakeholders we sought the business priorities, and there were two major milestones: changing the home page of guardian.co.uk would send the clearest public signal of intent (even though it was only one page), and launching our news content in the new design would demonstrate the depth, extent and utility of the transformation. So those were our two major targets.

But there was another major requirement running through all our launches, and that is that they should be sufficiently comprehensive and largely complete at the moment of launch — there shouldn’t be any obviously missing features or tools. Since the news agenda is both urgent and highly volatile the news desk needed a comprehensive set of tools with strong integration to be able to deal with the daily demand. That included polls, improved galleries, an audio player with better podcast integration, a wider range of layout templates, many more navigational components, more streamlined tools, cartoon pages, very flexible keyword management, and much more.

It was, in total, around a year’s worth of work, so getting there directly would have meant no major launches — no tangible benefits — for a year, and that just wasn’t on. Agile development is about providing value early. To deal with this problem we exploited that fact that many sections, such as Science and Media, would benefit greatly from early launches and wouldn’t need such a comprehesive featureset as News from the word go. And developing those other sections would help build up towards News. We then calculated that if we wanted to get to the News launch with a detour through those other launches then it was a difference of only 6%.

Clearly there were big wins all round. Many sections were launched early so those desks got the benefits early; the commercial team was able to make use of the flexible advertising early; the technology going to the news desk was tested and refined well ahead of launch; and the risks normally inherent in a big bang launch were drastically reduced.

Speaking personally, I found the launch of the News section surprisingly muted. Lots of the public excitement and discussion around the reworking of our site had occurred when we launched the front page many months before, and continued in varying forms with the release of each subsequent section. By the time we got to the News section it was much less startling to those outside looking in. But in terms of internal change so much traffic goes through the News section, and it involves so many people working with it each day, it was very significant. Frankly, big launches which happen with so little fuss is something I’m very happy to live with.