Dear all,

As many of you know I started another company,
Hipaa Acccelerator, http://www.hipaaccelerator.com,
about a year and a half ago, that is solely dedicated
to solve Hipaa Privacy problems.

Hipaa Privacy problems are intersting enterprise
problems because they almost always require
many projects to be managed and delivered
concurrently.  For example, Hipaa Privacy mandates
reports of PHI (protected health information),
and Disclosure Accounting reports, that must access
data throughout the enterprise, and coordinate
business processes often involving dozens of people
for approval, escalation, investigation, delegation,
management, routing, retrieval, etc.; for even
a single request.

Each client implementation needs to be deployed while
many other things change like:

   - changes in Hipaa Privacy and State laws
   - changes in the systems to be integrated with
   - changes in business processes (policies
     and procedures), typically coming from legal
     and/or business process owners
   - etc.

and couple with the normal changes and
uncertainties found in every project like:

   - staff overturn and staff absorption
   - staff mentoring/training in both the business
     domain and the technology
   - changes in technology i.e. development environment
     and deployment tools and versions, etc.;
   - changes in design
   - refactoring
   - etc.

all of which were very significat in our case.  To
make it ever more challenging, the government
mandated deadline is 4/14/2003, requiring every
project to be a "little miracle".

To cope with the above uncertainty and change, we
decided to use XBreed -- a combination of Scrum, XP,
Open Source and Alexanderian practices for every
client installation (More at: http://www.xbreed.net
Yes, I know, the XBreed site needs urgent updating...
but I am too busy in the trenches to keep it up to
date.  Besides that I don't sell software methods
or "general software development consulting" -- I
only sell Hipaa Privacy solutions these days :-)

Btw, XBreed, means "cross breed" not "extreme breed",
and it was inspired by the similar concept in genetics

which literally means a thing with the natural
selected genes of XP, Scrum, Alexanderian and
Open Source.

Today, I am glad to report that once again, Scrum,
with the extensions that we call XBreed, has helped
us deliver to production one of the most challenging
projects I had ever dealt with in my 20+ years of
experience.

Business details:
The project involved about 20 people, 5 which were
developers, 3 testers, 5 system people, 3 full time
users, 1 scrum master, 1 product owner, 2 sponsors,
etc.  It will be deployed to ~3000 thousand
users throughout the State of Idaho.

The application fulfills just about every requirement
for Hipaa Privacy compliance, as well as all the
state law preemptions for the State of Idaho.

Technical details:
The application is a 130-screen j2ee web-based
application, using servlets, EJBs, JSPs, etc.; and
works with a DB2 and SQL server.  And it includes
rule-based workflow, document management, an LDAP
role-based security among other things.

There is no doubt that without the power of Scrum,
that gave us constant feedback and with that a
fresh new "context" where to apply patterns on a
daily basis, a constant oppportunity for
self-organization and re-prioritization of tasks,
and the fabric of a cooperative culture that allowed
us to freely and constantly exchange knowledge, we
would have never got to where we are here today.

I am as always proud to be a Scrum practitioner; yet,
I am still intrigued and mystified about the
simple but powerful powers of this Scrum thing.

How can something so simple be so powerful?

As fascinating as the why might be, in the end
who cares!!  ... it surely works,

- Mike



=====
Michael A. Beedle Ph. D.
CEO, Hipaa Accelerator, Inc.
2275 Half Day Rd. Suite 350
Bannockburn, IL. 60015
Office: 847-821-2631 Cell: 847-840-9890
Email: beedlem@...
Web: http://www.hipaaccelerator.com

Congratulations on the successful delivery, Mike. That sounds like a great
project!

-Mike

-----Original Message-----
From: Mike Beedle [mailto:beedlem@...]
Sent: Tuesday, January 14, 2003 6:53 PM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] A Successful XBreed/Scrum Project


Dear all,

As many of you know I started another company,
Hipaa Acccelerator, http://www.hipaaccelerator.com,
about a year and a half ago, that is solely dedicated
to solve Hipaa Privacy problems.

Hipaa Privacy problems are intersting enterprise
problems because they almost always require
many projects to be managed and delivered
concurrently.  For example, Hipaa Privacy mandates
reports of PHI (protected health information),
and Disclosure Accounting reports, that must access
data throughout the enterprise, and coordinate
business processes often involving dozens of people
for approval, escalation, investigation, delegation,
management, routing, retrieval, etc.; for even
a single request.

Each client implementation needs to be deployed while
many other things change like:

   - changes in Hipaa Privacy and State laws
   - changes in the systems to be integrated with
   - changes in business processes (policies
     and procedures), typically coming from legal
     and/or business process owners
   - etc.

and couple with the normal changes and
uncertainties found in every project like:

   - staff overturn and staff absorption
   - staff mentoring/training in both the business
     domain and the technology
   - changes in technology i.e. development environment
     and deployment tools and versions, etc.;
   - changes in design
   - refactoring
   - etc.

all of which were very significat in our case.  To
make it ever more challenging, the government
mandated deadline is 4/14/2003, requiring every
project to be a "little miracle".

To cope with the above uncertainty and change, we
decided to use XBreed -- a combination of Scrum, XP,
Open Source and Alexanderian practices for every
client installation (More at: http://www.xbreed.net
Yes, I know, the XBreed site needs urgent updating...
but I am too busy in the trenches to keep it up to
date.  Besides that I don't sell software methods
or "general software development consulting" -- I
only sell Hipaa Privacy solutions these days :-)

Btw, XBreed, means "cross breed" not "extreme breed",
and it was inspired by the similar concept in genetics

which literally means a thing with the natural
selected genes of XP, Scrum, Alexanderian and
Open Source.

Today, I am glad to report that once again, Scrum,
with the extensions that we call XBreed, has helped
us deliver to production one of the most challenging
projects I had ever dealt with in my 20+ years of
experience.

Business details:
The project involved about 20 people, 5 which were
developers, 3 testers, 5 system people, 3 full time
users, 1 scrum master, 1 product owner, 2 sponsors,
etc.  It will be deployed to ~3000 thousand
users throughout the State of Idaho.

The application fulfills just about every requirement
for Hipaa Privacy compliance, as well as all the
state law preemptions for the State of Idaho.

Technical details:
The application is a 130-screen j2ee web-based
application, using servlets, EJBs, JSPs, etc.; and
works with a DB2 and SQL server.  And it includes
rule-based workflow, document management, an LDAP
role-based security among other things.

There is no doubt that without the power of Scrum,
that gave us constant feedback and with that a
fresh new "context" where to apply patterns on a
daily basis, a constant oppportunity for
self-organization and re-prioritization of tasks,
and the fabric of a cooperative culture that allowed
us to freely and constantly exchange knowledge, we
would have never got to where we are here today.

I am as always proud to be a Scrum practitioner; yet,
I am still intrigued and mystified about the
simple but powerful powers of this Scrum thing.

How can something so simple be so powerful?

As fascinating as the why might be, in the end
who cares!!  ... it surely works,

- Mike



=====
Michael A. Beedle Ph. D.
CEO, Hipaa Accelerator, Inc.
2275 Half Day Rd. Suite 350
Bannockburn, IL. 60015
Office: 847-821-2631 Cell: 847-840-9890
Email: beedlem@...
Web: http://www.hipaaccelerator.com

To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Congratulations to Mike on a job well done with his innovations in Scrum and
the technology he built for hipaaccelerator. Since we developed Scrum
experientially, I too am awed by how well it works. Someday we may even
understand why.
KEn

-----Original Message-----
From: Mike Beedle [mailto:beedlem@...]
Sent: Tuesday, January 14, 2003 8:53 PM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] A Successful XBreed/Scrum Project



Dear all,

As many of you know I started another company,
Hipaa Acccelerator, http://www.hipaaccelerator.com,
about a year and a half ago, that is solely dedicated
to solve Hipaa Privacy problems.

Hipaa Privacy problems are intersting enterprise
problems because they almost always require
many projects to be managed and delivered
concurrently.  For example, Hipaa Privacy mandates
reports of PHI (protected health information),
and Disclosure Accounting reports, that must access
data throughout the enterprise, and coordinate
business processes often involving dozens of people
for approval, escalation, investigation, delegation,
management, routing, retrieval, etc.; for even
a single request.

Each client implementation needs to be deployed while
many other things change like:

   - changes in Hipaa Privacy and State laws
   - changes in the systems to be integrated with
   - changes in business processes (policies
     and procedures), typically coming from legal
     and/or business process owners
   - etc.

and couple with the normal changes and
uncertainties found in every project like:

   - staff overturn and staff absorption
   - staff mentoring/training in both the business
     domain and the technology
   - changes in technology i.e. development environment
     and deployment tools and versions, etc.;
   - changes in design
   - refactoring
   - etc.

all of which were very significat in our case.  To
make it ever more challenging, the government
mandated deadline is 4/14/2003, requiring every
project to be a "little miracle".

