Agile Delivery at British Telecom - Part 3

Ian Evans, British Telecom

Early Reflections

Despite some turmoil at the start, and some painful failures among some of the earlier hot houses & delivery cycles, the new practices have now become accepted as the norm across BT. Now well into the second year of its shift from waterfall to agile delivery practices, few people would be willing to revert to pre-Agile practices. In fact, most programmes are now seeking ways of refining their delivery processes further by adopting truly iterative & test-driven development practices within each delivery cycle.

However, some observations would be worth noting.

• Firstly, when you're embarking on an agile delivery strategy at the enterprise level, it is imperative to quickly establish a 'critical mass' of people who not only grasp the ideas behind it but are also comfortable with its application. To establish that critical mass, you will probably need to turn to outside help. A number of consultancies now specialise in the adoption of agile practices within large organisations. BT chose to use two different companies, each of which brought different strengths and perspectives. Further to this, it is also essential to establish a strong central team to provide ad-hoc support, nurture the new techniques, and to actively support the new practices.
• Certain agile practices, such as test-driven development, are harder to adopt when most of your development is based on legacy code and / or externally-sourced components. Similarly, continuous integration becomes extremely complex when some of you main components are shared across multiple programmes. Some of BT's programmes are now pursuing test-first and continuous integration techniques, but this takes time and investment and is only being done on a selective basis.
• For Agile Development to work at the enterprise level, you still need to pay due attention to your systems architecture. "Big Design Up-Front" (BDUF) may not appeal to the agile purist, but re-factoring of an enterprise architecture simply isn't practical.
• Not all delivery activity fits neatly into the agile development model. Given a choice however, the natural tendency is to pursue most activities using the traditional approaches - you can always find some excuse why "the new approach" isn't appropriate on your project. If you go down this road, agile delivery will at best become a niche activity. At BT, a strong mandate ensured that all programmes put the new practices to the test whether this seemed logical or not. This helped to break through the "pain barrier" and to ensure that the new practices were given a real chance of taking hold.
• To be truly effective, the agile approach needs to reach right across the business, not just the IT organisation. You might expect that the business would be excited at the prospect of having regular deliveries of valuable functionality. However, the business also needs to move away from traditional waterfall practices and change how it engages with the IT organisation. It also has to place its trust in the IT organisation (something that certainly takes time) that it will deliver as promised. It then needs to ensure that it is geared up to exploit the deliveries to gain maximum business benefit.
• Finally, remember the old adage - "There's no gain without pain!" Applying the principles described here on large projects or programmes in typical large organisations requires courage, determination, and no small degree of risk. Also, such a radical strategy requires absolute commitment from the very top.

Conclusion

Re-orienting a large IT organisation from pursuing well-established waterfall-based delivery approach to being a truly agile delivery unit takes patience and time, as well as a lot of commitment. In BT, where the initial steps towards enterprise agile delivery were taken late 2004, there has been a noticeable and decisive shift away from waterfall-based thinking. It has also transformed, quite radically, the traditional function of the IT department as a supplier of IT services to one where IT is now seen as integral to all major business initiatives. Above all else, it has created an attitude, bordering on obsession, of delivering real value to the business through IT.

Despite the early successes however, it is clear within BT that there is still a long way to go before it can consider itself to be truly agile. For any large organisation, the journey from waterfall to agile can be very long and challenging. As with other proponents of Agile Development however, few at BT would want to turn back to the old ways.

References

1. "Agile & Iterative Development" by Craig Larman, Addison-Wesley (2004) ISBN: 0-13-111155-8
2. "Agile Software Development with Scrum" by Ken Schwaber & Mike Beedle, Prentice Hall (2002) ISBN: 0-13-067634-9
3. "User Stories Applied for Agile Software Development" by Mike Cohn, Addison Wesley (2004) ISBN: 0321205685
4. "Extreme Programming Explained" by Kent Beck & Cynthia Andres, Addison Wesley (2004) ISBN: 0321278658
5. "Lean Software Development - An Agile Toolkit" by Mary Poppendieck & Tom Poppendieck, Addison Wesley (2003) ISBN: 0321150783
6. Agile Manifesto - http://www.agilemanifesto.org

More Agile Knowledge

Scrum Expert

Agile Tutorials and Videos

Page 2   Back to the archive list