Process question - Trying to move a document driven organization to Risk-Driven/RUP/XP
Craig Garrett
want to move my organization from a document-driven process to a more
risk-driven environment. My organization currently uses a process that was
built/copied from MIL-STD-498 with CMM-Level 3 compliance in mind (this was
in the 1995-1997 timeframe). What resulted was a process that was
completely driven by documentation and lost all focus on product quality and
customer satisfaction (I have no one to blame except the personnel in my
organization at that time, many of whom are still here).
A short review of our process follows:
Customer provides a Mission Needs Document to management
Developers write a Requirements Document
Developers and Customers review the Requirements Document
Managers and Developers create the Software Development Plan
Developers write and review the High-Level Design Document
Developers write and review the Low-Level Design Document
Developers write the code and perform unit/integration testing
Testers test the software and write the Test Report
Configuration Management releases the software to the customers
Note that the purpose of almost every step is to "write a document". Also,
this process is entirely step-wise waterfall. By that, I mean that no
design can happen until 100% of the requirements are gathered and
documented. No coding can happen until 100% of the design is finished and
documented. Everyone (especially me) understands how important
documentation is (primarily for future maintenance), but our process does
not address prototyping, risk management, etc. As one might expect, this
attitude/focus has created some spectacular software failures in my
organization (of about 50 programmers plus 30 overhead).
So that is what we have currently. And now, I want to incorporate RUP
(Rational Unified Process) into my organization. In short, I want to move
our organization and process away from being document driven to being risk
driven. Problem: all of our process infrastructure (management insight,
milestones, SQA/SPA Audits, Configuration Management, etc.) are all based
upon document driven assumptions. I am looking for advice on how to
implement a risk-driven process (like RUP). I have the opportunity to
present ideas to management, as well as submit changes to our process.
Comments are appreciated.
Craig Garrett
Software Engineer, MIS Applications
cgar...@cox.net
David B Lightstone
"Craig Garrett" <cgarrett4@no_spam_cox.net> wrote in message
news:NmuI8.91405$Md6.3...@news1.east.cox.net...
The theory is that nothing starts before the previous effort in the water fall
has been completed. Now just what has the reality been? Quite often there is a
need to keep the junior programmers busy, so off they go coding up in
anticipation of the Low Level Design Document being acceptable. Do you really
have the proverbial waterfall? That is are you trolling, or just don't know how
your organization actually is developing things. (the skepticism is based upon
once being at an SEI LEvel 3 certified oranization ceased following its own
process and was apparently long overdue for decertification)
>
> So that is what we have currently. And now, I want to incorporate RUP
> (Rational Unified Process) into my organization. In short, I want to move
> our organization and process away from being document driven to being risk
> driven.
With XP you definitely get driven by risks. They just may not be the managed
risks you want. Take the time and review the works of Marytn Ould titled
Managing Software Quality and Business Risk
John Roth
"Craig Garrett" <cgarrett4@no_spam_cox.net> wrote in message
news:NmuI8.91405$Md6.3...@news1.east.cox.net...
processes. I
> want to move my organization from a document-driven process to a more
> risk-driven environment. My organization currently uses a process
that was
> built/copied from MIL-STD-498 with CMM-Level 3 compliance in mind
(this was
> in the 1995-1997 timeframe). What resulted was a process that was
> completely driven by documentation and lost all focus on product
quality and
> customer satisfaction (I have no one to blame except the personnel in
my
> organization at that time, many of whom are still here).
You're going to get some very conflicting responses since you've
posted this to two different newsgroups, with very different
attitudes about some process things. My responses are going to be from
the XP viewpoint; that's not to say that a more phasist approach, such
as
RUP, may not be appropriate for you. It's more a reflection of my biases
in the matter. I'm going to interleave comments.
If you would perfer to stick to RUP, and not deal with XP, please
remove the XP newsgroup from your posts. Thanks.
> A short review of our process follows:
>
> Customer provides a Mission Needs Document to management
This has nothing to do with development. You need something
so that management authorizes the activity, after all, so it's on
the Customer side of the fence. Consequently, XP does not
address this activity, although it's quite necessary.
Notice that XP provides a separation of responsibilities
between the Customer and the Developers. Analysts are, in
general, on the customer side, not the developer side.
> Developers write a Requirements Document
Customer writes whatever is necessary to get the requirements
across. The level of formality is up to the organization, although
XP has a bias toward less formality rather than more. Also,
XP requires that requirements eventually (that is, before code
is written) be embedded in automated acceptance tests.
> Developers and Customers review the Requirements Document
> Managers and Developers create the Software Development Plan
This activity is done at the front, using the use cases (which
substitute
for requirements documents). It's repeated at reasonable intervals,
like three months. The plan is not viewed as cast in concrete, it's a
general guide to how development is expected to go.
> Developers write and review the High-Level Design Document
> Developers write and review the Low-Level Design Document
This document does not exist. Period. XP design is done as part
of the integrated development process, as each piece is added to
the evolving software product. This is not to say that some high
level design isn't needed, but it's pretty much limited to an attempt
to forsee hardware and similar implementation issues.
> Developers write the code and perform unit/integration testing
Yes. Also do the design. A major part of this is test driven
development,
where the tests are written before the code. The code is actually
written in response to the tests, not the other way around. This is
possibly the most profoundly different thing about XP, and it takes
some real thinking and experimenting to get used to it.
There is no formal integration test. All features are added to a
working product, so they are integrated as part of the ongoing
development.
> Testers test the software and write the Test Report
Testers write the acceptance tests **before** the developers write
the code. The developers run the acceptance tests to judge whether
they've met the goal. Notice that the testers absolutely need to be
in on the requirements: if there isn't an automated acceptance test,
it isn't a requirement. (There are a few exceptions to 'automated,'
but they should be absolutely minimized.)
A test report is not really necessary. If needed, it can be produced
as an automated byproduct of running the acceptance tests.
> Configuration Management releases the software to the customers
The end of each two week iteration results in a working product which
runs
all acceptance tests for features produced to date. That product is
suitable to be rolled out to the field. Which iterations are rolled out
depends on the customer's judgement, although XP recommends that
installs be done every six weeks to three months to get feedback.
> Note that the purpose of almost every step is to "write a document".
Also,
> this process is entirely step-wise waterfall. By that, I mean that no
> design can happen until 100% of the requirements are gathered and
> documented. No coding can happen until 100% of the design is finished
and
> documented. Everyone (especially me) understands how important
> documentation is (primarily for future maintenance), but our process
does
> not address prototyping, risk management, etc. As one might expect,
this
> attitude/focus has created some spectacular software failures in my
> organization (of about 50 programmers plus 30 overhead).
Why is this not a surprise? Government projects are notorious for
running late, exceeding their budget and not satisfying the real
requirements
(as opposed to the written requirements.)
Your biggest issue is going to be understanding that documentation
is a waste of staff time and money unless it is actually used for
something beneficial.
XP is unique in not making a distinction between development
and maintenance. All features are added, a few at a time, to a
working product until the result has the features the customer needs.
There is no difference in process between features added because
they were identified up front, and features added because the need
was discovered later.
In XP, prototypes are simply early versions of the product, which
may not incorporate the final features, such as connections to the
corporate data base, etc., but which are production code for those
features that they do incorporate.
XP deals with risk by requireing everyone who spots something
that they think can't be done to state this up front, so that
the issue can be explored.
Part of the risk orientation is a very deep
dedication to not building something until you actually need it:
in this sense, it is very risk driven. The risk (to capital) of building
something that you won't need is thereby avoided.
Risk management is a customer responsibility, which MIS can, of course,
consult on. If there is an identified risk, the issue should be explored
in whatever depth is needed to resolve it, preferably before you
spend any resources in the non-optimal path.
This pervades the entire philosophy. If the developer is not
certain of how to implement a feature, he may very well do
a prototype implementation (called a spike) to explore how it
should work. The prototype code is then thrown away, and the
production code is written from scratch, using the experiance
gained in the spike.
> So that is what we have currently. And now, I want to incorporate RUP
> (Rational Unified Process) into my organization. In short, I want to
move
> our organization and process away from being document driven to being
risk
> driven. Problem: all of our process infrastructure (management
insight,
> milestones, SQA/SPA Audits, Configuration Management, etc.) are all
based
> upon document driven assumptions. I am looking for advice on how to
> implement a risk-driven process (like RUP). I have the opportunity to
> present ideas to management, as well as submit changes to our process.
Regardless of which methodology you decide to roll out, I would
suggest employing a management consultant who has done this
before. Neither waterfall, XP nor RUP are exactly unknown, and
it should be possible to find a consultant who won't need to use you
to gain experiance.
>
> Comments are appreciated.
>
> Craig Garrett
> Software Engineer, MIS Applications
> cgar...@cox.net
John Roth
My email address is not correct: I haven't been at that ISP in over a
year.
If you want to correspond by e-mail, please mention this in the
newsgroup.
I am only on the xp newsgroup, I don't read comp.object.
Craig Garrett
Wow - you have got us pegged. Yep, we are a SEI/CMM Level 3 certified
organization that stopped following our own processes (actually, I am not
sure we ever followed them - we did a great job bs-ing SEI during the
audit). It's true that while our process says to be totally step-wise, we
usually don't do that (that goodness). SQA audits, configuration
management, and project management involvement have this limited step-wise
philosophy, however. They fail to accurately reflect what happens during
software development, therefore decisions are made on poor information.
To increase the motivation, there is a pressing need (I won't go into it
now) for us to have our process correct. Our process MUST NOT lock us into
the traditional government situation of big-bang development that is late,
overbudget, and creates a poor quality product (after all, we have customers
to satisfy). How do I change the attitudes, or at least expose the problems
so that we can move forward?
Furthermore, I am looking for organizations that have "jumped the hurdle" of
document driven processes and moved on to something that actually works. I
sure wish we had a partner organization we could share ideas with.
-Craig
cgar...@cox.net
Craig Garrett
term you used called automated acceptance testing. Where can I learn more
about that?
I think you are pretty much right on in what you say, but I am in a position
to convince non-software engineers who are profoundly afraid that
programmers are just "hacking" to look beyond their precious documentation
that somehow "proves the programmers aren't hacking" (of course, it doesn't
prove anything - some of our "best documented" projects were our worst
failures). It's all so ridiculous.
I am also looking for more concrete examples of how to implement a managed,
mature process that *works* - not that just *assumes* it should work
according to 20-year-old software engineering theory.
-Craig
P.S. - I definitely want to hear from as many different viewpoints as
possible, so I will leave both newsgroups in the post. Are there any other
good software engineering groups or process groups I can look at?
"John Roth" <john...@ameritech.net> wrote in message
news:uf51j3r...@news.supernews.com...
Robert Chapman
would recommend eXtreme Programming: Embrace Change and eXtreme Programming
Installed as the core 2 to start with. I found that Embrace Change gave me
the highlights and structure of XP, and Installed really re-enforced the
practices and explained things in a way that I could understand.
These books, and the others in the series, should be available at any good
book store.
Cheers
--
Robert Chapman, MCSD
Manager, Applications Development
prairieFyre Software Inc.
http://www.prairiefyre.com
"Craig Garrett" <cgarrett4@no_spam_cox.net> wrote in message
news:fkwI8.91590$Md6.3...@news1.east.cox.net...
David B Lightstone
The purpose of SEI is to establish integrity, so that the Government can rely
upon the claims of their contractors. Obviously the message didn't get thru to
the upper management of your organization. Certainly the price didn't get
factored in properly
> It's true that while our process says to be totally step-wise, we
> usually don't do that (that goodness). SQA audits, configuration
> management, and project management involvement have this limited step-wise
> philosophy, however. They fail to accurately reflect what happens during
> software development, therefore decisions are made on poor information.
This is the key to your problem. Recognize that the decision quality of your
organization is poor. The cause will be mis-synchronization of information upon
which decisions are being made. Because to the mis-synchronization you can not
evaluate the extent and nature of the risks which you are incuring. It is
downhill from there as patch and gimmic is applied in an effort to pull a rabbit
out of the hat or hit a home run depending on the organizations prefered analogy
>
> To increase the motivation, there is a pressing need (I won't go into it
> now) for us to have our process correct. Our process MUST NOT lock us into
> the traditional government situation of big-bang development that is late,
> overbudget, and creates a poor quality product (after all, we have customers
> to satisfy). How do I change the attitudes, or at least expose the problems
> so that we can move forward?
The easiest way to expose the situation, is to suggest that the organization be
re-audited. If there is resistance to the idea, you know who wants to prevent
the situation from being exposed ( either as deck staker or decline leader). If
they agree, inquire as to their evaluation of the current situation. If they
think they are still SEI 3, well, you know who will need his rectial cranial
inversion reversed. (resist any temptation to avoid suggesting that the
organization be re-audited until the top level management agrees that
self-certification at SEI 1 is correct. They don't have an approved scale for
negative certifications and 1 is as low as you officially can go)
If they go for the evaluation, locate the worst run activities and the dumbest
people, and make certain they are all interviewed. If they are not interviewed,
then somebody has stacked the deck (again), and you may as well start looking
for a new job (because you are not being asked to develop a "real"
organization).
If everthing goes as planned you should get a small reality crisis. Nothing like
a good crisis to cause the management to pay attention. (reminds me of the Bush
trifecta joke of 9-12-2001) In this case loss of pedigree.
If perchance you are in the Chicago area, is your location just a little east of
53 and a little south of Dundee. Its a big complex, you can't miss it. (Been
there done that, run don't walk to the nearest exit. Bribe the guard to lock you
out if necessary).
>
> Furthermore, I am looking for organizations that have "jumped the hurdle" of
> document driven processes and moved on to something that actually works. I
> sure wish we had a partner organization we could share ideas with.
Nothing works, it all a big illusion. Its all a question of how screwed up the
situation can get.
You are not a document drven organization, probably never were. You just have
the illusion of being document driven. To paraphrase the XP types Try it it may
just work for you. Anyhow your real problems probably (sorry for the hedge) are
not document related. More likely they are configuration identification and
coordination (most organizations haven't got a clue). This at the level of
requirements rather than implemention elements (source code files, documents
etc)
>
> -Craig
> cgar...@cox.net
>
>
Shayne Wissler
"David B Lightstone" <david.lightst...@prodigy.net> wrote in
message news:cZxI8.4287$0F2.12...@newssvr17.news.prodigy.com...
> > Wow - you have got us pegged. Yep, we are a SEI/CMM Level 3 certified
> > organization that stopped following our own processes (actually, I am
not
> > sure we ever followed them - we did a great job bs-ing SEI during the
> > audit).
>
> The purpose of SEI is to establish integrity, so that the Government can
rely
> upon the claims of their contractors.
Integrity cannot be "established" by an outside organization. It is an
inherent quality in management--either they have it or they don't. And if
they're the type who think that paying big bucks can buy them their
integrity, well that just proves that they'll never get it.
Shayne Wissler
David B Lightstone
"Shayne Wissler" <thal...@yahoo.com> wrote in message
news:mFyI8.119564$UV4.216970@rwcrnsc54...
>
> "David B Lightstone" <david.lightst...@prodigy.net> wrote in
> message news:cZxI8.4287$0F2.12...@newssvr17.news.prodigy.com...
>
> > > Wow - you have got us pegged. Yep, we are a SEI/CMM Level 3 certified
> > > organization that stopped following our own processes (actually, I am
> not
> > > sure we ever followed them - we did a great job bs-ing SEI during the
> > > audit).
> >
> > The purpose of SEI is to establish integrity, so that the Government can
> rely
> > upon the claims of their contractors.
The post to which you have responded has only partially been quoted. Do you
think you can attempt to retain the context in the future?
"The purpose of SEI is to establish integrity, so that the Government can rely
upon the claims of their contractors. Obviously the message didn't get thru to
the upper management of your organization. Certainly the price didn't get
factored in properly"
>
> Integrity cannot be "established" by an outside organization. It is an
> inherent quality in management--either they have it or they don't. And if
> they're the type who think that paying big bucks can buy them their
> integrity, well that just proves that they'll never get it.
We are in agreement. Integrity is an inherent quality of management. The message
is that integrity is mandatory. I guess you failed to follow the intent of the
questions related to re-auditing. Oh well
>
>
> Shayne Wissler
>
>
>
John Roth
> It sure sounds like I need to learn more about XP. Of most interest
is the
> term you used called automated acceptance testing. Where can I learn
more
> about that?
Automated acceptance testing is somewhat of a black art, since it
isn't quite as cut and dried as unit testing. That is, most unit testing
can be done with the appropriate xUnit testing tools, while automated
acceptance testing pretty much has to be thought out with respect to
the requirements that are being tested.
The critical thing with acceptance tests is that they are an interface
between the customer and the developer, so the 'customer' needs
to understand them. In your case, this is probably a professional QA
organization, although there's every reason to allow the actual business
people to add test cases as they think of them.
The people on this NG are pretty friendly (as opposed to some other
newsgroups that I won't name.) We've got a couple of trolls
(what newsgroups doesn't) but even they are mostly polite, and
you can learn something from them if you realize their biases.
There are a fair number of books on XP. I find XP Explained
to be the best introduction, although the section on the 'customer'
is dated. There's a book on test driven development in the final
stages of publication that promises to be very interesting. You can
get them in just about any major bookstore.
There are two web sites to start out with. Look for extreme
programming on google, and watch out for a couple of
trolls.
> I think you are pretty much right on in what you say, but I am in a
position
> to convince non-software engineers who are profoundly afraid that
> programmers are just "hacking" to look beyond their precious
documentation
> that somehow "proves the programmers aren't hacking" (of course, it
doesn't
> prove anything - some of our "best documented" projects were our worst
> failures). It's all so ridiculous.
There are two general approaches. One is to deliver frequently.
I've found that having a release that's actually solving one of the
customer's needs substitutes for all kinds of progress documentation.
Once you get a reputation for delivering what you say you will
when you say you will, the requests for documentation will begin
subsiding of their own accord.
> I am also looking for more concrete examples of how to implement a
managed,
> mature process that *works* - not that just *assumes* it should work
> according to 20-year-old software engineering theory.
Process that works: it delivers what you say it will when you say it
will, without abusing the programmers by excessive overtime.
The only way I know of evolving to this point is to start with frequent
releases (every six to eight weeks) and keep working on it.
Feedback is crucial. XP recommends two week iterations. An iteration
is a block of work that starts out with the planning session where the
work for the iteration is agreed to. Developers sign up for parts of it.
It ends with the finished product ready to roll out. Most iterations
will
not roll out to the field, but every third or fourth one will.
The two week iteration means this is the absolute longest that you
can go before you absolutely have to face a problem.
John Roth
> It sure sounds like I need to learn more about XP.
Keith Ray's mini-faq is posted here weekly. The last
version went up two days ago (the 25th). It's a great
set of pointers to books and web sites.
Kent Beck
...
> The two week iteration means this is the absolute longest that you
> can go before you absolutely have to face a problem.
First, John, I wish I had written your summary of XP. I will use it to
introduce managers to XP.
Second, I recommend one-week iterations to start.
* You get more practice planning.
* You gather twice as much data.
* Your mistakes are smaller and less frustrating.
* You can try twice as many process experiments.
Sometimes one-week iterations can get to be a grind. You never have a chance
to try a risky-but-promising approach for 2-3 days without risking the whole
iteration's output. If teams experience this and want to shift to two-week
iterations after a few months, I encourage them to try.
Kent
Gerold Keefer
> Hello, I am posting to ask advice about software engineering processes. I
> want to move my organization from a document-driven process to a more
> risk-driven environment.
[snip]
> Comments are appreciated.
>
> Craig Garrett
> Software Engineer, MIS Applications
> cgar...@cox.net
craig,
i completely agree with mr. beck that the best thing to do
with a 50 developers organization that is currently based
on a dysfunctional CMM approach in order to become
risk-driven is to start with one week iterations.
particularly you will be risk-driven from day one of that
change. driven by the risk to loose your job for leading
your organizational from a partly dysfunctional situation
to a completely non-functional situation.
you should think about the following:
1. before you throw away everything you have,
you should think about the things that are positive
about your current process and that might be worth
to be preserved. are all documents that are written
useless or are there useful documents as well?
2. what is the nature of those spectacular failures you
reported on? those problems are the single most
important starting point of a change.
3. what are the goals you want to achieve after your
change effort?
out of the blue i see the following means for
improvement:
1. currently, process and product quality are not
coupled. i reckon there is double book keeping
in place, where the process on paper is not the
process practiced. you should ask why this is
the case. either the process on paper is bad or
it is not decently implemented. in any case, ask
"why?".
2. it seems that your organization is disintegrated.
you write about "management", "developers", "customer",
and "testers". you should more often write about "we".
the term "cross-functional team" comes to my mind.
involve those "testers" into the creation of the
requirements spec. have more involvement from the
customer during design, etc.. use for example the
winwin approach.
3. risk-driven: you can address this in two ways.
- do a formal risk management such as described in
our process at
http://www.avoca-vsm.com/Dateien-Download/CmmiRiskManagement.pdf .
- use an incremental process:
the incremental model proposed by berry boehm is a risk
driven one. develop the architectural core of your system
first. add functionality in subsequent increments. given the
size of you organization those increments should be at least
3 months long. one week is absurd, to say the least.
you should also beware that incremental development means
more planning, not less.
4. prototyping:
what prevents you currently from doing protoypes during
requirements development? is there a rule that says: you shall
not prototype?
and remember, without clear support from the top management of
your organization your efforts will be doomed.
regards,
gerold
--
=====================================================================
AVOCA GmbH - Advanced Visioning of Components and Architectures
Kronenstrasse 19
D-70173 Stuttgart
fo +49 711 2271374 fa +49 711 2271375
http://www.avoca-vsm.com mailto:in...@avoca-vsm.com
=====================================================================
Read my new article at
http://www.stickyminds.com/sitewide.asp?ObjectId=3440&ObjectType=ART&Function=edetail
John Roth
"Kent Beck" <kent...@my-deja.com> wrote in message
news:acv4mp$kqe$1...@nntp-m01.news.aol.com...
>
> John Roth <john...@ameritech.net> wrote in message
> news:uf5ojba...@news.supernews.com...
> ...
> > The two week iteration means this is the absolute longest that you
> > can go before you absolutely have to face a problem.
>
> First, John, I wish I had written your summary of XP. I will use it to
> introduce managers to XP.
Oh, my. Thank you.
> Second, I recommend one-week iterations to start.
> * You get more practice planning.
> * You gather twice as much data.
> * Your mistakes are smaller and less frustrating.
> * You can try twice as many process experiments.
>
> Sometimes one-week iterations can get to be a grind. You never have a
chance
> to try a risky-but-promising approach for 2-3 days without risking the
whole
> iteration's output. If teams experience this and want to shift to
two-week
> iterations after a few months, I encourage them to try.
You do have to strike a balance between something long enough
to be useful, short enough to hold your nose to the wall, and
inflexible enough that you have to deal with estimating properly
and meeting deadlines rather than living in a fog of denial.
If one week does that, then it does. You've got a lot more
experiance with this than I do.
John Roth
>
> Kent
>
>
Robert C. Martin
<cgarrett4@no_spam_cox.net> wrote:
>Furthermore, I am looking for organizations that have "jumped the hurdle" of
>document driven processes and moved on to something that actually works. I
>sure wish we had a partner organization we could share ideas with.
Take a look at these folks:
http://www3.workshare.com/news/ne_pressreleases_view.asp?pressID=27
http://www.sdmagazine.com/documents/s=2279/sdm0201a/0201a.htm
Or more of the same at:
http://www.objectmentor.com/ourCustomers/index
Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |
You and I can enjoy the experience of not always seeing
eye-to-eye, but we can also respect each other, even when
you might find some idea of mine totally ludicrous.
-- Richard Riehle
Craig Garrett
"Gerold Keefer" <gkeefer-...@avoca-vsm.com> wrote in message
news:3CF347FA...@avoca-vsm.com...
> Craig Garrett wrote:
>
> > Hello, I am posting to ask advice about software engineering processes.
I
> > want to move my organization from a document-driven process to a more
> > risk-driven environment.
>
> [snip]
>
> > Comments are appreciated.
> >
> > Craig Garrett
> > Software Engineer, MIS Applications
> > cgar...@cox.net
>
> craig,
>
> i completely agree with mr. beck that the best thing to do
> with a 50 developers organization that is currently based
> on a dysfunctional CMM approach in order to become
> risk-driven is to start with one week iterations.
>
> particularly you will be risk-driven from day one of that
> change. driven by the risk to loose your job for leading
> your organizational from a partly dysfunctional situation
> to a completely non-functional situation.
It's all pretty scary, isn't it? :)
>
> you should think about the following:
>
> 1. before you throw away everything you have,
> you should think about the things that are positive
> about your current process and that might be worth
> to be preserved. are all documents that are written
> useless or are there useful documents as well?
There are lots of things in our process worth keeping. I want to try to
keep everything we can, for lots of reasons, not the least of which is that
I will have an easier time selling this if I do.
> 2. what is the nature of those spectacular failures you
> reported on? those problems are the single most
> important starting point of a change.
Massive schedule overruns, extremely poor relations with customers, software
developed that was so buggy it couldn't pass our independent testers 7 times
in a row, stuff like that. I am really glad I wasn't personally involved -
what a nightmare.
> 3. what are the goals you want to achieve after your
> change effort?
Oh, lots. But your question is good - it tells me "make sure you have your
goals in mind, and work towards them"
> out of the blue i see the following means for
> improvement:
>
> 1. currently, process and product quality are not
> coupled. i reckon there is double book keeping
> in place, where the process on paper is not the
> process practiced. you should ask why this is
> the case. either the process on paper is bad or
> it is not decently implemented. in any case, ask
> "why?".
BINGO. Problem is, our process folks (SPA and SEPG) don't ask why - they
say, follow the process or else! It's a matter of focus. Our current SPA
and SEPG focus is on "enforcing" the process, not improving it. This is
perhaps the biggest point I hope to get across to management. I cannot hope
to change the process myself, it is going to take everyone to change thier
focus and actually think about how to improve things. This is my biggest
challenge.
> 2. it seems that your organization is disintegrated.
> you write about "management", "developers", "customer",
> and "testers". you should more often write about "we".
> the term "cross-functional team" comes to my mind.
> involve those "testers" into the creation of the
> requirements spec. have more involvement from the
> customer during design, etc.. use for example the
> winwin approach.
Very disentigrated. All of our projects have some amount of infighting
amongst the team members. It always ends up being a struggle between the
people who want to enforce the process (which usually amounts to stopping
development and focusing on documentation) and those who want to develop
software for the customer. On other occasions, we actually have bad
relationships with the customer, and those are the worst of all.
Fortunately, on my project, the customers loved us, so that was a plus, but
the things that made them love us we couldn't have done if we had actually
followed our written process. I think that our written process is quite
unfriendly to the customer in several ways (lots of "red tape", etc. meant
to protect us from the customer - not a good philosophy to have) Maybe that
should be another point I bring up to management...
> 3. risk-driven: you can address this in two ways.
>
> - do a formal risk management such as described in
> our process at
> http://www.avoca-vsm.com/Dateien-Download/CmmiRiskManagement.pdf .
> - use an incremental process:
> the incremental model proposed by berry boehm is a risk
> driven one. develop the architectural core of your system
> first. add functionality in subsequent increments. given the
> size of you organization those increments should be at least
> 3 months long. one week is absurd, to say the least.
> you should also beware that incremental development means
> more planning, not less.
Yes, 1-2 week increments are too short for my organization except in special
circumstances. 1-2 months sounds about right for us, and your point about
planning is very true.
> 4. prototyping:
> what prevents you currently from doing protoypes during
> requirements development? is there a rule that says: you shall
> not prototype?
Our process simply doesn't address prototyping at all. What ends up
happening is prototyping is looked at as hacking, and even worse, sometimes
is actually is hacking. This is more a training issue about how to use
prototypes, rather than a process problem for us, but it would be nice for
us to address it in some way.
> and remember, without clear support from the top management of
> your organization your efforts will be doomed.
Truer words were never spoken. That is my challenge in the next few weeks.
The one thing on my side is that we have (relatively) new management, and
they have not yet had any feedback from developers in the organization about
the process. Hopefully when management starts hearing the same story over
and over again, it will make an impresstion.
Here's hoping.
-Craig Garrett
cgar...@cox.net
Gerold Keefer
> Massive schedule overruns,
three primary reasons for that:
1. bad estimation and planning or
2. rework due to poor quality or
3. both.
with regard to the mentioned troubles
with independent tests, it is fair to say that
your quality system is not working.
> extremely poor relations with customers,
if your management is open enough, why not
ask those customers about how they see the
relationship and what they think needs improvement.
> software developed that was so buggy it couldn't pass our
> independent testers 7 times in a row, stuff like that.
from everything i know about the software industry the
single most effective way to bring system test bug counts
down is changing from
> Developers write the code and perform unit/integration testing
to
Developer writes the code, cross-inspect the code, and perform
unit/integration testing.
in other words establish an inspection process. hire an experienced
moderator who has done it in other organizations to help.
> > 3. what are the goals you want to achieve after your
> > change effort?
>
> Oh, lots. But your question is good - it tells me "make sure you have your
> goals in mind, and work towards them"
"lots" is not the right answer here.
you ought to have specific goals
- and you have to write them down
- and you have to find out how to define/measure success and the current status.
> BINGO. Problem is, our process folks (SPA and SEPG) don't ask why - they
> say, follow the process or else! It's a matter of focus. Our current SPA
> and SEPG focus is on "enforcing" the process, not improving it. This is
> perhaps the biggest point I hope to get across to management.
your organization has run into the "separate SEPG"-trap.
the SEPG seems to create more quality problems than they solve.
the single most important quality problem is frustated staff plagued
by some remote QA folks.
put the SEPG people *into* the projects. give developers the chance
to state reasons why they are not following the process and let them
decide on the process as well. start small.
> It always ends up being a struggle between the
> people who want to enforce the process (which usually amounts to stopping
> development and focusing on documentation) and those who want to develop
> software for the customer.
documentation *can* be development as well, it can be a waste
of time as well. it depends. development is *more* than coding.
a process should be the agreed best way to develop software with regards
to costs, schedule, and quality. software, however, implies all necessary
work products.
> I think that our written process is quite
> unfriendly to the customer in several ways (lots of "red tape", etc. meant
> to protect us from the customer - not a good philosophy to have) Maybe that
> should be another point I bring up to management...
"red tape" is an indication of mistrust within your organization.
empowerment and trust is what your organization is terribly lacking.
only top management can change this. they must be willing to level
the hierarchy and support their own people.
regards,
gerold
Ron Jeffries
<gkeefer-...@avoca-vsm.com> wrote:
>> Massive schedule overruns,
>
>three primary reasons for that:
>1. bad estimation and planning or
>2. rework due to poor quality or
>3. both.
Credit where credit is due:
Gerold, your last couple of postings to this thread have contained lots of good
advice. I might not agree with every tiny bit of it, but it's damn good. Well
done.
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Peter Horan
It is worth reading Weinberg "Quality Software Management, Vol 1 Systems
Thinking".
> There are lots of things in our process worth keeping. I want to try to
> keep everything we can, for lots of reasons, not the least of which is that
> I will have an easier time selling this if I do.
Good. Add helpful things rather than forbid the dysfunctional things.
>
> > 2. what is the nature of those spectacular failures you
> > reported on? those problems are the single most
> > important starting point of a change.
>
> Massive schedule overruns, extremely poor relations with customers, software
> developed that was so buggy it couldn't pass our independent testers 7 times
> in a row, stuff like that. I am really glad I wasn't personally involved -
> what a nightmare.
Sounds like the company ran into the complexity barrier.
> BINGO. Problem is, our process folks (SPA and SEPG) don't ask why - they
> say, follow the process or else! It's a matter of focus. Our current SPA
> and SEPG focus is on "enforcing" the process, not improving it.
Sounds like they are following a recipe and it is not working anymore.
But because they know no better, they keep on following it.
[It is easy to say "read X", but it saves me typing much explanation,
and Weinberg says it better than I would. He discusses all of the issues
raised}.
--
Peter Horan School of Computing and Mathematics
pe...@deakin.edu.au Deakin University
+61-3-5227 1234 (Voice) Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX) http://www.cm.deakin.edu.au/~peter
-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)
John Smith
offering.
check out the press release- Most useful for managing the life cycle
of softwere product development.
Hosted solution is available to try out- I use it and like it
JS
"Craig Garrett" <cgarrett4@no_spam_cox.net> wrote in message news:<4BYI8.4172$ib4.2...@news1.east.cox.net>...
John Smith
try their collaboration tool
Tufan offers digité that meets the needs of the evolving enterprise,
which are turning to team-based structures to improve productivity.
Essential to this is the need for a collaborative system where
everyone has access to critical project information making it possible
for groups, individuals and IT decision makers to make risk exposure
assessments. digité can be deployed entirely over the web reducing
the cost and complexity of traditional client/sever solutions. digité
is a comprehensive lifecycle management platform featuring the
following modules: Requirements Management, Project Planning and
Tracking, Issues and Defects Management, Document Management, Project
Change Management, and Software Configuration Management. All project
updates are made to a central data repository, so that all activity
can be securely viewed and monitored on a real-time basis from
anywhere in the world.
Hosted solution is available- that is what we tried out for our use-
works great.
js
Robert C. Martin <u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m> wrote in message news:<nsf7fu45ghi0lhgmi...@4ax.com>...
Craig Garrett
me frame what I want to do and are giving good ideas at the same time. It
also definitely sounds like my organization isn't the only one to have these
problems, and that is somewhat comforting, I suppose.
-Craig Garrett
cgar...@cox.net
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
news:ah99fu0aaimdrrkt9...@4ax.com...
Russell Martin
>
> I have to agree. I really appreciate everyone's comments. They are helping
> me frame what I want to do and are giving good ideas at the same time. It
> also definitely sounds like my organization isn't the only one to have these
> problems, and that is somewhat comforting, I suppose.
No, you're not alone, but I find that more frightening than comforting myself.
:-( OTOH, half of all organizations are below median. ;-)
Regards,
Russell
Troll_4
And the other half are trying to get there :-)
>
> Regards,
> Russell
John Roth
"Troll_4" <first...@hotmail.com> wrote in message
news:39e5fc28.02053...@posting.google.com...
Which means that the first half just have to wait to
become above average.
John Roth
Keith Collyer
> Very disentigrated. All of our projects have some amount
> of infighting amongst the team members. It always ends up
> being a struggle between the people who want to enforce the
> process (which usually amounts to stopping development and
> focusing on documentation) and those who want to develop
> software for the customer.
That is a scary statement in itself, especially when you
point to problems like code failing test seven times in a
row. Whose "fault" is that? The developers or the
documenters?
> Yes, 1-2 week increments are too short for my organization
> except in special circumstances. 1-2 months sounds about
> right for us, and your point about planning is very true.
1-2 weeks is not short, but it depends on the scope of your
iteration. I once ran a project that had very few reported
bugs from other groups, and also delivered functionality on
time. We did nightly builds to check that everything compiled
(1-day increment), weekly builds and smoke tests to check it
worked to a level that we could use (1-week increment), and
every month we released tested software to the rest of the
project (1-month increment). Worked extremely well.
Cheers
KeithC
--
mailto:%20ke...@computer.org Proud member of Echoes
(http://www.meddle.org)
"640K ought to be enough for anybody" (Bill Gates, 1981)
Gerold Keefer
> Credit where credit is due:
>
> Gerold, your last couple of postings to this thread have contained lots of good
> advice. I might not agree with every tiny bit of it, but it's damn good. Well
> done.
thanks a lot.
there is not too much disagreement with the ends, but considerable
disagreement with the means.
Troll_4
Well, if they keep purchasing duds marketed as silver bullets it won't
be long before the average goes down
>
> John Roth
Craig Garrett
"Keith Collyer" <kei...@computer.org> wrote in message
news:Xns921ED9F7F9DFk...@127.0.0.1...
> "Craig Garrett" <cgarrett4@no_spam_cox.net> wrote in
> news:4BYI8.4172$ib4.2...@news1.east.cox.net:
>
> > Very disentigrated. All of our projects have some amount
> > of infighting amongst the team members. It always ends up
> > being a struggle between the people who want to enforce the
> > process (which usually amounts to stopping development and
> > focusing on documentation) and those who want to develop
> > software for the customer.
>
> That is a scary statement in itself, especially when you
> point to problems like code failing test seven times in a
> row. Whose "fault" is that? The developers or the
> documenters?
Well, being the lead of a developer team, I have a biased viewpoint. Having
said that, I would blame the process folks (those wanting to stop and focus
on documentation). The project I mention that couldn't pass tests - on that
project the lead software enginner bent to the wishes of the process people
and spent 95% of his time documenting the software (which is how much time
you have to spend on it to fill out our document templates, which are
enforced to the extreme) and only 5% of his time doing software engineering.
Only 5% on minor stuff, like say... design.
> > Yes, 1-2 week increments are too short for my organization
> > except in special circumstances. 1-2 months sounds about
> > right for us, and your point about planning is very true.
>
> 1-2 weeks is not short, but it depends on the scope of your
> iteration. I once ran a project that had very few reported
> bugs from other groups, and also delivered functionality on
> time. We did nightly builds to check that everything compiled
> (1-day increment), weekly builds and smoke tests to check it
> worked to a level that we could use (1-week increment), and
> every month we released tested software to the rest of the
> project (1-month increment). Worked extremely well.
> Cheers
>
> KeithC
>
> --
> mailto:%20ke...@computer.org Proud member of Echoes
> (http://www.meddle.org)
> "640K ought to be enough for anybody" (Bill Gates, 1981)
Actually, on my project we had several 2 week increments, and those were
about right, but it was a very special circumstance where we were
"fine-tuning" the software right after release. Come to think of it, my
project was the first one ever in my organization to do that... Just one
more thing that our process doesn't address.
-Craig
Ron Jeffries
wrote:
>Well, being the lead of a developer team, I have a biased viewpoint. Having
>said that, I would blame the process folks (those wanting to stop and focus
>on documentation). The project I mention that couldn't pass tests - on that
>project the lead software enginner bent to the wishes of the process people
>and spent 95% of his time documenting the software (which is how much time
>you have to spend on it to fill out our document templates, which are
>enforced to the extreme) and only 5% of his time doing software engineering.
>Only 5% on minor stuff, like say... design.
Uncrossposted.
There's this technique called Big Visible Chart, or Information Radiator. If I
was spending 95% of my time not producing software, I'd make a BVC of my time,
with software time in green and other activities in shades of red. See if anyone
noticed.
David B Lightstone
"Craig Garrett" <cgarrett4@no_spam_cox.net> wrote in message
news:cpYJ8.36462$ib4.1...@news1.east.cox.net...
>
> "Keith Collyer" <kei...@computer.org> wrote in message
> news:Xns921ED9F7F9DFk...@127.0.0.1...
> > "Craig Garrett" <cgarrett4@no_spam_cox.net> wrote in
> > news:4BYI8.4172$ib4.2...@news1.east.cox.net:
> >
> > > Very disentigrated. All of our projects have some amount
> > > of infighting amongst the team members. It always ends up
> > > being a struggle between the people who want to enforce the
> > > process (which usually amounts to stopping development and
> > > focusing on documentation) and those who want to develop
> > > software for the customer.
> >
> > That is a scary statement in itself, especially when you
> > point to problems like code failing test seven times in a
> > row. Whose "fault" is that? The developers or the
> > documenters?
>
> Well, being the lead of a developer team, I have a biased viewpoint. Having
> said that, I would blame the process folks (those wanting to stop and focus
> on documentation). The project I mention that couldn't pass tests - on that
> project the lead software enginner bent to the wishes of the process people
> and spent 95% of his time documenting the software (which is how much time
> you have to spend on it to fill out our document templates, which are
> enforced to the extreme) and only 5% of his time doing software engineering.
> Only 5% on minor stuff, like say... design.
Lets see if I understand this.
They have metrics that allow to time allocation to be tracked (otherwise you
would not be able to say 95% of the time was spend on overhead tasks), and your
management still failed to realize that nobody was getting any work done.
Unreal!
Craig Garrett
Hehe, no, I don't think you *quite* understand. (this is where it gets
good) The process folks think that if you have documents, then everything
else will be taken care of. They equate documentation with software
development. They equate documentation with elimination of risk. See how
bad the situation is? The only software engineers we have are in
development positions. The ones in SQA/SPA/SEPG are the people who couldn't
program well, so they threw them in the overhead spots. Not a good call on
management's part...
-Craig
David B Lightstone
I understand it only too well. I stated earlier. Run, do not walk to the nearest
exit. Bribe the guards to lock you out!
Your organization's management has developed metrics to count beans (your 95%
spent on overhead) and thinks that it is work. Assuming your measurements are
correct (and I quite frankly believe that you are exagerating more than
slightly), the skew of the metrics alone tells the whole story ( way out of
wack)
It is customary not to cross post. The nature of your organization is such that
adopting an XP type development approach will not succeed (50 people is too
many)
>
> -Craig
>
>
>
Craig Garrett
>
> "Marc Poulin" <mpo...@verinet.com> wrote in message
> news:3cf903f3$0$186$7586...@news.frii.net...
> > In article <Xe6K8.38161$ib4.1...@news1.east.cox.net>, "Craig
> Garrett"
> > <cgarrett4@no_spam_cox.net> wrote:
> >
> > > Hehe, no, I don't think you *quite* understand. (this is where it
> gets
> > > good) The process folks think that if you have documents, then
> > > everything else will be taken care of. They equate documentation
> with
> > > software development. They equate documentation with elimination of
> > > risk.
> >
>
> That's a little advanced. What that kind of people usually haven't
> learned
> is how to define objectives and measure toward them. The biggest
> distinction I can find is between people who take a methodology
> and then hang onto it for dear life, and those who take a methodology,
> find out what works and what doesn't, take what works and go on
> from there.
>
> Unfortunately, the first group of people tend to be very security
> oriented, security being defined as following procedures that
> are recommended by authorities. They tend to get very threatened
> when someone challenges those procedures.
>
> John Roth
Ok, you are scaring me now. I couldn't possibly have described some of our
folks better than that. Are you psychic or something?
-Craig
Craig Garrett
Ok, you caught me. I was exaggerating. It became clear that the system
wasn't designed properly, but according to what was reported to management
about process compliance (which was just documentation audits, and that was
considered to equate to software quality) the project was right on track.
Then, when the project neared "completion" it began to fail testing, and had
other technical problems, turning it into a nightmare for everyone Oh,
well, I suppose it's not healthy to dwell on the past...
Sorry for the cross-posts, I guess I was just trying to hear from as many
people as I could.
-Craig
John Roth
"Craig Garrett" <cgarrett4@no_spam_cox.net> wrote in message
news:jW9K8.41047$ib4.1...@news1.east.cox.net...
Yes. :) But I didn't need to check into your org to see that. It's a
very common personality pattern. People who tend to do procedures
without thinking about the objective tend to have other authority
type behavior patterns as well. If you can't get yourself established
as the authority, your only other option is to leave before the ship
sinks.
John Roth
> -Craig
>
>
Ron Jeffries
<david.lightst...@prodigy.net> wrote:
>It is customary not to cross post. The nature of your organization is such that
>adopting an XP type development approach will not succeed (50 people is too
>many)
How do you know that XP style development can't work with 50 people?
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Sat, 01 Jun 2002 19:53:10 GMT, "David B Lightstone"
> <david.lightst...@prodigy.net> wrote:
>
> >It is customary not to cross post. The nature of your organization is such
that
> >adopting an XP type development approach will not succeed (50 people is too
> >many)
>
> How do you know that XP style development can't work with 50 people?
Lets see, when a a self proclaimed expert (that's you) asks, rather than
providing a counter-example, there is little need to think about the question.
Ron Jeffries
<david.lightst...@prodigy.net> wrote:
>"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
>news:co3jfuc8niuo5mba8...@4ax.com...
>> On Sat, 01 Jun 2002 19:53:10 GMT, "David B Lightstone"
>> <david.lightst...@prodigy.net> wrote:
>>
>> >It is customary not to cross post. The nature of your organization is such
>that
>> >adopting an XP type development approach will not succeed (50 people is too
>> >many)
>>
>> How do you know that XP style development can't work with 50 people?
>
>Lets see, when a a self proclaimed expert (that's you) asks, rather than
>providing a counter-example, there is little need to think about the question.
That would be your specialty, I take it. There was a team of over 30 programmers
at Tumbleweed. I have heard there is a team of over 40 at ThoughtWorks, but it's
not all programmers.
I don't recall proclaiming myself an expert, but I do admit that I think I have
a clue about XP.
Now then. You made the assertion that 50 people is too many for XP. Can you
support the assertion, please?
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Sun, 02 Jun 2002 11:55:38 GMT, "David B Lightstone"
> <david.lightst...@prodigy.net> wrote:
>
> >"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> >news:co3jfuc8niuo5mba8...@4ax.com...
> >> On Sat, 01 Jun 2002 19:53:10 GMT, "David B Lightstone"
> >> <david.lightst...@prodigy.net> wrote:
> >>
> >> >It is customary not to cross post. The nature of your organization is such
> >that
> >> >adopting an XP type development approach will not succeed (50 people is
too
> >> >many)
> >>
> >> How do you know that XP style development can't work with 50 people?
> >
> >Lets see, when a a self proclaimed expert (that's you) asks, rather than
> >providing a counter-example, there is little need to think about the
question.
>
> That would be your specialty, I take it. There was a team of over 30
programmers
> at Tumbleweed.
30 < 50 why provide a meaningless claim
>I have heard there is a team of over 40 at ThoughtWorks, but it's
> not all programmers.
not all programmers AND 40 < 50 why provide a meaningless claim
>
> I don't recall proclaiming myself an expert, but I do admit that I think I
have
> a clue about XP.
Each and every time you state that someone probably has not applied XP correctly
(as a means of rationalizing a project failure) you implicitly claim such
expertise.
>
> Now then. You made the assertion that 50 people is too many for XP. Can you
> support the assertion, please?
50*49 pairs big number of interactions, plenty of complexity, Coordination
difficulties etc. You have to impose an organizational as well as managerial
structure. That means multiple teams. Not really 50 people working together is
it?
Was it Brooks that pointed out the difficulties in managing large projects do to
such interactions? I can never remember such details. I'm certain you can infer
the rest. You have been around the block a few times.
Gerold Keefer
50 programmers fit in? :-)
regards,
gerold
Craig Garrett
10 people. To make the point somewhat moot - I don't think my organization
is close to ready to use something like XP. We have a long way to go before
we could even consider it, I am afraid. I am more than content to get us
moving in a quality-oriented, risk-driven direction first...
-Craig
"Gerold Keefer" <gkeefer-...@avoca-vsm.com> wrote in message
news:3CFA592F...@avoca-vsm.com...
Gerold Keefer
> The project I mention that couldn't pass tests - on that
> project the lead software enginner bent to the wishes of the process people
> and spent 95% of his time documenting the software (which is how much time
> you have to spend on it to fill out our document templates, which are
> enforced to the extreme) and only 5% of his time doing software engineering.
> Only 5% on minor stuff, like say... design.
well, something clearly went wrong. however, i do not agree that
writing a document is not "doing software engineering". this is only
the case if the document is useless.
brooks esitmate is 1/6 coding effort of total project effort. there
are estimates around that if you subtract communication and other tasks
from programmers time, around 18 hours per week are left for
"productive work". estimates often fail to take this into account.
regards,
gerold