32 burndowns
- 31 Jul 08, 2:49 PM
Hello! The image above shows the burndown charts we use to track project progress - the period covered is from sometime in 2003 to mid 2007. Burndown charts are one of the artefacts used in ; we've been doing agile development since at least before I joined, and we've found it works tremendously well. I'll share some personal insights here.
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.
© MMVIII
Comments