<?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"
	>
<channel>
	<title>Comments on: 12 signs of a great workplace</title>
	<atom:link href="http://scientificink.com/blog/2006/08/01/12-signs-of-a-great-workplace/feed/" rel="self" type="application/rss+xml" />
	<link>http://scientificink.com/blog/2006/08/01/12-signs-of-a-great-workplace/</link>
	<description>not particularly objective musings on odds and ends - Dunrie Greiling, Ann Arbor, MI 48103</description>
	<pubDate>Fri, 21 Nov 2008 10:10:53 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: dunrie</title>
		<link>http://scientificink.com/blog/2006/08/01/12-signs-of-a-great-workplace/#comment-33</link>
		<dc:creator>dunrie</dc:creator>
		<pubDate>Mon, 28 Aug 2006 11:58:32 +0000</pubDate>
		<guid isPermaLink="false">http://scientificink.com/blog/?p=8#comment-33</guid>
		<description>Yeah, I think you're right: formal roles serve Q1 rather than Q3.

Basically they help define expectations concretely. That was one thing our former place was good at: storycards, really formalized roles and ritualized interactions. But, unless one is perfectly suited to someone else's definition (unlikely) those formal roles will interfere with Q3. I recall a senior developer saying he had to turn part of his brain off to come into work. Eventually, that just gets painful and annoying.

That role formality also served their business model. Essentially, because of the transient nature of the team, they needed to be able to train up and deploy new folks all the time. And, our favorite client from that old place did say that consulting shops in general experience a lot of pressure to produce consistent product, so &lt;em&gt;making cogs&lt;/em&gt; is something that their process/business demanded.

