<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Richard Lawrence &#187; change</title>
	<atom:link href="http://www.richardlawrence.info/tag/change/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.richardlawrence.info</link>
	<description>On making software teams happier and more productive</description>
	<lastBuildDate>Tue, 20 Jul 2010 21:38:50 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>The Power of Small Experiments</title>
		<link>http://www.richardlawrence.info/2008/08/18/the-power-of-small-experiments/</link>
		<comments>http://www.richardlawrence.info/2008/08/18/the-power-of-small-experiments/#comments</comments>
		<pubDate>Mon, 18 Aug 2008 21:30:01 +0000</pubDate>
		<dc:creator>Richard Lawrence</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[change]]></category>
		<category><![CDATA[Scrum]]></category>

		<guid isPermaLink="false">http://www.richardlawrence.info/?p=27</guid>
		<description><![CDATA[Change can be scary. Change at work is particularly threatening. After all, most of us spend more time working that doing any other single thing. Even a potentially good change, one that promises a better future, is risky. The better future might not pan out. It might be worse than the status quo. It&#8217;s that [...]


Related posts:<ol><li><a href='http://www.richardlawrence.info/2008/07/25/tech-work-is-messed-upand-we-can-fix-it/' rel='bookmark' title='Permanent Link: Tech work is messed up&#8230;and we can fix it'>Tech work is messed up&#8230;and we can fix it</a></li>
<li><a href='http://www.richardlawrence.info/2008/08/04/how-multitasking-guarantees-low-customer-satisfaction/' rel='bookmark' title='Permanent Link: How Multitasking Guarantees Low Customer Satisfaction'>How Multitasking Guarantees Low Customer Satisfaction</a></li>
</ol>]]></description>
			<content:encoded><![CDATA[<p></p><p>Change can be scary. Change at work is particularly threatening. After all, most of us spend more time working that doing any other single thing. Even a potentially good change, one that promises a better future, is risky. The better future might not pan out. It might be worse than the status quo. It&#8217;s that risk that makes talking someone into accepting a change so ineffective.</p>
<p>To gain acceptance of a proposed change, stop trying to persuade on the merits of the change. Very few changes have to be permanent, so you don&#8217;t need to convince people to accept the change forever. Instead, look at ways you can remove the risk, ways to make the change undo-able. Frame your change as an experiment that can be rolled back if it doesn&#8217;t work. Set a date to evaluate the results and make a decision whether to continue with the change or roll back. And then stick to that plan, even if the change is going overwhelmingly well. It&#8217;ll remind people that you&#8217;re trustworthy and that when you propose an experiment you really mean it—you&#8217;re not just being sneaky.</p>
<p>When you consider how long to make an experiment, remember that it can take 21 or more repetitions for a new practice to become a habit. Think about the learning curve associated with your change. Try to make the experiment longer than that initial learning, habit-building period.</p>
<p>Scrum&#8217;s sprints and retrospectives give you a nice built-in cycle for experiments. It&#8217;s easy to propose trying something for 1, 2, or 3 sprints, to be reevaluated in the corresponding retrospective. Want to adopt TDD or pair programming? Want to move QA people into your team? It doesn&#8217;t have to be permanent. Just try it for a few sprints. Maybe measure cycle time or defects while you do it. If it doesn&#8217;t work for, you can always go back to what you&#8217;re doing today. It&#8217;s just an experiment.</p>


<p>Related posts:<ol><li><a href='http://www.richardlawrence.info/2008/07/25/tech-work-is-messed-upand-we-can-fix-it/' rel='bookmark' title='Permanent Link: Tech work is messed up&#8230;and we can fix it'>Tech work is messed up&#8230;and we can fix it</a></li>
<li><a href='http://www.richardlawrence.info/2008/08/04/how-multitasking-guarantees-low-customer-satisfaction/' rel='bookmark' title='Permanent Link: How Multitasking Guarantees Low Customer Satisfaction'>How Multitasking Guarantees Low Customer Satisfaction</a></li>
</ol></p>]]></content:encoded>
			<wfw:commentRss>http://www.richardlawrence.info/2008/08/18/the-power-of-small-experiments/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