To cope with the above uncertainty and change, we
decided to use XBreed -- a combination of Scrum, XP,
Open Source and Alexanderian practices for every
client installation (More at: http://www.xbreed.net
Yes, I know, the XBreed site needs urgent updating...
but I am too busy in the trenches to keep it up to
date.  Besides that I don't sell software methods
or "general software development consulting" -- I
only sell Hipaa Privacy solutions these days :-)

Btw, XBreed, means "cross breed" not "extreme breed",
and it was inspired by the similar concept in genetics

which literally means a thing with the natural
selected genes of XP, Scrum, Alexanderian and
Open Source.

Today, I am glad to report that once again, Scrum,
with the extensions that we call XBreed, has helped
us deliver to production one of the most challenging
projects I had ever dealt with in my 20+ years of
experience.

Business details:
The project involved about 20 people, 5 which were
developers, 3 testers, 5 system people, 3 full time
users, 1 scrum master, 1 product owner, 2 sponsors,
etc.  It will be deployed to ~3000 thousand
users throughout the State of Idaho.

The application fulfills just about every requirement
for Hipaa Privacy compliance, as well as all the
state law preemptions for the State of Idaho.

Technical details:
The application is a 130-screen j2ee web-based
application, using servlets, EJBs, JSPs, etc.; and
works with a DB2 and SQL server.  And it includes
rule-based workflow, document management, an LDAP
role-based security among other things.

There is no doubt that without the power of Scrum,
that gave us constant feedback and with that a
fresh new "context" where to apply patterns on a
daily basis, a constant oppportunity for
self-organization and re-prioritization of tasks,
and the fabric of a cooperative culture that allowed
us to freely and constantly exchange knowledge, we
would have never got to where we are here today.

I am as always proud to be a Scrum practitioner; yet,
I am still intrigued and mystified about the
simple but powerful powers of this Scrum thing.

How can something so simple be so powerful?

As fascinating as the why might be, in the end
who cares!!  ... it surely works,

- Mike



=====
Michael A. Beedle Ph. D.
CEO, Hipaa Accelerator, Inc.
2275 Half Day Rd. Suite 350
Bannockburn, IL. 60015
Office: 847-821-2631 Cell: 847-840-9890
Email: beedlem@...
Web: http://www.hipaaccelerator.com

To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Way to go, Mike! Congratulations!

The more I read about complexity theory, the more I see Scrum: a few
simple rules that generate complex structures. Exciting stuff.





Linda


Mike Beedle wrote:

>Dear all,
>
>As many of you know I started another company,
>Hipaa Acccelerator, http://www.hipaaccelerator.com,
>about a year and a half ago, that is solely dedicated
>to solve Hipaa Privacy problems.
>
>Hipaa Privacy problems are intersting enterprise
>problems because they almost always require
>many projects to be managed and delivered
>concurrently.  For example, Hipaa Privacy mandates
>reports of PHI (protected health information),
>and Disclosure Accounting reports, that must access
>data throughout the enterprise, and coordinate
>business processes often involving dozens of people
>for approval, escalation, investigation, delegation,
>management, routing, retrieval, etc.; for even
>a single request.
>
>Each client implementation needs to be deployed while
>many other things change like:
>
>  - changes in Hipaa Privacy and State laws
>  - changes in the systems to be integrated with
>  - changes in business processes (policies
>    and procedures), typically coming from legal
>    and/or business process owners
>  - etc.
>
>and couple with the normal changes and
>uncertainties found in every project like:
>
>  - staff overturn and staff absorption
>  - staff mentoring/training in both the business
>    domain and the technology
>  - changes in technology i.e. development environment
>    and deployment tools and versions, etc.;
>  - changes in design
>  - refactoring
>  - etc.
>
>all of which were very significat in our case.  To
>make it ever more challenging, the government
>mandated deadline is 4/14/2003, requiring every
>project to be a "little miracle".
>
>To cope with the above uncertainty and change, we
>decided to use XBreed -- a combination of Scrum, XP,
>Open Source and Alexanderian practices for every
>client installation (More at: http://www.xbreed.net
>Yes, I know, the XBreed site needs urgent updating...
>but I am too busy in the trenches to keep it up to
>date.  Besides that I don't sell software methods
>or "general software development consulting" -- I
>only sell Hipaa Privacy solutions these days :-)
>
>Btw, XBreed, means "cross breed" not "extreme breed",
>and it was inspired by the similar concept in genetics
>
>which literally means a thing with the natural
>selected genes of XP, Scrum, Alexanderian and
>Open Source.
>
>Today, I am glad to report that once again, Scrum,
>with the extensions that we call XBreed, has helped
>us deliver to production one of the most challenging
>projects I had ever dealt with in my 20+ years of
>experience.
>
>Business details:
>The project involved about 20 people, 5 which were
>developers, 3 testers, 5 system people, 3 full time
>users, 1 scrum master, 1 product owner, 2 sponsors,
>etc.  It will be deployed to ~3000 thousand
>users throughout the State of Idaho.
>
>The application fulfills just about every requirement
>for Hipaa Privacy compliance, as well as all the
>state law preemptions for the State of Idaho.
>
>Technical details:
>The application is a 130-screen j2ee web-based
>application, using servlets, EJBs, JSPs, etc.; and
>works with a DB2 and SQL server.  And it includes
>rule-based workflow, document management, an LDAP
>role-based security among other things.
>
>There is no doubt that without the power of Scrum,
>that gave us constant feedback and with that a
>fresh new "context" where to apply patterns on a
>daily basis, a constant oppportunity for
>self-organization and re-prioritization of tasks,
>and the fabric of a cooperative culture that allowed
>us to freely and constantly exchange knowledge, we
>would have never got to where we are here today.
>
>I am as always proud to be a Scrum practitioner; yet,
>I am still intrigued and mystified about the
>simple but powerful powers of this Scrum thing.
>
>How can something so simple be so powerful?
>
>As fascinating as the why might be, in the end
>who cares!!  ... it surely works,
>
>- Mike
>
>
>
>=====
>Michael A. Beedle Ph. D.
>CEO, Hipaa Accelerator, Inc.
>2275 Half Day Rd. Suite 350
>Bannockburn, IL. 60015
>Office: 847-821-2631 Cell: 847-840-9890
>Email: beedlem@...
>Web: http://www.hipaaccelerator.com
>
>To Post a message, send it to:   scrumdevelopment@eGroups.com
>To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

On 2002-12-14, 04:53, Mike Cohn wrote:
> I just came across this link:
> http://www.communications.xplabs.com/experience2001-1.html

> It doesn't mention Scrum directly but does describe how rugby as a
> useful metaphor for when "teamwork is key."

Now I finally got around to read this article. It was a really good
read! Unfortunately is rugby not that popular here in Sweden, but I'm
looking forward to watch (not play :-) ) some day!

Thanks for the pointer, Mike!

--
Best regards,
  Jonas

Nostalgia isn't what it used to be.
  - Peter De Vries

Ken wrote:
> Congratulations to Mike on a job well done with his
> innovations in Scrum and the technology he built for
> hipaaccelerator. Since we developed Scrum
> experientially, I too am awed by how well it works.
> Someday we may even understand why.

Mike wrote:
>Congratulations on the successful delivery, Mike.
> That sounds like a great project

Linda wrote:
> Way to go, Mike! Congratulations!
>
> The more I read about complexity theory, the more I
> see Scrum: a few simple rules that generate complex
> structures.
> Exciting stuff.


Thanks for cheering me up guys - it is nice to have
a forum to share Scrum development experiences.

I was told yesterday by the IDHW management
that they had never had delivered software as
fast and with as much quality as they had for this
project.  In the words of the Product Owner, the
Privacy Officer here at IDHW, our project
was "nothing short of a small miracle".

One thing that  really like about our "development
style", is that we continuously revise the
requirements, the design, and re-prioritize the
tasks.  You see, their official development style
here is a strict waterfall:  1) every project
needs to write a thorough requirements document,
2) design can't start until the requirements are
finished, 3) coding can't start until they finish the
design, 4) testing doesn't start until they finish
the code, etc.

Well, for this project, we were allowed to break the
above waterfall rules because of the urgency of the
situation (Hipaa Privacy compliance means huge
liabilities: law suits, fineimprisonmentmprisionment
in some cases).

Now, after they have seen what this agile stuff
is all about, people are talking about using
Scrum/XBreed in other projects here as well.

We'll have to see how the battle betweenbureaucracynd
bureacracy plays out,

- Mike

Ken wrote:
> Congratulations to Mike on a job well done with his
> innovations in Scrum and the technology he built for
> hipaaccelerator. Since we developed Scrum
> experientially, I too am awed by how well it works.
> Someday we may even understand why.

Mike wrote:
>Congratulations on the successful delivery, Mike.
> That sounds like a great project

Linda wrote:
> Way to go, Mike! Congratulations!
>
> The more I read about complexity theory, the more I
> seee Scrum: a few simple rules that generate complex
> structures.
> Exciting stuff.


