<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: 2004 essay: Lean Team Software Process</title>
	<atom:link href="http://leansoftwareengineering.com/2009/05/20/2004-essay-lean-team-software-process/feed/" rel="self" type="application/rss+xml" />
	<link>http://leansoftwareengineering.com/2009/05/20/2004-essay-lean-team-software-process/</link>
	<description>Essays on the Continuous Delivery of High Quality Information Systems</description>
	<lastBuildDate>Mon, 22 Feb 2010 09:08:24 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Curious Cat Management Improvement Blog &#187; Management Improvement Carnival #65</title>
		<link>http://leansoftwareengineering.com/2009/05/20/2004-essay-lean-team-software-process/comment-page-1/#comment-5428</link>
		<dc:creator>Curious Cat Management Improvement Blog &#187; Management Improvement Carnival #65</dc:creator>
		<pubDate>Mon, 01 Jun 2009 14:45:05 +0000</pubDate>
		<guid isPermaLink="false">http://leansoftwareengineering.com/?p=1366#comment-5428</guid>
		<description>[...] Lean Team Software Process by Corey Ladas - &#8220;The customer’s terms likely do not include any notion of defects-per-KLOC. The producer’s end is profit and reputation, which comes from managing cost and consistency. If TSP, or something related to it, helps us realize our ends, then (and only then) it is meaningful.&#8221; [...]</description>
		<content:encoded><![CDATA[<p>[...] Lean Team Software Process by Corey Ladas &#8211; &#8220;The customer’s terms likely do not include any notion of defects-per-KLOC. The producer’s end is profit and reputation, which comes from managing cost and consistency. If TSP, or something related to it, helps us realize our ends, then (and only then) it is meaningful.&#8221; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lean nello sviluppo di software &#124; Encob Blog</title>
		<link>http://leansoftwareengineering.com/2009/05/20/2004-essay-lean-team-software-process/comment-page-1/#comment-5349</link>
		<dc:creator>Lean nello sviluppo di software &#124; Encob Blog</dc:creator>
		<pubDate>Thu, 21 May 2009 06:59:06 +0000</pubDate>
		<guid isPermaLink="false">http://leansoftwareengineering.com/?p=1366#comment-5349</guid>
		<description>[...] trovato questi due articoli che parlano dello sviluppo software in maniera lean: uno è di Corey Ladas, ex sviluppatore Microsoft, l&#8217;altro è un articolo di Eric Ries (autore del blog Lessons [...]</description>
		<content:encoded><![CDATA[<p>[...] trovato questi due articoli che parlano dello sviluppo software in maniera lean: uno è di Corey Ladas, ex sviluppatore Microsoft, l&#8217;altro è un articolo di Eric Ries (autore del blog Lessons [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Corey Ladas</title>
		<link>http://leansoftwareengineering.com/2009/05/20/2004-essay-lean-team-software-process/comment-page-1/#comment-5347</link>
		<dc:creator>Corey Ladas</dc:creator>
		<pubDate>Thu, 21 May 2009 03:02:23 +0000</pubDate>
		<guid isPermaLink="false">http://leansoftwareengineering.com/?p=1366#comment-5347</guid>
		<description>What&#039;s interesting to me about this is how many ideas are already baked into such a short essay:

* one-piece flow
* customer pull
* value-denominated work items
* gemba / genchi genbutsu (go and see for yourself)
* rolling wave planning
* service-level agreements
* inventory limits
* value stream maps
* workflow management
* integrated security and reliability engineering
* continuous integration
* continuous deployment

...and that is on top of a process definition that is already based on Statistical Process Control, standard work, and continuous improvement.

I started this essay in Spring 04, around the time of the first &quot;Scrumban&quot; process definition.  This draft is from Autumn 04, according to the timestamped revision control logs.</description>
		<content:encoded><![CDATA[<p>What&#8217;s interesting to me about this is how many ideas are already baked into such a short essay:</p>
<p>* one-piece flow<br />
* customer pull<br />
* value-denominated work items<br />
* gemba / genchi genbutsu (go and see for yourself)<br />
* rolling wave planning<br />
* service-level agreements<br />
* inventory limits<br />
* value stream maps<br />
* workflow management<br />
* integrated security and reliability engineering<br />
* continuous integration<br />
* continuous deployment</p>
<p>&#8230;and that is on top of a process definition that is already based on Statistical Process Control, standard work, and continuous improvement.</p>
<p>I started this essay in Spring 04, around the time of the first &#8220;Scrumban&#8221; process definition.  This draft is from Autumn 04, according to the timestamped revision control logs.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.625 seconds -->
