tag:blogger.com,1999:blog-51161745550320752772024-02-07T22:20:39.547-08:00Inspiration for AgilistsFood for thought for Agile practitionersAnonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-5116174555032075277.post-81889362544971196912017-04-30T19:26:00.000-07:002017-04-30T19:30:59.362-07:00Order out of Chaos<div class="MsoNormal">
<span style="font-size: 12pt;"><b>Putting your Product Backlog in order –
what should you work on first?</b></span></div>
<div class="MsoNormal">
<span lang="EN-AU">Suppose you’re a <a href="http://www.scrumguides.org/scrum-guide.html#team-po">Product Owner</a>
and you have a few items in your <a href="http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog">Product
Backlog</a>. How would you advise the <a href="mailto:http://www.scrumguides.org/scrum-guide.html%23team-dev">Development
Team</a> on what to start working on first? Should you even care at all? What
difference would it make if you were a bit deliberate about the order in which
work items get tackled?<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-AU"><o:p><b>The tale of the two leaky barrels</b></o:p></span></div>
<div class="MsoNormal">
<span lang="EN-AU">To explore answers to these questions,
let’s consider the story of two leaky barrels. Imagine we run a bar and have
two troublesome barrels. One holds whisky, the other holds beer. Both are
leaking right now, losing us money. Every minute that passes, we loose about
$50 worth of whisky and $10 worth of beer.<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-AU">Based on this information, which one should
we fix first? A natural impulse would be to start working on the whiskey
barrel. After all, we’re losing five times as much money each minute from it.
So far, so good.<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-AU">Imagine that we resist that temptation
briefly enough to get curious about how long it would take to repair the
barrels. Let’s further suppose that our investigation turns out that it would
take a minute to fix the beer barrel and about ten minutes to fix the whiskey
barrel. Armed with this new information, is it still a safe bet to fix the
whiskey barrel first? Oops. Not so much anymore.<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-AU">Sure, in the minute we’d take to fix the
beer barrel, we’d lose $50 worth of whiskey. But if we took the ten minutes to
fix the whiskey barrel, we’d lose $100 worth of beer. Ouch.<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Cost of Delay or Speed to Value?</b></div>
<div class="MsoNormal">
<span lang="EN-AU">We can think of the $10/minute beer loss as
a <i style="mso-bidi-font-style: normal;"><a href="http://www.scaledagileframework.com/wsjf/">cost of delay</a></i> (see <a href="https://smile.amazon.com/Principles-Product-Development-Flow-Generation-ebook/dp/B007TKU0O0/">Don
Reinertsen’s work</a>). Seen from this perspective, it shows us how much would
it cost us if we delay the repair by a minute. However, we can also think of it
as a <i style="mso-bidi-font-style: normal;">speed to value</i>. In this
interpretation, if it took a minute to achieve, we’d get a $50 value saving
from the whisky barrel and just $10 from the beer one.<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-AU">Thinking of it as a <i style="mso-bidi-font-style: normal;">speed to value</i> has another benefit. In physics, when we divide
speed by time we get acceleration. Therefore, when we divide the <i style="mso-bidi-font-style: normal;">speed to value</i> by the duration estimate,
we end up with <i style="mso-bidi-font-style: normal;">acceleration to value</i>.
In our example, $10/minute divided by 1 minute gives us a value of 10, whereas
the whisky $50/minute divided by 10 gives us a value of 5. The higher value for
the <i style="mso-bidi-font-style: normal;">acceleration to value</i> is a simple
and reliable indicator that that initiative should be undertaken first. In my experience, thinking of <i>acceleration to value</i> is a lot easier to wrap your mind around than "<i>Cost of Delay Divided by Duration</i>" (or CD3 as it's sometimes referred to).<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-AU">In this manner, you can develop a cunning
practice of ordering your Product Backlog in such a way as to maximise the <i style="mso-bidi-font-style: normal;">acceleration to value</i>. Items with the
highest acceleration to value would be worked on first.<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-AU"><o:p><b>The Scientific Method to the rescue!</b></o:p></span></div>
<div class="MsoNormal">
<span lang="EN-AU">This economic assessment is equivalent to
using the scientific method: making a theory, running some experiments,
assessing the results, then improving the theory. First, we make a theory of
which items are most important to work on – the value model, speed to value and
acceleration to value concepts are elements of this theory. Then, we run some
experiments by creating items in the order suggested by the theory, and assess
the outcomes. Based on the findings, we can then decide to continue to use our
theory as-is, or adjust its elements to improve its predictive ability.<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-AU">It’s conceivable that in some cases
dependencies across items may sometimes drag items with smaller accelerations
to value closer to the top of the backlog. However it would only happen if it enables
the creation of an item with acceleration higher than everything else.<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-AU"><o:p><b>The Quality of Order - What's "good enough"?</b></o:p></span></div>
<div class="MsoNormal">
<span lang="EN-AU">The quality of the order of the items in
the backlog is driven by the accuracy of the value model used to determine
speed to value. The result is further influenced by the accuracy of the effort
estimates. Overall, it’s good to remember you don’t need a “perfect” model. You
just need something “good enough” to give you a promising order to experiment
with. Having a system to create and assess value is far more effective than
just random decisions.<o:p></o:p></span></div>
<div class="MsoNormal">
<br /></div>
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]-->
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-US</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
<w:UseFELayout/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="276">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"MS 明朝";
panose-1:0 0 0 0 0 0 0 0 0 0;
mso-font-charset:128;
mso-generic-font-family:roman;
mso-font-format:other;
mso-font-pitch:fixed;
mso-font-signature:1 134676480 16 0 131072 0;}
@font-face
{font-family:"MS 明朝";
panose-1:0 0 0 0 0 0 0 0 0 0;
mso-font-charset:128;
mso-generic-font-family:roman;
mso-font-format:other;
mso-font-pitch:fixed;
mso-font-signature:1 134676480 16 0 131072 0;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:0;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:-536870145 1073743103 0 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin:0cm;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:Cambria;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"MS 明朝";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;
mso-ansi-language:EN-AU;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
mso-themecolor:hyperlink;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-noshow:yes;
mso-style-priority:99;
color:purple;
mso-themecolor:followedhyperlink;
text-decoration:underline;
text-underline:single;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-family:Cambria;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"MS 明朝";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;
mso-ansi-language:EN-US;}
@page WordSection1
{size:595.0pt 842.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;
mso-header-margin:35.4pt;
mso-footer-margin:35.4pt;
mso-paper-source:0;}
div.WordSection1
{page:WordSection1;}
-->
</style>
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:Cambria;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;
mso-ansi-language:EN-US;}
</style>
<![endif]-->
<!--StartFragment-->
<!--EndFragment--><br />
<div class="MsoNormal">
<span lang="EN-AU">The overall intention is to figure out how
soon it’s a good idea to stop. Your development team will have a known burn
rate.<span style="mso-spacerun: yes;"> </span>You’ll want to stop work on this
product as soon as the value of the items you’re trying to build is lower than
the cost of production over the same duration.<o:p></o:p></span></div>
Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-7018656390550468172013-02-19T14:20:00.000-08:002013-02-19T14:22:09.081-08:00The Lean Leadership mindsetIn his excellent <a href="http://bit.ly/GembaWalks" title="Gemba Walks" target="_blank">Gemba Walks</a>, Jim Womack suggests a Lean Leadership mindset. The Lean Leader will:
<ol>
<li>Embrace the practice of problem-solving by going to the actual place of work, seeing the actual situation, asking great questions about the issues and impediments found, seeking root causes, and showing respect for the lower-level managers and for colleagues at the same organizational level by continuing to ask hard questions until good answers emerge.</li>
<li>Understand that no manager at a higher level should attempt to solve a problem at a lower level on their own. Instead, the higher-level manager can assign responsibility to a manager at a lower level to tackle the problem through continuing dialogue, both vertically with the higher-level manager and horizontally with everyone actually touching the process causing the impediment. This is where Communities of Practice may shine (such as the ones fostered by our Agile Transformation Offices in our various organizations and accounts), by providing ready access to the people most closely involved with and familiar with relevant topics. Problems are best solved right where they are found, in conversation with the people that live with them, rather than pondered in abstract in some remote executive suite.</li>
<li>Know that all problem-solving is about experimentation, preferably by practicing a plan-do-check-act habit of continuous inspection and adaptation. No-one can know the best answer before experiments are conducted, and the many experiments that fail will yield great learning to be applied for the next rounds of experiments.</li>
<li>Appreciate that no problem is ever solved forever. Introducing a promising countermeasure is sure to create other new problems elsewhere in the system. This is not bad - it is to be expected, and it is good, provided that the critical, probing minds of the Leaders keep pursuing continuous improvement.</li>
</ol>Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-53906581207320661942013-02-17T12:39:00.000-08:002013-02-17T12:42:56.699-08:00So, what's the role of the Agile Project Manager then?<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5QtHAVSdJloD41kyNWpVPeBSFo4shBr3SXEX6z_7Tng7Z4Tr7nu6L2Zjja6BNBGz8o31RGLmVgwqTZ-_DjU6ebcXTtbxrvjYfEgSpgRhh83MUy6cHZaYPeqK_iKhq9LRW6JA6O_-7IcJZ/s1600/mindset-small.jpg" imageanchor="1" style="float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5QtHAVSdJloD41kyNWpVPeBSFo4shBr3SXEX6z_7Tng7Z4Tr7nu6L2Zjja6BNBGz8o31RGLmVgwqTZ-_DjU6ebcXTtbxrvjYfEgSpgRhh83MUy6cHZaYPeqK_iKhq9LRW6JA6O_-7IcJZ/s1600/mindset-small.jpg" /></a></div>
I find that invariably, after I give a brief introduction to <a href="http://inspiration4agilists.blogspot.com/2012/02/power-of-agile-mindset.html" target="_blank">the Agile mindset</a>, someone will ask "So, what's the role of the Project Manager in an Agile work process then?"<br />
<br />
Let's take the <a href="http://scrum.org/Scrum-Guides" target="_blank">Scrum framework</a> as an example of a typical Agile way of work. Since it only includes the Product Owner, Team Member and ScrumMaster roles, some people may wonder what is to become of Project Managers? Surely, there must be a role for Project Managers in the Agile work process, right?<br />
<br />
The short answer is that there are multiple roles available for the Project Manager - each person will have to choose according to their personal experience and aspirations.<br />
<br />
All effective Agile work processes take advantage of sound project management practices. The various <a href="https://secure.wikimedia.org/wikipedia/en/wiki/A_Guide_to_the_Project_Management_Body_of_Knowledge" target="_blank">PMBOK knowledge areas</a> still need care and attention - using an Agile work process doesn't involve any magic that would effortlessly resolve issues of managing integration, scope, time, cost, quality, people, communications, risk, procurement or stakeholders (the fifth version of the <a href="http://www.pmi.org/PMBOK-Guide-and-Standards.aspx" target="_blank">PMBOK guide</a> now includes a new chapter on Stakeholder Management).<br />
<br />
Agile teams address these issues in a manner culturally different to traditional project management approaches. Rather than concentrating the responsibility to manage the concerns of all project management knowledge areas into a single person (the Project Manager), effective Agile teams rely on all members of the team to contribute their efforts and expertise. Experience teaches us that synergy drawn from diversity is consistently far more effective than individual effort, no matter how heroic a single person might be.<br />
<br />
<h4>
Project Management or Product Management?</h4>
A vital distinction is that Agile work processes tend to be focused on perfecting the art of product management, by creating, adjusting and sustaining a product over time in response to feedback from its user community - a product may have an indefinite lifespan, and ever-evolving scope, limited only by its market relevance. On the other hand, by definition:<br />
<blockquote class="tr_bq">
A project is a temporary endeavor undertaken to create a unique product, service or result.</blockquote>
This dynamic leads to a number of significant implications for the practice of project management in an Agile product development context. The project management disciplines are still vital, regardless of the nature of the work process one might use. <br />
<br />
However, there is no room for a traditional Project Manager in an Agile work process, as long as the person insists on behaving with exactly the same habits. For example, in an Agile work process, we cannot continue to expect to have a single person assign tasks to people. Instead, team members self-organize to identify and agree which tasks they should best perform and hold each other accountable for achieving them to meet the Team's commitments.<br />
<br />
Does this mean there is no need for Project Managers in Agile work? Not at all - on the contrary, there is a desperate need for Agile Project Managers. If people with a project management background are willing to transform the way they work, they are best placed to make a decisive contribution to changing the world of work for the better for everyone.<br />
<br />
<h4>
The Project Manager as Product Owner</h4>
Some Project Managers may have sufficient depth of knowledge in a particular industry or market such that they would make outstanding <a href="http://www.mountaingoatsoftware.com/scrum/product-owner" target="_blank">Product Owners</a> (or <a href="http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/" target="_blank">Proxy Product Owners</a>).<br />
<br />
<h4>
The Project Manager as Product Manager</h4>
For large or complex products that may involve quite a few aspects besides software-intensive systems development, a Project Manager may consider the role of Product Manager.<br />
<br />
Using a Product Manager/Product Owner pair for such products, the Product Manager may focus more attention on the customer-facing and non-software aspects, while the Product Owner may devote their attention with priority to the software-intensive systems development activities. For best results, these two people must keep their thinking synchronized at all times. Otherwise, waste and disruption follows.<br />
<br />
<h4>
The Project Manager as Program Manager</h4>
For product development efforts that involve many teams, Project Managers may consider playing the role of Program Manager, working with the various teams to coordinate their deliveries. Most of the program management disciplines can continue to be applied in a rather straightforward manner to Agile product development programs, provided the Program Manager develops a good understanding of the nature of the Agile work process used by the teams, paying close attention to the way in which scope evolves over time in the pursuit of value for the customer.<br />
<br />
<h4>
The Project Manager as Scrum Master</h4>
As more organizations embrace Agile work processes in their quest to delight customers and make work joyful at the same time, we have a dire need for Scrum Masters to act as Chief Obstacle Removers, defending the health of the Team and its work process from impediments and predators in the form of people making unreasonable or absurd demands. Therefore, we hope that many Project Managers will embrace the Scrum Master role in its full spirit, while steadfastly resisting any lingering command-and-control temptations.<br />
<br />
<h4>
The Project Manager as Team Member</h4>
One of the factors which is significantly putting at risk the long term health of software-intensive systems development organizations is the way in which they nurture their technical communities. If the only way to achieve career advancement is to let go of hands-on creation of valuable systems components and turn to a management path of some sort, then the organization will consistently bleed most of their hard-won experts away.<br />
<br />
There is a significant challenge in the task of invigorating the approach to nurturing a Technical Career Path such that it becomes much more attractive as a long-term investment and many more people would be able to achieve a satisfying career progression without having to leave it.<br />
<br />
If work as a Team Member becomes sufficiently valued and respected socially, then it is conceivable that some Project Managers may choose to join teams back again. They might try their hand at testing, designing the user experience, coding, writing - whatever needs doing in an Agile team. Project Managers as team members would most likely prove excellent mentors, helping all other team members to develop a deeper appreciation of the various aspects of effective project management and increasing the overall effectiveness of the team. If their background was technical to begin with, Project Managers may simply delight in coming back up to speed and then refining their technical expertise in one or more domains, taking a more direct involvement in creating amazing systems.<br />
<br />
<h4>
The Project Manager as Agile Coach</h4>
Some Project Managers may have the desire and talent to serve as great <a href="http://prezi.com/fuwenqdqdvc6/an-agile-coaching-framework/" target="_blank">Agile Coaches</a>. For more on Agile Coaching, consider the <a href="http://www.agilecoachinginstitute.com/" target="_blank">Agile Coaching Institute</a>.<br />
<br />
<h4>
The Project Manager as Strategist or Entrepreneur</h4>
Many Project Managers have a wealth of contacts within one or more industries. Some may be able to help organizations to identify and pursue promising product development efforts, shape joint ventures where appropriate, and may help to draw together key teams and experts that can bring them to life.<br />
<br />
When preparing programs to start producing new system increments, seasoned Project Managers are well placed to identify and attract the most promising talent.<br />
<br />
<h4>
The Project Manager as Evangelist</h4>
In time, some Project Managers may even become Agile evangelists, bringing the good news of continuous improvement to various organizations, helping them to transform their work processes using Lean and Agile thinking.<br />
<br />
<h4>
Your Voice</h4>
The usefulness of such ideas multiplies considerably when people add their perspectives. Please consider contributing your thoughts to this topic in the comments. I would warmly welcome a robust dialogue - all views are welcome, from intense support to abject disdain and everything in between.Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-57656149926997039672012-09-19T17:06:00.001-07:002012-09-20T10:10:31.006-07:00Seven Unbreakable Rules of Software Leadership<img alt="Seven Unbreakable Rules of Software Leadership" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioOlOu3uy9E6QvP2WKA3ndb_OKjhApuu50Yx4uAig5-P2xhmBPfLxcJwLAV98rj3sEDAuTrQkEIpGR3I9GwT-jUdZXCDc4bbaOOqyXQjllLuVXa94Bow2heM7ufN69PqXkrMMMJm25McHJ/s1600/Seven+Unbreakable+Rules+of+Software+Leadership.jpg" style="float: right; margin-bottom: 1em; margin-left: 1em;" />
<a href="http://www.stevemcconnell.com/" mce_href="http://www.stevemcconnell.com/" target="_blank" title="Steve McConnell">Steve McConnell</a>, of <a href="http://construx.com/" mce_href="http://construx.com" target="_blank" title="Construx">Construx</a> and <a href="http://www.amazon.com/Code-Complete-ebook/dp/B004OR1XGK/" mce_href="http://www.amazon.com/Code-Complete-ebook/dp/B004OR1XGK/" target="_blank" title="Code Complete second edition">Code Complete</a> fame, gave a webinar on this topic earlier today. He started by observing that there's no shortage of number-based leadership advice, from the <a href="http://www.amazon.com/The-One-Minute-Manager-Blanchard/dp/0007107927/" mce_href="http://www.amazon.com/The-One-Minute-Manager-Blanchard/dp/0007107927/" target="_blank" title="The One Minute Manager">One Minute Manager</a>, to <a href="http://www.amazon.com/Corps-Business-ebook/dp/B000W94FFU/" mce_href="http://www.amazon.com/Corps-Business-ebook/dp/B000W94FFU/" target="_blank" title="Corps Business">The 30 Management Principles of the US Marines</a> and nearly everything in between.<br />
<br />
He argued that leaders of Software organizations must articulate a
vision for the future of the organization - be sure that you're actually
going somewhere where people might want to follow. What might the
future of work in our organization look like? What kinds of improvements
do we want to see in our work? How will we get there?<br />
<br />
Steve then observed that the more successful leaders of software
organizations don't just expect responsibility to be parceled out to
them - they claim it. They don't "play the victim card", saying things
like "my boss won't let me do X". Instead, they take an active role in
explaining great ideas and initiatives, with tenacity and tireless
determination. In other words, don't expect to be "assigned" or
"allowed" to do something valuable or useful. Jump in, and make it
happen as fast as you can.<br />
<br />
In software, there's no "perfect" fore-knowledge. That's why great
software leaders must figure out how to make viable decisions even in
ambiguous circumstances. Figuring out what's the "<a href="http://decision-coach.com/lean-and-real-options/" mce_href="http://decision-coach.com/lean-and-real-options/" target="_blank" title="Lean and Real Options">last responsible moment</a>" to make a decision is a critical art to master.<br />
<br />
You also have to put the organization first - which means you might
need to take some hard decisions, provided they contribute to the
long-term health and viability of the organization. Some people observed
that there's an apparent conflict of rule 4 with rule 7, "Treat Your
Staff as Volunteers"- the astute leader will find a good balance of
decisive decision-making and community engagement, possibly through
habits like <a href="http://theleanedge.org/?p=3845" mce_href="http://theleanedge.org/?p=3845" target="_blank" title="Nemawashi explained">nemawashi</a> and <a href="http://inspiration4agilists.blogspot.com.au/2011/06/gemba-walk-with-jim-womack.html" target="_blank">Gemba walks</a>.<br />
<br />
The trouble with lack of "passion" or engagement is that no business
leader wants a software leader that's lackadaisical about their
business. While discussing the need to find passion for your company's
business, Steve offered the personal experience that although you might
not feel particularly passionate about a topic at first (like he didn't
feel particularly passionate about software engineering when he started
writing the first version of Code Complete), you might find yourself
develop an intense passion over time (like he did by the time he
finished writing the 900+ pages of that tome). <br />
<br />
Habits can inspire
emotion. Even if you don't feel particularly joyful and you smile, the
body will tend to release "happy" chemicals in your blood-stream. Pretty
soon, you might notice you feel better. Similarly, if you should need
to "fake" passion in your business for a while, that's OK - after a
spell, you may well get swept in the excitement and your passion may
just become "real". <br />
<br />
Becoming a student of communication means
that great software leaders must master the art of adapting their
communication style to the needs of their audience. A CFO might want
numbers. A marketing executive will want stories of exciting features.
Developers may want exciting new tech. This may seem obvious for sales
or marketing professionals, but it looks like it needs to be spelled out
explicitly for software leads.<br />
<br />
And finally, Steve concluded by
observing that <a href="http://www.stoosnetwork.org/what-is-the-problem/" target="_blank">command-and-control is essentially dead</a>. You can't afford not to
treat your staff like volunteers, doing your best to give them <a href="http://www.danpink.com/drive" mce_href="http://www.danpink.com/drive" target="_blank" title="Dan Pink's Drive">purpose, autonomy and chances to practice mastery</a> in their work.<br />
<br />
What do you think of these seven rules?Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com1Wellington, New Zealand-41.2864603 174.776236-41.4773693 174.46037900000002 -41.095551300000004 175.092093tag:blogger.com,1999:blog-5116174555032075277.post-22839125999271639412012-09-03T22:43:00.000-07:002012-09-03T22:48:45.034-07:00You think "that" about teamwork?<p><img alt="Teamwork" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSoOrR6ak2e4gu-zxGstg51mVPutwvMWZkH62dCbZOaHl8eTBPxbheGMUyWnu5bZaOtbXsRa0ZOwabOUGFL4VQV4qQ2iSJV1MSiRy5fggd30EXNyvOyhV6VqfxEJpFp3AlNYqxgICJ33f9/s1600/True-Teamwork.jpg" style="float: right; margin: 2px;" />Here are six misperceptions that HBR's J. Richard Hackman <a href="http://blogs.hbr.org/cs/2011/06/six_common_misperceptions_abou.html" target="_blank" title="Common Misperceptions about Teamwork">found out through research</a>:</p>
<p><b>Misperception #1:</b> Harmony helps. Smooth interaction among collaborators avoids time-wasting debates about how best to proceed.</p>
<p><b>Comment: </b>A bit of creative tension is indeed useful.
High-performance teams are usually also high-energy teams, that know how
to navigate conflict well. I suggest that a deeper harmony exists in
high-performance teams, not just superficially. People trust each other
to express diverging opinions and then creatively integrate them for the
benefit of all involved. That's true harmony - not just the surface
appearance of it.</p>
<p><b>Misperception #2:</b> It's good to mix it up. New members bring
energy and fresh ideas to a team. Without them, members risk becoming
complacent, inattentive to changes in the environment, and too
forgiving of fellow members' misbehavior.</p>
<p><b>Comment:</b> No surprises here - longer lived teams fare much
better. We can safely continue to push for long-lived Agile teams in
pursuit of high performance.</p>
<p><b>Misperception #3:</b> Bigger is better. Larger groups have more
resources to apply to the work. Moreover, including representatives of
all relevant constituencies increases the chances that whatever is
produced will be accepted and used.</p>
<p><b>Comment:</b> No surprise here either - <a href="http://inspiration4agilists.blogspot.co.nz/2012/02/hrair-how-many-folks-should-we-have-in.html" target="_blank" title="Hrair for teams">7+/-2 still seems to work best</a>.</p>
<p><b>Misperception #4:</b> Face-to-face interaction is passé. Now that
we have powerful electronic technologies for communication and
coordination, teams can do their work much more efficiently at a
distance.</p>
<p><b>Comment:</b> Yes, we must keep pushing for more face-to-face contact in order to improve the flow of value.</p>
<p><b>Misperception #5:</b> It all depends on the leader. Think of a
team you have led, or on which you have served, that performed
superbly. Now think of another one that did quite poorly. What accounts for the difference between them? If you are like most people, your explanation will have something to do with the personality, behavior, or style of the leaders of those two teams.</p>
<p><b>Comment:</b> Yes, self-organizing teams matter most for achieving
success. It's not just the leader - it's up to all of us to make our
teams run like greased lightning...</p>
<p><b>Misperception #6:</b> Teamwork is magical. To harvest its many
benefits, all one has to do is gather up some really talented people
and tell them in general terms what is needed--the team will work out
the details.</p>
<p><b>Comment:</b> Yes, teamwork requires <b>work</b>. High performance doesn't just emerge or happen as soon as you've dropped the "ingredients" together and stirred a bit.</p>Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0Paraparaumu, New Zealand-40.9142336 175.0083802-41.010228600000005 174.8504517 -40.8182386 175.1663087tag:blogger.com,1999:blog-5116174555032075277.post-25274711810594755922012-08-29T15:51:00.000-07:002012-08-29T16:09:24.295-07:00Confronting Reality - are you ready to become Fierce?<div class="separator" style="clear: both; text-align: center;">
<a href="http://en.wikipedia.org/wiki/Miyamoto_Musashi" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="http://upload.wikimedia.org/wikipedia/commons/thumb/2/20/Musashi_ts_pic.jpg/220px-Musashi_ts_pic.jpg" width="137" /></a></div>
Surfacing issues or current states of mind to top levels of leadership in organizations with deep hierarchies is fraught with peril. Some top leaders seem afraid of transparency. Some resist the idea of <a href="http://theleanedge.org/?p=3845">nemawashi</a> - of showing deep respect for their people, of acknowledging that in order to improve our collective lot we should engage everyone's intellect. Vital constraints and facts are closely guarded, and decisions are made in relative secrecy.<br />
<br />
Top leaders don't have to attempt to carry the full burden of imagination. They don't have to do all the thinking for all of us, and then issue directives. And yet, many of them don't yet know how to let go. Some haven't managed to <a href="http://www.fierceinc.com/leadership-books/">muster the courage to become fierce</a>. Some are likely Very Afraid of just such Anarchy as <a href="http://agileanarchy.tumblr.com/post/29560070022/the-spirit-of-change">Tobias Mayer's Spirit of Change</a> implies. And <a href="http://www.stoosnetwork.org/what-is-the-problem/">attempts at tightening grips of control</a> will only generate more backlash and discontent, more frustration & misery.<br />
<br />
Ultimately (and rather amazingly), it comes down to <a href="http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html">what we believe matters most</a>. Belief is so insubstantial, it's a fleeting pattern of dynamic electro-chemical reactions in the neural networks of humans. And despite this fragility, belief and intent are perhaps the most powerful forces in the human sphere of affairs.<br />
<br />
What we believe in drives our habits. It informs our reactions and choices. It shapes who we are, and what we want to be remembered for. <br />
<br />
What do you believe in? How do you want to be remembered? What will you do to make it so? Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0Paraparaumu, New Zealand-40.9142336 175.0083802-41.010228600000005 174.8504517 -40.8182386 175.1663087tag:blogger.com,1999:blog-5116174555032075277.post-84272919963796305672012-08-28T21:10:00.001-07:002012-08-28T21:13:19.924-07:00STEP – A Map for an Agile Journey<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.infoq.com/resource/articles/STEP-map-Agile-Journey/en/smallimage/logo.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.infoq.com/resource/articles/STEP-map-Agile-Journey/en/smallimage/logo.jpg" /></a></div>
I recently <a href="http://www.infoq.com/articles/STEP-map-Agile-Journey" target="_blank">published an article on InfoQ</a>, about how one might look at a journey of continuous improvement inspired by Agile thinking. Would love to hear what you think of it. Which ideas are most helpful to you?Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0Paraparaumu 5032, New Zealand-40.9142336 175.0083802-41.010228600000005 174.8504517 -40.8182386 175.1663087tag:blogger.com,1999:blog-5116174555032075277.post-56123664351122778822012-04-29T16:31:00.001-07:002012-09-01T21:53:42.483-07:00Delight and Joy - unalienable rights<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtWvW529xIkDOfCKcUJgZci40Ro3IslNE95VLl6rFZoSCfcTHQBtDrTaTH3UGKVqpwvbsbOUWRCOaT_KmYYqGk23bjViLUhEOiwAJKGw6B4_Zk2hgOsz4yZ1LBJSFvkeHuyh9s2rPEpDlD/s1600/We+The+People.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="98" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtWvW529xIkDOfCKcUJgZci40Ro3IslNE95VLl6rFZoSCfcTHQBtDrTaTH3UGKVqpwvbsbOUWRCOaT_KmYYqGk23bjViLUhEOiwAJKGw6B4_Zk2hgOsz4yZ1LBJSFvkeHuyh9s2rPEpDlD/s200/We+The+People.jpg" width="200" /></a></div>
The <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a> is an excellent foundation for creating better software development organisations. However, on its own, it lacks a unifying foundation - a means of bringing everyone together, across any organisational boundaries.<br />
<br />
Many people still predominantly think in terms of applicability of Agile for specific projects: "Can this project be run using Agile?" or "Would Agile be appropriate for this project?". That kind of attitude slows organisation-wide improvement - it implies that in some areas, the existing ways of work might be "good enough" and therefore exempt from scrutiny and improvement.<br />
<br />
The Agile Manifesto, as it currently stands, doesn't directly help people to think in more holistic terms, like: "How may we delight our customers better?", or "How may we best improve our way of work?", despite the fact that agile techniques are very well designed to support improvement.<br />
<br />
A few hundred years ago, a nation was born with a proclamation that included the following words:
<br />
<blockquote>
<span style="font-family: Times, 'Times New Roman', serif;">We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are <b>Life, Liberty and the pursuit of Happiness</b>.</span></blockquote>
In my experience, nothing fundamental has changed in the mean time - we can still safely perceive these truths as self-evident. All of us that work for a living deserve the opportunity to <b>delight our customers</b> and find <b>joy in our work</b>.<br />
<br />
Recent research shows that positive emotions play a significant role in achieving success. Consider Shawn Achor's <a href="http://www.ted.com/talks/shawn_achor_the_happy_secret_to_better_work.html" target="_blank">TED Talk: The happy secret to better work</a>, and Barbara Fredrickson's <a href="http://www.positivityratio.com/" target="_blank">work on positivity</a>.<br />
<br />
We all deserve to have ample opportunities <a href="http://www.scoop.it/t/well-being" target="_blank">to pursue happiness</a>. Since our work lives use up most of our waking hours each week, we had better make sure we can find great joy in our work. Focusing on delighting customers is an excellent and sustainable source of joy and satisfaction in work.<br />
<br />
<a href="http://www.danpink.com/drive" target="_blank">Dan Pink</a> proposes that in our current culture we are primarily motivated by <b>autonomy, mastery </b>and <b>purpose</b> - I find it fascinating how well that parallels with spirit of the Declaration of Independence. Liberty matches autonomy (the freedom to choose our own course of action), mastery matches life (the opportunity to work at improving our skills, minds and bodies), and happiness matches purpose.<br />
<br />
I suggest we may find ways of improving upon the Agile Manifesto, quite possibly by harnessing the influence of positive emotions to achieve lasting success in our organisations. What do you think?Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0Paraparaumu, New Zealand-40.9142336 175.0083802-41.010228600000005 174.8504517 -40.8182386 175.1663087tag:blogger.com,1999:blog-5116174555032075277.post-5978146835580764342012-03-12T15:52:00.001-07:002012-03-12T15:54:35.622-07:00Beware greed in retrospectives<a href="http://www.infoq.com/news/2010/03/Rules-for-Better-Retrospective">Retrospectives</a> are healthy. Retrospectives are vital for improving our work life. Without them, we wouldn't have <a href="http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/">a systematic way of examining what needs improving and what we might do about it</a>.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQspc9PSZ1h0hL5m8hnCgQ9x9P2IUiAXgIDLz8e0iXBmZ03n7qPiwrKXGKAbsmAx0awCPh4tG5sw_Xnf6QGgfqJYZekMTpzoBIVY_dpqh7WEpHEopvfDzjq_jQOZlagleGXK9jDzZj2IuE/s1600/Rear-view+mirror.jpg" imageanchor="1" style="clear:right; float:right; margin-left:1em; margin-bottom:1em"><img border="0" height="86" width="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQspc9PSZ1h0hL5m8hnCgQ9x9P2IUiAXgIDLz8e0iXBmZ03n7qPiwrKXGKAbsmAx0awCPh4tG5sw_Xnf6QGgfqJYZekMTpzoBIVY_dpqh7WEpHEopvfDzjq_jQOZlagleGXK9jDzZj2IuE/s200/Rear-view+mirror.jpg" /></a></div><br />
Even so, too often I see teams becoming so excited with the 57 things they've just discovered could do with improvement that they want to try them all at once. Beware greed in retrospectives - do your best to pick just one. Search for the most valuable improvement opportunity, design some experiments for countermeasures, and focus on that one improvement. Create a measurement system such that the results can be analysed with as much clarity as possible. Let the data speak.<br />
<br />
Only then focus on the next most pressing constraint and repeat the process of root cause analysis, countermeasure design, experimentation and adaptation. We owe it to ourselves to be very reserved with our investments - we only have a very limited capacity for improvement, we should spend it wisely, on the item that we expect will lead to the best improvement.Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-37527185331572153062012-02-16T18:58:00.005-08:002012-02-16T19:16:28.528-08:00Hrair - how many folks should we have in our meetings?Meetings:<br />
<ul><li> Some are the bane of our existence. Too many people involved, too easy to get distracted, not much happening overall.</li>
<li>Some are delightful. Just enough people, high energy, intense conversation and collaboration, joyful enthusiasm shared.</li>
</ul>It turns out that our brains are wired such that we can only keep a very small number of things in mind at any one time. Some argued for <a href="http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two" title="Magical 7 plus-minus 2" target="_blank">7+/-2</a>, some say even less, around three or four.<br />
<div class="separator" style="clear: both; text-align: center;"><br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbDzcGyJsmA-C5vnTck5thvdVfDf_ylxyu4fCkLIri__A889tmTTuscHEjoslRA2yFtM94TdASlI5vzKU7_CWQRMmkVSTEic5_-HVOMxE0hMNK152xj1VeVPqCtpq-cAaQ3jTz7ZvRc9he/s1600/rabbit.jpg" imageanchor="1" style="clear:right; float:right; margin-left:1em; margin-bottom:1em"><img border="0" height="199" width="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbDzcGyJsmA-C5vnTck5thvdVfDf_ylxyu4fCkLIri__A889tmTTuscHEjoslRA2yFtM94TdASlI5vzKU7_CWQRMmkVSTEic5_-HVOMxE0hMNK152xj1VeVPqCtpq-cAaQ3jTz7ZvRc9he/s200/rabbit.jpg" /></a></div><a href="http://everything2.com/title/Hrair" title="Hrair" class="populated">Hrair</a> is a word found in the <a href="http://everything2.com/title/rabbit" title="rabbit" class="populated">rabbit</a> vocabulary of the book <a href="http://everything2.com/title/Watership+Down" title="Watership Down" class="populated">Watership Down</a>. Since rabbits have an awful time with numbers, they only have actual words for numbers <a href="http://everything2.com/title/one" title="one" class="populated">one</a>, <a href="http://everything2.com/title/two" title="two" class="populated">two</a>, <a href="http://everything2.com/title/three" title="three" class="populated">three</a>, and <a href="http://everything2.com/title/four" title="four" class="populated">four</a>. Any number after that is <em>hrair</em>, which literally means "a <a href="http://everything2.com/title/thousand" title="thousand" class="populated">thousand</a>", but often means "a lot". The idea is that for humans, <em>hrair</em> might be similar, and at most stretch to 7 plus-or-minus 2.<br />
<br />
The interesting observation is that small meetings (of no more than <em>hrair</em> folks) tend to be far more focused, effective and joyful. The same concept applies to Agile teams - teams of no more than <em>hrair</em> folks have an advantage at keeping tightly focused on a shared set of goals.<br />
<br />
Groups of more than <em>hrair</em> people find it increasingly harder to keep focused on a single conversation. It becomes a progressively easier to get distracted and tempted to draw into a side-conversation with <em>hrair</em> folks or less.Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-38239485370378631132012-02-16T18:36:00.000-08:002012-09-26T10:39:26.867-07:00The Power of an Agile Mindset<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.agileroots.com/wp-content/uploads/2012/03/linda-rising-400.jpg" imageanchor="1" style="float: right; margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="http://www.agileroots.com/wp-content/uploads/2012/03/linda-rising-400.jpg" /></a></div>
Linda Rising gave rousing closing keynote <a href="http://www.agilealliance.org/resources/learning-center/keynote-the-power-of-an-agile-mindset/">The Power of an Agile Mindset</a> at <a href="http://agile2011.agilealliance.org/">Agile 2011</a>. She got an impressing standing ovation at the end of the session, and at times there were even a few tears in the audience - a most impressive feat for a rather cerebral audience.<br />
<br />
Linda draws our attention to the “agile mindset,” an attitude that equates failure and problems with opportunities for learning, a belief that we can all improve over time, that our abilities are not fixed but evolve with effort.<br />
<br />
In contrast, a fixed mindset constrains our ability to change, improve & adapt - it robs us of a joyful future.Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-78230894614973948322011-07-28T14:48:00.000-07:002011-07-28T23:16:44.707-07:00Agile Manifesto T-shirtsHere are a couple of suggestions for T-shirt stencils you might consider. The word clouds for Agile Manifesto and the principles behind it...<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-left: 1em; margin-right: 1em; text-align: left;"><tbody>
<tr> <td style="text-align: center;"><a href="http://www.wordle.net/show/wrdl/3878264/The_original_Agile_Manifesto" style="clear: left; margin-bottom: 1em; margin-left: 0; margin-right: 1em;" title="Wordle: The original Agile Manifesto"><img alt="Wordle: The original Agile Manifesto" src="http://www.wordle.net/thumb/wrdl/3878264/The_original_Agile_Manifesto" style="border: 1px solid rgb(221, 221, 221); padding: 4px;" /></a></td> <td style="text-align: center;"><a href="http://www.wordle.net/show/wrdl/3878287/The_original_Agile_Manifesto_Principles" style="clear: right; margin-bottom: 1em; margin-left: 1em; margin-right: 1em;" title="Wordle: The original Agile Manifesto Principles"><img alt="Wordle: The original Agile Manifesto Principles" src="http://www.wordle.net/thumb/wrdl/3878287/The_original_Agile_Manifesto_Principles" style="border: 1px solid rgb(221, 221, 221); padding: 4px;" /></a></td> </tr>
<tr> <td class="tr-caption" style="text-align: center;">The Agile Manifesto</td> <td class="tr-caption" style="text-align: center;">Principles behind the Agile Manifesto</td><td class="tr-caption" style="text-align: center;"></td> </tr>
</tbody></table>Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com1tag:blogger.com,1999:blog-5116174555032075277.post-47551848510565328442011-07-27T00:00:00.000-07:002012-08-29T15:54:00.335-07:00Word cloud for "Describe what you do in three words"<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMWru8hsf9MKDnPHQNBbOnSFDhn__ikW7hKaiPaSmHg3DQXfIC997GZq0itkY4XRUC7GdB5-xgfxnap4KRI2k6cyfHxE7qZHwgL3zIXL4mHyZnpGTBjwIOtx25SqQ0mtgWkWGHmPyhIQEl/s1600/Three+Words+for+What+you+Do.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="174" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMWru8hsf9MKDnPHQNBbOnSFDhn__ikW7hKaiPaSmHg3DQXfIC997GZq0itkY4XRUC7GdB5-xgfxnap4KRI2k6cyfHxE7qZHwgL3zIXL4mHyZnpGTBjwIOtx25SqQ0mtgWkWGHmPyhIQEl/s320/Three+Words+for+What+you+Do.jpg" width="320" /></a></div>
A <a href="http://www.linkedin.com/groups/Are-you-up-challenge-Use-37987.S.39983135?qid=308413c0-03ec-4185-8782-734836c826b1&trk=group_most_popular-0-b-ttl&goback=%2Egmp_37987">recent popular thread</a> on the <a href="http://www.linkedin.com/groups?home=&gid=37987&trk=anet_ug_hm">Lean Six Sigma</a> LinkedIn group triggered over a thousand responses. So I took a snapshot on Wednesday July 27th (New Zealand time) and created a <a href="http://www.wordle.net/">word cloud</a>, to see what we were all saying.<br />
<br />
By the looks of it, most of us Improve, quite a few of us Make, Learn, Deliver, Create, Analyze, Lead, Drive, etc.<br />
<br />
Enjoy!Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-50026053408099874392011-07-11T19:26:00.000-07:002011-07-11T19:30:17.666-07:00Entertain me!...As Agile Coaches, we often have to find fun ways of inspiring our Teams to learn and gain fresh insights so they may collaborate better.<br />
<br />
<span id="goog_184491176"></span><a href="http://bit.ly/MarshmallowChallenge">The Mashmallow Challenge</a><span id="goog_184491177"></span> is a very instructive design exercise that encourages teams to <span class="style_1">experience </span><i>simple</i> and profound lessons in collaboration, innovation and creativity. The TED video is well worth watching, it's virtually guaranteed to amuse you.<br />
<br />
<a href="http://bit.ly/TastyVision">TastyCupcakes.org</a> is another brilliant source of inspiration for various games, including quite a few <a href="http://bit.ly/TastyAgileGames">designed for Agile Teams</a>.Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-11841865880980598212011-07-11T14:21:00.000-07:002011-07-11T14:21:33.015-07:00Great Teams are Grown, not HiredRoy Osherove discusses <a href="http://bit.ly/CustomizeTeamLeadership">three maturity stages</a> of a team and adjusting leadership accordingly, along with techniques meant to bring craftsmanship and maturity in a software development team.<br />
<br />
Roy argues that Great Teams must be grown - they cannot be hired in whole. Teams must learn how to become great at their work through practice and intense collaboration (just as military units become better by drilling and fighting together).<br />
<br />
To grow Teams more effectively, leaders must tailor their leadership approach to the development stage or characteristics of the Team.Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-74869929944940016952011-06-29T22:56:00.000-07:002012-09-19T23:26:12.774-07:00The Gemba Walk with Jim WomackJim Womack just gave an excellent <a href="http://bit.ly/GembaWalkWebinar">The Gemba Walk</a> webinar (there's also a follow-up <a href="http://www.lean.org/common/display/?o=1860" target="_blank" title="Gemba Walk follow-up session">Q&A session to watch</a>), under the auspices of the <a href="http://www.lean.org/">Lean Enterprise Institute</a>. The core message is that the <a href="http://bit.ly/GembaWalks">Gemba Walk</a> can be used as a mechanism to give context for horizontal conversations that lead to improved flow. An excellent practice for all leaders!Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-54118858339792414852011-06-28T14:35:00.000-07:002011-06-28T14:36:21.798-07:00What's this Kanban thing, anyway?<p><a href="https://secure.wikimedia.org/wikipedia/en/wiki/Kanban">Kanban</a> is a simple way to visualize and control work (or things-to-do in general), limiting the amount of work-in-process in order to achieve good flow.</p><p>For details on how Kanban may be applied at different scales, please see or listen to:</p><ul><li><a href="http://www.personalkanban.com/pk/personal-kanban-101/">Personal Kanban</a> and <a href="http://business901.com/blog1/pk-flow-what-is-it-and-why-use-it/">PK Flow: what is it and why use it?</a> - applying Kanban at an individual level</li>
<li><a href="http://business901.podbean.com/2011/03/16/becoming-an-agile-family-thru-kanban/">Becoming an Agile Family thru Kanban</a> - applying Kanban at a family and Team level</li>
<li><a href="http://business901.podbean.com/2011/02/21/yeret-on-agile-and-kanban/">Agile and Kanban</a> - applying Kanban in Agile Teams </li>
</ul>Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-91155711353237994392011-06-21T21:48:00.000-07:002011-06-21T22:08:09.013-07:00Start with WhySee the <a href="http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html">Simon Sinek: How great leaders inspire action</a> TED talk for an interesting view on modern leadership. Simon argues that the leading companies answer the question Why? before they attempt to tackle the How? and the What?. By presenting a message in the order Why?, How?, What?, leaders can forge an emotional connection with their people and clients. <a href="http://www.rallydev.com/agileblog/">Jean Tabaka</a> just hosted a nice <a href="http://www.meetup.com/AgileWelly/events/17369917/">session in Wellington</a> following this very concept, applied to the use of <a href="http://agilemanifesto.org/">Agile methods</a>.<br />
<br />
This is not to be construed as being in conflict with <span id="LabelArticleText"><a href="http://inspiration4agilists.blogspot.com/2011/06/going-to-gemba-for-agilists.html">John Shook's advice</a> about the order of asking questions when doing a <a href="http://www.amazon.com/Gemba-Walks-ebook/dp/B004OYTDM4">Gemba walk</a>: "First ask <u>what</u>, then <u>why</u>, then <u>what if</u> ... and, finally, <u>why not</u>." Notice that this order checks for the standard work that should be the What?, then verifies that the Why? is understood, and then explores improvement opportunities.</span><br />
<br />
<span id="LabelArticleText">Both views are harmonious. A healthy value stream or network needs a clear Why? It drives the value being created for clients, and guides the improvement efforts of the workers, for both work products (What?) and work processes (How?).</span>Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0tag:blogger.com,1999:blog-5116174555032075277.post-6056184608034604992011-06-21T21:36:00.000-07:002011-06-26T21:11:14.852-07:00Going to the Gemba for AgilistsJohn Shook's latest e-letter, <a href="http://www.lean.org/common/display/?o=1843">How to Go to the Gemba: Go See, Ask Why, Show Respect</a> covers four main perspectives from which people generally observe work when going to the Gemba:<br />
<ol><li>Solution View - hunting for opportunities to use Lean tools. Tempting but risky - since it implies a hazardous rush to conclusions - potentially disruptive for continuous improvement if used on its own. </li>
<li>Waste View - keeping an eye out for <a href="http://www.processexcellencenetwork.com/methodologies-statistical-analysis-and-tools/columns/8-wastes-of-lean-manufacturing-in-a-services-conte/">wastes of various kinds</a>. Useful, and should be handled carefully so as not to pursue local optimization to the detriment of global outcomes.</li>
<li>Problem View - confirming and inquiring into impediments. Handy, and may take many shapes - its weakness (and opportunity) lies in the fact that it lacks an in-built structure. Various problem-solving approaches can be devised to suit the team and organization's context.</li>
<li>Kaizen View - seeking patterns, forms, routines. By engaging the people doing the value-adding work into a structured problem-solving pattern, this is the strongest choice.</li>
</ol><br />
What does this mean for the business of software-intensive systems development? The ideas apply directly - no significant adjustment required.<br />
<br />
To achieve continuous improvement, we must start by respecting our engineers, encouraging and supporting them to create improvements to their work processes, in addition to creating and enhancing features for the systems they develop. We trust them to create intricate engineering constructs. Surely they're best placed to design the improvements to their work processes as well.<br />
<br />
We have a responsibility to develop ourselves and our colleagues into intense noticers and tenacious experimenters. We must challenge each other to create better systems that create products in addition to creating the great products themselves.Anonymoushttp://www.blogger.com/profile/13500699514800678133noreply@blogger.com0Paraparaumu, New Zealand-40.9142336 175.00838020000003-40.9589481 174.98140820000003 -40.869519100000005 175.03535220000003