As Chris and I have discussed, that level of formality and ritual was great for training new folks, but they found it difficult to maintain and hold the senior folks...</description>
		<content:encoded><![CDATA[<p>Yeah, I think you&#8217;re right: formal roles serve Q1 rather than Q3.</p>
<p>Basically they help define expectations concretely. That was one thing our former place was good at: storycards, really formalized roles and ritualized interactions. But, unless one is perfectly suited to someone else&#8217;s definition (unlikely) those formal roles will interfere with Q3. I recall a senior developer saying he had to turn part of his brain off to come into work. Eventually, that just gets painful and annoying.</p>
<p>That role formality also served their business model. Essentially, because of the transient nature of the team, they needed to be able to train up and deploy new folks all the time. And, our favorite client from that old place did say that consulting shops in general experience a lot of pressure to produce consistent product, so <em>making cogs</em> is something that their process/business demanded.</p>
<p>As Chris and I have discussed, that level of formality and ritual was great for training new folks, but they found it difficult to maintain and hold the senior folks&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Helene</title>
		<link>http://scientificink.com/blog/2006/08/01/12-signs-of-a-great-workplace/#comment-31</link>
		<dc:creator>Helene</dc:creator>
		<pubDate>Fri, 25 Aug 2006 18:33:24 +0000</pubDate>
		<guid isPermaLink="false">http://scientificink.com/blog/?p=8#comment-31</guid>
		<description>The upshot - I do agree with most of Dunrie's comments, and do feel that an Agile environment addresses most of the issues in helping to build a good workplace. I do not feel that the implementation at our last place of employment really played to the benefits of Agile. The short contracts and frequent 'on the bench' time actually worked to pit people against one another for the next opening. I think your term of people being 'hungry' is a good one to explain the feeling at that workplace. When you're hungry all the time, you're just working to meet your basic needs, and not being your best or doing your best. Looking back at my time there, I feel bad for *not* being able to be at my best there and for the negative impact I may have had on others. It was a stressful situation - but I don't believe is typical of Agile environments.</description>
		<content:encoded><![CDATA[<p>The upshot - I do agree with most of Dunrie&#8217;s comments, and do feel that an Agile environment addresses most of the issues in helping to build a good workplace. I do not feel that the implementation at our last place of employment really played to the benefits of Agile. The short contracts and frequent &#8216;on the bench&#8217; time actually worked to pit people against one another for the next opening. I think your term of people being &#8216;hungry&#8217; is a good one to explain the feeling at that workplace. When you&#8217;re hungry all the time, you&#8217;re just working to meet your basic needs, and not being your best or doing your best. Looking back at my time there, I feel bad for *not* being able to be at my best there and for the negative impact I may have had on others. It was a stressful situation - but I don&#8217;t believe is typical of Agile environments.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Helene</title>
		<link>http://scientificink.com/blog/2006/08/01/12-signs-of-a-great-workplace/#comment-30</link>
		<dc:creator>Helene</dc:creator>
		<pubDate>Fri, 25 Aug 2006 18:24:16 +0000</pubDate>
		<guid isPermaLink="false">http://scientificink.com/blog/?p=8#comment-30</guid>
		<description>Q4 - praised or recognized in last 7 days...while I agree with Dunrie that management influence and workplace culture plays a bigger role than simply Agile/XP practices could, one minor form of recognition occurs in the Show &#38; Tell. If based on a 1 week iteration, one shares what they have accomplished in the last week and can subsequently feel a sense of recognition for it, allowing others to share in recognizing the work completed. The XP practice of breaking tasks down into smaller pieces of work does indeed help to foster this.</description>
		<content:encoded><![CDATA[<p>Q4 - praised or recognized in last 7 days&#8230;while I agree with Dunrie that management influence and workplace culture plays a bigger role than simply Agile/XP practices could, one minor form of recognition occurs in the Show &amp; Tell. If based on a 1 week iteration, one shares what they have accomplished in the last week and can subsequently feel a sense of recognition for it, allowing others to share in recognizing the work completed. The XP practice of breaking tasks down into smaller pieces of work does indeed help to foster this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Helene</title>
		<link>http://scientificink.com/blog/2006/08/01/12-signs-of-a-great-workplace/#comment-29</link>
		<dc:creator>Helene</dc:creator>
		<pubDate>Fri, 25 Aug 2006 18:15:22 +0000</pubDate>
		<guid isPermaLink="false">http://scientificink.com/blog/?p=8#comment-29</guid>
		<description>Q3 - formal roles don't let people do what they do best. I do feel that more informal roles work better at letting people branch out. I'm seeing more creative and willing progress at the 'traditional/non-agile' place I'm at where the developers are asked to be more than just developers - and they do indeed rise to the occassion. Specifically, thinking in a broader sense of what is needed for the business, some early business analysis that takes them out of the 'of course I can code it' to 'should it be coded at all?'. All items that I think are more beneficial than straight-jacketing people into roles. So, this really begs the question that should one abandon the XP practice of defined roles? I think what I find that works the best is to let people expand a bit more than confine them, which enables those around them to also think of people outside of their specific role and see them for the value that they can bring to the situation. So for me, no, the XP formal defined roles do *not* enable people to do their best every day.</description>
		<content:encoded><![CDATA[<p>Q3 - formal roles don&#8217;t let people do what they do best. I do feel that more informal roles work better at letting people branch out. I&#8217;m seeing more creative and willing progress at the &#8216;traditional/non-agile&#8217; place I&#8217;m at where the developers are asked to be more than just developers - and they do indeed rise to the occassion. Specifically, thinking in a broader sense of what is needed for the business, some early business analysis that takes them out of the &#8216;of course I can code it&#8217; to &#8217;should it be coded at all?&#8217;. All items that I think are more beneficial than straight-jacketing people into roles. So, this really begs the question that should one abandon the XP practice of defined roles? I think what I find that works the best is to let people expand a bit more than confine them, which enables those around them to also think of people outside of their specific role and see them for the value that they can bring to the situation. So for me, no, the XP formal defined roles do *not* enable people to do their best every day.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
