Web Development

Our forums are currently in maintenance mode and the ability to post is disabled. We will be back up and running as soon as possible. Thanks for your patience!

General discussion


Agile Delivery at British Telecom

By martinig ·
This article describes the approach used by British Telecom to move towards an Agile development process


This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Agile or Faster Waterfall?

by Wayne M. In reply to Agile Delivery at British ...

Although I would like to actually investigate British Telcom's success before weighing in, I question whether they will adopt and continue to use agile practices. I am concerned that merely reducing delivery schedules without changing the development process and infrastructure will eventually lead to rejection of agile.

My concern is that reducing delivery cycles without implementing new practices only results in a faster waterfall with all of the inherent problems discussed in part one of the article. I also note that in the first paragraph of part 3, the author notes, "...most programmes are NOW seeking ways of refining their delivery processes further by adopting truly iterative & test-driven development paractices within each delivery cycle (emphasis mine)." Following that paragraph are several bullet points, some giving good advice, but some being agile misconceptions.

Contrary to the second bullet point, test-driven design is equally valid with legacy code. Changes to legacy code will be tested, so it is far more beneficial to create tests for the affected code (not the entire code base) prior to making changes. This locks down the existing functionality and gives the developers the ability to make clean changes to the code instead of relying on the minimal patch and crossed fingers.

The third bullet point states "... refactoring of an enterprise architecture simply isn't practical." Unless one has fully defined an enterprise architecture and can ensure the current system environment will remain the same for all time, then changes to the enterprise architecture are ineveitable. The alternative to refactoring is the massive "forklift" upgrade; this is the approach that has failed spectacularly time after time. It is refactoring, the gradual implementation of changes over time, that provides the low risk method to change the enterprise architecture. Enterprise architectures need to evolve and refactoring is the means to do it.

The first bullet, however, shows the proper approach for establishing agile approaches. First teach and train your people on how perform agile practices. Second, adapt the organization to agile practices (requirements analysts, architects, developers, and testers are no longer independent roles in separate departments). Do the first two, and short development cycles will result. Reduce the development cycles without providing the necessary skills and environment will only lead to stress and rejection of the approach.

Related Discussions

Related Forums