<?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>James Grenning's Blog &#187; Agile Development</title>
	<atom:link href="http://www.renaissancesoftware.net/blog/archives/category/agile-development/feed" rel="self" type="application/rss+xml" />
	<link>http://www.renaissancesoftware.net/blog</link>
	<description>Blogging about Agile Development, especially embedded.  Follow me on twitter: jwgrenning</description>
	<lastBuildDate>Tue, 03 Aug 2010 19:26:01 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Boy Scout Rule Applied to Every Day Coding</title>
		<link>http://www.renaissancesoftware.net/blog/archives/90</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/90#comments</comments>
		<pubDate>Mon, 02 Aug 2010 17:58:20 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Refactoring C]]></category>
		<category><![CDATA[Test Driven Development]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=90</guid>
		<description><![CDATA[The Boy Scouts have a rule: leave the camp cleaner than you found it. This does not mean that all the trash has to be cleaned up now, but you can&#8217;t let it get worse, and it must get at least a little better. In Bob Martin&#8217;s book, Clean Code, he asks, &#8220;What if code [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/90/feed</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
		<item>
		<title>Agile Design and Embedded</title>
		<link>http://www.renaissancesoftware.net/blog/archives/81</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/81#comments</comments>
		<pubDate>Thu, 12 Nov 2009 12:31:03 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Agile Embedded]]></category>
		<category><![CDATA[Embedded TDD]]></category>
		<category><![CDATA[Evolutionary Design]]></category>
		<category><![CDATA[Embedded]]></category>
		<category><![CDATA[Embedded Agile]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=81</guid>
		<description><![CDATA[One important realization on the journey from a BDUF approach to an iterative and agile approach is that design is never done. Designs evolve. The waterfall emphasis has been to unnaturally try to control software physics by imposing requirements freezes and burdensome change control. The process of developing software is part science and part creative. [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/81/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Embedded Memory Constraints and TDD</title>
		<link>http://www.renaissancesoftware.net/blog/archives/72</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/72#comments</comments>
		<pubDate>Tue, 10 Nov 2009 23:33:19 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Agile Embedded]]></category>
		<category><![CDATA[Embedded TDD]]></category>
		<category><![CDATA[Unit Testing]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=72</guid>
		<description><![CDATA[Constrained Memory is the reality for many embedded developers. Running tests in the development system won&#8217;t suffer the same memory constraints found in the target. Here are a few things to help TDD in constrained memory situations. First of all, use dual targeting so the bulk of your code is tested off-target. See my paper [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/72/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Why Test Driven Development for Embedded?</title>
		<link>http://www.renaissancesoftware.net/blog/archives/55</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/55#comments</comments>
		<pubDate>Wed, 07 Oct 2009 17:02:47 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Agile Embedded]]></category>
		<category><![CDATA[Embedded TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Unit Testing]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=55</guid>
		<description><![CDATA[Embedded software has all the challenges of &#8220;regular&#8221; software, like poor quality and unreliable schedules. It is just software with some additional challenges. The additional challenges do not disqualify TDD for embedded. TDD even helps with some of those uniquely embedded challenges. Leaving embedded out of it for a moment, here are benefits that TDD [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/55/feed</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>What Should you Expect from a Unit Test Harness</title>
		<link>http://www.renaissancesoftware.net/blog/archives/50</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/50#comments</comments>
		<pubDate>Tue, 06 Oct 2009 19:43:13 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Agile Embedded]]></category>
		<category><![CDATA[Embedded TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Unit Testing]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[test-driven-development-tdd]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=50</guid>
		<description><![CDATA[A unit test harness’ job is to provide: A concise common language to express test cases A concise common language to express expected results A place to collect all the unit test cases for the project, system, or subsystem The facilities to run the test cases, either in full or partial batches A concise report [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/50/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Story Weight Reduction Toolkit</title>
		<link>http://www.renaissancesoftware.net/blog/archives/48</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/48#comments</comments>
		<pubDate>Sat, 01 Aug 2009 20:13:20 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Agile Embedded]]></category>
		<category><![CDATA[User Stories]]></category>
		<category><![CDATA[User Story]]></category>
		<category><![CDATA[estimation]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=48</guid>
		<description><![CDATA[Stories often start out too big. Big stories are a challenge, and it is not always obvious how to deal with them. Its important that stories be small enough to estimate, to fit easily into an iteration and to have a decent definition of done. This article explores why some stories don&#8217;t fit this mold [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/48/feed</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Extra! Extra! TDD Doubles LOC and No One Cares!</title>
		<link>http://www.renaissancesoftware.net/blog/archives/46</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/46#comments</comments>
		<pubDate>Wed, 15 Jul 2009 01:52:37 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Defect Prevention]]></category>
		<category><![CDATA[TDD]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=46</guid>
		<description><![CDATA[Test Driven Development more than doubles the lines of code you have to write. With all that extra code to write, where will we ever find the time?! We have deadlines! Lines of code has always been a bad metric; why bring them up now? Error-free robots, programming at a constant rate, might have to [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/46/feed</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
		<item>
		<title>Deep Agile Panel Questions &#8211; Documentation</title>
		<link>http://www.renaissancesoftware.net/blog/archives/44</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/44#comments</comments>
		<pubDate>Wed, 13 May 2009 18:21:55 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Documentation]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Agile Documentation]]></category>
		<category><![CDATA[Agile Embedded]]></category>
		<category><![CDATA[Deep Agile Embedded]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=44</guid>
		<description><![CDATA[This is the third in my Deep Agile Embedded Panel Questions series. The question is: We had a team doing agile. To them that included not doing any documentation. We need documentation once we go into maintenance. Is doing documentation allowed in Agile? The short answer is yes. Agile does allow documentation. Do you think [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/44/feed</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Deep Agile Panel Questions &#8211; Change</title>
		<link>http://www.renaissancesoftware.net/blog/archives/43</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/43#comments</comments>
		<pubDate>Wed, 06 May 2009 14:41:05 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Agile Embedded]]></category>
		<category><![CDATA[Embedded TDD]]></category>
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=43</guid>
		<description><![CDATA[Prior to the Deep Agile conference, I received a number of questions about getting people to change, to try new things. Change is hard. People need to be motivated to change. &#8220;If it ain’t broke, don’t fix it&#8221; they say. But there is always some things that are broken. First there needs to be awareness/acceptance [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/43/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Don&#8217;t Let Embedded Tool Chain Slow You Down.</title>
		<link>http://www.renaissancesoftware.net/blog/archives/41</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/41#comments</comments>
		<pubDate>Wed, 01 Apr 2009 22:55:15 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Embedded TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[Embedded]]></category>
		<category><![CDATA[Hardware]]></category>
		<category><![CDATA[TDD]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=41</guid>
		<description><![CDATA[During my TDD session at the Embedded Systems Conference yesterday, I did a demo. Before the demo, I make the case for TDD as a way to prevent bugs (see Physics of TDD). For the live demo I usually code on my mac and run the tests there as well. The question always comes up: [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/41/feed</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>
