Reflections on how an iterative attitude can reduce costs

5 September 2008 (Friday)

As part of the process for trying to get Clever Plugs onto the BBC commissioning roster for on-air graphics, we had to reflect on how we would help the BBC reduce costs. So I wrote the following about why I thought our approach –  iterative,  tendency agile (see e2x’s article on sustainable software for an interesting differentiation here).

We work with the latest technologies and with only the highest standard of multi-disciplinary developers and designers. These are both ways of cutting costs, but can also present risks (latest technologies carry unknowns, highest standard of developers delivery quality, but are expensive). For this reason we find that risk is the highest factor affecting cost, and we dedicate our working practices to controlling and reducing risk within the project, aiming to have a smooth curve in the decline in risk over the course of project’s timeline.

To do this, we use best practices & methodologies from the agile methods of software methodology (see Martin Fowler on the New Methodology and The Agile Manifesto). Overall this means focusing on interactions amongst the team, working software, and collaboration with our customer to achieve the needs of the project over its lifetime.

This leads to practical impact on what we don’t do, what we do do, and then how this reduces cost…

What we don’t do
In particular, we do not believe that it is worth spending a large tranche of time at the beginning of a project, writing up long specification documents, and engaging in back and forth between client and ourselves ironing out these documents until they are perfect. This is because these documents are often a major source of cost drain. Not only do they take time themselves, but they (perhaps somewhat counter intuitively) add to project risk. They seem to promote good understanding  – but with a focus on description of software rather than delivered software – and there is still a large gap (wherein a large risk) between the words of description and the delivery. Until software is actually coded, understanding what is achievable (at a high quality and within a reasonable time span) cannot be known. By fixating on a given specification, easy wins that come up during development cannot be capitalized on, and resources may focus on one hard immovable task. With so much communication and work gone on in the specification phase, during development, teams have a tendency to go uncommunicative. In order to deliver to a fixed feature set contract, punitive change control charges encourage everyone to minimize. Teamwork across client and supplier are discouraged.

What we do do
Of course it is necessary to establish common ground and focus.  We aim to first have a clear shared understanding of the context of the commissioned  project, including its aims and the outcomes and targets for our software. With this high-level view understood, the team (commissioner and supplier together) pick the most critical, small, achievable piece of functionality, and we progress that as soon as possible to working software, and deliver it to the customer. Things that are included in this software are working production quality code. This is not a prototype or mock up, or a rough draft. It is version 1 (of many version). All sorts of things can be added, improved, but the basic code quality is fixed at an initial (high) level. Code is subjeced to automatic tests (the (separate) body of test-code grows and grows through the lifecycle of the project –  a large body of “regression tests” ensuring that new functionality added doesn’t unintentionally remove or corrupt previous functionality).

This means risk has gone down. The gap between expectation and actual delivery has been lessened – so any misunderstandings or wrong directions can be corrected. The next step is to collectively choose – what is missing – why couldn’t this be used as it is? Usually, although many things may come up, one or two are in some way more critical or core to the project. These are then discussed and simply described, coded (and tested) and delivered. This then becomes of cycle of progressive improvement of the technology.

As time passes (in day or in weeks, depending on the agreed schedule of the project), the project team sees the software approach its delivery targets – quality being of a consistent standard, and more functionality being delivered to ongoing specification.

How this reduces cost
Time is not wasted specifying things that cannot or should not or will not be built. Communication gaps are kept to a minimum and forced out into the open as soon as possible. Risk is lowered over the course of the project. Budgets can be fixed and most high priority functionality focused on. Ongoing communications and delivery helps encourage transparency, trust and teamwork.


One Response to “Reflections on how an iterative attitude can reduce costs”

  1. Tim Diggins Says:

    Mark Stringer over at Agile Lab gave some useful critique of this attempt (let’s call it iteration 1) at and gave some useful pointers for iteration 2 (thanks Mark)

Comments are closed.

%d bloggers like this: