<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.2" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: An Agile Roadmap: The First Iteration</title>
	<link>http://www.mythic-cartography.org/2009/03/21/an-agile-roadmap-the-first-iteration/</link>
	<description>Revitalizing Riddles, Mythic Story, Family, Village and Land.</description>
	<pubDate>Fri, 10 Feb 2012 11:13:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.2</generator>
		<item>
		<title>By: Willem</title>
		<link>http://www.mythic-cartography.org/2009/03/21/an-agile-roadmap-the-first-iteration/#comment-24694</link>
		<dc:creator>Willem</dc:creator>
		<pubDate>Mon, 20 Apr 2009 23:57:13 +0000</pubDate>
		<guid>http://www.mythic-cartography.org/2009/03/21/an-agile-roadmap-the-first-iteration/#comment-24694</guid>
		<description>I agree; I hope that somehow we can interview someone who has performed on a superior level team, to discover "what that looked like".

But even "advanced" or "intermediate" would tell us a lot; if you can mine your own experiences of:

1. how the effectiveness of your team meetings changed over time, and what benchmarks you observed (who ran the meetings? how often? did that person change? how many people could do it, and when? how long did they last? what results did you achieve? how did that change over time?)
2. similarly, team planning, improving team processes (feedback, metrics, etc.), consistency and quality of software delivery - benchmarks, how did they change over time, emergent properties?

If novices say words, intermediates speak sentences, advanced speak paragraphs, and superiors speak exposition, how does this look on an agile team?

I think out there, we have enough experiences that we can sift this all out. It just takes mining that experience, don't you think?</description>
		<content:encoded><![CDATA[<p>I agree; I hope that somehow we can interview someone who has performed on a superior level team, to discover &#8220;what that looked like&#8221;.</p>
<p>But even &#8220;advanced&#8221; or &#8220;intermediate&#8221; would tell us a lot; if you can mine your own experiences of:</p>
<p>1. how the effectiveness of your team meetings changed over time, and what benchmarks you observed (who ran the meetings? how often? did that person change? how many people could do it, and when? how long did they last? what results did you achieve? how did that change over time?)<br />
2. similarly, team planning, improving team processes (feedback, metrics, etc.), consistency and quality of software delivery - benchmarks, how did they change over time, emergent properties?</p>
<p>If novices say words, intermediates speak sentences, advanced speak paragraphs, and superiors speak exposition, how does this look on an agile team?</p>
<p>I think out there, we have enough experiences that we can sift this all out. It just takes mining that experience, don&#8217;t you think?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jay Bazuzi</title>
		<link>http://www.mythic-cartography.org/2009/03/21/an-agile-roadmap-the-first-iteration/#comment-24693</link>
		<dc:creator>Jay Bazuzi</dc:creator>
		<pubDate>Mon, 20 Apr 2009 06:42:46 +0000</pubDate>
		<guid>http://www.mythic-cartography.org/2009/03/21/an-agile-roadmap-the-first-iteration/#comment-24693</guid>
		<description>I think that defining the higher levels of Agile fluency will be particularly difficult, because so few teams ever reach it. In my experience, most software teams barely function at all. 

I was lucky enough to be part of a team of novices that functioned extremely well, far outperforming established teams of experienced programmers. My sense is that we reached "Advanced" competency, but without definitions that claim doesn't mean much. One thing we did right was that we were learning and teaching each other and ourselves all the time.</description>
		<content:encoded><![CDATA[<p>I think that defining the higher levels of Agile fluency will be particularly difficult, because so few teams ever reach it. In my experience, most software teams barely function at all. </p>
<p>I was lucky enough to be part of a team of novices that functioned extremely well, far outperforming established teams of experienced programmers. My sense is that we reached &#8220;Advanced&#8221; competency, but without definitions that claim doesn&#8217;t mean much. One thing we did right was that we were learning and teaching each other and ourselves all the time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Willem</title>
		<link>http://www.mythic-cartography.org/2009/03/21/an-agile-roadmap-the-first-iteration/#comment-24636</link>
		<dc:creator>Willem</dc:creator>
		<pubDate>Sat, 21 Mar 2009 23:59:47 +0000</pubDate>
		<guid>http://www.mythic-cartography.org/2009/03/21/an-agile-roadmap-the-first-iteration/#comment-24636</guid>
		<description>A Post-script:

I think the amount of hero stories we have about the iconic behavior of high-performing teams, can hamper our ability to bring a team there. Yes, we know we want short, effective high-energy meetings that address concrete issues; yes, we know we want to see continuous improvement in the work process of the team; yes, we know we want to see effective and flexible work plans created from within the team; yes, we know we want consistent shippable software. But all this can't possibly happen, full-bore, at once!

We have to pick one level of proficiency, at a time, with concrete measures to check our progress. At Novice level, what does a highly competent, fluent Novice team do in a meeting? What does it look like?

How does that same meeting look at Intermediate level? Advanced? Superior/high-performing? This marks where I see the opportunity for real growth in Agile coaching and adoption. If we have a concrete roadmap with specific milestones, it turns the team into a fully informed crew of collaboraters, operating at their current fluency. They have the big-picture for when they need it, and they have the next tiny piece of skill work to do too, constantly interweaving the pieces into the greater puzzle. They know what to ask for, and what to expect.</description>
		<content:encoded><![CDATA[<p>A Post-script:</p>
<p>I think the amount of hero stories we have about the iconic behavior of high-performing teams, can hamper our ability to bring a team there. Yes, we know we want short, effective high-energy meetings that address concrete issues; yes, we know we want to see continuous improvement in the work process of the team; yes, we know we want to see effective and flexible work plans created from within the team; yes, we know we want consistent shippable software. But all this can&#8217;t possibly happen, full-bore, at once!</p>
<p>We have to pick one level of proficiency, at a time, with concrete measures to check our progress. At Novice level, what does a highly competent, fluent Novice team do in a meeting? What does it look like?</p>
<p>How does that same meeting look at Intermediate level? Advanced? Superior/high-performing? This marks where I see the opportunity for real growth in Agile coaching and adoption. If we have a concrete roadmap with specific milestones, it turns the team into a fully informed crew of collaboraters, operating at their current fluency. They have the big-picture for when they need it, and they have the next tiny piece of skill work to do too, constantly interweaving the pieces into the greater puzzle. They know what to ask for, and what to expect.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

