Re: [AM] Sharing information across the enterprise

"Scott E. Preece" <[email protected]>
Newsgroups gmane.comp.programming.modeling.agile
Message-ID <[email protected]>
We work some of these issues by having "community of practice" groups
that span the enterprise; these are formed as simple e-mail lists
(anybody can subscribe); some of them have active core groups that
organize meetings, manage archives of discussions and research, etc.

We also have an annual enterprise-wide software symposium, run like an
IEEE conference, with refereed papers, industry guest speakers, etc., as
well as a number of smaller, discipline-specific symposia run more like
workshops, with lighterweight papers and more time for discussion and
networking.

However, I think these are orthogonal to the notion of product lines.
I think Scott A's essay is closer to what's needed than Jason's note -
the product line team needs dedicated staff and needs to own the
interfaces to the common archtiecture, so that the project teams can
build conforming components and expect them to work across the product
line with only nominal adaptation required.

scott

| From: Scott Ambler<[email protected]>
| Date: Fri, 06 Feb 2004 22:00:07 -0500
| 
| 
| Sounds really close to what I talk about at 
| http://www.agiledata.org/essays/enterpriseArchitecture.html and 
| www.agilemodeling.com/essays/agileArchitecture.htm.
| 
| Other solutions, as Jason implied, include:
| 1. Getting together and talking with other people over drinks, or at a 
| softball game, ...
| 2. Your informal network of people.
| 3. The "less effective" forms of communication, such as email, documents, ...
| 
| - Scott
| 
| At 04:54 PM 2/6/2004 -0700, you wrote:
| >I have not worked on a product line since well before discovering agility, 
| >but ever since then I have been wanting to try out the following strategy 
| >when I get the right opportunity:
| >
| >1. You have project teams and one product line team.
| >2. The product line team consists of a pool of senior developers, each of 
| >whom:
| >- Is an active member of one of the projects teams (perhaps rotating among 
| >the project teams every month or 2).
| >- Meets for a few hours every week with the other members of the product 
| >line team to talk about global issues and solutions.
| >- Looks for components, patterns, practices, etc. in their project that 
| >should be shared with the other projects.
| >- Promotes the reuse in their project of the things that have been 
| >accumulated from the other projects.
| >3. If the shared components get large and complex enough, it could be 
| >worth considering having a separate project team or a subset of the 
| >product line team refactor them into an appropriate framework.
| >
| >Replace "product line" with "enterprise", if you like.
| >
| >Steven A. Gordon, Ph.D.
| >Manager, Software Factory
| >Arizona State University
| >PO Box 875506
| >Tempe, AZ 85287-9509
| >http://sf.asu.edu
| >(480)-727-6271
| >
| >
| >-----Original Message-----
| >From: J. B. Rainsberger [mailto:[email protected]]
| >Sent: 06 February 2004 23:19
| >To: [email protected]
| >Subject: [AM] Sharing information across the enterprise
| >
| >Stephen Cohen wrote:
| >
| > > I haven't spent a lot of time pair programming ...
| > > How do you share approaches or warn of identified issues, across
| > > projects? How is the knowledge circulated though out an enterprise?
| >
| >Either by formal presentations or by rotating individuals across teams.
| >
| > > I am accustomed to working on large programs with many concurrent
| > > projects.  While high-communication methods work very well within a
| > > project I have found it difficult to maintain across an entire program.
| >
| >I'm not convinced that communication across projects is so important:
| >each project has its own local conditions, including the specific people
| >involved, the tools, the schedule... so much so that I doubt there is much
| >of practical use that straddles multiple teams.
| >--
| >J. B. Rainsberger,
| >Diaspar Software Services
| >http://www.diasparsoftware.com :: +1 416 791-8603 Let's write software that
| >people understand
| >
| >For more information about AM, visit the Agile Modeling Home Page at
| >www.agilemodeling.com
| >
| >For more information about AM, visit the Agile Modeling Home Page at 
| >www.agilemodeling.com
| >
| >For more information about AM, visit the Agile Modeling Home Page at 
| >www.agilemodeling.com
| 
| ====================================================
| Scott W. Ambler
| Senior Consultant, Ronin International, Inc.
| www.ronin-intl.com/company/scottAmbler.html
| 
| www.agiledata.org
| www.agilemodeling.com
| www.ambysoft.com
| www.enterpriseunifiedprocess.info
| www.modelingstyle.info
| www.ronin-intl.com
| 
| For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
| 
| 
| 
| 


-- 
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il  61820  
e-mail:	[email protected]	fax:	217-384-8550
phone:	217-384-8589	cell: 217-433-6114	pager: [email protected]

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.