Agile development and ISO

Agile development and ISO

Post by 4Spac » Fri, 04 Jul 2003 19:57:47



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

 
 
 

Agile development and ISO

Post by Adrian » Sat, 05 Jul 2003 00:29:53


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.

 
 
 

Agile development and ISO

Post by 4Spac » Sat, 05 Jul 2003 15:53:48


[snip]

Quote:> 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

 
 
 

Agile development and ISO

Post by Robert C. Mart » Tue, 08 Jul 2003 08:33:36



(or about)  Thu, 03 Jul 2003 10:57:47 GMT, :

Quote:>When I joined this company a couple of years ago, it was still in full blown
>RUP 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.

Quote:>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?

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.  

Quote:>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.

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

Quote:>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?

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"                  

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     |

 
 
 

Agile development and ISO

Post by Phli » Tue, 08 Jul 2003 09:48:41



Quote:> (Just the other day I had to ... gently remind a
> developer who checked in code that passed all unit tests, but didn't
> pass acceptance tests.)

I envision a process that "hallows" passing acceptance tests by adding them
to the list of tests under superTest.

Acceptance test lifecycle:

 - someone thinks of it
 - unless motivated to keep it a secret, they write it
 - it fails
 - the programmer tests catch up to it
 - it passes
 - X happens
 - someone adds it to the superTest script

("superTest" is the test all code must pass at integration time. Developers
develop using TDD on the Programmer Tests only, local to the current
folder.)

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.

Further, when your developer neglected to run the acceptance tests, were
they part of a superTest? or were they (ahem) launched manually?

Who has experienced any best practices in that area?

--
  Phlip
    http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

 
 
 

Agile development and ISO

Post by Robert C. Mart » Tue, 08 Jul 2003 14:14:44



on (or about)  Mon, 07 Jul 2003 00:48:41 GMT, :

Quote:>Further, when your developer neglected to run the acceptance tests, were
>they part of a superTest? or were they (ahem) launched manually?

The ATs themselves are automated, but they are launched manually.

Robert C. Martin  | "Uncle Bob"                  

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     |

 
 
 

Agile development and ISO

Post by 4Spac » Tue, 08 Jul 2003 16:21:14


Quote:> >When I joined this company a couple of years ago, it was still in full
blown
> >RUP 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.

That is correct, but it wasn't unusual for the older projects to have more
documentation than code. Being new to software at the time, I just thought
that was the RUP.

Cheers

4Space

 
 
 

Agile development and ISO

Post by Laurent Bossavi » Wed, 09 Jul 2003 01:12:56


Quote:> 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.
 
 
 

Agile development and ISO

Post by Dale Kin » Fri, 11 Jul 2003 11:23:40



Quote:> [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

 
 
 

Agile development and ISO

Post by 4Spac » Fri, 11 Jul 2003 17:07:25


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




> > [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

 
 
 

Agile development and ISO

Post by Markus Spat » Fri, 11 Jul 2003 18:23:34



>>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.
Quote:> 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

 
 
 

Agile development and ISO

Post by Wad » Sat, 12 Jul 2003 05:17:26


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


> 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

 
 
 

Agile development and ISO

Post by 4Spac » Sat, 12 Jul 2003 14:04:30


Quote:> 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

 
 
 

Agile development and ISO

Post by Dale Kin » Wed, 16 Jul 2003 02:03:29




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

 
 
 

1. Announcing The Agile Life - a free ezine on the human side of software development

I have just published the first issue of The Agile Life, a new free
monthly eZine devoted to the human side of software development. It is
a collection of tools, techniques and ideas to enable software
professionals and teams to go beyond the status quo and achieve more
than they thought possible. Drawing on ideas from agile software
development, psychology, creativity, complexity, system dynamics and
life/business coaching, The Agile Life is for anyone in the IT
industry who want to find new ways of improving their work and their
lives.

You can read the first issue at
http://www.thedeveloperscoach.com/AgileLife.htm, or subscribe by

Dave Kirby -  The Developers' Coach
Helping software professionals and teams achieve peak performance

email:    dave

          .com

web:      http://www.thedeveloperscoach.com - sign up for my new free eZine, The Agile Life

2. Sol 2.5 sendmail ?

3. Agile Software Development: Principles, Patterns, and Practices

4. servlets / entrust ????

5. Announcing The Agile Life - a free ezine on the human side of software development

6. Dual Processor Question

7. Agile Software Development: Principles, Patterns, and Practices

8. Modem Sharing Client On WindowsXP Pro Won't Work

9. Agile software development is like fast food...

10. Caterpillar Digs Into Agile Development

11. Announcing The Agile Life - a free ezine on the human side of software development

12. Agile development experiences