Click here to view the complete list of archived articles
This article was originally published in the Summer 2006 issue of Methods & Tools
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 agiledelivery 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-basedthinking. It has also transformed, quite radically, the traditional function ofthe IT department as a supplier of IT services to one where IT is now seen asintegral to all major business initiatives. Above all else, it has created anattitude, 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 trulyagile. For any large organisation, the journey from waterfall to agile can bevery long and challenging. As with other proponents of Agile Development however, few at BT would want to turn back to the old ways.
References
- "Agile & Iterative Development" by Craig Larman, Addison-Wesley (2004) ISBN: 0-13-111155-8
- "Agile Software Development with Scrum" by Ken Schwaber & Mike Beedle, Prentice Hall (2002) ISBN: 0-13-067634-9
- "User Stories Applied for Agile Software Development" by Mike Cohn, Addison Wesley (2004) ISBN: 0321205685
- "Extreme Programming Explained" by Kent Beck & Cynthia Andres, Addison Wesley (2004) ISBN: 0321278658
- "Lean Software Development – An Agile Toolkit" by Mary Poppendieck & Tom Poppendieck, Addison Wesley (2003) ISBN: 0321150783
- Agile Manifesto – http://www.agilemanifesto.org
Page 2 Back to the archive list