Extreme Programming - DuPont's TIMEBOX (R) development approach.

Author

DuPont's TIMEBOX (R) development approach.

DrWho

2005-02-15, 8:58 pm

This posting is partly in response to a recent posting about DuPont's TIMEBOX(R) process and partly an unplanned dump of related thoughts. I hope you find it interesting. To help you qualify me, I am a bright technical person with 20 years of IT experie
nce working with a wide range of tools on a wide range of platforms, most as an employee of one company. I currently involved in an XP project as a developer (I am learning "true" OOP for the first time).

(TIMEBOX (R) is a registered trademark of DuPont corporation).

About ten years ago, at a Sterling Software conference in San Francisco, pure chance and a bit of good luck put me at a lunch table with the DuPont manager who was responsible for implementing the TIMEBOX process. He was a soft-spoken Jewish fellow who h
ad strong opinions about TIMEBOX's success when used with a full-cycle CASE tool such as IEF or IEW (which was renamed to ADW, KEY:Enterprise, COOL:Enterprise, then CA:Enterprise).

Aside: At the time (1996?), I was managing the development environment for a large development project that was using ADW. One of our consortium partners had given us a sample video tape of a "Computer Channel" broadcast, which happened to be on CASE tool
s and RAD development. "Computer Channel" specialized in privately broadcast, content-rich, dryly produced, once-a-w

coverage of new developments in corporate I.T. topics. The tape I viewed on RAD and CASE had a three-hour "show" on DuPont's experien
ce with both.

It was about 5 minutes into the lunch when I realized that the main "guest" of that show was sitting at the same table. To introduce myself I asked him if he had produced a TV show on RAD development. He was happily surprised to meet someone who had act
ually seen it. Over the next two hours I grilled him on DuPont's experience and came away completely sold on the TIMEBOX idea and put it to use at every opportunity since. There is no question about TIMEBOX's value with CASE tools and the old Informatio
n Engineering approaches, but it definitely works best when you can write the application as a functional, evolving prototype that becomes the final system. How else do you get effective client feedback?

One of the keys to the success of TIMEBOX is that you can involve high-quality clients who would otherwise not be available because asking for them to be involved continuously for more than a month or two is asking them to derail their careers.

Do not underestimate the significance of this point!

Like XP/AGILE, the TIMEBOX approach made scope as much a variable as was practical. TIMEBOX was very heavily focused on treating the client's time as being more valuable to the client than the project; meaning time slots were booked with tact and only wh
en there were specific objectives to be achieved. Less knowledgeable people were involve for routine testing, once again out of respect for the client's need to progress with their career.

In my own experience, getting the wrong clients is a common occurrence and the bigger the project, the greater the chance that you will get the people that the client's department can spare - the one's who don't know enough to be valuable. I have seen t
his happen on a $70M project, where the guy they gave us to be manager of client involvement was so unqualified, his department had run out of places to move him to. The project manager had to continually work around this person, who twice tried to forc
e all communications between developers and clients to be in writing and be reviewed by him before they were acted upon. It took twelve months to convince the VP that he was introducing too much risk by giving us this person and even then, we got him bac
k 12 months later when we needed to involve an additional client.

I have just been trained on XP and am working with consultants on a project that they are managing, and aside from automated testing, see much in common between what DuPont was doing and what we are doing now. One significant difference is that XP stress
es Emergent Design. DuPont and four other companies that were very successful with CASE tools (the only success stories I found at that conference, by the way) were all working out the design issues up front as much as possible by assigning a small, expe
rienced team to work out the technical infrastructure of the application and development environment and to create code templates and macros that automated routine coding tasks BEFORE the development work officially started. This core technical team cont
inued to work on the technical design as the developers cranked out code, so the finished product was very consistent and the code "read" quite well, even though it was innovative in it's design.

One of these companies - who described themselves as the third largest Swiss bank - had just applied this technique to a C++ project that repaced their core banking system. They had amazed their senior management team when a code review team brought in
by Internal Audit found virtually no "spaghetti" code or "cowboy" code and gave the code the higest consistencyand clarity rating they had ever given. The presenters credited their success to their advance design work and to hiring relatively inexperienc
ed C++ programmers - people who would not bring preconceived notions and favourite techniques to the table, but would instead willing follow the templates and work in conjunction with the core design team through the project. They also mentioned that dev
elopers were each assigned to particular templates and produced all code that matched those templates.

