Agile development and ISO

[4Space]

When I joined this company a couple of years ago, it was still in full blown
RUP document driven development. Thankfully, this is well on its way to
being changed to a more agile process, we're not there yet - any company
that's been around for 120 years has a good deal of inertia too it.

Despite its almost innumerable evils, document driven development did have
one seemingly good thing going for it. It allowed the engineering director
to go toe-to-toe with an ISO auditor and say "OK buddy-boy, just have a look
at this then, we've got more process than you can shake a stick at!". And
the auditor retreats to whatever location he inhabits between audits.

Now, is this as easy with an Agile process. To quote Uncle Bob - "Software
without documentation is a disaster." - and that's a point most if not all
can agree with. But would the "short and salient" documentation he goes on
to describe pass the ISO auditor?

Another interesting one, is the question of review. Now, we've been
integrating pair programming on some areas of our code base, and typically,
these areas would not be subject to wider review. In the older process, all
code of any architectural significance would be reviewed by 3 or 4
developers. The reviewee would present in a quite formal fashion, and the
feedback recorded in an equally formal fashion. Whilst this was slow and
cumbersome, it does provide good proof of quality control and process. The
way we have decided to tackle this, is using Visual SourceSafe. When we
check our files in, we add the names of the pair of programmers to the
comment field of the check-in.

I'm curious to know how other teams have tackled this issue. Does an agile
process easily align with the kind of proof-of-process required by the ISO
guys?


Cheers,

4Space

[Adrian L.]

I have been using RUP en many kinds of projects and I think that it is
no heavy. I think that people that use it apply it in a *heavy* way.
Yo have to configure RUP for every organization, and you obtain a RUP
for this organization (RUP-Org), and then re-configure that RUP-Org
for every project you do in that organization. In the configuration
process you have to agilize it or not depending on the project. Then
my opinion is that people is agile not the process. It is not the same
with ISO which objective is totaly different it is a
documentation-oriented process for the organization purposes not for
software development purposes.
Adrian.

[4Space]

[snip] It is not the same with ISO which objective is totaly different it is a documentation-oriented process for the organization purposes not for software development purposes.

It's interesting to hear your views on this. Maybe my understanding of what
ISO's objectives are, but I thought that organisation was one part of it,
but a bigger part was ensuring quality in the 'engineering process.'

Cheers

4Space

[Uncle Bob (Robert C. Martin)]

"4Space" <4Space@NoSpam.com> might (or might not) have written this on
(or about) Thu, 03 Jul 2003 10:57:47 GMT, :
When I joined this company a couple of years ago, it was still in full blownRUP document driven development.

Ah, a lovely oxymoron. RUP is not document driven. Lots of people
think it is; and I admit that it can be hard to tell from the existing
documentation that it is not. However, RUP does not demand any
documents at all.
Despite its almost innumerable evils, document driven development did haveone seemingly good thing going for it. It allowed the engineering directorto go toe-to-toe with an ISO auditor and say "OK buddy-boy, just have a lookat this then, we've got more process than you can shake a stick at!". Andthe auditor retreats to whatever location he inhabits between audits.Now, is this as easy with an Agile process. To quote Uncle Bob - "Softwarewithout documentation is a disaster." - and that's a point most if not allcan agree with. But would the "short and salient" documentation he goes onto describe pass the ISO auditor?

As I understand it, yes. As I understand the ISO rules, they simply
tell you to say what you are going to do, and then do what you said
you would do.
Another interesting one, is the question of review. Now, we've beenintegrating pair programming on some areas of our code base, and typically,these areas would not be subject to wider review. In the older process, allcode of any architectural significance would be reviewed by 3 or 4developers. The reviewee would present in a quite formal fashion, and thefeedback recorded in an equally formal fashion. Whilst this was slow andcumbersome, it does provide good proof of quality control and process. Theway we have decided to tackle this, is using Visual SourceSafe. When wecheck our files in, we add the names of the pair of programmers to thecomment field of the check-in.

That seems reasonable. You should also have a rule (comes free with
XP) that you can't check something in unless all unit tests and all
currently passing acceptance tests pass.

(Just the other day I had to bawl out -- er -- gently remind a
developer who checked in code that passed all unit tests, but didn't
pass acceptance tests.)
I'm curious to know how other teams have tackled this issue. Does an agileprocess easily align with the kind of proof-of-process required by the ISOguys?