Thanks for cheering me up guys - it is nice to have
a forum to share Scrum development experiences.

I was told yesterday by the IDHW management
that they had never had delivered software as
fast and with as much quality as they had for this
project.  In the words of the Product Owner, the
Privacy Officer here at IDHW, our project
was "nothing short of a small miracle".

One thing that  really like about our "development
style", is that we continuously revise the
requirements, the design, and reprioritize the
tasks.  You see, their official development style
here is a strict waterfall:  1) every project
needs to write a thorough requirements document,
2) design can't start until the requirements are
finished, 3) coding can't start until they finish the
design, 4) testing doesn't start until they finish
the code, etc.

Well, for this project, we were allowed to break the
above waterfall rules because of the urgency of the
situation (Hipaa Privacy compliance means huge
liabilities: law suits, fines, and even imprisionment
in some cases).

Now, after they have seen what this agile stuff
is all about, people are talking about using
Scrum/XBreed in other projects here as well.

We'll have to see how the battle between agility and
bureacracy plays out,

- Mike

http://www.geocities.com/towccwypmtfe/index.html

Interesting couple of articles - has anyone heard of this effort by
the US government to develop a better way to develop software?

. . . Today's software is not as interoperable, scalable, or
cost-effective
as it needs to be, despite the enormous sums spent on its
development and maintenance.
A key to solving the problem lies in converting software design and
development - historically a solitary art practiced by programming
"wizards"
- into a formal science and engineering discipline governed by widely
accepted principles, methods, and best practices for achieving
high-quality
results. Engineers would not dream of building a suspension bridge
without
a detailed blueprint of the technical requirements, state-of-the-art
disciplinary knowledge of the principles and materials involved, and
cost-effective
manufacturing processes to produce lasting structural elements of
certified quality. As a pervasive, critical underpinning of our
national
infrastructure, software must be at least as scientifically
engineered.
One NITRD research focus is on creating, testing, and evaluating
models
for a new science of software development.The goal is to move beyond
today's idiosyncratic, arcane code to stable, engineered designs that
are
rational, modular, verifiable, and reusable. Scientific principles and
methods
will enable developers and users to design, build, test, and stress
software
products using automated techniques to see how they perform and to
pinpoint, prior to deployment, weaknesses that now simply cannot be
found
amid large-scale software's millions of lines of handcrafted code.
Automating aspects of design and implementation and employing
empirical
testbeds will curb today's very high development costs by not only
streamlining the programming stage but speeding and improving the
expensive debugging process.
The end result will be a development methodology that dramatically
increases the "productivity" of software by making more products of
higher
quality not only possible but substantially cheaper to generate and
easier to
maintain.
. . .
* Software and system science, including languages and compilers;
composition methods; and design foundations for systems and
networks that are distributed and scalable
* Automated engineering, including efficient, reliable software
components and integration processes; methods (such as specification,
analysis, and verification) for integrated software and systems
development; interoperability of concurrently running networked
applications; and configurable tool environments for rapid
composition and customization of domain-specific development
environments
* Pilot applications and empirical studies of technologies for
embedded
applications and systems development projects
----------------------------------------------------
To date, U.S. ingenuity in creating and interconnecting the inventions
of
the IT revolution has outpaced the underlying science needed to assure
that
the systems we build are engineered for reliability, security, safety,
and
scalability (can the system grow without weakening its integrity and
reliability?). In the security and safety areas, for example,
techniques
in
cryptography, public key infrastructure (PKI), network management,
intrusion detection, and fault/failure tolerance have been developed
largely
independent of core functionality and speed. We have not yet
integrated
the
high-confidence attributes we now know are necessary into the
technical
design foundations for both large- and small-scale complex software
and
systems. In the current incremental, add-on development process, the
responsibility for determining whether the system works falls largely
to
a
costly, time-consuming, after-the-fact process of testing, which often
fails
nonetheless to catch system failure conditions in the subtle
interactions
among software and hardware components.
The fact is that we do not yet understand the underlying patterns of
failures in large complex systems, or even the systems themselves. The
NITRD agencies' focused research effort in high-confidence software
and
systems seeks to provide the missing theoretical and technological
underpinnings for assured construction of secure, highly reliable
software
and systems.This revolutionary work will give system designers and
engineers a formal scientific grounding for building sound systems as
well as
powerful new diagnostic and forensic tools for cost-effectively
assessing
software and system reliability, security, and performance.
In FY 2003, the NITRD agencies will support research in modeling and
reasoning about whole systems and about their component technologies
(operating system, middleware, networking, safety and especially
security
attributes) and mathematical and engineering approaches to
specification,
component integration, and interoperability issues. Other research
focus
areas are languages, tools, and automated techniques to eliminate
sources of
error, and technical strategies for integrating high-confidence
properties in
software and systems design.
Major Research Challenges
* Foundations of assurance, including rigorous modeling and reasoning
about high-confidence properties; interoperable methods and tools;
system composition; specification, safety, and security foundations
* Scalable fault prevention, detection, analysis, and recovery,
including
robust system architectures and tools for monitoring and adaptive
response
* Correct-by-construction software technologies, including
programming languages, tools, and environments; systems software,
middleware, and networking (reusable middleware services such as
efficient, predictable, scalable, dependable protocols for timing,
consensus, synchronization, and replication for large-scale
distributed
embedded applications and domain-specific services)
* Verification and validation technologies
* Forensic and diagnostic tools
* Experimentation with large-scale systems
* Reference implementations
* Domain-specific certification technologies
* Reduction of time, effort, and cost of assurance and certification
* Technological base of public domain, advanced prototype
implementations of high-confidence technologies to enable rapid
adoption in the private sector and in government

Interesting couple of articles - has anyone heard of this effort by
the US government to develop a better way to develop software?

. . . Today's software is not as interoperable, scalable, or
cost-effective
as it needs to be, despite the enormous sums spent on its
development and maintenance.
A key to solving the problem lies in converting software design and
development - historically a solitary art practiced by programming
"wizards"
- into a formal science and engineering discipline governed by widely
accepted principles, methods, and best practices for achieving
high-quality
results. Engineers would not dream of building a suspension bridge
without
a detailed blueprint of the technical requirements, state-of-the-art
disciplinary knowledge of the principles and materials involved, and
cost-effective
manufacturing processes to produce lasting structural elements of
certified quality. As a pervasive, critical underpinning of our
national
infrastructure, software must be at least as scientifically
engineered.
One NITRD research focus is on creating, testing, and evaluating
models
for a new science of software development.The goal is to move beyond
today's idiosyncratic, arcane code to stable, engineered designs that
are
rational, modular, verifiable, and reusable. Scientific principles and
methods
will enable developers and users to design, build, test, and stress
software
products using automated techniques to see how they perform and to
pinpoint, prior to deployment, weaknesses that now simply cannot be
found
amid large-scale software's millions of lines of handcrafted code.
Automating aspects of design and implementation and employing
empirical
testbeds will curb today's very high development costs by not only
streamlining the programming stage but speeding and improving the
expensive debugging process.
The end result will be a development methodology that dramatically
increases the "productivity" of software by making more products of
higher
quality not only possible but substantially cheaper to generate and
easier to
maintain.
. . .
* Software and system science, including languages and compilers;
composition methods; and design foundations for systems and
networks that are distributed and scalable
* Automated engineering, including efficient, reliable software
components and integration processes; methods (such as specification,
analysis, and verification) for integrated software and systems
development; interoperability of concurrently running networked
applications; and configurable tool environments for rapid
composition and customization of domain-specific development
environments
* Pilot applications and empirical studies of technologies for
embedded
applications and systems development projects
----------------------------------------------------
To date, U.S. ingenuity in creating and interconnecting the inventions
of
the IT revolution has outpaced the underlying science needed to assure
that
the systems we build are engineered for reliability, security, safety,
and
scalability (can the system grow without weakening its integrity and
reliability?). In the security and safety areas, for example,
techniques
in
cryptography, public key infrastructure (PKI), network management,
intrusion detection, and fault/failure tolerance have been developed
largely
independent of core functionality and speed. We have not yet
integrated
the
high-confidence attributes we now know are necessary into the
technical
design foundations for both large- and small-scale complex software
and
systems. In the current incremental, add-on development process, the
responsibility for determining whether the system works falls largely
to
a
costly, time-consuming, after-the-fact process of testing, which often
fails
nonetheless to catch system failure conditions in the subtle
interactions
among software and hardware components.
The fact is that we do not yet understand the underlying patterns of
failures in large complex systems, or even the systems themselves. The
NITRD agencies' focused research effort in high-confidence software
and
systems seeks to provide the missing theoretical and technological
underpinnings for assured construction of secure, highly reliable
software
and systems.This revolutionary work will give system designers and
engineers a formal scientific grounding for building sound systems as
well as
powerful new diagnostic and forensic tools for cost-effectively
assessing
software and system reliability, security, and performance.
In FY 2003, the NITRD agencies will support research in modeling and
reasoning about whole systems and about their component technologies
(operating system, middleware, networking, safety and especially
security
attributes) and mathematical and engineering approaches to
specification,
component integration, and interoperability issues. Other research
focus
areas are languages, tools, and automated techniques to eliminate
sources of
error, and technical strategies for integrating high-confidence
properties in
software and systems design.
Major Research Challenges
* Foundations of assurance, including rigorous modeling and reasoning
about high-confidence properties; interoperable methods and tools;
system composition; specification, safety, and security foundations
* Scalable fault prevention, detection, analysis, and recovery,
including
robust system architectures and tools for monitoring and adaptive
response
* Correct-by-construction software technologies, including
programming languages, tools, and environments; systems software,
middleware, and networking (reusable middleware services such as
efficient, predictable, scalable, dependable protocols for timing,
consensus, synchronization, and replication for large-scale
distributed
embedded applications and domain-specific services)
* Verification and validation technologies
* Forensic and diagnostic tools
* Experimentation with large-scale systems
* Reference implementations
* Domain-specific certification technologies
* Reduction of time, effort, and cost of assurance and certification
* Technological base of public domain, advanced prototype
implementations of high-confidence technologies to enable rapid
adoption in the private sector and in government