I likened this to Henry Ford's idea of bringing the complex craft of auto construction down to the level of the available workers by figuring out the design details then having each worker specialize. Now, I know that Ford's principals are a risky idea w
hen it comes to software, and that software is often "manufactured" once as opposed to cars, which are manufactured in the tens of thousands, but I recognize that the principles of specialization and advance design worked for this bank because C++ GUI pro
gramming is a complex task and specialization was a great way to improve productivity and consistency and to discourage "unwanted inventiveness".

Two of the companies I learned from have recently moved into GUI applications. Both had assigned a user-interface specialist to introduce the client to innovative user-interface elements such as tree views and drag-n-drop features during up-front analysis
& design sessions. In other words, they recognized that the pressure to maintain the burn-down rate on the contracted scope* would limit their opportunities to be innovative, especially as the application's code base was built up, and took specific acti
ons to minimize the amount of emergent design that would take place during coding.

I believe there are some obvious conclusions to draw here about the relative importance of client interaction with evolving code versus emergent design.

*In real life, the basic contract remains as "a specified scope for a specified cost at a specified date with qualify as near-perfect", so as much as XP tells us we are fooling ourselves if we try to fix all four variables, we are fooling ourselves if we
think the client is going to accept anything less than full scope.

During my lunch with the DuPont person, I mentioned that I learning about TIMEBOX from articles by a high-profile industry consultant and asked what his role had been. He had some unexpectedly harsh words about high-priced consultants who attempt to furt
her their careers by putting their name to innovations that that they had little to do with, and mentioned that he had engaged the company lawyers more than once to ensure that TIMEBOX was properly respected as a trademark of DuPont.

(The consultant in question was NOT Martin Fowler)

Anonymous,
Canada

Shane Mingins

2005-02-16, 3:58 am

"DrWho" <DrWho@daleks.ca> wrote in message
news:K9wQd.399975$8l.377096@pd7tw1no...
>
> I likened this to Henry Ford's idea of bringing the complex craft of auto
construction down to the level of the available workers by figuring out the
design details then having each worker specialize.

Correct me if I am wrong ... but weren't the American car company's hammered
by the Japanese and what was then called JIT Manufacturing? And then what
is now called Lean Manufacturing and Lean Thinking attributes part of its
success to allowing the workers to figure out the design details.

http://www.poppendieck.com/overview..._Responsibility

Regards
Shane

--
“Traditional scientific method has always been at the very best, 20-20
hindsight.
It's good for seeing where you've been. It's good for testing the truth of
what you think
you know, but it can't tell you where you ought to go.”

- Robert M. Pirsig (1928 - ) -
US novelist, writer

Isaac Gouy

2005-02-16, 3:58 am

Thanks, the story was interesting to me.

-snip-
> Over the next two hours I grilled him on DuPont's experience and
> came away completely sold on the TIMEBOX idea and put it to use at
> every opportunity since. There is no question about TIMEBOX's value
> with CASE tools and the old Information Engineering approaches, but
> it definitely works best when you can write the application as a
> functional, evolving prototype that becomes the final system. How
> else do you get effective client feedback?

I've heard the name Scott Shultz in reference to DuPont's TIMEBOX(R) -
was that who you talked with at lunch?

DrWho

2005-02-17, 8:57 pm

I can't remember his name. I took a look through my old VHS tapes, but it looks like I tossed that one out. I might still have his business card at the office. If I do, I'll post a follow-up.

John Roth

2005-02-18, 3:57 pm

Interesting.

I think it bears repeating that conventional "one delivery at the
end of the project" techniques have two major flaws:

1. Delivering the wrong system
2. Delivering a system too late to be relevant.

Timebox (R) sounds like another cut at an agile
process. The earliest cut at this (at least the one
that gets all the ink) is Spiral.

The critical issue in any incremental development
process is making sure that the product code
keeps the same level of maintainability throughout
the life of the project. If the level of maintainability
drops too far, the project will fail before it completes.

The process you describe certainly sounds like it
addressed that issue in the context of an otherwise
conventional process.

