Agile Delivery at British Telecom - Part 2

Ian Evans, British Telecom

Agile Development

Although not intended to be a "silver bullet", Agile Development should help resolve these problems. For example,

• Focussing only on what's really important to the business will help overcome the tendency to want to document all requirements up-front. Techniques such as User Stories [2] often proves helpful here.
• Involving your customer as part of your team certainly helps ensure that the solution is developed in line with expectations, and doesn't incur too many surprises once completed
• Developing in short iterative cycles again helps to break the problem down into more manageable chunks, and allows feedback to be gleaned early and often. The Scrum [3] method, for instance, advocates 30-day cycles.
• Applying a 'test-first' and continuous integration development approach, two of the core practices of XP [4], not only helps to further break down the complexity of the problem but also avoids the 'integration headache' described above

The Challenges of Enterprise Agile

This is all very well when you have a development team of some 10 or 20 people, or if you are implementing agile development on perhaps one of your larger (say, 100 people) projects and have ample mentoring resources at your disposal. Even then, if you're adopting Agile for the first time, you have the challenge of changing people's mindsets, aligning the new practices with a supportive customer, while also remembering to successfully deliver the actual project.

For most large organisations, architectural considerations also need to be addressed. Also, no doubt a high proportion of the code base is probably implemented in the form of third-party Commercial Off-The Shelf (COTS) components. On top of this, you then have the added complexities of off-shore development, widely distributed in-house resource, an IT department that is probably not highly regarded within the business, plus a whole pile of legacy code for which tests probably don't exist in any shape or form let alone automated.

Finally, your programme has significant business commitments to make, and little scope to take on the added risk of adopting new practices. So where do you start?

Scaling to the Enterprise - The BT Approach

At BT, the drive towards agile delivery started with an uncompromising determination to introduce shorter delivery cycles across the entire delivery programme portfolio, establish a ruthless focus on delivering real business and end-customer value, and to nurture a strong collaborative ethos between the IT and Business communities.

90-day cycles

With more or less immediate effect, all delivery programmes were required to adopt a standard 90-day delivery cycle. That is, having picked up one or more distinct business problems on day 1, a working solution is expected to be available, fully-tested, for deployment by the end of the remaining 90 calendar days. For BT, this represented a seismic shift from the 12+ month delivery cycles that were previously commonplace.

Each 90-day cycle is kick-started by an intensive 3-day "hot house" in which cross-functional teams explore one or more business problems in some detail, with the main stakeholder(s) usually being at hand to resolve any queries. Out of each hot house, the intention is that one or more working prototypes are produced which, if accepted by the stakeholder, forms the basis of the development activity for the remainder of the cycle.

For the remainder of each cycle, the intention is that wherever practical, programmes pursue agile development practices such as more fine-grained iterative development (e.g. 2 - 4 weeks),

Step 2 - Focus on Delivering Business Value

Early in each delivery cycle, the programme sets out clear targets for what it expects to achieve for the business during that cycle. These targets invariably include a strong emphasis on the end-customer experience, such as overall response times, transaction success rates, and so on. At the end of the cycle, the programme is assessed against these targets, and the outcome of this assessment will influence the timing of bonus payments for the programme team members. Programmes failing to deliver business value over a series of cycles face being closed down altogether.

This of course places a certain amount of pressure on the (internal) customer to be clear about the business priorities and the features that would provide the greatest return on investment. It also requires that the customer is ready and able to deploy the solutions into the business and realise the intended benefits. In practice, programmes often take two or more 90-day cycles to progress a particular solution to a point where it is fit for deployment. Even so, there is an opportunity at the end of each cycle to assess what has been delivered so far, and to provide feedback based on what has already been developed.

Step 3 - Instil a Collaborative approach

Truly successful programmes require a strong partnership approach between the business customer and the development community. Within BT, close collaboration is established at the outset of each project through attendance at the hot houses. The onus is then on the programme teams to ensure this collaboration continues throughout the delivery cycle through design walkthrough sessions, prototype reviews, and so on.

In practice, the end-user representatives you want to have at your hot house are also the ones who are hardest to release from operational duties. With several programmes running numerous hot houses during the course of a year, this problem can quickly become compounded and often makes it extremely difficult to achieve true collaboration on a day-to-day basis. However, collective ownership of the eventual solution needs to become the accepted norm, and any practical steps to enhance collaboration should be taken.

Page 1    Page 3    Back to the archive list