To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

The entire mail assumes that making software is like building bridges. I
disagree with that. Building a bridge is more like compiling a software.
Programming is a design activity. Is more like writting the bridge's
plan. So I think that is useless to try to systematize software like
building construction.

That's why we need empirical methods to make software (like scrum).

Aureliano.
PS: I apologize for my english.

>Interesting couple of articles - has anyone heard of this effort by
>the US government to develop a better way to develop software?
>
>. . . Today's software is not as interoperable, scalable, or
>cost-effective
>as it needs to be, despite the enormous sums spent on its
>development and maintenance.
>A key to solving the problem lies in converting software design and
>development - historically a solitary art practiced by programming
>"wizards"
>- into a formal science and engineering discipline governed by widely
>accepted principles, methods, and best practices for achieving
>high-quality
>results. Engineers would not dream of building a suspension bridge
>without
>a detailed blueprint of the technical requirements, state-of-the-art
>disciplinary knowledge of the principles and materials involved, and
>cost-effective
>manufacturing processes to produce lasting structural elements of
>certified quality. As a pervasive, critical underpinning of our
>national
>infrastructure, software must be at least as scientifically
>engineered.
>One NITRD research focus is on creating, testing, and evaluating
>models
>for a new science of software development.The goal is to move beyond
>today's idiosyncratic, arcane code to stable, engineered designs that
>are
>rational, modular, verifiable, and reusable. Scientific principles and
>methods
>will enable developers and users to design, build, test, and stress
>software
>products using automated techniques to see how they perform and to
>pinpoint, prior to deployment, weaknesses that now simply cannot be
>found
>amid large-scale software's millions of lines of handcrafted code.
>Automating aspects of design and implementation and employing
>empirical
>testbeds will curb today's very high development costs by not only
>streamlining the programming stage but speeding and improving the
>expensive debugging process.
>The end result will be a development methodology that dramatically
>increases the "productivity" of software by making more products of
>higher
>quality not only possible but substantially cheaper to generate and
>easier to
>maintain.
>. . .
>* Software and system science, including languages and compilers;
>composition methods; and design foundations for systems and
>networks that are distributed and scalable
>* Automated engineering, including efficient, reliable software
>components and integration processes; methods (such as specification,
>analysis, and verification) for integrated software and systems
>development; interoperability of concurrently running networked
>applications; and configurable tool environments for rapid
>composition and customization of domain-specific development
>environments
>* Pilot applications and empirical studies of technologies for
>embedded
>applications and systems development projects
>----------------------------------------------------
>To date, U.S. ingenuity in creating and interconnecting the inventions
>of
>the IT revolution has outpaced the underlying science needed to assure
>that
>the systems we build are engineered for reliability, security, safety,
>and
>scalability (can the system grow without weakening its integrity and
>reliability?). In the security and safety areas, for example,
>techniques
>in
>cryptography, public key infrastructure (PKI), network management,
>intrusion detection, and fault/failure tolerance have been developed
>largely
>independent of core functionality and speed. We have not yet
>integrated
>the
>high-confidence attributes we now know are necessary into the
>technical
>design foundations for both large- and small-scale complex software
>and
>systems. In the current incremental, add-on development process, the
>responsibility for determining whether the system works falls largely
>to
>a
>costly, time-consuming, after-the-fact process of testing, which often
>fails
>nonetheless to catch system failure conditions in the subtle
>interactions
>among software and hardware components.
>The fact is that we do not yet understand the underlying patterns of
>failures in large complex systems, or even the systems themselves. The
>NITRD agencies' focused research effort in high-confidence software
>and
>systems seeks to provide the missing theoretical and technological
>underpinnings for assured construction of secure, highly reliable
>software
>and systems.This revolutionary work will give system designers and
>engineers a formal scientific grounding for building sound systems as
>well as
>powerful new diagnostic and forensic tools for cost-effectively
>assessing
>software and system reliability, security, and performance.
>In FY 2003, the NITRD agencies will support research in modeling and
>reasoning about whole systems and about their component technologies
>(operating system, middleware, networking, safety and especially
>security
>attributes) and mathematical and engineering approaches to
>specification,
>component integration, and interoperability issues. Other research
>focus
>areas are languages, tools, and automated techniques to eliminate
>sources of
>error, and technical strategies for integrating high-confidence
>properties in
>software and systems design.
>Major Research Challenges
>* Foundations of assurance, including rigorous modeling and reasoning
>about high-confidence properties; interoperable methods and tools;
>system composition; specification, safety, and security foundations
>* Scalable fault prevention, detection, analysis, and recovery,
>including
>robust system architectures and tools for monitoring and adaptive
>response
>* Correct-by-construction software technologies, including
>programming languages, tools, and environments; systems software,
>middleware, and networking (reusable middleware services such as
>efficient, predictable, scalable, dependable protocols for timing,
>consensus, synchronization, and replication for large-scale
>distributed
>embedded applications and domain-specific services)
>* Verification and validation technologies
>* Forensic and diagnostic tools
>* Experimentation with large-scale systems
>* Reference implementations
>* Domain-specific certification technologies
>* Reduction of time, effort, and cost of assurance and certification
>* Technological base of public domain, advanced prototype
>implementations of high-confidence technologies to enable rapid
>adoption in the private sector and in government
>
>
>
>To Post a message, send it to:   scrumdevelopment@eGroups.com
>To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>

-----Original Message-----
From: Aureliano Calvo [mailto:acalvo@...]
Sent: Friday, January 24, 2003 6:45 AM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] tax $$ at work - a better way to develop software

The entire mail assumes that making software is like building bridges. I
disagree with that. Building a bridge is more like compiling a software.
Programming is a design activity. Is more like writting the bridge's
plan. So I think that is useless to try to systematize software like
building construction.

That's why we need empirical methods to make software (like scrum).

Aureliano.
PS: I apologize for my english.

