I found this interesting case study @ methodsandtools website. It talks about how Agile practices were introduced and implemented in British telecom.
Introduction from the ArticleIt is becoming clear, not least from the pages of this publication, that agile development methods are being adopted or at least considered by a growing number of software development teams & organisations. Whether you are already an active practitioner agile development, or considering its adoption on your project, you will be aware of the business benefits that can be derived through faster and more effective software delivery not to mention the motivational impact it can have on development teams. Alternatively, maybe you work for a large organisation that has yet to make any serious inroads into agile development, and are left wondering how agility could be made to work on a large scale.Observations 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.