<?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>Conscious Development &#187; kanban</title>
	<atom:link href="http://samipoimala.com/it/tag/kanban/feed/" rel="self" type="application/rss+xml" />
	<link>http://samipoimala.com/it</link>
	<description>Curious perversions from software development</description>
	<lastBuildDate>Tue, 30 Nov 2010 12:21:52 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Day one at Scanagile</title>
		<link>http://samipoimala.com/it/2009/10/15/day-one-at-scanagile/</link>
		<comments>http://samipoimala.com/it/2009/10/15/day-one-at-scanagile/#comments</comments>
		<pubDate>Thu, 15 Oct 2009 20:31:12 +0000</pubDate>
		<dc:creator>Sami Poimala</dc:creator>
				<category><![CDATA[Conscious development]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[kanban]]></category>
		<category><![CDATA[lean]]></category>

		<guid isPermaLink="false">http://samipoimala.com/it/?p=55</guid>
		<description><![CDATA[Here are some highlights from the first day in Scan-Agile conference. Mary Poppendieck &#8211; Leadership and Self-Organizing Teams &#8211; Incompatible or Synergistic? Leader&#8217;s job is to keep the team from their comfort zone! Too often &#8211; espeacially small &#8211; teams are aiming for consensus &#8211; leaving out most of the wisdom that individuals have. The [...]]]></description>
			<content:encoded><![CDATA[<p>Here are some highlights from the first day in <a href="http://www.scan-agile.org">Scan-Agile</a> conference.</p>
<p><span id="more-55"></span><strong>Mary Poppendieck &#8211; Leadership and Self-Organizing Teams &#8211; Incompatible or Synergistic?</strong></p>
<ul>
<li>Leader&#8217;s job is to keep the team from their comfort zone!<br />
Too often &#8211; espeacially small &#8211; teams are aiming for consensus &#8211; leaving out most of the wisdom that individuals have. The leader has to ask unpleasant questions.</li>
<li>What differentiates a team from a workgroup is &#8216;common purpose&#8217;.<br />
A workgroup or committee is a group of people doing work together &#8211; but they don&#8217;t necessarile have the same goal. A team by definition is a group of people working together towards a shared vision or goal &#8211; common purpose.</li>
<li>Teams are dependant on their ability to make good decisions. And good decisions need:<br />
1) Diversity of opinions &#8211; all people participate in decision making<br />
2) Independence &#8211; team members may not be dependant on each other<br />
3) Decentralization &#8211; tema members are needed to have different specializations<br />
4) Aggregation &#8211; team must be able to draw conclusion from diverse opinions that come from different expertises</li>
<li>Team need two kinds of leadership:<br />
Competence leadership &#8211; like a master teacher who tells you how to play violin<br />
Product champion- like a  band leader wo is guiding the whole group</li>
<li>Competence leader assists in specialization while product champion helps in aggregation</li>
<li>There are two types of management: 1) Mission command and 2) Detailed command</li>
<li>In agile and lean development, mission command is what we need.</li>
<li>Mission commanders job (leader) is to<br />
1) State intent<br />
2) Set the tone &amp; tempo<br />
3) Make better people<br />
4) Improve the system</li>
<li>Always consider the cultural aspects of any organization and remember that different countries have totally differnet biases on what&#8217;s acceptable and what&#8217;s not.</li>
<li>When reading ANY theory, always consider in what country the author was raised up.</li>
<li>Lean originates from Japan, Agile originates from US</li>
</ul>
<p><strong>Jim Coplien &#8211; Why Lean and Agile are in conflict, and how to resolve the conflicts</strong></p>
<ul>
<li>Scrum is not about some fancy practises</li>
<li>Even the much touted Nokia test doesn&#8217;t guarantee real, suscesful Scrum implementation</li>
<li>Lean is meant to deal with complicated things while agile is meant to deal with complex things</li>
<li>Productivity is actually waste! It causes queues and inventories. You need to concentrate on ROI and the flow of value through the whole stream</li>
<li>Agile is about &#8220;doing just enough to get just enough quality&#8221; while lean is about &#8220;doing the least you can to achieve excellence&#8221;</li>
<li>Irritating fact, that seems amazingly commonly to be surprise: A hope is not a plan.</li>
<li>Scrum is not about 30% not even 100% of improvement. It&#8217;s about 2-3 orders of magnitude improvement when done correctly</li>
</ul>
<p><strong>Petri Heiramo &#8211; Scrum from the customer point of view</strong></p>
<ul>
<li>First impressions: weird terminology and a little common ground</li>
<li>Key benefits<br />
1) Improved communication<br />
2) Better visibility<br />
3) Enabling changing requirements<br />
4) Faster feedback<br />
5) Building quality in<br />
=&gt; Higher ROI</li>
<li>Success and value cannot be managed through cost. Instead, focus on<br />
1) User research&amp;business analysis<br />
2) Competence &amp; motivation of team members<br />
3) Amount of knowledge generated in every iteration<br />
4) Ability to incorporate cost<br />
=&gt; Focus on value</li>
<li>Research is completely different from development. You cannot estimate research.</li>
<li>Start from the definion of value and aim only towards generating more of it</li>
<li>Software should not be buyed be spec but by a vision instead.</li>
<li>Buying on spec causes higher cost, lower value and loss of knowledge between different phases of the project</li>
<li>You need continuous integration at project level, especially on multi-supplier projects</li>
<li>Never fix scope on a contract, even if cost and duration are fixed</li>
<li>Enable changes and early termination</li>
<li>The finnish acquisiotion law actually do not state you need waterfall. It especially makes it possible to avoid so called &#8220;open conduct&#8221; and use a &#8220;negotiative conduct&#8221; instead whenever the nature of purchase is such that the requiremetns cannot be clearly stated beforehand.</li>
</ul>
<p><strong>Karl Scotland &#8211; Five steps to kanban</strong></p>
<ol>
<li>Map the value stream</li>
<li>Visualize it</li>
<li>Limit work in progress</li>
<li>Establish cadence (pull system doesn&#8217;t need timeboxing!)</li>
<li>Reduce the kanban tokens</li>
</ol>
<ul>
<li>You need to keep the work flowing, not the workers busy</li>
<li>Ideally, development of a new feature doesn&#8217;t start before customer has paid for it.</li>
<li>Visualize the work in progress and gradually limit the number of work items in progress</li>
<li>Ideally the whole team works on a single story all the time.</li>
</ul>
<p><strong>Ari Tikka &#8211; Understanding power</strong></p>
<ul>
<li>&#8216;Power distance&#8217; is an important aspect of everyday life</li>
<li>It&#8217;s easy to be dependant on other people<br />
- The other will take care of me<br />
- I don&#8217;t have to decide<br />
=&gt; A tempting trap</li>
<li>Use of power is often constraining the system. There are two types of constraining.</li>
<li>Productive constraining. Like timeboxing &#8211; constrains the time axis</li>
<li>Bad constraining. Like micro-management that amplifies power distance and adds friction. Or conflict avoidance, which results in weaker decisions.</li>
</ul>
<p><strong>Bonus Panel &#8211; why bother with agile?</strong></p>
<p>The discussion went &#8220;a bit&#8221; off-topic, but interested discussion whatsoever <img src='http://samipoimala.com/it/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<ul>
<li>Agility started from software development, now we need to get higher in the corporate culture</li>
<li>Agile practises have worked long time, long before agile was a buzzword.</li>
<li>The only companies that will survive are those capable of changing rapidly</li>
<li>We are pretty good at looking into the future &#8211; but too often forget that the future will not stay the same!<br />
Also, we feel unpleasant to look back into the past &#8211; which is where we could learn</li>
<li>Waterfall has itäs place and works in simple projects. Complex projects are where you need something more and agility <em><strong>may</strong></em> work. In chaotic circumstances nothing will survive.</li>
<li>The biggest mistake we made was to plan year-long projects at the day-level detail.</li>
<li>The trend is towards smaller teams, where everyone is required to participate in decision making. There&#8217;s no room for just hanging around.</li>
</ul>
<p>Of course, you can <a href="http://twitter.com/#search?q=%23scanagile">follow what is going on on Twitter</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://samipoimala.com/it/2009/10/15/day-one-at-scanagile/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

