<?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: Agile Tokyo 2010</title>
	<atom:link href="http://continuousdelivery.com/2010/07/agile-tokyo-2010/feed/" rel="self" type="application/rss+xml" />
	<link>http://continuousdelivery.com/2010/07/agile-tokyo-2010/</link>
	<description>Jez Humble&#039;s work blog</description>
	<lastBuildDate>Mon, 09 Jan 2012 16:13:08 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Ippoippo</title>
		<link>http://continuousdelivery.com/2010/07/agile-tokyo-2010/comment-page-1/#comment-1922</link>
		<dc:creator>Ippoippo</dc:creator>
		<pubDate>Tue, 20 Sep 2011 21:31:05 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=118#comment-1922</guid>
		<description>Having worked in Japan, those three points pretty much describe how IT gets delivered. Constantly underestimated, and the developers having to constantly over-work to get something out of the door at the agreed date.

It just doesn&#039;t work. That said, Agile will be difficult to implement there on big projects.</description>
		<content:encoded><![CDATA[<p>Having worked in Japan, those three points pretty much describe how IT gets delivered. Constantly underestimated, and the developers having to constantly over-work to get something out of the door at the agreed date.</p>
<p>It just doesn&#8217;t work. That said, Agile will be difficult to implement there on big projects.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Agile Tokyo 2010</title>
		<link>http://continuousdelivery.com/2010/07/agile-tokyo-2010/comment-page-1/#comment-1035</link>
		<dc:creator>Agile Tokyo 2010</dc:creator>
		<pubDate>Wed, 22 Dec 2010 12:20:12 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=118#comment-1035</guid>
		<description>[...] &#8211; both Agile Tokyo and Agile Japan are only two years old &#8211; and there was a real... [full post]    jez     Continuous Delivery   uncategorized            0        0        0        0        0     [...]</description>
		<content:encoded><![CDATA[<p>[...] &#8211; both Agile Tokyo and Agile Japan are only two years old &#8211; and there was a real&#8230; [full post]    jez     Continuous Delivery   uncategorized            0        0        0        0        0     [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jez</title>
		<link>http://continuousdelivery.com/2010/07/agile-tokyo-2010/comment-page-1/#comment-184</link>
		<dc:creator>jez</dc:creator>
		<pubDate>Mon, 16 Aug 2010 07:59:01 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=118#comment-184</guid>
		<description>&lt;strong&gt;Update:&lt;/strong&gt; this article made it to &lt;a href=&quot;http://slashdot.jp/developers/article.pl?sid=10/08/11/081219&quot; rel=&quot;nofollow&quot;&gt;Slashdot Japan&lt;/a&gt;

Google Translate for Japanese is pretty crap, but &lt;a href=&quot;http://slashdot.jp/developers/comments.pl?sid=504292&amp;cid=1808407&quot; rel=&quot;nofollow&quot;&gt;this comment&lt;/a&gt; caught my eye:

Waterfall - Japanese-style choices
1, make desperate efforts
2, work hard for Dear Life
3, (in short) and adding staff, work hard until they die</description>
		<content:encoded><![CDATA[<p><strong>Update:</strong> this article made it to <a href="http://slashdot.jp/developers/article.pl?sid=10/08/11/081219" rel="nofollow">Slashdot Japan</a></p>
<p>Google Translate for Japanese is pretty crap, but <a href="http://slashdot.jp/developers/comments.pl?sid=504292&#038;cid=1808407" rel="nofollow">this comment</a> caught my eye:</p>
<p>Waterfall &#8211; Japanese-style choices<br />
1, make desperate efforts<br />
2, work hard for Dear Life<br />
3, (in short) and adding staff, work hard until they die</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: 「ウォーターフォール開発」、本当に日本でうまく行っているのか？ &#124; eamcet*</title>
		<link>http://continuousdelivery.com/2010/07/agile-tokyo-2010/comment-page-1/#comment-147</link>
		<dc:creator>「ウォーターフォール開発」、本当に日本でうまく行っているのか？ &#124; eamcet*</dc:creator>
		<pubDate>Wed, 11 Aug 2010 14:47:01 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=118#comment-147</guid>
		<description>[...] 「Continuous Delivery」というソフトウェア開発に関する書籍の著者、Jez Humble氏によりますと、多くの日本IT企業は大規模ソフトウェア開発プロジェクトでウォーターフォール（Waterfall）な開発手法を取っているのですが、この開発手法は世界中で多くの失敗を引き起こしているにも関わらず、日本ではなぜかうまく行っているそうです（Humble氏のブログ記事）。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 「Continuous Delivery」というソフトウェア開発に関する書籍の著者、Jez Humble氏によりますと、多くの日本IT企業は大規模ソフトウェア開発プロジェクトでウォーターフォール（Waterfall）な開発手法を取っているのですが、この開発手法は世界中で多くの失敗を引き起こしているにも関わらず、日本ではなぜかうまく行っているそうです（Humble氏のブログ記事）。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: links for 2010-07-31 &#171; Dan Creswell&#8217;s Linkblog</title>
		<link>http://continuousdelivery.com/2010/07/agile-tokyo-2010/comment-page-1/#comment-93</link>
		<dc:creator>links for 2010-07-31 &#171; Dan Creswell&#8217;s Linkblog</dc:creator>
		<pubDate>Sat, 31 Jul 2010 12:06:44 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=118#comment-93</guid>
		<description>[...] Agile Tokyo 2010 &#124; Continuous Delivery The most surprising discovery for me was that agile is considered new and somewhat subversive in Japan. Japanese IT companies have been doing waterfall on large projects for a long time now, and it is deeply entrenched. (tags: agile japan) [...]</description>
		<content:encoded><![CDATA[<p>[...] Agile Tokyo 2010 | Continuous Delivery The most surprising discovery for me was that agile is considered new and somewhat subversive in Japan. Japanese IT companies have been doing waterfall on large projects for a long time now, and it is deeply entrenched. (tags: agile japan) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jez</title>
		<link>http://continuousdelivery.com/2010/07/agile-tokyo-2010/comment-page-1/#comment-85</link>
		<dc:creator>jez</dc:creator>
		<pubDate>Fri, 30 Jul 2010 08:05:25 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=118#comment-85</guid>
		<description>My understanding is that &quot;works perfectly&quot; means projects come in more or less on time, on budget, and with acceptable quality. One of the questions put to the panel was how agile could guarantee quality. Unfortunately I only had a couple of days there, so I wasn&#039;t able to come to anything other than a very general understanding of how projects are run. Obviously I&#039;d love the opportunity to go back.

The main difference between the v-model and long sprints is the phased approach of the v-model. In agile and lean methodologies, quality is built in to the process rather than being a phase performed by a separate team, and integration and analysis are performed continuously throughout the scope of the project - so if new requirements come in towards the end, they can be accommodated.

But yes, you&#039;re right that projects run according to this plan can&#039;t claim they shipped the right thing - i.e. something they know will be valuable to users - on time.</description>
		<content:encoded><![CDATA[<p>My understanding is that &#8220;works perfectly&#8221; means projects come in more or less on time, on budget, and with acceptable quality. One of the questions put to the panel was how agile could guarantee quality. Unfortunately I only had a couple of days there, so I wasn&#8217;t able to come to anything other than a very general understanding of how projects are run. Obviously I&#8217;d love the opportunity to go back.</p>
<p>The main difference between the v-model and long sprints is the phased approach of the v-model. In agile and lean methodologies, quality is built in to the process rather than being a phase performed by a separate team, and integration and analysis are performed continuously throughout the scope of the project &#8211; so if new requirements come in towards the end, they can be accommodated.</p>
<p>But yes, you&#8217;re right that projects run according to this plan can&#8217;t claim they shipped the right thing &#8211; i.e. something they know will be valuable to users &#8211; on time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Creswell</title>
		<link>http://continuousdelivery.com/2010/07/agile-tokyo-2010/comment-page-1/#comment-77</link>
		<dc:creator>Dan Creswell</dc:creator>
		<pubDate>Thu, 29 Jul 2010 08:16:08 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=118#comment-77</guid>
		<description>&quot;Indeed, everybody I spoke to confirmed that waterfall worked perfectly well for them as a software development methodology.&quot;

Can you provide some more details of what &quot;worked perfectly&quot; means and how the Japanese measure that? Looking at this:

&quot;For me, the most egregious problem with this plan is that the planning stage for phase 2 of the project comes before the testing stage for phase 1. So anything discovered during the testing and user acceptance stages cannot be fed in to phase 2&quot;

I&#039;d note that&#039;s almost like doing very long sprints. It also seems to contradict the &quot;works perfectly well&quot; - phase I is going to ship with issues discovered during testing and phase II won&#039;t fix them. Seems the Japanese could claim they shipped something on time, seems much harder for them to claim they shipped the right thing at the right quality on time?

Love to hear some more details as this is interesting stuff....</description>
		<content:encoded><![CDATA[<p>&#8220;Indeed, everybody I spoke to confirmed that waterfall worked perfectly well for them as a software development methodology.&#8221;</p>
<p>Can you provide some more details of what &#8220;worked perfectly&#8221; means and how the Japanese measure that? Looking at this:</p>
<p>&#8220;For me, the most egregious problem with this plan is that the planning stage for phase 2 of the project comes before the testing stage for phase 1. So anything discovered during the testing and user acceptance stages cannot be fed in to phase 2&#8243;</p>
<p>I&#8217;d note that&#8217;s almost like doing very long sprints. It also seems to contradict the &#8220;works perfectly well&#8221; &#8211; phase I is going to ship with issues discovered during testing and phase II won&#8217;t fix them. Seems the Japanese could claim they shipped something on time, seems much harder for them to claim they shipped the right thing at the right quality on time?</p>
<p>Love to hear some more details as this is interesting stuff&#8230;.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic page generated in 1.191 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2012-02-01 23:53:37 -->

