<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.9.2" -->
<rss version="0.92">
<channel>
	<title>Agile Insider</title>
	<link>http://www.agileinsider.org</link>
	<description>reality bytes...</description>
	<lastBuildDate>Fri, 23 Jul 2010 07:58:01 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />

	<item>
		<title>Thank you Rhod Gilbert</title>
		<description><![CDATA[I have to let out a massive thanks to Rhod Gilbert.  I was watching his video "Rhod Gilbert and the Award Winning Mince Pie" and he provided me with a phrase that eloquently describes what happens when you continue to build upon technical debt (deliberately or not) or to defend a flawed design or architecture [...]]]></description>
		<link>http://www.agileinsider.org/2010/07/thank-you-rhod-gilbert/</link>
			</item>
	<item>
		<title>The Agile Jigsaw Puzzle</title>
		<description><![CDATA[A colleague at emergn asked if I had any suitable pictures for some course brochures and I didn't.  However, for a bit of fun (and to play with some new technologies) I had a blast at creating some imagery.  My first draft is my take on the agile jigsaw puzzle.  Rather than use the mona [...]]]></description>
		<link>http://www.agileinsider.org/2010/05/the-agile-jigsaw-puzzle/</link>
			</item>
	<item>
		<title>Enterprise Agile &#8211; Evolutionary Standards</title>
		<description><![CDATA[At the risk of being lambasted by the agile community I will use the words enterprise and agile in the same sentence  
This article largely follows on from some previous entries and in particular my entry on user centred test driven development.
It is often a complaint that large organisations trundle along painfully and slowly.  [...]]]></description>
		<link>http://www.agileinsider.org/2010/04/enterprise-agile-evolutionary-standards/</link>
			</item>
	<item>
		<title>Keeping It Simple &#8211; Regression vs Acceptance Testing</title>
		<description><![CDATA[Another emergn coach asked me the other day how I distinguished between an acceptance test and regression tests.  For me there is a very simple rule...

If I write the test before I write any code, it's an acceptance test.
If I write the test after I've written the code, it's a regression test.
If I write code [...]]]></description>
		<link>http://www.agileinsider.org/2010/04/keeping-it-simple-regression-vs-acceptance-testing/</link>
			</item>
	<item>
		<title>Top Tips &#8211; User Centred Automated Acceptance Tests</title>
		<description><![CDATA[Following on from my previous article, I thought I would share some top tips for creating automated acceptance tests for projects using user centred design.  There is nothing inherent in user centred design which prevents an agile approach being adopted and indeed agile adds huge value to user centred design by reducing the feedback loops [...]]]></description>
		<link>http://www.agileinsider.org/2010/04/top-tips-user-centred-automated-acceptance-tests/</link>
			</item>
	<item>
		<title>&#8220;Natural Language&#8221; Automated Acceptance Testing</title>
		<description><![CDATA[I read with extreme interest James Shore's blog about FIT but was dismayed that he devalues automated acceptance testing.  To claim that FIT is a "natural language" is wrong, it is a developer language and this is possibly why customers don't get involved.  Concordion on the other hand is natural language and I think plays [...]]]></description>
		<link>http://www.agileinsider.org/2010/04/natural-language-automated-acceptance-testing/</link>
			</item>
	<item>
		<title>Limitations of &#8220;Grow Your Own&#8221; Agile</title>
		<description><![CDATA[Over the course of my career I have worked at several organisations and have always tried to improve the internal processes using agile techniques and principles. Despite being a valued employee (I hope) at each of the companies I have worked at, the amount of success I achieved in agile adoption always reached some internal [...]]]></description>
		<link>http://www.agileinsider.org/2010/03/limitations-of-grow-your-own-agile/</link>
			</item>
	<item>
		<title>Functional Debt</title>
		<description><![CDATA[Thanks to Ward Cunningham, we now have a wonderful metaphor "Technical Debt" which explains the common problem of skipping a little bit of design or missing out that little bit of refactoring to meet a deadline.  Whenever we cut corners there is a very good chance we are taking on more and more Technical Debt.
But [...]]]></description>
		<link>http://www.agileinsider.org/2009/09/functional-debt/</link>
			</item>
	<item>
		<title>Vision &gt;= Solution &gt;= Problem</title>
		<description><![CDATA[I'll admit it, I'm not 100% agile since I tend to like solutions.  I would prefer a problem to solve, but if a problem is intangible I often find a solution is a great way to explore the potential and help express the underlying problem.
It is worth noting that innovation and invention are solutions [...]]]></description>
		<link>http://www.agileinsider.org/2009/08/vision-solution-problem/</link>
			</item>
	<item>
		<title>Ten Commandments of Agile</title>
		<description><![CDATA[I've posted a few entries now about my unease with the fuzziness surrounding Agile and how I feel it needs some clarity so I thought I'd have a quick stab at it.
The following commandments would be my first stab at such a list which would apply to any person who is part of or interacts [...]]]></description>
		<link>http://www.agileinsider.org/2009/07/ten-commandments-of-agile/</link>
			</item>
</channel>
</rss>