That depends upon what kind of journals you keep. If you have to be
audited, then I think it would be very wise to keep a wiki with a page
for each day. Have the team journal what you do each day.

You could use FitNesse for that wiki, and it would also keep your
acceptance tests.
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 |

[Laurent Bossavit]

> I'm curious about when X happens. What is X? Should we review the test? let it settle in? or automatically push it into superTest.

I'd suggest pushing new acceptance tests to superTest once the latest
revision of the system has been demoed to the on-site customer, or
otherwise passed a "surprise and delight" test.

[Dale King]

"4Space" <4Space@NoSpam.com> wrote in message
news:0w9Na.763905$pv3.5240068@news.easynews.com... [snip] It is not the same with ISO which objective is totaly different it is a documentation-oriented process for the organization purposes not for software development purposes. It's interesting to hear your views on this. Maybe my understanding of
what ISO's objectives are, but I thought that organisation was one part of it, but a bigger part was ensuring quality in the 'engineering process.'


A common misconception. ISO has almost nothing to do with ensuring quality
of the actual product, just quality of the paperwork.

Some MUST reads on ISO are these articles from Embedded Systems Programming:

http://www.embedded.com/story/OEG20020125S0101
http://www.embedded.com/story/OEG20020524S0080

And here are some of the user responses (you have to read the letter from
Bruce Reynolds at the first link):

http://www.panelsoft.com/murphyslaw/feb02.htm
http://www.panelsoft.com/murphyslaw/jun02.htm
--
Dale King

[4Space]

I was at the the ACCU conference a couple of years back, the was a guy who
did a session on this kind of theme, the thrust was - "If the company you
work for cannot show a demonstrably show that their process has improved
something in their business, ask them how they know it's better than a
random process."

He won many friends.

4Space

"Dale King" <KingD@tmicha.net> wrote in message
news:3f0cd628@news.tce.com... "4Space" <4Space@NoSpam.com> wrote in message news:0w9Na.763905$pv3.5240068@news.easynews.com... [snip] It is not the same with ISO which objective is totaly different it is a documentation-oriented process for the organization purposes not for software development purposes. It's interesting to hear your views on this. Maybe my understanding of what ISO's objectives are, but I thought that organisation was one part of
it, but a bigger part was ensuring quality in the 'engineering process.' A common misconception. ISO has almost nothing to do with ensuring quality of the actual product, just quality of the paperwork. Some MUST reads on ISO are these articles from Embedded Systems
Programming: http://www.embedded.com/story/OEG20020125S0101 http://www.embedded.com/story/OEG20020524S0080 And here are some of the user responses (you have to read the letter from Bruce Reynolds at the first link): http://www.panelsoft.com/murphyslaw/feb02.htm http://www.panelsoft.com/murphyslaw/jun02.htm -- Dale King

[4Space]

"If the company you work for cannot demonstrably show that...."

Wow, that made sense.

"4Space" <4Space@NoSpam.com> wrote in message
news:199Pa.200717$8Q5.29954@news.easynews.com... I was at the the ACCU conference a couple of years back, the was a guy who did a session on this kind of theme, the thrust was - "If the company you work for cannot show a demonstrably show that their process has improved something in their business, ask them how they know it's better than a random process." He won many friends. 4Space "Dale King" <KingD@tmicha.net> wrote in message news:3f0cd628@news.tce.com... "4Space" <4Space@NoSpam.com> wrote in message news:0w9Na.763905$pv3.5240068@news.easynews.com... [snip] > It is not the same > with ISO which objective is totaly different it is a > documentation-oriented process for the organization purposes not for > software development purposes. It's interesting to hear your views on this. Maybe my understanding of what ISO's objectives are, but I thought that organisation was one part of it, but a bigger part was ensuring quality in the 'engineering process.' A common misconception. ISO has almost nothing to do with ensuring
quality of the actual product, just quality of the paperwork. Some MUST reads on ISO are these articles from Embedded Systems Programming: http://www.embedded.com/story/OEG20020125S0101 http://www.embedded.com/story/OEG20020524S0080 And here are some of the user responses (you have to read the letter
from Bruce Reynolds at the first link): http://www.panelsoft.com/murphyslaw/feb02.htm http://www.panelsoft.com/murphyslaw/jun02.htm -- Dale King

[Markus Spath]

