RE: [AM] Sharing information across the enterprise

Unfortunately, in most enterprises, when you try to make the right things happen via rules and authority, you end up with a form of command and control that sharply reduces agility.

	-----Original Message----- 
	From: Stephen Cohen [mailto:[email protected]] 
	Sent: Sat 2/7/2004 8:39 AM 
	To: [email protected] 
	Cc: 
	Subject: RE: [AM] Sharing information across the enterprise
	
	

	I strongly agree with Scott's enterprise architecture essay
	[http://www.agiledata.org/essays/enterpriseArchitecture.html]. 
	
	I believe we are moving from the open plain of the wild, wild, west to
	an era where we are fencing in the code cowboys.  No longer free to
	roam, many will be in fight or flight mode. Our challenge is to create
	an environment where multiple software products can both co-exist and
	compete for a place in the business.  Allowing the software that most
	effectively aids the business in the performance of its mission to win
	out. 
	
	This however, requires an even playing field defined by rules/laws, and
	enforced by some authority. 
	
	-- Stephen
	
	-----Original Message-----
	From: Scott Ambler [mailto:[email protected]]
	Sent: Friday, February 06, 2004 10:00 PM
	To: [email protected]
	Subject: RE: [AM] Sharing information across the enterprise
	
	
	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
	
	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
--^----------------------------------------------------------------
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
--^----------------------------------------------------------------