>Interesting couple of articles - has anyone heard of this effort by
>the US government to develop a better way to develop software?
>
>. . . Today's software is not as interoperable, scalable, or
>cost-effective
>as it needs to be, despite the enormous sums spent on its
>development and maintenance.
>A key to solving the problem lies in converting software design and
>development - historically a solitary art practiced by programming
>"wizards"
>- into a formal science and engineering discipline governed by widely
>accepted principles, methods, and best practices for achieving
>high-quality
>results. Engineers would not dream of building a suspension bridge
>without
>a detailed blueprint of the technical requirements, state-of-the-art
>disciplinary knowledge of the principles and materials involved, and
>cost-effective
>manufacturing processes to produce lasting structural elements of
>certified quality. As a pervasive, critical underpinning of our
>national
>infrastructure, software must be at least as scientifically
>engineered.
>One NITRD research focus is on creating, testing, and evaluating
>models
>for a new science of software development.The goal is to move beyond
>today's idiosyncratic, arcane code to stable, engineered designs that
>are
>rational, modular, verifiable, and reusable. Scientific principles and
>methods
>will enable developers and users to design, build, test, and stress
>software
>products using automated techniques to see how they perform and to
>pinpoint, prior to deployment, weaknesses that now simply cannot be
>found
>amid large-scale software's millions of lines of handcrafted code.
>Automating aspects of design and implementation and employing
>empirical
>testbeds will curb today's very high development costs by not only
>streamlining the programming stage but speeding and improving the
>expensive debugging process.
>The end result will be a development methodology that dramatically
>increases the "productivity" of software by making more products of
>higher
>quality not only possible but substantially cheaper to generate and
>easier to
>maintain.
>. . .
>* Software and system science, including languages and compilers;
>composition methods; and design foundations for systems and
>networks that are distributed and scalable
>* Automated engineering, including efficient, reliable software
>components and integration processes; methods (such as specification,
>analysis, and verification) for integrated software and systems
>development; interoperability of concurrently running networked
>applications; and configurable tool environments for rapid
>composition and customization of domain-specific development
>environments
>* Pilot applications and empirical studies of technologies for
>embedded
>applications and systems development projects
>----------------------------------------------------
>To date, U.S. ingenuity in creating and interconnecting the inventions
>of
>the IT revolution has outpaced the underlying science needed to assure
>that
>the systems we build are engineered for reliability, security, safety,
>and
>scalability (can the system grow without weakening its integrity and
>reliability?). In the security and safety areas, for example,
>techniques
>in
>cryptography, public key infrastructure (PKI), network management,
>intrusion detection, and fault/failure tolerance have been developed
>largely
>independent of core functionality and speed. We have not yet
>integrated
>the
>high-confidence attributes we now know are necessary into the
>technical
>design foundations for both large- and small-scale complex software
>and
>systems. In the current incremental, add-on development process, the
>responsibility for determining whether the system works falls largely
>to
>a
>costly, time-consuming, after-the-fact process of testing, which often
>fails
>nonetheless to catch system failure conditions in the subtle
>interactions
>among software and hardware components.
>The fact is that we do not yet understand the underlying patterns of
>failures in large complex systems, or even the systems themselves. The
>NITRD agencies' focused research effort in high-confidence software
>and
>systems seeks to provide the missing theoretical and technological
>underpinnings for assured construction of secure, highly reliable
>software
>and systems.This revolutionary work will give system designers and
>engineers a formal scientific grounding for building sound systems as
>well as
>powerful new diagnostic and forensic tools for cost-effectively
>assessing
>software and system reliability, security, and performance.
>In FY 2003, the NITRD agencies will support research in modeling and
>reasoning about whole systems and about their component technologies
>(operating system, middleware, networking, safety and especially
>security
>attributes) and mathematical and engineering approaches to
>specification,
>component integration, and interoperability issues. Other research
>focus
>areas are languages, tools, and automated techniques to eliminate
>sources of
>error, and technical strategies for integrating high-confidence
>properties in
>software and systems design.
>Major Research Challenges
>* Foundations of assurance, including rigorous modeling and reasoning
>about high-confidence properties; interoperable methods and tools;
>system composition; specification, safety, and security foundations
>* Scalable fault prevention, detection, analysis, and recovery,
>including
>robust system architectures and tools for monitoring and adaptive
>response
>* Correct-by-construction software technologies, including
>programming languages, tools, and environments; systems software,
>middleware, and networking (reusable middleware services such as
>efficient, predictable, scalable, dependable protocols for timing,
>consensus, synchronization, and replication for large-scale
>distributed
>embedded applications and domain-specific services)
>* Verification and validation technologies
>* Forensic and diagnostic tools
>* Experimentation with large-scale systems
>* Reference implementations
>* Domain-specific certification technologies
>* Reduction of time, effort, and cost of assurance and certification
>* Technological base of public domain, advanced prototype
>implementations of high-confidence technologies to enable rapid
>adoption in the private sector and in government
>
>
>
>To Post a message, send it to:   scrumdevelopment@eGroups.com
>To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@eGroups.com
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
> 
>





To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

I think Ken's point (actually everyone's point) is captured in the
interesting, yet unintended direction the thread went.  What I was
hoping to discover was if anyone knew the direction this government
agency was going or was in any way involved.  I agree that
empirically, Scrum seems to work fairly well for us.  In fact, better
the more we use it.  Based on that, I'm hoping that next year my boss
won't come to me and say "The NITRD just developed a new software
methodology that is proven [in theory] to produce great software.
Your team should follow that."

I've had a *little* experience with proof-driven methodologies such
as "Clean room" (popularized by IBM & HP), and found that while they
generated low-defect software, it wasn't necessarily what the
customer or the market demanded by the time it rolled out.

Dan Brown


--- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
<ken.schwaber@v...> wrote:
> "A key to solving the problem lies in converting software design and
> development - historically a solitary art practiced by programming
> "wizards"- into a formal science and engineering discipline
governed by
> widely
> accepted principles, methods, and best practices for achieving
> high-quality results. Engineers would not dream of building a
suspension
> bridge
> without a detailed blueprint of the technical requirements, state-
of-the-art
> disciplinary knowledge of the principles and materials involved, and
> cost-effective manufacturing processes to produce lasting structural
> elements of
> certified quality. As a pervasive, critical underpinning of our
> national infrastructure, software must be at least as scientifically
> engineered."
>
> I've been following this thread with keen interest, for a feel the
above
> statement describes the premise that led us into the rigorous,
defined,
> unworkable methodologies that fail so miserably when applied to
complex
> projects (all the one's that I've seen). We seem myopic, looking at
other
> disciplines and wishing that we had the precise, defined,
scientific rigor
> they had. Yet, the "big dig" in Boston is a wonderful example that
this
> isn't true. The project managers laid out great plans and budgets
for
> submerging an elevated highway through Boston into an underground
tunnel.
> However, reality quickly diverged from plan as they dug, uncovering
> tremendous differences from what they had assumed. For instance,
the bedrock
> on which a "simple to engineer" bridge was to be placed wasn't as
expected,
> and when they started to use it they discovered infrastructure
pressures
> that rattled nearby subway lines. Day by day, iteration by
iteration, they
> had to compromise and revise their plans based on what they found.
The
> project is now some 300% over budget, and everyone says they are
> imcompentent. I believe the only incompetence was in their
believing that
> they had a science and could predict the unpredictable. When they
built one
> suspension bridge, they vastly overspent because - despite all of
the
> science of bridge building - the stress that the cables put on the
bridge
> required empirical tuning and retuning to work.
>
> Some really good books on this subject. Like "American Ground",
describing
> the deconstructing of the World Trade Center disaster, where
everything
> emerged through daily meetings directed by two people with no
authority and
> no detailed plan. Like "The Emergence of Everything", where Harold
Morowitz
> points out that - despite popular perceptions - deterministic
science has
> only proven useful when roughly applied. For instance, Newton's
laws are
> used to describe and predict interplanetary movement. Yet they are
> applicable for only two bodies. The complexity of what really is
occcurring
> invalidates these laws when they try to predict the
interoperability of
> three or more bodies. The idea of observing something and reducing
it to a
> set of laws, principles, and practices has been wildly successful
in gaining
> coarse control over our environment. However, using these same laws
to
> predict how finely grained objects interact as they built up have
been
> horribly unsuccessful. It turns out, as complexity science has
observed,
> that very minute variations in the initial conditions often lead to
wildly
> unpredictable perturbations when scaled into the large.
>
> I believe that software development is a wonderful subject - both
to do and
> to study. I belive that we need to understand it better to do it
better. I
> have moved Scrum forward because I find it to be a sustainable,
scalable
> framework for software development. But I do not understand how it
works. I
> don't understand emergence, I just understand the beauty of it and
how it
> unleashes creativity. I don't know how models translate from the
mind to the
> software, and I don't know how we make up for the fuzzy boundaries
and
> undefined or weakly defined aspects of models. But I know with
inspection,
> adaptation, and dilligence, that we can built software.
>
> In "Corps Business", the approach the US Marines take to complexity
is
> discussed. They belive that the world has gotten so complicated and
dense
> that the marines will find every possible battlefield complexity
within a
> three block area - far too complex and dense for top down direction
from
> generals to privates. To address this, the marines train
extensively in
> every possible technique of warfare, in every conceivable
circumstance.
> Before a mission, they meet and discuss the mission - it's
objectives, the
> desired outcome, the risks, the potential variations and
complexities. Then
> they put the troops into the battlefield and count on them to use
their
> training, their common sense, and their knowledge of the situation
to do the
> best they can possible do. The marine corps trains leaders, not
scientists.
>
> Thanks for your attention,
> Ken

[Note -- if you have previously submitted a tutorial for this
conference, please send it again. Due to an unfortunate disk crash, all
submissions prior to Dec 2002 were lost -- BaB]

                           XP/Agile Universe
                            New Orleans, LA
                           August 10-13, 2003

                    Tutorial Call For Participation

                          Conference Web Site:
                       http://www.xpuniverse.com

                        Tutorial CFP Home Page:
             http://www.xpuniverse.com/CallForParticipation

                            Important Dates:
                  Proposal Deadline: February 28, 2003
                Acceptance Notification: April 17, 2003
                   Final Manuscript Due: May 16, 2003

                        Tutorial Submissions To:
                  Brian Button, tutorials@...

The XP/Agile Universe Conference is now accepting proposals for the
2003 tutorial sessions. Tutorials for any Agile Method are
accepted and encouraged.

Tutorials are an independent instruction on a self-contained topic of
relevance to conference attendees.  Therefore no commercial or
sales-oriented presentations will be accepted.  We encourage tutorial
proposals that provide clear utility to practitioners, especially
innovative tutorials, which depart from lecture style delivery, and
tutorials on highly advanced topics in lightweight processes.

Tutorials are presented in half-day (3-hour) or full-day sessions
(6-hour). Accepted tutorials will run only if there is enough
attendance.