Dale King wrote:
ISO's objectives are, but I thought that organisation was one part of it,but a bigger part was ensuring quality in the 'engineering process.' A common misconception. ISO has almost nothing to do with ensuring quality of the actual product, just quality of the paperwork.

this actually is a common misconception. did you read the iso 9001 yourself, or
are you just redistributing this mantra? there is as much second hand wisdom
permutated about the ISO as there is about XP.

Some MUST reads on ISO are these articles from Embedded Systems Programming: http://www.embedded.com/story/OEG20020125S0101 http://www.embedded.com/story/OEG20020524S0080 And here are some of the user responses (you have to read the letter from Bruce Reynolds at the first link): http://www.panelsoft.com/murphyslaw/feb02.htm http://www.panelsoft.com/murphyslaw/jun02.htm -- Dale King

[Wade]

Our company is just starting the registration process for ISO 9001. I
am wondering what documentation as far as software is required for it.
We are a small company with only three engineers. Are you required
to do Unit Tests and Acceptances tests and UML documents for your
designs or what else might be requirements that company's have that
are ISO 9001. Does a company adopt a system like Agile as a ISO
requirement?

Thanks for the help


"4Space" <4Space@NoSpam.com> wrote in message news:<L_TMa.3247804$uT2.476738@news.easynews.com>... When I joined this company a couple of years ago, it was still in full blown RUP document driven development. Thankfully, this is well on its way to being changed to a more agile process, we're not there yet - any company that's been around for 120 years has a good deal of inertia too it. Despite its almost innumerable evils, document driven development did have one seemingly good thing going for it. It allowed the engineering director to go toe-to-toe with an ISO auditor and say "OK buddy-boy, just have a look at this then, we've got more process than you can shake a stick at!". And the auditor retreats to whatever location he inhabits between audits. Now, is this as easy with an Agile process. To quote Uncle Bob - "Software without documentation is a disaster." - and that's a point most if not all can agree with. But would the "short and salient" documentation he goes on to describe pass the ISO auditor? Another interesting one, is the question of review. Now, we've been integrating pair programming on some areas of our code base, and typically, these areas would not be subject to wider review. In the older process, all code of any architectural significance would be reviewed by 3 or 4 developers. The reviewee would present in a quite formal fashion, and the feedback recorded in an equally formal fashion. Whilst this was slow and cumbersome, it does provide good proof of quality control and process. The way we have decided to tackle this, is using Visual SourceSafe. When we check our files in, we add the names of the pair of programmers to the comment field of the check-in. I'm curious to know how other teams have tackled this issue. Does an agile process easily align with the kind of proof-of-process required by the ISO guys? Cheers, 4Space

[4Space]

> Our company is just starting the registration process for ISO 9001. I am wondering what documentation as far as software is required for it. We are a small company with only three engineers. Are you required to do Unit Tests and Acceptances tests and UML documents for your designs or what else might be requirements that company's have that are ISO 9001. Does a company adopt a system like Agile as a ISO requirement?

I think the idea is that you have to have A process. A process that in
theory leads to an improved business product. And be seen to follow this
process, and your activities should be traceable. At least that's my
understanding. RUP / Agile / A.N. Other proces - your call. But for 3
engineers, Agile would probably be the way to go.

Cheers,

4Space

[Dale King]

"Markus Spath" <markus_spath@yahoo.de> wrote in message
news:3f0d3266_2@news.arcor-ip.de... Dale King wrote:ISO's objectives are, but I thought that organisation was one part of
it,but a bigger part was ensuring quality in the 'engineering process.' A common misconception. ISO has almost nothing to do with ensuring
quality of the actual product, just quality of the paperwork. this actually is a common misconception. did you read the iso 9001
yourself, or are you just redistributing this mantra? there is as much second hand
wisdom permutated about the ISO as there is about XP.

I would say it is more the common reality. You can argue the what the intent
of ISO was, but the reality is that it doesn't really make a difference in
product quality. As was discussed in the links posted and the post from
4space, people are starting to demand proof that there really is any value
in it.

My experience is with the application of ISO where I've worked. I don't have
horror stories like some of the letters I linked to, but I have never seen
it be of any value whatsoever. My biggest problem is that the goal of an ISO
program is the certification, not on improvement. Failing an audit is seen
as a failure. If your intent is improvement then failing an audit is
actually a good thing, you know where to improve.

--
Dale King