XP, of course, addresses the same issues in
a rather different manner. There is always more
than one way to skin a cat.

John Roth

"DrWho" <DrWho@daleks.ca> wrote in message
news:K9wQd.399975$8l.377096@pd7tw1no...
> This posting is partly in response to a recent posting about DuPont's
> TIMEBOX(R) process and partly an unplanned dump of related thoughts. I
> hope you find it interesting. To help you qualify me, I am a bright
> technical person with 20 years of IT experience working with a wide range
> of tools on a wide range of platforms, most as an employee of one company.
> I currently involved in an XP project as a developer (I am learning "true"
> OOP for the first time).
>
> (TIMEBOX (R) is a registered trademark of DuPont corporation).
>
> About ten years ago, at a Sterling Software conference in San Francisco,
> pure chance and a bit of good luck put me at a lunch table with the DuPont
> manager who was responsible for implementing the TIMEBOX process. He was
> a soft-spoken Jewish fellow who had strong opinions about TIMEBOX's
> success when used with a full-cycle CASE tool such as IEF or IEW (which
> was renamed to ADW, KEY:Enterprise, COOL:Enterprise, then CA:Enterprise).
>
> Aside: At the time (1996?), I was managing the development environment for
> a large development project that was using ADW. One of our consortium
> partners had given us a sample video tape of a "Computer Channel"
> broadcast, which happened to be on CASE tools and RAD development.
> "Computer Channel" specialized in privately broadcast, content-rich, dryly
> produced, once-a-w

coverage of new developments in corporate I.T.
> topics. The tape I viewed on RAD and CASE had a three-hour "show" on
> DuPont's experience with both.
>
> It was about 5 minutes into the lunch when I realized that the main
> "guest" of that show was sitting at the same table. To introduce myself I
> asked him if he had produced a TV show on RAD development. He was happily
> surprised to meet someone who had actually seen it. Over the next two
> hours I grilled him on DuPont's experience and came away completely sold
> on the TIMEBOX idea and put it to use at every opportunity since. There
> is no question about TIMEBOX's value with CASE tools and the old
> Information Engineering approaches, but it definitely works best when you
> can write the application as a functional, evolving prototype that becomes
> the final system. How else do you get effective client feedback?
>
> One of the keys to the success of TIMEBOX is that you can involve
> high-quality clients who would otherwise not be available because asking
> for them to be involved continuously for more than a month or two is
> asking them to derail their careers.
>
> Do not underestimate the significance of this point!
>
> Like XP/AGILE, the TIMEBOX approach made scope as much a variable as was
> practical. TIMEBOX was very heavily focused on treating the client's time
> as being more valuable to the client than the project; meaning time slots
> were booked with tact and only when there were specific objectives to be
> achieved. Less knowledgeable people were involve for routine testing,
> once again out of respect for the client's need to progress with their
> career.
>
> In my own experience, getting the wrong clients is a common occurrence and
> the bigger the project, the greater the chance that you will get the
> people that the client's department can spare - the one's who don't know
> enough to be valuable. I have seen this happen on a $70M project, where
> the guy they gave us to be manager of client involvement was so
> unqualified, his department had run out of places to move him to. The
> project manager had to continually work around this person, who twice
> tried to force all communications between developers and clients to be in
> writing and be reviewed by him before they were acted upon. It took
> twelve months to convince the VP that he was introducing too much risk by
> giving us this person and even then, we got him back 12 months later when
> we needed to involve an additional client.
>
> I have just been trained on XP and am working with consultants on a
> project that they are managing, and aside from automated testing, see much
> in common between what DuPont was doing and what we are doing now. One
> significant difference is that XP stresses Emergent Design. DuPont and
> four other companies that were very successful with CASE tools (the only
> success stories I found at that conference, by the way) were all working
> out the design issues up front as much as possible by assigning a small,
> experienced team to work out the technical infrastructure of the
> application and development environment and to create code templates and
> macros that automated routine coding tasks BEFORE the development work
> officially started. This core technical team continued to work on the
> technical design as the developers cranked out code, so the finished
> product was very consistent and the code "read" quite well, even though it
> was innovative in it's design.
>
> One of these companies - who described themselves as the third largest
> Swiss bank - had just applied this technique to a C++ project that repaced
> their core banking system. They had amazed their senior management team
> when a code review team brought in by Internal Audit found virtually no
> "spaghetti" code or "cowboy" code and gave the code the higest
> consistencyand clarity rating they had ever given. The presenters
> credited their success to their advance design work and to hiring
> relatively inexperienced C++ programmers - people who would not bring
> preconceived notions and favourite techniques to the table, but would
> instead willing follow the templates and work in conjunction with the core
> design team through the project. They also mentioned that developers were
> each assigned to particular templates and produced all code that matched
> those templates.
>
> I likened this to Henry Ford's idea of bringing the complex craft of auto
> construction down to the level of the available workers by figuring out
> the design details then having each worker specialize. Now, I know that
> Ford's principals are a risky idea when it comes to software, and that
> software is often "manufactured" once as opposed to cars, which are
> manufactured in the tens of thousands, but I recognize that the principles
> of specialization and advance design worked for this bank because C++ GUI
> programming is a complex task and specialization was a great way to
> improve productivity and consistency and to discourage "unwanted
> inventiveness".
>
> Two of the companies I learned from have recently moved into GUI
> applications. Both had assigned a user-interface specialist to introduce
> the client to innovative user-interface elements such as tree views and
> drag-n-drop features during up-front analysis & design sessions. In other
> words, they recognized that the pressure to maintain the burn-down rate on
> the contracted scope* would limit their opportunities to be innovative,
> especially as the application's code base was built up, and took specific
> actions to minimize the amount of emergent design that would take place
> during coding.
>
> I believe there are some obvious conclusions to draw here about the
> relative importance of client interaction with evolving code versus
> emergent design.
>
> *In real life, the basic contract remains as "a specified scope for a
> specified cost at a specified date with qualify as near-perfect", so as
> much as XP tells us we are fooling ourselves if we try to fix all four
> variables, we are fooling ourselves if we think the client is going to
> accept anything less than full scope.
>
> During my lunch with the DuPont person, I mentioned that I learning about
> TIMEBOX from articles by a high-profile industry consultant and asked what
> his role had been. He had some unexpectedly harsh words about high-priced
> consultants who attempt to further their careers by putting their name to
> innovations that that they had little to do with, and mentioned that he
> had engaged the company lawyers more than once to ensure that TIMEBOX was
> properly respected as a trademark of DuPont.
>
> (The consultant in question was NOT Martin Fowler)
>
> Anonymous,
> Canada