If you want to organize a tutorial, submit a proposal via e-mail to
the tutorial chair Brian Button (tutorials@...). We will
accept PDF (preferred), HTML and MS Word files as proposals. A
tutorial proposal must be two pages and should include:

* Tutorial title and summary (used in advance program)
* Duration (full- or half-day), aims and audience
* Content outline
* Presenter resume with contact information
* Examples of supporting material

Each tutorial proposal will be evaluated on its anticipated benefit
for prospective participants and its fit within the tutorial program
as a whole. Factors to be considered also include: relevance,
timeliness, importance, and audience appeal; suitability for
presentation in a half- or full-day tutorial format; effectiveness of
teaching methods; and qualifications of the instructor(s).

Previous tutorial topics have included:

XP and Legacy Environments
Unit Testing Techniques
Advanced Unit Testing Techniques
Refactoring Techniques
Organizational Change
Scrum
Coaching
Feature Driven Development
Acceptance Testing Techniques
System Metaphor
Scaling Agile Processes
User Stories
Planning Extreme and Agile Projects

Brian Button
Tutorial Chair
XP/Agile Universe
--
Brian Button 	 bbutton@...
Principal Consultant  http://www.agilesolutionsgroup.com
Agile Solutions Group  636.399.3146
St. Louis, MO

Extreme Programming in St. Louis - http://www.groups.yahoo.com/group/xpstl

Ken,

We've all seen this argument for heavyweight processes a hundred
times, and we always come up with the same defense, which is to point
out that, "software development is not like defined processes, such
as bridge-building."  In this post, however, I think you have
introduced what may be an even better argument - that classical
engineering isn't nearly as defined as people say it is!

I recall recently seeing a documentary on the development of the new
Harley-Davidson V-Rod.  These guys started with a list of
requirements that were as vauge and incomplete as any you would find
in a software project, ("it has to 'look' like a Harley!").  Every
day of development brought on a whole new set of problems, to the
point where you wondered if they were going to be able to release the
product at all.  There were attributes of that development process
that seemed very familiar.

1.  The engineers, product specialists, artists, marketing people,
executives, test drivers etc. all worked on the same team to deliver
the product.  They met regularly, held impromptu design meetings,
talked constantly, and were always critiqueing each others work.
There were no "engineering" or "QA" departments, just one team that
had everyone it needed.

2.  They started with only rudimentary requirements.  The rest of the
requirements came out as the product people and executives saw the
result take shape.  The stakeholders saw the product and gave
feedback on a daily basis.

3.  The engineers relied heavily on their knowledge of physics and
mechanics - and known best practices - rather than on a strict
process.

4.  They built a lot of prototypes.  In one scene, they used a FedEx
box and duct tape to build a working air scoop.  This turned out to
be one of their greatest successes.

Everything I listed above could have been straight from an agile
development project.  The lesson in all of this is that classical
engineering isn't nearly as defined as some people say it is.  The
usual confusion between design and construction may be just as much
an issue with them as it is with us.  I wonder what the
Harley-Davidson team would say if they had to come up with a detailed
technical specification before they could build a prototype!

-arc

--- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
<ken.schwaber@v...> wrote:
> "A key to solving the problem lies in converting software design and
> development - historically a solitary art practiced by programming
> "wizards"- into a formal science and engineering discipline
governed by
> widely
> accepted principles, methods, and best practices for achieving
> high-quality results. Engineers would not dream of building a
suspension
> bridge
> without a detailed blueprint of the technical requirements,
state-of-the-art
> disciplinary knowledge of the principles and materials involved, and
> cost-effective manufacturing processes to produce lasting structural
> elements of
> certified quality. As a pervasive, critical underpinning of our
> national infrastructure, software must be at least as scientifically
> engineered."
>
> I've been following this thread with keen interest, for a feel the
above
> statement describes the premise that led us into the rigorous,
defined,
> unworkable methodologies that fail so miserably when applied to
complex
> projects (all the one's that I've seen). We seem myopic, looking at
other
> disciplines and wishing that we had the precise, defined,
scientific rigor
> they had. Yet, the "big dig" in Boston is a wonderful example that
this
> isn't true. The project managers laid out great plans and budgets
for
> submerging an elevated highway through Boston into an underground
tunnel.
> However, reality quickly diverged from plan as they dug, uncovering
> tremendous differences from what they had assumed. For instance,
the bedrock
> on which a "simple to engineer" bridge was to be placed wasn't as
expected,
> and when they started to use it they discovered infrastructure
pressures
> that rattled nearby subway lines. Day by day, iteration by
iteration, they
> had to compromise and revise their plans based on what they found.
The
> project is now some 300% over budget, and everyone says they are
> imcompentent. I believe the only incompetence was in their
believing that
> they had a science and could predict the unpredictable. When they
built one
> suspension bridge, they vastly overspent because - despite all of
the
> science of bridge building - the stress that the cables put on the
bridge
> required empirical tuning and retuning to work.
>
> Some really good books on this subject. Like "American Ground",
describing
> the deconstructing of the World Trade Center disaster, where
everything
> emerged through daily meetings directed by two people with no
authority and
> no detailed plan. Like "The Emergence of Everything", where Harold
Morowitz
> points out that - despite popular perceptions - deterministic
science has
> only proven useful when roughly applied. For instance, Newton's
laws are
> used to describe and predict interplanetary movement. Yet they are
> applicable for only two bodies. The complexity of what really is
occcurring
> invalidates these laws when they try to predict the
interoperability of
> three or more bodies. The idea of observing something and reducing
it to a
> set of laws, principles, and practices has been wildly successful
in gaining
> coarse control over our environment. However, using these same laws
to
> predict how finely grained objects interact as they built up have
been
> horribly unsuccessful. It turns out, as complexity science has
observed,
> that very minute variations in the initial conditions often lead to
wildly
> unpredictable perturbations when scaled into the large.
>
> I believe that software development is a wonderful subject - both
to do and
> to study. I belive that we need to understand it better to do it
better. I
> have moved Scrum forward because I find it to be a sustainable,
scalable
> framework for software development. But I do not understand how it
works. I
> don't understand emergence, I just understand the beauty of it and
how it
> unleashes creativity. I don't know how models translate from the
mind to the
> software, and I don't know how we make up for the fuzzy boundaries
and
> undefined or weakly defined aspects of models. But I know with
inspection,
> adaptation, and dilligence, that we can built software.
>
> In "Corps Business", the approach the US Marines take to complexity
is
> discussed. They belive that the world has gotten so complicated and
dense
> that the marines will find every possible battlefield complexity
within a
> three block area - far too complex and dense for top down direction
from
> generals to privates. To address this, the marines train
extensively in
> every possible technique of warfare, in every conceivable
circumstance.
> Before a mission, they meet and discuss the mission - it's
objectives, the
> desired outcome, the risks, the potential variations and
complexities. Then
> they put the troops into the battlefield and count on them to use
their
> training, their common sense, and their knowledge of the situation
to do the
> best they can possible do. The marine corps trains leaders, not
scientists.
>
> Thanks for your attention,
> Ken

---------------------------------------------------------------------
    XP Agile Universe 2003 Call for Workshop Proposals
    New Orleans, Louisiana, USA
    August 10-13, 2003
    www.agileuniverse.com
    www.xpuniverse.com
---------------------------------------------------------------------

[Apologies for multiple copies of this announcement]

Workshops provide a forum for small groups to engage in rich
intellectual discussions about a topic of common interest. They aim
to advance the state of agile software development methods and/or
provide insight into future research directions. Workshops also
provide a valuable opportunity for representatives of a technical
community to coordinate efforts and to establish collective plans of
action.

We welcome proposals on any topic of interest to the Agile Community.
We also encourage proposals involving research or applied topics in
neighboring areas.

To foster dialog, the workshops will be kept small, with upto 20
invited participants (exceptions can be made). To ensure a
sufficiently small group for effective interaction and discussion,
workshop organizers manage attendance based on a review of short
position papers from potential attendees. The position papers need to
be published on the Web prior to the workshop by the workshop
organizers.

Workshops are typically a half-day (3 hours) in length. In
exceptional cases, full day (6-hour) workshops will also be accepted.
We particularly encourage proposals for novel, highly-interactive
workshops. Each workshop must have at least two organizers,
preferably from different organizations.

If you want to organize a workshop, submit a proposal via e-mail to
the Workshop Chair Grigori Melnik (grigori.melnik@...) by
February 28, 2003. We will accept PDF, XHTML and MS Word files.
Workshop proposals should include:
- a workshop title and a half-page description (to be included in the
Conference Program);
- the name of the workshop primary contact;
- an outline of the theme and goals of the workshop (please identify
specific issues on which workshop will focus, as opposed to proposing
broad discussion of a particular field of research. Discuss why the
topic is of interest at this time);
- a description of the proposed workshop format and proposed length
(half-day or full-day);
- a short description of the participant solicitation and selection
process (usually, the selection process is based on peer review);
- a brief description of each organizer's background with contact
information.

