91Èȱ¬

1. We often have fixed deadlines aligned to the broadcast schedule that we can't miss - for example Wimbledon is traditionally a major event in our development calendar. This year we've also got the Olympics. In order to guarantee we meet this, we adopt the 'fixed deadline, variable scope' philosophy of agile. This takes advantage of the malleability of software construction compared to hardware, and guarantees that we can deliver in time for the deadline.

2. It's possible to get hung up on the agile artefacts (burndowns, story cards, backlogs etc) and lose the essence of why agile's being used. I've observed projects which on the surface claim to be agile since they have the right artefacts, and yet have adopted 'fixed-scope, fixed-time' as the planning philosophy. You'll see the changes in style of the burndowns above. This is an example of fiddling around with Excel - in this case I added extra lines or columns, which I wouldn't have done had I been hand-drawing them. I'll admit the hassle wasn't actually worth it -they don't add anything useful to the information being conveyed, and distracted me from the project. The message is: don't get into an agile rut, and remember it's meant to be light-weight.

3. Small projects are preferred to big ones. We built our in-house authoring tools over many releases. This gives us the agileness of agile - that our clients change their minds, so we allow for that. This is particularly suited to a media company such as ourselves, where most times we wouldn't expect our internal clients to write formal specs up-front. The Two Stream Quiz was built over around 6-7 separate build projects over several years. Smaller projects also ensure the engineering team have variety, which is always welcome.

Use of Fitnesse on our Freesat build, use to write automated acceptance tests. This reduces the need for manual regression testing.

Here the Freesat unit tests are run in CruiseControl

4. Automation is great. The engineering team here have implemented automated integration using , and packaging using s over the last year. In tandem with acceptance tests (in ) this gives us robust development, and allows us to change the functionality of a product over many builds and retain the confidence that prior functionality still works.

5. Agile development doesn't give us everything a project needs - classic project management techniques such as stakeholder management and risk management are still needed. Product and architecture roadmaps are also needed in order to supply a strategic direction and general themes, for example 'automation' or 'skinnability'. Here, we still have post-build testing as well as unit tests and acceptance tests, since we need to check the viewer experience on many different set-top boxes.

6. Agile isn't always appropriate. An example is when we're adding support for a new platform to an existing product. We want the same repertoire of functionality on the new platform, rather than a subset, and we want the functionality and viewer experience to be the same (as much as possible). In this case waterfall development is a good model, wit the previously implemented platforms being used as a working spec.

7. Beyond agile - it's not just the build: we've created a support team to support the full lifecycle of our products and services. In hindsight, this is a classic part of . We have to remember, with every new service we build, we're going to have to maintain and support it, probably for years, and our capacity for this needs to be planned.

Whilst we've had a lot of experience here with agile development, we've still got a lot to do. Over the last year we've adopted test-driven development for Freeview and Freesat using our new MHEG unit test framework. However, we're still not fully test-driven on our cable and OpenTV development - this'll need developmental effort and time.

Many thanks to my predecessors in TV Platforms Group, Chris Young and Karl Scotland, who started agile development and test-driven development in the department in 2000-2001.

Comments

The following comments were originally posted on the 91Èȱ¬i Labs blog

At 1:16pm on 20 Aug 2008, hmsberlin wrote:

Don't give up on this blog. This might me the first comment in 21 days, but thats just because burndowns aren't exciting.

At 01:47am on 22 Aug 2008, Garrif wrote:

When will interactive services be avalible on the Freesat version of 91Èȱ¬ HD?

At 1:26pm on 01 Sep 2008, Andrew Bowden wrote:

hmsberlin - there's been a brief hiatus caused by Rob (who was looking after it all) moving to a different department) but we will return! And how can you say that burndowns aren't that exciting ;)

At 1:46pm on 06 Nov 2008, kswaters wrote:

Who said burndowns aren't exciting! Personally I think they're great :-)

Seriously, this blog post is very informative and it sounds like 91Èȱ¬ is doing great with agile development.

I've been blogging for a while now all about agile (https://www.allaboutagile.com). I also work for a large media company and in that environment I think agile is the only way to go.

Kelly.