Isaac Gouy

2005-02-28, 8:57 pm

John Roth wrote:
> Interesting.
>
> I think it bears repeating that conventional "one delivery at the
> end of the project" techniques have two major flaws:
>
> 1. Delivering the wrong system
> 2. Delivering a system too late to be relevant.
>
> Timebox (R) sounds like another cut at an agile
> process. The earliest cut at this (at least the one
> that gets all the ink) is Spiral.
>
> The critical issue in any incremental development
> process is making sure that the product code
> keeps the same level of maintainability throughout
> the life of the project. If the level of maintainability
> drops too far, the project will fail before it completes.
>
> The process you describe certainly sounds like it
> addressed that issue in the context of an otherwise
> conventional process.
>
> XP, of course, addresses the same issues in
> a rather different manner. There is always more
> than one way to skin a cat.

Indeed, there's more than one way to skin a cat - and maybe one-way is
more appropriate for a tiger and another-way more for a domestic tabby.

Seems a long time ago that JAD became a way to avoid "delivering the
wrong system".
http://www.thefacilitator.com/cgi-b...orbusinessplans

And then we have "The Ten Commandments of RAD" James M. Kerr, "Database
Programming and Design" May 1991.
1. Thou shalt narrow thy scope.
2. Thou shalt keep thy teams small and focused.
3. Thou shalt require full-time user participation.
4. Thou shalt empower the RAD team.
5. Thou shalt prevent burnout.
6. Thou shalt hire consultants when necessary.
7. Thou shalt use CASE technology.
8. Thou shalt establish a RAD Control Panel.
9. Thou shalt reward success.
10. Thou shalt not tolerate quick and dirty development.

Sponsored Links