Extreme Programming - Re: Article on Agile Adoption at British Telecom

Author

Re: Article on Agile Adoption at British Telecom

Phlip

2006-07-26, 7:57 am

editormt wrote:

> The Methods & Tools newsletter has just released in its archive section
> the article "Agile Delivery at British Telecom". This article describes
> the approach used by British Telecom to move towards an Agile
> development process
>
> http://www.methodsandtools.com/arch...chive.php?id=43

Thanks! This explores one answer to the question "how to make 'Agile' scale
to large teams?"

Firstly, note that replacing Waterfall required obtaining a new CIO. That's
a profound commentary on human nature, when folks with C in their titles are
so endlessly capable of damaging an organization by giving bad orders, which
are then followed mindlessly.

Next British Telecom has >8,000 IT employees. The article does not discuss
starting projects with small teams. BT's pre-existing teams already have
core competencies to leverage. So, instead, the team-of-teams follows the
Scrum practice of "synchronizing iterations":

'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 w

s).'

Note that without 2-4 w

iterations within a team, the 90-day release
cycle would devolve back into mini-Waterfall. The paper's author, Ian Evans,
credits the 90-day releases for stabilizing development. We should suspect
that 2 w

iterations had a bigger impact.

--
Phlip
[url]http://c2.com/cgi/wiki?Z

Land[/url] <-- NOT a blog!!!

S Perryman

2006-07-26, 6:58 pm

"Phlip" <phlipcpp@yahoo.com> wrote in message
news:SkKxg.73126$fb2.58002@newssvr27.news.prodigy.net...

> editormt wrote:

[color=darkred]
[color=darkred]
> Thanks! This explores one answer to the question "how to make 'Agile'
> scale to large teams?"

Usenets' XP muppet is off again. And as always, serious selective editing.

#include <IsaacGuoy.h>

<quote>

Drawbacks of the waterfall

Reinforcement of current waterfall-based practices was not really the
answer however. Many of the delivery problems experienced at BT, and no
doubt
other large organisations, stem from the nature of the waterfall lifecycle
itself. Some examples of these problems are given here. For a more complete
demolition of waterfall practices, refer to Craig Larman's excellent
work [1].

</quote>

Is this the "excellent work" whose conclusions relating to the efficacy
of "Agile" methods based on referenced source material has in fact been
subject to a "complete demolition" by people who actually read said
source material. And a demolition that has been acknowledged by the
author himself ... ??

No doubt similar Larman-esque replies to come once people have actually read
the entire article.

But before then, Usenets' XP muppet is of course aware of the fact that BT
is one
of my previous clients, and that I am in contact with several people who
work on
their systems development. So which specific BT systems would the muppet
like to discuss with us ... ??

Regards,
Steven Perryman

Bjorn Reese

2006-07-26, 6:58 pm

Phlip wrote:

> Thanks! This explores one answer to the question "how to make 'Agile' scale
> to large teams?"

And finds that...

<quote>
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.
</quote>

--
mail1dotstofanetdotdk

Phlip

2006-07-26, 6:58 pm

Bjorn Reese wrote:

>
> And finds that...
>
> <quote>
> 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.
> </quote>

Right. Legacy code has an existing design that must be respected. They now
use Small-Design Up Front.

It seems their biggest gain came from defeating BigRequirementsUpFront. They
no longer work in huge, over-specified batches of one year.

--
Phlip
[url]http://c2.com/cgi/wiki?Z

Land[/url] <-- NOT a blog!!!

Bjorn Reese

2006-07-27, 6:58 pm

Phlip wrote:

> Right. Legacy code has an existing design that must be respected. They now
> use Small-Design Up Front.

Where does he say that he is talking about legacy code, and that they
are using "Small-Design Up Front" now?

--
mail1dotstofanetdotdk

Phlip

2006-07-27, 6:58 pm

Bjorn Reese wrote:

> Phlip wrote:
>
>
> Where does he say that he is talking about legacy code,

They don't say they re-wrote from scratch, so I might ass-ume they keep
their existing code. Hence it is "legacy code".

Sometimes that means code without unit tests. The author concurs that their
"before" process suffered "the lack of any effective regression test
capability", so they agree with that meaning.

> and that they
> are using "Small-Design Up Front" now?

"For most large organisations, architectural considerations also need to be
addressed..."

'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.'

If this were completely "Agile", it would obey "emergent design". The team
of teams would agree on goals and interfaces, yet they would not run a
prototyping phase. One might infer this "hot house" technique represents
some small amount of up-front design. Otherwise what exactly are they doing
for those three days?

I'm unsure what you think my, or the author's, point is regarding small
design up front. I suspect I agree with the author that it's mostly
harmless, and that the biggest boost (so far) came from switching from Big
Requirements Up Front to Small Requirements Up Front.

One year to one quarter, with test-first, provided a boost big enough to
receive executive notice, and such.

--
Phlip
[url]http://c2.com/cgi/wiki?Z

Land[/url] <-- NOT a blog!!!

Sponsored Links