<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Can we elevate constraints in the requirements process to encourage creativity?</title>
	<atom:link href="http://www.bridging-the-gap.com/the-power-of-constraints-to-encourage-creativity/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bridging-the-gap.com/the-power-of-constraints-to-encourage-creativity/</link>
	<description>Advance Your Business Analysis Career</description>
	<lastBuildDate>Thu, 09 Feb 2012 00:08:14 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Nathan Caswell</title>
		<link>http://www.bridging-the-gap.com/the-power-of-constraints-to-encourage-creativity/comment-page-1/#comment-1089</link>
		<dc:creator>Nathan Caswell</dc:creator>
		<pubDate>Thu, 11 Jun 2009 03:02:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=953#comment-1089</guid>
		<description>btw ... I would point out that requirements make very poor boundary objects.</description>
		<content:encoded><![CDATA[<p>btw &#8230; I would point out that requirements make very poor boundary objects.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nathan Caswell</title>
		<link>http://www.bridging-the-gap.com/the-power-of-constraints-to-encourage-creativity/comment-page-1/#comment-1088</link>
		<dc:creator>Nathan Caswell</dc:creator>
		<pubDate>Thu, 11 Jun 2009 03:00:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=953#comment-1088</guid>
		<description>a few related works that might be interesting:
Design Rules, Vol. 1: The Power of Modularity, Carliss Y. Baldwin &amp; Kim B. Clark, MIT Press 2000

and 

Star SL &amp; Griesemer JR (1989). &quot;Institutional Ecology, &#039;Translations&#039; and Boundary Objects: Amateurs and Professionals in Berkeley&#039;s Museum of Vertebrate Zoology, 1907-39&quot;. Social Studies of Science 19 (4): 387–420

The first develops the theory of design rules (very similar to the Toyota constraints) that put a dependency matrix into block diagonal form (or nearly so). What this means is that each &quot;block&quot; represents a module that can be developed independently as long as the overlap with other modules (in it language the sub system interface :) is respected. It turns out that many broad dependencies can be factored and fixed to create modular systems out of apparent chaos. More recent work has focused on software systems, particularly the difference between open source and proprietary development approaches.

The second is all about the notion of &quot;boundary objects&quot;. A boundary object is tangible that is shared between two domains but which has different semantics in those domains. The situation described in the paper is about the communication between hunters and trappers and academic museum naturalists and biologists. The boundary object is the pelt and the condition of the pelt. For auto designers, the car and its various models (both physical and computer generated) are the boundary object. Designers (in this case visual style design) and think about systems of shape and color while the manufacturing designers think about rigidity, draw depth, and waste material. This, implicit, concept is crucial to the operation of the &quot;big room&quot;. In theory, a structured facilitation like JAD depends on focus around boundary objects, but representations are ID derived (disadvantaging one side) and have a misplaced focus on working as a team, rather than as an inter-domain discussion where each domain needs to go off and discuss among them selves. For example, to we really want the subcutaneous fat scraped off the skunk skin before we get it?

If you put these together with the &quot;don&#039;t make any decisions until you really have to&quot; rule, I think you get much of the design process.</description>
		<content:encoded><![CDATA[<p>a few related works that might be interesting:<br />
Design Rules, Vol. 1: The Power of Modularity, Carliss Y. Baldwin &amp; Kim B. Clark, MIT Press 2000</p>
<p>and </p>
<p>Star SL &amp; Griesemer JR (1989). &#8220;Institutional Ecology, &#8216;Translations&#8217; and Boundary Objects: Amateurs and Professionals in Berkeley&#8217;s Museum of Vertebrate Zoology, 1907-39&#8243;. Social Studies of Science 19 (4): 387–420</p>
<p>The first develops the theory of design rules (very similar to the Toyota constraints) that put a dependency matrix into block diagonal form (or nearly so). What this means is that each &#8220;block&#8221; represents a module that can be developed independently as long as the overlap with other modules (in it language the sub system interface <img src='http://www.bridging-the-gap.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  is respected. It turns out that many broad dependencies can be factored and fixed to create modular systems out of apparent chaos. More recent work has focused on software systems, particularly the difference between open source and proprietary development approaches.</p>
<p>The second is all about the notion of &#8220;boundary objects&#8221;. A boundary object is tangible that is shared between two domains but which has different semantics in those domains. The situation described in the paper is about the communication between hunters and trappers and academic museum naturalists and biologists. The boundary object is the pelt and the condition of the pelt. For auto designers, the car and its various models (both physical and computer generated) are the boundary object. Designers (in this case visual style design) and think about systems of shape and color while the manufacturing designers think about rigidity, draw depth, and waste material. This, implicit, concept is crucial to the operation of the &#8220;big room&#8221;. In theory, a structured facilitation like JAD depends on focus around boundary objects, but representations are ID derived (disadvantaging one side) and have a misplaced focus on working as a team, rather than as an inter-domain discussion where each domain needs to go off and discuss among them selves. For example, to we really want the subcutaneous fat scraped off the skunk skin before we get it?</p>
<p>If you put these together with the &#8220;don&#8217;t make any decisions until you really have to&#8221; rule, I think you get much of the design process.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nathan Caswell</title>
		<link>http://www.bridging-the-gap.com/the-power-of-constraints-to-encourage-creativity/comment-page-1/#comment-1087</link>
		<dc:creator>Nathan Caswell</dc:creator>
		<pubDate>Thu, 11 Jun 2009 01:56:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=953#comment-1087</guid>
		<description>-- It would make life so much easier, but GM has had a long time to look at Toyota and is still baffled. Indeed, most American manufacturers are running in the opposite direction, outsourcing manufacturing for cost reduction.

-- I think the &#039;constraints&#039;, are more like optimization constraints: less than, greater than or between conditions. 

Can you say some more about how it is applied to agile?</description>
		<content:encoded><![CDATA[<p>&#8211; It would make life so much easier, but GM has had a long time to look at Toyota and is still baffled. Indeed, most American manufacturers are running in the opposite direction, outsourcing manufacturing for cost reduction.</p>
<p>&#8211; I think the &#8216;constraints&#8217;, are more like optimization constraints: less than, greater than or between conditions. </p>
<p>Can you say some more about how it is applied to agile?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rod Claar</title>
		<link>http://www.bridging-the-gap.com/the-power-of-constraints-to-encourage-creativity/comment-page-1/#comment-1085</link>
		<dc:creator>Rod Claar</dc:creator>
		<pubDate>Wed, 10 Jun 2009 14:09:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=953#comment-1085</guid>
		<description>Nice article, Laura.  Another thing to realize is that the constraints of a requirement are continuously refined and narrowed until the &quot;feature&quot; (door panel, alternator, software system) is good enough and the cost of the next step exceeds the benefit.</description>
		<content:encoded><![CDATA[<p>Nice article, Laura.  Another thing to realize is that the constraints of a requirement are continuously refined and narrowed until the &#8220;feature&#8221; (door panel, alternator, software system) is good enough and the cost of the next step exceeds the benefit.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