Each proposal will be reviewed by the program committee representing
a cross-section of practitioners and researchers (for the list of
members, consult the main conference site). Acceptance will be based
on the evaluation of the workshop potential to advance the state of
agile methods, the expected level of interest in the topic, and the
organizers' ability to lead a successful workshop.

Workshop organizers will be responsible for:
- submitting a workshop proposal;
- developing a Call for Position Papers for the workshop;
- setting up and maintaining a workshop Web site;
- inviting, selecting and confirming workshop participants;
- announcing the workshop in relevant newsgroups, distributing the
Call for Position Papers to electronic mailing lists, and ensuring
the workshop publicity;
- soliciting position papers from their colleagues;
- managing position papers review process and notifying authors;
- distributing position papers and other pre-workshop materials to
participants in advance of the workshop;
- assembling camera-ready electronic version of one-page summary of
the workshop for the conference proceedings;
- facilitating the workshop.


Full Announcement and Call for Participation for the XP Agile
Universe 2003 Conference:
http://www.agileuniverse.com/CallForParticipation

Just to close the loop: you're describing a new product development process.
The origin of our use of "scrum" is in fact from this very arena: Hirotaka
Takeuchi
and Ikujiro Nonaka, "The New New Process Development Game." New product
development processes stand in stark contrast with manufacturing processes,
from
which we get heavyweight processes like CMM. We *are* using engineering
best practice -- from the applicable domain of engineering.
Robert Henley

----- Original Message -----
From: <acirillo@...>
To: <scrumdevelopment@yahoogroups.com>
Sent: Wednesday, January 29, 2003 12:26 AM
Subject: [scrumdevelopment] Re: tax $$ at work - a better way to develop
software


> Ken,
>
> We've all seen this argument for heavyweight processes a hundred
> times, and we always come up with the same defense, which is to point
> out that, "software development is not like defined processes, such
> as bridge-building."  In this post, however, I think you have
> introduced what may be an even better argument - that classical
> engineering isn't nearly as defined as people say it is!
>
> I recall recently seeing a documentary on the development of the new
> Harley-Davidson V-Rod.  These guys started with a list of
> requirements that were as vauge and incomplete as any you would find
> in a software project, ("it has to 'look' like a Harley!").  Every
> day of development brought on a whole new set of problems, to the
> point where you wondered if they were going to be able to release the
> product at all.  There were attributes of that development process
> that seemed very familiar.

Andy,
Now, I finally have the reason to get a Harley-Davidson V-Rod!! Just
investigating the results of an agile process, not indulging myself.
Ken

-----Original Message-----
From: Andy Cirillo <acirillo@...> [mailto:acirillo@...]
Sent: Wednesday, January 29, 2003 12:27 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Re: tax $$ at work - a better way to develop
software


Ken,

We've all seen this argument for heavyweight processes a hundred
times, and we always come up with the same defense, which is to point
out that, "software development is not like defined processes, such
as bridge-building."  In this post, however, I think you have
introduced what may be an even better argument - that classical
engineering isn't nearly as defined as people say it is!

I recall recently seeing a documentary on the development of the new
Harley-Davidson V-Rod.  These guys started with a list of
requirements that were as vauge and incomplete as any you would find
in a software project, ("it has to 'look' like a Harley!").  Every
day of development brought on a whole new set of problems, to the
point where you wondered if they were going to be able to release the
product at all.  There were attributes of that development process
that seemed very familiar.

1.  The engineers, product specialists, artists, marketing people,
executives, test drivers etc. all worked on the same team to deliver
the product.  They met regularly, held impromptu design meetings,
talked constantly, and were always critiqueing each others work.
There were no "engineering" or "QA" departments, just one team that
had everyone it needed.

2.  They started with only rudimentary requirements.  The rest of the
requirements came out as the product people and executives saw the
result take shape.  The stakeholders saw the product and gave
feedback on a daily basis.

3.  The engineers relied heavily on their knowledge of physics and
mechanics - and known best practices - rather than on a strict
process.

4.  They built a lot of prototypes.  In one scene, they used a FedEx
box and duct tape to build a working air scoop.  This turned out to
be one of their greatest successes.

Everything I listed above could have been straight from an agile
development project.  The lesson in all of this is that classical
engineering isn't nearly as defined as some people say it is.  The
usual confusion between design and construction may be just as much
an issue with them as it is with us.  I wonder what the
Harley-Davidson team would say if they had to come up with a detailed
technical specification before they could build a prototype!

-arc

--- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
<ken.schwaber@v...> wrote:
> "A key to solving the problem lies in converting software design and
> development - historically a solitary art practiced by programming
> "wizards"- into a formal science and engineering discipline
governed by
> widely
> accepted principles, methods, and best practices for achieving
> high-quality results. Engineers would not dream of building a
suspension
> bridge
> without a detailed blueprint of the technical requirements,
state-of-the-art
> disciplinary knowledge of the principles and materials involved, and
> cost-effective manufacturing processes to produce lasting structural
> elements of
> certified quality. As a pervasive, critical underpinning of our
> national infrastructure, software must be at least as scientifically
> engineered."
>
> I've been following this thread with keen interest, for a feel the
above
> statement describes the premise that led us into the rigorous,
defined,
> unworkable methodologies that fail so miserably when applied to
complex
> projects (all the one's that I've seen). We seem myopic, looking at
other
> disciplines and wishing that we had the precise, defined,
scientific rigor
> they had. Yet, the "big dig" in Boston is a wonderful example that
this
> isn't true. The project managers laid out great plans and budgets
for
> submerging an elevated highway through Boston into an underground
tunnel.
> However, reality quickly diverged from plan as they dug, uncovering
> tremendous differences from what they had assumed. For instance,
the bedrock
> on which a "simple to engineer" bridge was to be placed wasn't as
expected,
> and when they started to use it they discovered infrastructure
pressures
> that rattled nearby subway lines. Day by day, iteration by
iteration, they
> had to compromise and revise their plans based on what they found.
The
> project is now some 300% over budget, and everyone says they are
> imcompentent. I believe the only incompetence was in their
believing that
> they had a science and could predict the unpredictable. When they
built one
> suspension bridge, they vastly overspent because - despite all of
the
> science of bridge building - the stress that the cables put on the
bridge
> required empirical tuning and retuning to work.
>
> Some really good books on this subject. Like "American Ground",
describing
> the deconstructing of the World Trade Center disaster, where
everything
> emerged through daily meetings directed by two people with no
authority and
> no detailed plan. Like "The Emergence of Everything", where Harold
Morowitz
> points out that - despite popular perceptions - deterministic
science has
> only proven useful when roughly applied. For instance, Newton's
laws are
> used to describe and predict interplanetary movement. Yet they are
> applicable for only two bodies. The complexity of what really is
occcurring
> invalidates these laws when they try to predict the
interoperability of
> three or more bodies. The idea of observing something and reducing
it to a
> set of laws, principles, and practices has been wildly successful
in gaining
> coarse control over our environment. However, using these same laws
to
> predict how finely grained objects interact as they built up have
been
> horribly unsuccessful. It turns out, as complexity science has
observed,
> that very minute variations in the initial conditions often lead to
wildly
> unpredictable perturbations when scaled into the large.
>
> I believe that software development is a wonderful subject - both
to do and
> to study. I belive that we need to understand it better to do it
better. I
> have moved Scrum forward because I find it to be a sustainable,
scalable
> framework for software development. But I do not understand how it
works. I
> don't understand emergence, I just understand the beauty of it and
how it
> unleashes creativity. I don't know how models translate from the
mind to the
> software, and I don't know how we make up for the fuzzy boundaries
and
> undefined or weakly defined aspects of models. But I know with
inspection,
> adaptation, and dilligence, that we can built software.
>
> In "Corps Business", the approach the US Marines take to complexity
is
> discussed. They belive that the world has gotten so complicated and
dense
> that the marines will find every possible battlefield complexity
within a
> three block area - far too complex and dense for top down direction
from
> generals to privates. To address this, the marines train
extensively in
> every possible technique of warfare, in every conceivable
circumstance.
> Before a mission, they meet and discuss the mission - it's
objectives, the
> desired outcome, the risks, the potential variations and
complexities. Then
> they put the troops into the battlefield and count on them to use
their
> training, their common sense, and their knowledge of the situation
to do the
> best they can possible do. The marine corps trains leaders, not
scientists.
>
> Thanks for your attention,
> Ken


To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

On Wednesday, January 29, 2003, at 11:09:54 AM, Ken Schwaber wrote:

> Now, I finally have the reason to get a Harley-Davidson V-Rod!! Just
> investigating the results of an agile process, not indulging myself.

Almost certainly even tax-deductible!

Ron Jeffries
www.XProgramming.com
Accroche toi a ton reve.  --ELO

This article at CNet prompted a thoughts/questions..

"Blogs open doors for developers"
http://news.com.com/2100-1001-982854.html?tag=fd_lede1_hed

Thoughts..

1. Using a weblog/rss feed for daily reporting?

2. Communicating status to customers via a weblog?

Best Regards,

Dean Goodmanson


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Dean Goodmanson wrote:

  > This article at CNet prompted a thoughts/questions..
  >
  > "Blogs open doors for developers"
  > http://news.com.com/2100-1001-982854.html?tag=fd_lede1_hed
  >
  > Thoughts..
  >
  > 1. Using a weblog/rss feed for daily reporting?
  >
  > 2. Communicating status to customers via a weblog?

I like what the article says about opening up the flow of
information about the project, and removing secrecy.  I
think this is a vital part of what makes agile processes
successful.

The article talks about using a weblog to form a community
between the development organization and the users/customers
/partners, which is interesting.  It may be a tool to help a
single "customer" (e.g., product manager) that has to act as
a proxy for a larger group of actual customers/end users.

But I don't think it applies well to the immediate
development team.  They shouldn't be isolated enough from
each other to make the use of a weblog something they would
choose to do.

I prefer the daily scrum/stand up meeting for communicating
status amongst the immediate team members, which includes
all the developers, the "customers" (product manager, QA,
IA/UI folks), and the project manager(s).  At this level of
immediacy and detail, the higher bandwidth and dynamics of
face-to-face communication facilitates the work much better.

This assumes the immediate team is collocated, and that a
permanent record of the daily status is not an issue
(although it could be captured by a scribe if need be).
Distributed "immediate" teams are a whole different issue.

For communicating to more distant team members, perhaps a
weblog might work.  I've never tried it, but instead we use
just a normal doc, distributed at the end of each weekly
iteration.  Frankly, daily status for non-immediate team
members is overkill and probably a warning sign of micro-
management at too high a level.

Regards,
Paul
-----
Paul Hodgetts -- President, Principal Consultant
Agile Logic  -- www.agilelogic.com
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Java, J2EE, C++, OOA/D -- Agile Methods/XP/Scrum, Use Cases, UI/IA

On Friday, January 31, 2003, at 3:38:07 PM, Paul Hodgetts wrote:

> But I don't think it applies well to the immediate
> development team.  They shouldn't be isolated enough from
> each other to make the use of a weblog something they would
> choose to do.

Yes. Plus, the weblog, or a wiki, does not implement communication. It
implements /publication/ which is emphatically not the same thing.

> I prefer the daily scrum/stand up meeting for communicating
> status amongst the immediate team members, which includes
> all the developers, the "customers" (product manager, QA,
> IA/UI folks), and the project manager(s).  At this level of
> immediacy and detail, the higher bandwidth and dynamics of
> face-to-face communication facilitates the work much better.

Yes. Strongly agree.

Ron Jeffries
www.XProgramming.com
To be on the wire is life. The rest is waiting.  --Karl Wallenda

Although publication often results in no communication, I can atest
that my company and many of our clients get a lot of communication
done via wikis and bulletin boards.  In fact, often _better_
communication than verbally.
Alan Shalloway


--- In scrumdevelopment@yahoogroups.com, Ron Jeffries
<ronjeffries@a...> wrote:
> On Friday, January 31, 2003, at 3:38:07 PM, Paul Hodgetts wrote:
>
> > But I don't think it applies well to the immediate
> > development team.  They shouldn't be isolated enough from
> > each other to make the use of a weblog something they would
> > choose to do.
>
> Yes. Plus, the weblog, or a wiki, does not implement
communication. It
> implements /publication/ which is emphatically not the same thing.
>
> > I prefer the daily scrum/stand up meeting for communicating
> > status amongst the immediate team members, which includes
> > all the developers, the "customers" (product manager, QA,
> > IA/UI folks), and the project manager(s).  At this level of
> > immediacy and detail, the higher bandwidth and dynamics of
> > face-to-face communication facilitates the work much better.
>
> Yes. Strongly agree.
>
> Ron Jeffries
> www.XProgramming.com
> To be on the wire is life. The rest is waiting.  --Karl Wallenda

On Friday, January 31, 2003, at 5:01:10 PM, Alan Shalloway
<alshall@...> wrote:

> Although publication often results in no communication, I can atest
> that my company and many of our clients get a lot of communication
> done via wikis and bulletin boards.  In fact, often _better_
> communication than verbally.

How do you ensure that everyone who needs the word gets the word?

Ron Jeffries
www.XProgramming.com
Only the hand that erases can write the true thing.  -- Meister Eckhart

Trust and e-mails.
Everyone in my company, for example, is supposed to check the recent
changes topic and look.  Otherwise, we post an entry to the wiki and
just tell people - hey read this!

The advantage is two of us can have a conversation when a third person
isn't there and then they can catch up by reading the entries.  For many
things, however a bulletin board with a threaded discussion is better.
We use both, depending upon the type of material to be discussed.

We have one client who uses a wiki to discuss QA issues - relates
acceptance tests back to the use-cases.  We have another client who uses
a bulletin board (we like the UBB from info pop - cheap and easy) to
coordinate his customers (they've got lot's of users so the lead - who
plays the role of customer as he used to be one - coordinates with
dozens of customers to get a single voice).

Alan Shalloway, Sr. Consultant, CEO
office: 425-313-3065. mobile: 425-531-0810

Net Objectives' vision is effective software development without
suffering. Our mission is to assist software development teams in
accomplishing this through a combination of training and mentoring.


-----Original Message-----
From: Ron Jeffries [mailto:ronjeffries@...]
Sent: Friday, January 31, 2003 2:15 PM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Re: daily status blogs

On Friday, January 31, 2003, at 5:01:10 PM, Alan Shalloway
<alshall@...> wrote:

> Although publication often results in no communication, I can atest
> that my company and many of our clients get a lot of communication
> done via wikis and bulletin boards.  In fact, often _better_
> communication than verbally.

How do you ensure that everyone who needs the word gets the word?

Ron Jeffries
www.XProgramming.com
Only the hand that erases can write the true thing.  -- Meister Eckhart


To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

On Friday, January 31, 2003, at 5:21:50 PM, Alan Shalloway wrote:

> Trust and e-mails.

Trust is good. So is email.

> Everyone in my company, for example, is supposed to check the recent
> changes topic and look.  Otherwise, we post an entry to the wiki and
> just tell people - hey read this!

> The advantage is two of us can have a conversation when a third person
> isn't there and then they can catch up by reading the entries.  For many
> things, however a bulletin board with a threaded discussion is better.
> We use both, depending upon the type of material to be discussed.

Of course, I see the advantage. Do you see the disadvantage?

> We have one client who uses a wiki to discuss QA issues - relates
> acceptance tests back to the use-cases.  We have another client who uses
> a bulletin board (we like the UBB from info pop - cheap and easy) to
> coordinate his customers (they've got lot's of users so the lead - who
> plays the role of customer as he used to be one - coordinates with
> dozens of customers to get a single voice).

Yes, lots of people use them. They're good. They have that one key
disadvantage, however.

Ron Jeffries
www.XProgramming.com
Accroche toi a ton reve.  --ELO

Yeah, there are disadvantages.  Verbal communication on some things is
just more energizing and clearer.  I don't mean to imply that written
communication is superior to verbal, just sometimes (and at least not
always inferior).

The thing that is often overlooked in verbal communication (and
definitely in pairing in design/coding) is that there is synergy between
two people talking to each other.  It can't be explained, but it can be
experienced.  However, if it's opinions on things you want, or tracking
facts, written works well.

Alan Shalloway, Sr. Consultant, CEO
office: 425-313-3065. mobile: 425-531-0810

Net Objectives' vision is effective software development without
suffering. Our mission is to assist software development teams in
accomplishing this through a combination of training and mentoring.


-----Original Message-----
From: Ron Jeffries [mailto:ronjeffries@...]
Sent: Friday, January 31, 2003 2:32 PM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Re: daily status blogs

On Friday, January 31, 2003, at 5:21:50 PM, Alan Shalloway wrote:

> Trust and e-mails.

Trust is good. So is email.

> Everyone in my company, for example, is supposed to check the recent
> changes topic and look.  Otherwise, we post an entry to the wiki and
> just tell people - hey read this!

> The advantage is two of us can have a conversation when a third person
> isn't there and then they can catch up by reading the entries.  For
many
> things, however a bulletin board with a threaded discussion is better.
> We use both, depending upon the type of material to be discussed.

Of course, I see the advantage. Do you see the disadvantage?

> We have one client who uses a wiki to discuss QA issues - relates
> acceptance tests back to the use-cases.  We have another client who
uses
> a bulletin board (we like the UBB from info pop - cheap and easy) to
> coordinate his customers (they've got lot's of users so the lead - who
> plays the role of customer as he used to be one - coordinates with
> dozens of customers to get a single voice).

Yes, lots of people use them. They're good. They have that one key
disadvantage, however.

Ron Jeffries
www.XProgramming.com
Accroche toi a ton reve.  --ELO


To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/