tag:blogger.com,1999:blog-22157543838298869942024-03-27T16:53:04.418-07:00Alex YakymaUnknownnoreply@blogger.comBlogger38125tag:blogger.com,1999:blog-2215754383829886994.post-11213135532472273532020-08-15T16:31:00.001-07:002020-08-15T16:31:23.023-07:00New Book: Pursuing Enterprise Outcomes<p><span style="background-color: white; color: #444444; font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 14px;">Hello, Friends. My new book, PURSUING ENTERPRISE OUTCOMES: Maximizing Business Value and Improving Strategy for Organizations and Teams, is out and </span><a href="https://www.amazon.com/dp/0998162922" style="background-color: white; border: 0px; font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 14px; margin: 0px; outline: none; padding: 0px; text-decoration-line: none; vertical-align: baseline;"><span style="color: #3d85c6;">available for purchase</span></a><span style="background-color: white; color: #444444; font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 14px;"> via Amazon.</span></p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRjz_XC7INbQXeZDlLnFvJI0HmiUTi3PYpp8apYHQUNv7fdV9M6m2u4FXf1Ja5fVcE9lTCcFux2dLGnfqXp5R60NzyYL9BpdBV6wpTdfZwdtRcmQWAyx074uj6odEr43Mxm-S9QD_orQQ/s827/IMG_1080.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="827" data-original-width="500" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRjz_XC7INbQXeZDlLnFvJI0HmiUTi3PYpp8apYHQUNv7fdV9M6m2u4FXf1Ja5fVcE9lTCcFux2dLGnfqXp5R60NzyYL9BpdBV6wpTdfZwdtRcmQWAyx074uj6odEr43Mxm-S9QD_orQQ/s640/IMG_1080.png" /></a></div><span style="background-color: white; color: #444444; font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 14px;"><br /></span><p></p><p style="background-color: white; border: 0px; color: #444444; font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 14px; line-height: 1.71429; margin: 0px 0px 20px; padding: 0px; vertical-align: baseline;">Enjoy the read, and here’s a brief book description for you:</p><p style="background-color: white; border: 0px; color: #444444; font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 14px; line-height: 1.71429; margin: 0px 0px 20px; padding: 0px; vertical-align: baseline;"><em style="border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">Today’s enterprises are overwhelmed with complex tasks in marketing, business development, software engineering, IT infrastructure, talent management, and other critical areas. Yet a large number of those tasks fail to deliver desired outcomes, despite tremendous spend.</em></p><p style="background-color: white; border: 0px; color: #444444; font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size: 14px; line-height: 1.71429; margin: 0px 0px 20px; padding: 0px; vertical-align: baseline;"><em style="border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">A must-read for leaders at every level, Pursuing Enterprise Outcomes provides answers that will boost your ability to succeed with your challenging initiatives. You will learn how to identify organizational disconnects and complex bottlenecks that prevent you from succeeding with your mission; discover and progressively refine outcomes and the business value that they deliver; drive the emergence of a complex solution that will help achieve the outcomes; discover and develop leverage points that will offer you a strategic advantage. You will learn to see the opportunity for creating enterprise value where others can’t see it.</em></p>Unknownnoreply@blogger.com16tag:blogger.com,1999:blog-2215754383829886994.post-4898165719209663292018-07-31T09:29:00.001-07:002018-08-01T11:11:22.441-07:00New Paper on Matrix Equivalence <div dir="ltr" style="text-align: left;" trbidi="on">
Just finished this recently. Glad I was able to arrive at a solution that is also constructive and assumes existence of a normal form for matrices over a certain type of commutative local rings with 2-generated maximal ideal. Matrix equivalence, if solved for a class of rings, has impact on classification problems in other areas such as linear groups, finite group representations, finite-dimensional algebras and more.<br />
<br />
The paper is available at the following locations:<br />
<br />
<a href="https://osf.io/uz2sm/" target="_blank">OSF Website: Matrix Equivalence and Reduction to Normal Form over Commutative Local Rings with 2-generated Maximal Ideal.</a><br />
<br />
<a href="https://www.academia.edu/37152913/Matrix_Equivalence_and_Reduction_to_Normal_Form_over_Commutative_Local_Rings_with_2-generated_Maximal_Ideal" target="_blank">Academia.edu: Matrix Equivalence and Reduction to Normal Form over Commutative Local Rings with 2-generated Maximal Ideal.</a><br />
<br />
<a href="https://www.researchgate.net/publication/326752465_Matrix_Equivalence_and_Reduction_to_Normal_Form_over_Commutative_Local_Rings_with_2-generated_Maximal_Ideal" target="_blank">ResearchGate: Matrix Equivalence and Reduction to Normal Form over Commutative Local Rings with 2-generated Maximal Ideal. </a><br />
<br />
<br />
In both cases the full text is accessible.</div>
Unknownnoreply@blogger.com69tag:blogger.com,1999:blog-2215754383829886994.post-81886438099565426252017-11-20T11:09:00.005-08:002017-11-20T11:09:52.173-08:00Welcome to Org Mindset (Alex Yakyma)<div dir="ltr" style="text-align: left;" trbidi="on">
by Alex Yakyma.<br />
<br />
In January 2017 I launched a new company, Org Mindset (<a href="http://orgmindset.com/">http://orgmindset.com</a>). The mission behind Org Mindset is to help organizations grow the right mindset and culture for organizational learning, innovation and agility.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhV-G4ehs99uJJ-lbV0Gqh5RA6agpr0EH0OZfyvqAG1t_m1_HUmq1NVr_2g86wbcxMFuukSwXtIRVz3EyNdFo5BRRmvnmz-bspDz2feylthpWdTcC5cXi3Ce5OyN_bXnZyHaZwgHCPdhfg/s1600/OM+Logo+Hi-Res+Transparent.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="165" data-original-width="598" height="55" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhV-G4ehs99uJJ-lbV0Gqh5RA6agpr0EH0OZfyvqAG1t_m1_HUmq1NVr_2g86wbcxMFuukSwXtIRVz3EyNdFo5BRRmvnmz-bspDz2feylthpWdTcC5cXi3Ce5OyN_bXnZyHaZwgHCPdhfg/s200/OM+Logo+Hi-Res+Transparent.png" width="200" /></a></div>
<br />
<br />
If you are an organizational change agent or a leader who is looking to take the organization to the next level, you may be interested in taking one of our Org Mindset Lean-Agile Enterprise Coach classes in the US.<br />
<br />
Here you can find more information about the course: <a href="http://orgmindset.com/enterprise-lean-agile-coach-course/">http://orgmindset.com/enterprise-lean-agile-coach-course/</a><br />
<br />
...and the class schedule: <a href="http://orgmindset.com/course-schedule/">http://orgmindset.com/course-schedule/</a>.<br />
<br />
Good luck with your transformation.<br />
<br /></div>
Unknownnoreply@blogger.comtag:blogger.com,1999:blog-2215754383829886994.post-84764011678748625292014-09-09T09:12:00.001-07:002018-11-03T09:29:51.219-07:00New Ebook: Pacific Express<div dir="ltr" style="text-align: left;" trbidi="on">
Recently, after working literally day and night, I finished a short ebook - "Pacific Express" - a novella about adopting Lean and Agile at Scale, Systems Thinking and... courage that those change agents in the field demonstrate everyday in order to succeed with the magic of software engineering at large scale.<br />
<br />
Why magic? Well, it's not really <i>magic</i>, but it takes a whole different mindset to be able to break the bondage with the ways of working that were developed in the past but still prevail across the industry. It takes a whole different paradigm in thinking about software development process, as even those organizations that managed to adopt agility at the team level, have often nothing to operate with at the higher levels of the organization. But guess what - that is the level where most interesting things occur and we're about to explore it on a fictional example of an organization that grew too fast to sustain any decent level of productivity and starts stagnating in the core area of the business. This light read will guide us through the transformation processes they chose, their challenges and discoveries down that path, that may lead them to better performance in delivering value to the business.<br />
<br />
Oh, did I say "fictional"? Although the organization and all characters <i>are</i> fictional, we will be witnessing facts and situations that occurred in real life, in the organizations that the author worked with in the past.<br />
<br />
Enjoy!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://scaledagileframework.com/pacific-express/" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhp8kNF_jNXRZ-MjuzryerAtghyphenhyphenhGKD40HrsNtXESfOiZhLlw7lPIdJMENrViRQThvj2okok-QtWxNrZWCKs9iBIhHBvlCmKKxKJsidQD3etFycxwK3gn6ZkfRMyhuYFCd6WdD0xAnqCUU/s1600/Pacific+Express+Thumbnail.png" width="256" /></a></div>
</div>
Unknownnoreply@blogger.com109tag:blogger.com,1999:blog-2215754383829886994.post-7489607530350528512013-09-20T07:58:00.002-07:002013-09-20T07:58:54.008-07:00Why SAFe Has Hardening<div dir="ltr" style="text-align: left;" trbidi="on">
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]--><br />
<!--[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>X-NONE</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: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="false"
DefSemiHidden="false" DefQFormat="false" DefPriority="99"
LatentStyleCount="371">
<w:LsdException Locked="false" Priority="0" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 9"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="header"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footer"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index heading"/>
<w:LsdException Locked="false" Priority="35" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of figures"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope return"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="line number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="page number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of authorities"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="macro"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="toa heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 5"/>
<w:LsdException Locked="false" Priority="10" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Closing"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Signature"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="true"
UnhideWhenUsed="true" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Message Header"/>
<w:LsdException Locked="false" Priority="11" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Salutation"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Date"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Block Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Hyperlink"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="FollowedHyperlink"/>
<w:LsdException Locked="false" Priority="22" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Document Map"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Plain Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="E-mail Signature"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Top of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Bottom of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal (Web)"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Acronym"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Cite"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Code"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Definition"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Keyboard"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Preformatted"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Sample"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Typewriter"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Variable"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Table"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation subject"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="No List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Contemporary"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Elegant"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Professional"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Balloon Text"/>
<w:LsdException Locked="false" Priority="39" Name="Table Grid"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Theme"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" QFormat="true"
Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" QFormat="true"
Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" QFormat="true"
Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" QFormat="true"
Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" QFormat="true"
Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" QFormat="true"
Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" SemiHidden="true"
UnhideWhenUsed="true" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="TOC Heading"/>
<w:LsdException Locked="false" Priority="41" Name="Plain Table 1"/>
<w:LsdException Locked="false" Priority="42" Name="Plain Table 2"/>
<w:LsdException Locked="false" Priority="43" Name="Plain Table 3"/>
<w:LsdException Locked="false" Priority="44" Name="Plain Table 4"/>
<w:LsdException Locked="false" Priority="45" Name="Plain Table 5"/>
<w:LsdException Locked="false" Priority="40" Name="Grid Table Light"/>
<w:LsdException Locked="false" Priority="46" Name="Grid Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="Grid Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="Grid Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="46" Name="List Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="List Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="List Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 6"/>
</w:LatentStyles>
</xml><![endif]--><!--[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:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:8.0pt;
mso-para-margin-left:0in;
line-height:107%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
</style>
<![endif]-->
<br />
<div class="MsoPlainText">
<i style="mso-bidi-font-style: normal;"><span style="color: black; font-size: 14.0pt; mso-bidi-font-size: 10.5pt;">By Alex Yakyma.</span></i></div>
<div class="MsoPlainText">
<br /></div>
<div class="MsoPlainText">
We used to consider hardening effort as an extremely
controversial topic. It’s been discussed multiple times in the community, never
without emotions. At times the arguments can feel like full-fledged religious warfare.
In SAFe, hardening is one of the three components of the HIP Sprint that is
placed in the end of the PSI, and stands for Hardening, Innovation and Planning. </div>
<div class="MsoPlainText">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixmDrmNmBw8rK1iMtrlB_OCYvY42BtgeR0La-OFY55EBpuXwe4MCS_P7-0xwd619cMx6TwBtdumWMssoO2lvqSc2-_f3rctbub2MyyIhFchdUpKXs6aNpgz7PMdNjhUZrCZZ8V3TAtFzM/s1600/HIP+Sprint.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="97" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixmDrmNmBw8rK1iMtrlB_OCYvY42BtgeR0La-OFY55EBpuXwe4MCS_P7-0xwd619cMx6TwBtdumWMssoO2lvqSc2-_f3rctbub2MyyIhFchdUpKXs6aNpgz7PMdNjhUZrCZZ8V3TAtFzM/s320/HIP+Sprint.png" width="320" /></a></div>
<div class="MsoPlainText">
The term suggests that this sprint reserves capacity for PSI planning itself and
planning preparation, as well as placeholders for hackathons, <span style="mso-spacerun: yes;"> </span>research activities for the next PSI, and,
finally, the room for completing any work that was not covered during the
regular sprints. Now, take a deep breath and hold your arguments for a little
bit longer, as we are going on a journey that will help us understand the multiple
misconceptions and misinterpretations with respect to the hardening. <span style="mso-spacerun: yes;"> </span>If you bear with me through the rest of the
article, a lot of things will become obvious and totally logical.</div>
<div class="MsoPlainText">
<br /></div>
<div class="MsoPlainText">
The most “troublesome” aspect of hardening to many is
that hardening sounds overly waterfall’ish, representing an additional phase in
the process covering a bunch of aspects that weren’t tackled earlier. I will
surprise you with the answer to that - yes, indeed, hardening stands out as a
separate timeframe that is not inherently agile. And yet, hundreds of SAFe
consultants (SPCs) in the field and their numerous clients adopt hardening, a
knowingly non-agile construct. Why? For a number of reasons. </div>
<div class="MsoPlainText">
<br /></div>
<div class="MsoPlainText">
First, SAFe is adopted by a number of large Fortune 500
organizations that develop both software and hardware. It may indeed be hard to
do thorough testing of the navigation system on <span style="mso-spacerun: yes;"> </span>an actual vehicle or a new air conditioning
configuration system in a real building <i style="mso-bidi-font-style: normal;">in
every sprint</i>. In this case, we fully utilize Lean Thinking and the concept
of batch/lot size optimization and a balance between transaction cost (mainly
reflecting different levels and aspects of system integration and testing) AND
holding costs (which mostly is the growing complexity of un-validated increment
of software). And in many cases, the optimum batch size for concerns like
end-to-end testing on the target hardware environment turns out to be <i style="mso-bidi-font-style: normal;">more than two weeks</i>. </div>
<div class="MsoPlainText">
<br /></div>
<div class="MsoPlainText">
Second, somewhere in Narnia there lives a lonely agile
team consisting of seven dwarfs and a Scrum Master. They develop their own
product themselves. Most likely, they can move full steam ahead in a matter of
two week sprints that include all aspects of software engineering. Well, the usual
reality of software engineering at scale resembles more of Mordor, than Narnia.
It involves tens or even hundreds of teams, millions of lines of code, and brittle
product architecture that’s been around for 12 years already, because the first
version was written by the company’s CEO himself. Wouldn't it be nice if they
could cover all the steps in the value stream every two weeks? Yes! It would be
awesome. But can they really do that at this point? Even if we deal with pure
software (no hardware involved), <span style="mso-spacerun: yes;"> </span>many
aspects would absolutely disrupt sprinting. What SAFe strongly recommends is to
“choose the blue pill” and get back to reality, no matter how dark and ugly it
may seem. Hardening is very important, and absolutely needs to be called out
explicitly, otherwise there is absolutely no chance to reduce it or even get
rid of it in the future, even in the cases where removing it is feasible.
Taiichi Ohno was always emphasizing the importance of clear goal setting as no improvement
is possible otherwise. The goal can be even overly aggressive, according to
Ohno - <span style="mso-spacerun: yes;"> </span>that's how Toyota managed to
implement such extreme practices as SMED - but it needs to be <i style="mso-bidi-font-style: normal;">explicit</i> and aware of the current state.
That's why hardening matters. In many cases it's a temporary necessity that is absolutely
critical to purposeful, continuous improvement. This perspective of hardening
allows agile release trains to clearly separate definition of done (DoD) for
stories on one hand and from that for the features, on the other hand. The
whole matter of reducing or even fully eliminating hardening can then be
explicitly interpreted as a gradual process of bridging the gap between these
two DoDs. </div>
<div class="MsoPlainText">
<br /></div>
<div class="MsoPlainText">
Next, every once per PSI they have hardening
activities... Well, here comes the limitations of the visual representation of knowledge
and the overall desire to keep things simple as much as possible. Not always at
zero cost. We place hardening effort at the end of the PSI on the Big Picture,
and the initial suggestion would be to do exactly so in the beginning. But it
is not necessarily the end state. As program matures over time, its holding
cost and transaction cost curves change their shape. Normally, transaction cost
curve flattens (which is the evidence of improved program's efficiency in
integration, testing, tech writing, UAT, etc). As a result, the optimum batch
size may become smaller. In such cases, we strongly encourage programs to split
the hardening effort into more than one occurrence in the PSI. So, for instance,
they may have one hardening chunk as a second week of sprint three and a second
week of sprint 5, in a five-sprint PSI. Quite possibly, but not necessarily,
their next step after a couple of PSIs would be splitting it even further and
thus basically reach the point where hardening effort gets fully distributed
across every sprint in the PSI. In other words, story DoD becomes equivalent to
feature DoD. Overall, it is totally logical that different aspects of hardening
may take a different optimum batch size. So, for example, full system
integration could and should eventually be performed in every sprint (however
it can be a real stretch for most organizations in the beginning). Tech writing
and releasing to production – every two sprints, for instance. Full UAT and
training internal users – once per PSI. </div>
<div class="MsoPlainText">
<br /></div>
<div class="MsoPlainText">
The whole unnecessary, emotional load that is so often
associated with the word “hardening” fully disappears as soon as we adopt a systems
thinking view, of which Lean Thinking is a great example that we use throughout
the framework. As we stop being religious about agile and look at a broader
picture and a full value stream, things begin to gradually add up. Achieving
continuous flow of value at scale indeed requires additional constructs, like hardening
effort. It may not seem highly desirable to have one, but it reflects the
reality of many organizations and gives them a solid chance of substantially
improving their practices and techniques in the future. Also, as we learned, hardening
comprises a whole bunch of distinct aspects, of which some may be fully
embraced by agile teams as a regular sprint routine --some can be done more
frequently than once per PSI, and some may still require lower frequency. We
see hardening as important tool, a result of “systems thinking” rather than the
final goal itself. </div>
<div class="MsoNormal">
<br /></div>
</div>
Unknownnoreply@blogger.com154tag:blogger.com,1999:blog-2215754383829886994.post-46477097015654399002013-06-29T09:26:00.002-07:002013-06-29T09:27:52.103-07:00Agile Engineering Assessment at Scale<div dir="ltr" style="text-align: left;" trbidi="on">
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]--><br />
<!--[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>X-NONE</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: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="false"
DefSemiHidden="false" DefQFormat="false" DefPriority="99"
LatentStyleCount="371">
<w:LsdException Locked="false" Priority="0" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 9"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="header"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footer"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index heading"/>
<w:LsdException Locked="false" Priority="35" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of figures"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope return"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="line number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="page number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of authorities"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="macro"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="toa heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 5"/>
<w:LsdException Locked="false" Priority="10" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Closing"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Signature"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="true"
UnhideWhenUsed="true" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Message Header"/>
<w:LsdException Locked="false" Priority="11" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Salutation"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Date"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Block Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Hyperlink"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="FollowedHyperlink"/>
<w:LsdException Locked="false" Priority="22" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Document Map"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Plain Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="E-mail Signature"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Top of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Bottom of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal (Web)"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Acronym"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Cite"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Code"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Definition"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Keyboard"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Preformatted"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Sample"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Typewriter"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Variable"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Table"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation subject"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="No List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Contemporary"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Elegant"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Professional"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Balloon Text"/>
<w:LsdException Locked="false" Priority="39" Name="Table Grid"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Theme"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" QFormat="true"
Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" QFormat="true"
Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" QFormat="true"
Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" QFormat="true"
Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" QFormat="true"
Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" QFormat="true"
Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" SemiHidden="true"
UnhideWhenUsed="true" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="TOC Heading"/>
<w:LsdException Locked="false" Priority="41" Name="Plain Table 1"/>
<w:LsdException Locked="false" Priority="42" Name="Plain Table 2"/>
<w:LsdException Locked="false" Priority="43" Name="Plain Table 3"/>
<w:LsdException Locked="false" Priority="44" Name="Plain Table 4"/>
<w:LsdException Locked="false" Priority="45" Name="Plain Table 5"/>
<w:LsdException Locked="false" Priority="40" Name="Grid Table Light"/>
<w:LsdException Locked="false" Priority="46" Name="Grid Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="Grid Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="Grid Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="46" Name="List Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="List Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="List Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 6"/>
</w:LatentStyles>
</xml><![endif]--><!--[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:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:8.0pt;
mso-para-margin-left:0in;
line-height:107%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
</style>
<![endif]-->
<br />
<div class="MsoNormal">
<i>By Alex Yakyma. </i> </div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJTpH2K5M9pjIOBbg7YDuxMdr0pxX2_XCIEf2khmyFxgqgzMeEVbv5owd8fyk1EaVFh8K_zHbYMyZ3kmX5CDgEXVD05dqUHrN2vl2mLu5mumShSwvGi6bLmN-Yutw0P3DBTGm8SJ7OZHI/s676/Agile+Engineering+Assessment+at+Scale.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="129" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJTpH2K5M9pjIOBbg7YDuxMdr0pxX2_XCIEf2khmyFxgqgzMeEVbv5owd8fyk1EaVFh8K_zHbYMyZ3kmX5CDgEXVD05dqUHrN2vl2mLu5mumShSwvGi6bLmN-Yutw0P3DBTGm8SJ7OZHI/s200/Agile+Engineering+Assessment+at+Scale.png" width="200" /></a></div>
<div class="MsoNormal">
I had the intention of putting together a consistent
assessment of such kind for quite a while. Some topics were part of other
assessments, others were just assumed.<span style="mso-spacerun: yes;">
</span>Recently though, as I finished working on DevOps article for SAFe, I
have decided to finalize this assessment as well. Especially because I could
then add a good fresh summary related to the deployment process. So, here it is...</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span style="font-size: small;"><a href="https://sites.google.com/site/alexyakyma/Agile%20Engineering%20Assessment%20at%20Scale%20%28v1_0%29.xlsx?attredirects=0&d=1" target="_blank">Download Agile Engineering Assessment at Scale</a></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The purpose is to assess program capabilities in the
following key engineering/technical areas: <i style="mso-bidi-font-style: normal;">Architecture/Design</i>,
<i style="mso-bidi-font-style: normal;">System Integration</i>, <i style="mso-bidi-font-style: normal;">Acceptance Testing</i>, <i style="mso-bidi-font-style: normal;">NFR Testing</i> and <i style="mso-bidi-font-style: normal;">Deployment</i>.<span style="mso-spacerun: yes;"> </span></div>
<div class="MsoNormal">
It makes sense to use it actually in both program and team
environments. Programs need to understand where they are with respect to
engineering concerns. But teams actually employ the practices and keep the work
flowing, so they need to carefully track where they are as well. It is also
useful to look at this assessment as a set of improvement objectives and
incrementally work towards accomplishing them.<span style="mso-spacerun: yes;">
</span></div>
</div>
Unknownnoreply@blogger.com49tag:blogger.com,1999:blog-2215754383829886994.post-17580156989952360532013-06-20T05:28:00.002-07:002013-06-29T09:33:58.424-07:00Improving Enterprise Performance with Value Threads<div dir="ltr" style="text-align: left;" trbidi="on">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<br />
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;"><i style="mso-bidi-font-style: normal;">By Alex Yakyma</i></b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Value Stream is one of the key concepts of Lean|Agile
development at scale. A value stream is a set of steps, starting from the
definition of the idea of a new functionality all the way through to the implementation
and deployment to satisfy user and business goals. Another aspect of a value
stream is people – the teams that contribute to the end user value. Thus, a
value stream is most often the set of steps (and a number of teams) required to
develop or maintain a software solution. More often than not, value streams consist
of <i style="mso-bidi-font-style: normal;">multiple</i> collaborating agile teams.
</div>
<div class="MsoNormal">
Let’s start by summing up the key reasons why we care at all
about value streams and value stream analysis. As we know from experience, a value
stream perspective allows an organization to effectively focus on:</div>
<div class="MsoListParagraphCxSpFirst" style="margin-left: 40.85pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">1.<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Improving the process as a whole, thereby
genuinely improving it.</div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 40.85pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">2.<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Continuously improving the average cycle time.</div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 40.85pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">3.<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Enhancing quality by building it into every
process step.</div>
<div class="MsoListParagraphCxSpLast" style="margin-left: 40.85pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">4.<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Actively creating, sharing and evolving relevant
knowledge. </div>
<div class="MsoNormal">
These are all meaningful goals that allow an organization to
considerably enhance its operational performance. Surprisingly enough, however,
value streams alone don’t let you improve these <i style="mso-bidi-font-style: normal;">at scale </i>and here’s why. </div>
<div class="MsoNormal">
Let’s consider an agile program that works on a specific
value stream, consisting of seven agile teams. The result of their work is an
end-to-end solution – a large software system for which the teams advance the
functionality and nonfunctional requirements, as required by the business. What
can we say about such a value stream? Just as for any value stream at scale –
not much. It consists of five process steps that repeat indefinitely over
feature sets:</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVrmoXwXoN-Cf9nb4JsCBxagKsNuz5_ar_jnx6xyzadadljn0XAuJ0hlFfvRpiu8NpctjCBuiWQWGgJyAXm3E3l-Z7QSJ8J3B8c8eDihIsu6tRgIdsIEezYFQQHSMJURSgRivHtV1Ljp8/s1600/Figure+1.+Value+Stream+Perspective.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="347" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVrmoXwXoN-Cf9nb4JsCBxagKsNuz5_ar_jnx6xyzadadljn0XAuJ0hlFfvRpiu8NpctjCBuiWQWGgJyAXm3E3l-Z7QSJ8J3B8c8eDihIsu6tRgIdsIEezYFQQHSMJURSgRivHtV1Ljp8/s640/Figure+1.+Value+Stream+Perspective.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure <span style="mso-no-proof: yes;">1</span>. Value
stream perspective</td></tr>
</tbody></table>
<div class="MsoNormal" style="page-break-after: avoid;">
<span style="mso-no-proof: yes;"><br /></span></div>
<div class="MsoCaption">
</div>
<div class="MsoNormal">
Figure 1 doesn’t say very much, primarily because we have tried
to outline process commonalities for all seven teams and those are pretty
generic and therefore, not overly useful. The process is much more complex <i style="mso-bidi-font-style: normal;">inside</i> and requires much more subtle
treatment. In fact, such a rough perspective (as seen in figure 1) can be
largely harmful to the program for the following reasons: </div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Applying Work-In-Process (WIP) limits on the
entire program in a “wholesale” manner may unbalance the flow instead of
stabilizing it</div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>Some teams may have their unique, context-dependent
steps in the process which substantially impact their performance but are not
visible as a part of the value stream.</div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Symbol; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span>The specific ways in which the teams impact one
another in the program usually has a dramatic impact on the overall program
performance and requires special treatment. </div>
<div class="MsoNormal">
In order to explore the internal structure of a value stream
at scale, we need to take a microscopic view. What seems to be a flat surface
to the naked eye may turn out to be an entire new world with its own ridges,
peaks, plateaus and trenches. We will start our journey by defining the ground
rules. We will be zooming in for a closer look at a value stream, but only insofar
as we don’t lose the features (chunks of an end-to-end user value) from sight. </div>
<div class="MsoNormal">
The reality of most programs suggests that the teams
collaboratively create user value and that the patterns of such collaboration
are context dependent (See figure 2). <span style="mso-spacerun: yes;"> </span></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibHydSjTUqPfndISfQu1-tuDRgz6FNQVWEqqMZLYwcNaTHKRvXf3u3SYTn3rofj5FJzR4XQNCVGnrzUkT6hsqQkMBvzt3e9Eyoxe_yGPGf5PaY3m3s75wr6RKM6qS3mhGZFJ1XbYW11wA/s1600/Figure+2.+Value+Threads.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="338" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibHydSjTUqPfndISfQu1-tuDRgz6FNQVWEqqMZLYwcNaTHKRvXf3u3SYTn3rofj5FJzR4XQNCVGnrzUkT6hsqQkMBvzt3e9Eyoxe_yGPGf5PaY3m3s75wr6RKM6qS3mhGZFJ1XbYW11wA/s640/Figure+2.+Value+Threads.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure <span style="mso-no-proof: yes;">2</span>. A value
stream consisting of a number of value threads</td></tr>
</tbody></table>
<div class="MsoNormal" style="page-break-after: avoid;">
<span style="mso-no-proof: yes;"></span>So, features 1 and 2 require three teams to work together,
feature 3 involves four teams, and feature 4 requires two teams’ input. The
teams that are connected with a same color link form up a <i style="mso-bidi-font-style: normal;">Value Thread</i> – <i style="mso-bidi-font-style: normal;">a subset of a
program teams that are able to deliver a specific feature or a feature set</i>.
Value threads can be as small as one team (in case of feature teams, for
example) or can be as big as the entire program (often, when it consists of component
teams).
</div>
<div class="MsoNormal">
Most interactions occur within the value threads. Thus, in
order to be able to improve the process at scale, we redirect our focus from an
overly abstract value stream to significantly more detailed value threads. We
would like to see value being created in a fast, synchronous manner within each
value thread, as Figure 3 suggests:</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgG1HzicYjEEpYMEDCoCAgg7Sk_QnaLVrQ1e26p9sUi3956XC-i0aLh-szdqvjxAqRr3dnmdCBrbZzahRS2y2mvlAKiuyRl8YlRI6Vt5yYTvjMKOSlG7ft3VVAQqCskqnh2OAFKyaG9XN8/s1600/Figure+3.+Synchronous+implementation+of+a+feature.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="318" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgG1HzicYjEEpYMEDCoCAgg7Sk_QnaLVrQ1e26p9sUi3956XC-i0aLh-szdqvjxAqRr3dnmdCBrbZzahRS2y2mvlAKiuyRl8YlRI6Vt5yYTvjMKOSlG7ft3VVAQqCskqnh2OAFKyaG9XN8/s320/Figure+3.+Synchronous+implementation+of+a+feature.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure <span style="mso-no-proof: yes;">3</span>.
Synchronous work on a feature within a value thread</td></tr>
</tbody></table>
<div class="MsoNormal" style="page-break-after: avoid;">
<span style="mso-no-proof: yes;"></span>Now it is obvious that the following Lean|Agile techniques
make a lot of sense primarily <i style="mso-bidi-font-style: normal;">within a
value thread</i>:
</div>
<ul>
<li><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;"></span></span>Applying WIP limits.</li>
<li><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;"><span style="font: 7.0pt "Times New Roman";"></span></span></span>Backlog grooming, planning, tracking progress
and demonstrating the results.</li>
<li><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;"><span style="font: 7.0pt "Times New Roman";"></span></span></span>Measuring the feature cycle time and cumulative
flow.</li>
<li><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;"><span style="font: 7.0pt "Times New Roman";"></span></span></span>Creating and sharing knowledge. </li>
<li><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;"><span style="font: 7.0pt "Times New Roman";"></span></span></span>Advancing in test automation, and collective
code ownership</li>
<li><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;"><span style="font: 7.0pt "Times New Roman";"></span></span></span>Collectively retrospecting and improving the
process.</li>
</ul>
<div class="MsoNormal">
It is unarguably better to move towards feature oriented
agile teams, where a team actually is a full value thread. In reality, however,
this is far from always possible or may require a huge amount of time and
effort. Uncontrollably bloated technology stacks, narrow specialization,
geographical distribution, and organizational impediments – these can all
present serious hurdles when moving towards feature teams. However, once value
threads are made visible within an organization, it may considerably increase
managerial support and willingness to make changes as they start to see the
real source of existing inefficiencies. </div>
<div class="MsoNormal">
Start by asking yourself several questions. What are the
smaller constructs (value threads) within my program that are responsible for
end-to-end value delivery? Are the teams aware of their peer teams, with whom they
have to actively collaborate? How many sprints does it take to deliver an
end-to-end chunk of functionality within such a thread? Do teams
collaboratively plan and track progress within the thread? Now that you know
what your target object is – you can help your organization improve. It will be
a tough journey, but the prize is also worth it. </div>
<div class="MsoNormal">
In future posts, we will explore different important aspects
of the value threads and offer further practical advice in terms of
applications.<span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </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>false</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: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="false"
DefSemiHidden="false" DefQFormat="false" DefPriority="99"
LatentStyleCount="371">
<w:LsdException Locked="false" Priority="0" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 9"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="header"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footer"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index heading"/>
<w:LsdException Locked="false" Priority="35" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of figures"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope return"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="line number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="page number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of authorities"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="macro"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="toa heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 5"/>
<w:LsdException Locked="false" Priority="10" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Closing"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Signature"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="true"
UnhideWhenUsed="true" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Message Header"/>
<w:LsdException Locked="false" Priority="11" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Salutation"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Date"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Block Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Hyperlink"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="FollowedHyperlink"/>
<w:LsdException Locked="false" Priority="22" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Document Map"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Plain Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="E-mail Signature"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Top of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Bottom of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal (Web)"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Acronym"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Cite"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Code"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Definition"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Keyboard"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Preformatted"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Sample"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Typewriter"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Variable"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Table"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation subject"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="No List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Contemporary"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Elegant"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Professional"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Balloon Text"/>
<w:LsdException Locked="false" Priority="39" Name="Table Grid"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Theme"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" QFormat="true"
Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" QFormat="true"
Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" QFormat="true"
Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" QFormat="true"
Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" QFormat="true"
Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" QFormat="true"
Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" SemiHidden="true"
UnhideWhenUsed="true" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="TOC Heading"/>
<w:LsdException Locked="false" Priority="41" Name="Plain Table 1"/>
<w:LsdException Locked="false" Priority="42" Name="Plain Table 2"/>
<w:LsdException Locked="false" Priority="43" Name="Plain Table 3"/>
<w:LsdException Locked="false" Priority="44" Name="Plain Table 4"/>
<w:LsdException Locked="false" Priority="45" Name="Plain Table 5"/>
<w:LsdException Locked="false" Priority="40" Name="Grid Table Light"/>
<w:LsdException Locked="false" Priority="46" Name="Grid Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="Grid Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="Grid Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="46" Name="List Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="List Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="List Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 6"/>
</w:LatentStyles>
</xml><![endif]--><!--[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:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:8.0pt;
mso-para-margin-left:0in;
line-height:107%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
</style>
<![endif]--></div>
Unknownnoreply@blogger.com110tag:blogger.com,1999:blog-2215754383829886994.post-69943845467351403282013-03-18T12:16:00.000-07:002013-03-18T12:16:37.295-07:00Legacy Mindsets in Test Automation<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal">
<i><span lang="EN-US">By Alex Yakyma. </span></i></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFaqe7XbtkGoO3l1eyTPjdC9tk8wrRlUMPFwQ3wjPKE3qMyw3mB2AHPyjS3DgXi4OgjBDMKBEov5JjI5hC3I6UDPL58UEem5XGtkEBaGb-d-Yvm4EJvKURoRi5v3bR6n4qOGZtWp95NHc/s1600/Legacy+Mindsets+in+Software+Testing.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFaqe7XbtkGoO3l1eyTPjdC9tk8wrRlUMPFwQ3wjPKE3qMyw3mB2AHPyjS3DgXi4OgjBDMKBEov5JjI5hC3I6UDPL58UEem5XGtkEBaGb-d-Yvm4EJvKURoRi5v3bR6n4qOGZtWp95NHc/s320/Legacy+Mindsets+in+Software+Testing.png" width="320" /></a></div>
<div class="MsoNormal">
<span lang="EN-US"> In software development even these days test
automation fails much more often than it succeeds. There are multiple reasons
for this, but traditional thinking has a very strong impact in this regard – I’m
referring to various legacy mindsets, originating from decades of the “divide
and manage by function” pseudo-scientific set of beliefs that don’t withstand
any practical validation, but unfortunately thousands of minds of otherwise
smart people still adhere to such thinking. After one or two failed attempts, many
organizations do not automate at all. Others do, but their process is not very
effective even though automated test engineers manage to stay surprisingly
busy. We will explore these false beliefs as well as working alternatives that
evolved as a result of applying Lean thinking and Agile testing approaches
inspired by Extreme Programming and its further evolution into areas such as
BDD and ATDD. We will also be primarily concerned with principles that work at
scale. </span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-US">Let’s consider these areas of concerns in
more detail: </span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span lang="EN-US">Legacy Mindset #1: Automation should primarily
be done by a separate automation team. </span></b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-US">This is one of the most severe issues with
testing <i>per se</i>, creating endless list of problems, the most challenging of
which are:</span></div>
<div class="MsoListParagraphCxSpFirst" style="text-indent: -.25in;">
<span lang="EN-US">-<span style="font: 7.0pt "Times New Roman";">
</span></span><span lang="EN-US">Developers never use these tests on a daily
basis to prevent the propagation of un-validated code into the main code branch
in the first place. This basically makes the feedback loop, which should be as
short as possible, just the opposite, necessitating significant rework later
when the tests are run. A lot of money gets wasted this way. </span></div>
<div class="MsoListParagraphCxSpMiddle" style="text-indent: -.25in;">
<span lang="EN-US">-<span style="font: 7.0pt "Times New Roman";">
</span></span><span lang="EN-US">Developers and architects never bother with system
testability and grow system design under completely different set of forces,
making test automation an incredibly tough work. </span></div>
<div class="MsoListParagraphCxSpLast" style="text-indent: -.25in;">
<span lang="EN-US">-<span style="font: 7.0pt "Times New Roman";">
</span></span><span lang="EN-US">Such tests never keep up with the latest
requirements as developers (and possibly manual testers) move faster and are
more flexible in responding to new requests and clarifications from the product
owner and stakeholders. </span></div>
<div class="MsoListParagraphCxSpLast" style="text-indent: -.25in;">
<br /></div>
<div class="MsoNormal">
<span lang="EN-US">Agile team has to cover as many steps in
the target value stream as possible. And even though something may be left outside
their purview within iteration, this cannot be automated testing as it is indeed
one of the key agile practices. If you cannot automate the tests for your own
code, you are not a truly agile team. However, automation must be taken very
seriously; many teams would be surprised at how much simpler automation actually
is than they might have initially thought. </span></div>
<div class="MsoNormal">
<span lang="EN-US">It is also important to note that the </span><a href="http://scaledagileframework.com/system-team/"><span lang="EN-US">System Team</span></a><span lang="EN-US"> can perform certain part of test automation within the program even
in a very effective agile environment. However, if this is the only team creating
automated tests and if the rest of the agile teams in the program do not
automate, this just introduces equally poor waterfall-like behaviors with all the
corresponding disadvantages, leading to a slowly moving, unreliable process. A
good scenario entails just the opposite – when the system team actively
collaborates with agile teams and aims to continuously give away more and more
automation work to them while the system team themselves looks for the next
systemic bottleneck for the program to cope with. This is part of the self-organization
paradigm for the </span><a href="http://scaledagileframework.com/agile-release-train/"><span lang="EN-US">Agile
Release Train</span></a><span lang="EN-US"> as a team of teams capable of
producing “the best architectures, requirements, and designs” at scale. </span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span lang="EN-US">Legacy Mindset #2: Automation is
primarily done by specially trained automation engineers, using expensive
automation tools. </span></b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-US">Companies waste hundreds of thousands of dollars
on tools, and spend their time and effort hiring external people who can man
them, essentially creating a hard dependency and largely ineffective process. These
days, one can find very decent free tools with wide user communities, which
are:</span></div>
<div class="MsoListParagraphCxSpFirst" style="text-indent: -.25in;">
<span lang="EN-US">1.<span style="font: 7.0pt "Times New Roman";"> </span></span><span lang="EN-US">Easier to use.</span></div>
<div class="MsoListParagraphCxSpMiddle" style="text-indent: -.25in;">
<span lang="EN-US">2.<span style="font: 7.0pt "Times New Roman";">
</span></span><span lang="EN-US">Developed by agilists for agilists, so it’s no
wonder it works for agile teams.</span></div>
<div class="MsoListParagraphCxSpLast" style="text-indent: -.25in;">
<span lang="EN-US">3.<span style="font: 7.0pt "Times New Roman";"> </span></span><span lang="EN-US">Can be used by virtually anybody on the team.</span></div>
<div class="MsoNormal">
<span lang="EN-US">Most unit testing frameworks are free for
most platforms. Most BDD/ATDD tools are also free and work great for acceptance
testing. Moreover, these tools are typically open source, allowing for customization
whenever required. Using such tools helps to avoid multiple different
bottlenecks that expensive commercial tools and employees with rare skills tend
to introduce in the organization. </span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span lang="EN-US">Legacy Mindset #3: Testing via the User
Interface. </span></b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-US">Do not test via the UI whenever it may be
avoided. Always first look for alternatives and be ready to invest in those –
it will tremendously pay off over time. Tests that operate via the UI are
brittle and laborious both in terms of their creation and maintenance. Once again,
a lot of money wasted. Even with such useful tools like Robot Framework or
Cucumber (that leverage the re-use of “bindings”), their application to testing
via the UI remains very fragile. Apart from very rare cases, following is the
right thing:</span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<i><span lang="EN-US">Test via the programming API itself or
simpler protocols such as XML or REST services, flat files, etc., but not UI. </span></i></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-US">To enable this, the system under test
should allow for testability. In very many cases, though, the system is not
designed so. In this case it is time to revise key system design assumptions
and to start gradually breaking hard dependencies in the overloaded UI and thus
start moving towards the separation of concerns. <i>System testability is one
of the key nonfunctional requirements</i> (just like performance or scalability
or any other “-ility”) and should be considered very seriously as it ultimately
enables everything else. </span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span lang="EN-US">Legacy Mindset #4: Manual testers cannot
write automated tests. </span></b></div>
<div class="MsoNormal">
<span lang="EN-US">In the post about </span><a href="http://www.yakyma.com/2013/02/atdd-and-effective-exploratory-testing.html"><span lang="EN-US">ATDD and Exploratory Testing</span></a><span lang="EN-US">, I describe
a scenario that enables manual test engineers to effectively create new
automated tests from existing step definitions that have been created by others.
While this process still requires little attention from developers (or
automated test engineers), at some point, it allows manual testers to do a lot
on their own without interrupting anybody else. </span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span lang="EN-US">Legacy Mindset #5: It is OK to write
automated tests later. </span></b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-US">No it is not. “Building quality in” is one
of the key Lean themes. It is too late and fairly pointless to write tests
against the existing functionality. It requires too much effort to achieve an
effect that is too marginal. </span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span lang="EN-US">Legacy Mindset #6: It is OK if only
technical people are able to understand automated tests. </span></b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-US">The disruptive success of new agile tools
and ATDD techniques involving agile teams and their stakeholders in
collaboratively defining system requirements in the form of executable examples
(read: tests) is proving to be just the opposite. Tests can be written in plain
English (or another natural language) and yet execute against the system and indicate
what is passing and what is not. This type of tests becomes a kind of a
cornerstone for conversation between business people, developers and testers. Nothing
better sets the shared context. Tests in a natural language save significant effort
and money by driving away ambiguities in requirements and their implementation.
Gherkin-based tools (such as Cucumber, SpecFlow, JBehave, Lattuce, Behat, RSpec
– for whole variety of platforms) that support business readable tests have already
been widely adopted and are gaining more and more users as we speak. Other
tools like Robot Framework or Fitnesse are also solving this problem from a
slightly different angle. </span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="EN-US">---------------------------- </span></div>
<div class="MsoNormal">
<i><span lang="EN-US">By taking an economic view and applying
systems thinking, this allows organizations to critically look at their current
practices and improve the quality and speed of the process. Automated testing
is much more tightly connected with requirements definition, is primarily a
collaborative practice used by agile teams, and relies heavily on paying continuous
attention to proper design that would support testability. </span></i></div>
</div>
Unknownnoreply@blogger.com184tag:blogger.com,1999:blog-2215754383829886994.post-36593301938163834242013-03-05T11:24:00.001-08:002013-03-05T11:25:11.605-08:00Project Managers in Agile Enterprise<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
<i>By Alex Yakyma.</i><br />
<br />
Project managers exist in many organizations. With agile adoption throughout the industry, it turns out that most of the work tactics of the inglorious past, such as top-to-bottom planning, tracking, big up-front requirements and design, are no longer competitive. Methodologies like Scrum had clearly put project managers out of the scene, calling them "chickens" and claiming that they are not committed. Many authors explicitly call them the "overhead" in an agile organization. Given the overwhelmingly growing need for methods for scaling agility within an enterprise, the following question is becoming more and more important:
<br />
<br />
<b>Where do project managers fit in the agile enterprise?
</b><br />
<br />
To be completely clear about our objective here, we are not trying to legitimize the role of the project manager or his equivalent. Nor do we aim to build a mapping of responsibilities or see how we could sneak traditional methods into the agile world just to ensure that a certain number of jobs remain secure. In fact, there are hordes of project managers who, for months, if not for years, have not been able to figure out how they fit into this new Lean | Agile paradigm. For the most part, these people should be given a chance to succeed elsewhere – agile teams only need strong and courageous enablers who are capable of challenging existing organizational rules and procedures in order to enable a fast sustainable value flow. But the question remains – if they (project managers) can't even enable themselves, then who needs them?
<br />
<br />
That being said, there are people who hold this position and are effective leaders, who, instead of impeding agility, end up being essentially helpful. I personally know such people – they embrace Lean thinking, paradigms of agile software engineering, and lead teams and programs to better alignment with business needs, a faster flow, and eventually assist the organization in its agile transformation at scale. Moreover, the actual reality of a large organization makes us think beyond the simplistic chicken and pig metaphor in order to realistically cope with external dependencies and overall organizational resistance to any change that could expose the dysfunctional aspects of its behavior. There is wide variety of areas where these people are able to help tremendously, and that is what I would like to explore in this article. But prior to starting our journey, it is necessary to indicate exactly <i>what</i> these people should <i>stop doing</i> once they embrace their new role, and that is... <i>managing people on the teams in the context of their daily engineering activities</i>. This has to unconditionally go away. Agile teams essentially estimate and plan their work, and they make most of tactical decisions on their own and do not require anyone to micromanage them.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmWLfVmyZ0fEJeYdk78YZjI44m6ff_Thse0PwBwVcFfUruJOisvySuKzpGDXj7AtafWfAtwNqrFiYIQfxtd42vEmh2sTlZXg1Mb8u3mJhduY0vFg1vjgb1xzCDAOEjzlgs20n4YWZNZlI/s1600/Project+Managers+in+Agile+Enterprise.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="476" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmWLfVmyZ0fEJeYdk78YZjI44m6ff_Thse0PwBwVcFfUruJOisvySuKzpGDXj7AtafWfAtwNqrFiYIQfxtd42vEmh2sTlZXg1Mb8u3mJhduY0vFg1vjgb1xzCDAOEjzlgs20n4YWZNZlI/s640/Project+Managers+in+Agile+Enterprise.png" width="640" /></a></div>
<br />
There must be a conceptual shift from a manager-centric model towards a team-member centric model, where the project manager strives to find a way to enable teams in all possible aspects, instead of becoming a bottleneck for their daily work, as well as encouraging team members’ learning process and continuous improvement. Below are the areas where project managers are indeed capable of helping. It takes much more skill, expertise and courage then creating another Gantt chart or time reporting process. But this real leadership becomes quickly visible due to the fast feedback loops in the Lean | Agile enterprise, and serves as an optimum strategy to make a meaning and impact on your organization. Here are those areas where they may benefit the organization:
<br />
<br />
<i>1. Foster organizational changes in bottleneck areas</i>. This is the toughest one that requires real courage to challenge what has been believed to be best practices (or at least necessary ones) within your organization for years and years. Teams extremely appreciate effective help in this regard, whether it is an overly heavyweight procedure of deployment, obtaining approvals for something, receiving admin/ops/production support, or such a useless thing as time reporting, etc. The people who created these procedures in the first place are most likely ignorant in terms of lean thinking or understanding the principles of flow. Thus, what they have created for repetitive use by agile teams not only could be, but rather actually <i>should</i> be challenged. Most project managers simply fail in this respect, as their role never actually requires taking a chance by changing the status quo within the organization. Now, not only have they fallen outside of their own comfort zone, but they also have to challenge the status quo of others. A very simple formula works here: no courage – no result.<br />
<br />
<i>2. Create an environment that fosters the right team behavior</i>. Work to eliminate individualistic performance review models. Instead, work to embrace team-centric improvement objectives, where individuals are left with a wide variety of options to manifest spontaneous situational leadership in different domains and thus, be evaluated "according to their contribution" to these team-centric objectives. Work hard with teams and communities of practice in terms of adopting collaborative agile practices such as side-by-side (and pair-) programming, specification by example, ATDD, and continuous integration. These are not just engineering techniques, but important cultural scenarios within and across teams. <br />
<br />
<i>3. Make key problems at scale visible and unambiguous to everyone</i>. This should be done so that they can actualize and collaboratively improve once the problem becomes apparent. Is the problem due to too much work-in-progress across multiple teams, excessive delays on the part of ops teams, or too much rework of overly detailed design specs, or it is due to something else? People in our industry are not stupid, but they have become rather blinded by decades of theories promoting overly hierarchical methods of “managing” an organization’s productivity by maximizing utilization. Unfortunately, this has made the flow and thinking around the flow of value somewhat counter intuitive to us. This is something you’ll have to change. Make it visible to developers, testers, your fellow PMs, other departments and upper management by efficiently using BVIRs and actively engaging people in a conversation about how the work is flowing (well, unfortunately it will be mostly about how and why <i>it doesn’t flow</i>). This should all stimulate reflection and adaptation on their behalf, which you will also likely need to actively facilitate. <br />
<br />
<i>4. Help teams to embrace essential agility</i>. Practically guide them through real challenging things such as splitting value into vertical slices, working collaboratively on those slices, or continuously refactoring code to enable future value delivery, or defining effective acceptance tests. These are all very challenging things that require a substantial shift in the team’s mentality. This is much more important at scale and much harder to achieve than simply ensuring that the team formally follows the Scrum ceremonies. <br />
<br />
<i>5. Educate your peers and upper management in Lean thinking</i>. Show your peers and management how your teams resolve real problems in action, how they plan, how they resolve dependencies during execution, and how they demo. Teach them "indiscernibly" by engaging them in "Gemba kaizen" – the "real place" where all of the action actually takes place. Stimulate curiosity and encourage them to challenge existing rules and processes. Be patient as it takes time, but take every opportunity to present the results to other people in the organization and take every opportunity to involve them in the collaborative workshops for your teams – such events speak for themselves without any words. <br />
<br />
<i>6. Engage business stakeholders in alignment sessions</i>. Events like program backlog grooming, release planning, release demo, etc. are pretty much useless if they are done only by the teams without synchronizing actual plans with product managers, infrastructure managers, the system/enterprise architect, and other people that have stake in the forthcoming scope. The recipe is simple: developers, testers and product owners from different teams should come together in the same room with business stakeholders. <br />
<br />
<i>7. Facilitate learning within and across teams</i>. Build and facilitate different communities of practice (CoPs) for Scrum Masters, Product Owners, developers and testers, where they can exchange the proven best practices emerging in their agile team. <br />
<br />
<i>8. Create a balanced decentralized decision-making model</i>. Essentially, tactical decisions need to be made quickly by the people who actually do the work and know best what should be done. Legacy mindsets and cultural scenarios within teams may largely prevent such decentralization and paralyze the flow. You should practically guide teams through the decision-making process and coach them in real scenarios whenever they stumble. Over time, this will transform them into a substantially self-organizing and self-managing team and will allow you to concentrate on identifying the next bottleneck in the organization, requiring your dedicated work as an enabler. <br />
<br />
Rather recently, I had a talk with a bunch of project managers at one of the world’s largest organizations (unfortunately, I am not entitled to specifically name them here) regarding their role in agile enterprise, and it took quite a bit of time to go through all topics of interest. I have only summarized some of them in this post, but there are many more and they require your attention. However, to execute your agenda, you need to start small and realize that your ability for analytical thinking, your passion and unconditional courage must be combined together to do the job. Start the journey as soon as possible as there is a long way to go.
</div>
<br /></div>
Unknownnoreply@blogger.com38tag:blogger.com,1999:blog-2215754383829886994.post-2895156424829330342013-02-25T19:47:00.001-08:002013-02-25T19:49:52.248-08:00ATDD and Effective Exploratory Testing<div dir="ltr" style="text-align: left;" trbidi="on">
<i>By Alex Yakyma.</i><br />
<br />
Acceptance Test-Driven Development heavily relies on automated scenarios that reflect the key behaviors of the system. Basically it represents the way and the team process to physically bind the requirements, expressed as acceptance tests, to the code. Besides these key acceptance tests, or in other words – examples of system functionality – teams normally also want to ensure that certain less obvious and less predictable behaviors are implemented correctly. "Less predictable" and "less obvious" does not mean that they are less probable. In fact, teams, by definition, have their "implementer bias" and may easily overlook things. That is the reason for exploratory testing – to look at the system from a new angle, to try scenarios that have not been tried before, to play with different combinations of environment and configuration settings, so on and so forth. This important effort involves both creativity on the part of testers and their hard work in running desirable scenarios under certain conditions. The process most often entails one more of the following problems:<br />
<br />
• It consumes a lot of the testers' time. Very often they perform all or almost all operations manually, which, apart from the execution of desirable scenarios, also includes manual environment setup, data preparation as part of different upstream scenarios, etc.<br />
<br />
• It takes developers a lot of extra time in the case that they create and maintain special harnesses for manual testing.<br />
<br />
• The tests are not persistent. Even when the team performs some kind of automation, typically there is a considerable gap between the process of exploratory testing and the automation of those valuable new test scenarios obtained as a result of exploration. The gap is both in terms of time and skillset due to the fact that exploratory testing is often performed by manual testers while, most often, automation is done by developers or automated test engineers.<br />
<br />
• Testers' options are mostly constrained to black box testing. System-level scenarios result from a combination of different conditional flows that occur in different parts of the code. The problem is that it is impossible to test the system by only operating at a high level – we simply experience a "combinatorial explosion" – a stratospheric number of scenarios.<br />
<br />
• The knowledge and context of sharing with developers is ineffective. While testers may play with certain type of system behaviors and even catch some interesting defects, there is almost no sharing of their tacit knowledge about the system with the developers, no collaborative analytical thinking, and no generalization or synthesis. There is no way to induce the specific useful implementation or design takeaways from the findings discovered during exploratory testing.<br />
<br />
ATDD turns out to be very useful in creating certain behaviors and effects that help to address these problems. The secret is in the team's ability to quickly automate new scenarios, in the tooling, that turns out to be extremely useful, and in constant collaboration that drives ATDD process. Here is how it works.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-0ojKUFwRUjxA0zli79aWSL-kFfkNisZ0hJeAp_YUBW_0Ac9cprlZ7k6Sy5b5d9Fi2JaaLnf-4-E631JZpG0TkZk4CM1LJIXzWyhI2WHkjlho0Jx6j4NPR5Ipg55DfUdnSNdAFn1YQkc/s1600/ATDD+and+Exploratory+Testing.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="449" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-0ojKUFwRUjxA0zli79aWSL-kFfkNisZ0hJeAp_YUBW_0Ac9cprlZ7k6Sy5b5d9Fi2JaaLnf-4-E631JZpG0TkZk4CM1LJIXzWyhI2WHkjlho0Jx6j4NPR5Ipg55DfUdnSNdAFn1YQkc/s640/ATDD+and+Exploratory+Testing.png" width="640" /></a></div>
<br />
<br />
ATDD relies on automation tools like Cucumber, SpecFlow, FIT, RobotFramework etc., which allow for defining scenarios in business language. These scenarios are then physically linked to the system by what is called "bindings" or "scenario step definitions" – little pieces of code that interpret the corresponding scenario steps, and run them against the system. Very often these steps are parameterized, so that, for example, this would be a step written in Gherkin language, which is used in tools like SpecFlow and Cucumber: "customer provides <country>, <province> and <zip_code> and whether this <is_or_isnot> a permanent address". This enables testers to do exploratory testing at a whole new level: </is_or_isnot></zip_code></province></country><br />
<br />
<country><province><zip_code><is_or_isnot>• Testers use the same tools as developers to "play with scenarios". The only difference is that they only play with the input parameters of an existing scenario steps, which does not require any coding. </is_or_isnot></zip_code></province></country><br />
<br />
<country><province><zip_code><is_or_isnot>• When testers need a new step for exploratory testing that does not yet exist, they ask developers to create it. They often pair with developers to make sure that the right steps are built. </is_or_isnot></zip_code></province></country><br />
<br />
<country><province><zip_code><is_or_isnot> • When binding new key scenarios to the code, which happens as a part of the normal ATDD flow, testers and developers ensure that steps are properly parameterized so that testers could immediately use them for exploratory testing, apart from their primary function. Sometimes, however, teams decide to hide some hairy detail in the step bindings (usually for better readability). In such cases, testers may ask developers to simply create a "parameterized" version of the steps, which will be used primarily for exploratory testing. When the initial binding code is in place, this becomes a very quick operation. </is_or_isnot></zip_code></province></country><br />
<br />
<country><province><zip_code><is_or_isnot>• By easily combining and running different steps with different input/output parameters, testers can more effectively capture unexpected outcomes. Here is the fun part: every finding can be captured as an automated test by simply replicating the set of steps with the specific set of parameters into a separate scenario file. </is_or_isnot></zip_code></province></country><br />
<br />
<country><province><zip_code><is_or_isnot> • Frequent collaboration between developers and testers flows very naturally this way. Developers immediately learn what is wrong with the system and testers learn to understand and to be able to read the binding code by looking behind the developer's shoulder and operate much better in terms of "white box" or at least "grey box" testing. There is nothing sophisticated about the binding code. In fact, it has to be fairly simple by definition - those who write automated scenarios leverage simplicity in order to prevent false positive or false negative scenarios. It is really that simple! </is_or_isnot></zip_code></province></country><br />
<br />
<country><province><zip_code><is_or_isnot>After an iteration or two, this approach becomes so obvious and natural to testers that all they had normally done previously, in terms of exploratory testing, seems ridiculously inefficient to them. This approach allows them to explore more, but also to capture findings so they could be run over and over again. It helps testers externalize valuable knowledge and turn it into better software as a result of collaboration with developers.
</is_or_isnot></zip_code></province></country></div>
Unknownnoreply@blogger.com107tag:blogger.com,1999:blog-2215754383829886994.post-3849099746679889642013-02-15T08:36:00.003-08:002013-03-03T14:48:52.609-08:0017 Truths about PSI/Release Objectives<div dir="ltr" style="text-align: left;" trbidi="on">
<i>By Alex Yakyma.</i><br />
<br />
PSI (Release) Objectives are defined in Scaled Agile Framework as a key alignment tool that teams use within the agile program. For definition and key characteristics, we refer the reader to the original article on <span id="goog_2075354750"></span><a href="http://scaledagileframework.com/objectives/" target="_blank">PSI Objectives in SAFe</a><span id="goog_2075354751"></span>. <br />
<br />
PSI Objectives are actually not a trivial concept, as is, in fact, the case for anything describing complex aspects of software engineering at scale. That's why it is important that agile teams, program stakeholders, consultants and coaches understand PSI Objectives and their correct application. In this post I will try to provide simple, understandable, compact and actionable points regarding PSI/Release Objectives. Even though unordered, they are useful as they represent answers to common queries:<br />
<ol style="text-align: left;">
<li>PSI Objectives are not features from the <a href="http://scaledagileframework.com/program-backlog/" target="_blank">Program Backlog</a>. They can directly correspond to features sometimes, but not necessarily always.</li>
<li>PSI Objectives are the key output of <a href="http://scaledagileframework.com/release-planning/" target="_blank">PSI/Release planning</a> event. Every team has their objectives sheet as a result of planning. </li>
<li>Business value, assigned to each objective by business owners, should be interpreted unambiguously by both stakeholders and the team.</li>
<li>Business value has nothing to do with the effort involved. It only shows you "how much useful stuff is there" for the business.</li>
<li>PSI Objectives are kind of a "reality check". While top N <a href="http://scaledagileframework.com/feature/" target="_blank">Features</a> from the Program Backlog are the idealistic plan of intent, PSI objectives reflect them in the real world: what contribution is required from different teams? What are the different aspects, such as research, infrastructure, design enablement, etc.? </li>
<li>If a team does not have Stretch Objectives, then they either honestly believe in the fixed scope game or they are made to believe in it. Either way it has nothing to do with agile development.</li>
<li>Business Owners should be able to understand all PSI Objectives and their business value; otherwise, they likely lack some members of the Business Owner team (such as system or enterprise architect, infrastructure manager etc.)</li>
<li>PSI Objectives may reflect scope that does not originate from Program Backlog – for instance, the team's technical debt, maintenance, other commitments (routine releases, patches, etc.), improvement initiatives, infrastructure and process related effort, etc.</li>
<li>PSI objectives are used by teams at every <a href="http://scaledagileframework.com/team-backlog/" target="_blank">Backlog Grooming</a>, sprint planning and sprint demo event to ensure that they are on track.</li>
<li>There's no direct correlation between feature priorities (<a href="http://scaledagileframework.com/wsjf/" target="_blank">WSJF</a>) and the business value of the PSI objectives, which the feature spawns on different teams' objectives sheets. However, if the feature is important, then at least one of the corresponding objectives will have a relatively high business value (but not necessarily all). </li>
<li>PSI Objectives are the main communication protocol between stakeholders and teams both at PSI/Release planning, execution and <a href="http://scaledagileframework.com/inspect-and-adapt/" target="_blank">Demo</a>.</li>
<li>The same PSI Objective may create multiple business effects, all of which should be considered when assigning business value. Thinking in terms of business effects creates the foundation for alignment. </li>
<li>S.M.A.R.T. PSI Objectives are context dependent. Besides the basic requirements of S.M.A.R.T.-ness, different organizations evolve their own understanding of what the quality PSI objectives are in their own specific case. It is important to capture these context-specific characteristics as early as possible.</li>
<li>PSI Objectives are used at Scrum-of-Scrums, PO/PM meetings, and as system demos.</li>
<li>Business Value is always considered at a current moment of time. If something is only valuable in the distant future, it should get high business value in the future, but not right now. </li>
<li>Business Value does not determine the sequence in which PSI objectives are taken into development by the team. Business value only shows what to expect as a result.</li>
<li>Normally PSI Objectives may be accomplished with reduced scope. This only means that the achieved business value will be lower than the planned one, but key business expectations can still be met. </li>
</ol>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiH8grJFwPZCwhU3hVmI49d_0mbcqOA4Q_x2hCqraOa9m0xUd3eT7cvJNsRmfOVXYZDqRuYaNOcKmbvpY-kc5Iafkq7qAWpjD-8gusoNstn8BC4PzvhlaoIjAKD3ScJ-KFBxN7cmdg2Jhk/s1600/PSI+Objectives+Alignment+Teams+Business+Owners.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="209" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiH8grJFwPZCwhU3hVmI49d_0mbcqOA4Q_x2hCqraOa9m0xUd3eT7cvJNsRmfOVXYZDqRuYaNOcKmbvpY-kc5Iafkq7qAWpjD-8gusoNstn8BC4PzvhlaoIjAKD3ScJ-KFBxN7cmdg2Jhk/s320/PSI+Objectives+Alignment+Teams+Business+Owners.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 1. PSI/Release Objectives are the primary tool for alignment within agile program</td></tr>
</tbody></table>
<div style="text-align: left;">
Understanding PSI objectives is very important for business alignment. Programs and teams realize they are able to deliver value effectively, as they really come to understand what they are building and why. By having a set of clear, committed to, PSI Objectives, every team will know how to be efficient within the program. PSI Objectives enable a program to become a self-organized team of teams – a key mechanism for agility at scale. <br />
<br />
<br />
<br /></div>
</div>
Unknownnoreply@blogger.com39tag:blogger.com,1999:blog-2215754383829886994.post-14095320881972371802013-02-11T21:43:00.002-08:002013-02-20T13:49:07.618-08:00Specification by Example and Card-Conversation-Confirmation<div dir="ltr" style="text-align: left;" trbidi="on">
<b><i>By Alex Yakyma. </i></b><br />
<br />
Recently I happened to encounter a lack of specificity in a purportedly trivial situation. I was at a restaurant in Longmont, CO and wanted to start in my rather typical way, having tea with honey. Given that it was snowing, seems like a quite natural thing. I ordered "black tea with honey", the waitress asked "why black?", to which I answered that, in some countries, unless you say "black tea" or "black coffee", you will receive it with milk. Also, I noted that, this way, one could distinguish it from green tea, which is an entirely different thing. She smiled and, in a minute, I got my... you guessed it... glass of ice tea (actually with a lot of ice in it) and a little vessel with honey on the side.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2ow0Ho2trTCmmZD2WJB6KrspaPAM_BLt4KYwyjMnq4_WRPqYtGML7paj9wWM6cDjph61JgkL9ROp4m221Nc9dmcYLlRZ49fGMXuLYWfRqDcM9FUxnwW57Uzj_iAeDL6VrxU87hlQOybI/s1600/atdd-sbe-ice-tea-with-honey.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="268" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2ow0Ho2trTCmmZD2WJB6KrspaPAM_BLt4KYwyjMnq4_WRPqYtGML7paj9wWM6cDjph61JgkL9ROp4m221Nc9dmcYLlRZ49fGMXuLYWfRqDcM9FUxnwW57Uzj_iAeDL6VrxU87hlQOybI/s320/atdd-sbe-ice-tea-with-honey.png" width="320" /></a></div>
I was speechless, and she disappeared before I recovered. I felt like Eric Cartman with his funny-fuse, when he wasn't able to laugh any more :) Anyways, to make a long story short, I knew what I wanted, and we even had a chat about it. I thought we had even defined everything clearly, but turns out we didn't. Sound familiar?<br />
<br />
I think XP folks impacted on the software development industry much more significantly than we may have otherwise thought. In fact, user stories aren't a Scrum invention; this was institutionalized in XP. In particular, Ron Jeffries, defined what we know as the "3C": <a href="http://xprogramming.com/articles/expcardconversationconfirmation/">Card, Conversation and Confirmation</a> - three important aspects of user stories (actually any stories, not just user ones). The "triad" actually means physical card, on which the story is written – a conversation between those who define and those who implement – to clarify detail and, finally, the acceptance criteria by which it is decided whether a job is done. This is a great conceptualization of what is necessary to keep in mind for teams. Nevertheless, the 3C itself is dependent on how effective a conversation is in terms of identifying detail; otherwise... you may get your ice tea with honey.<br />
<br />
A useful technique to make the 3C work efficiently is <i>Specification by Example</i> - a collaborative approach to defining requirements based on concrete examples, instead of abstract statements. The "Second C" in this case gets recurrently supplied by examples, which become a natural way for requirements’ disambiguation for the team and stakeholders. What's important is that the "examples" are goal-driven and thus, the Conversation continues to be meaningful. So, had I said that, to warm up in such cold weather, I would need a cup of good Earl Grey tea with honey, then there likely would never have been such confusion in the first place. By the way, there indeed happens to be waiters and waitresses that have a good facilitation skill for thing like Specification by Example. But these are as rare as good facilitators among people in the software domain. Nevertheless, here's a set of simple recommendations that I give during ATDD coaching:<br />
<ul style="text-align: left;">
<li>Refine requirements collaboratively as a team, involve external stakeholders as much as possible; keep in mind that your co-dependent agile team is just another "stakeholder", so invite some representatives.</li>
<li>Include the Specification Workshop (where Specification by Example actually comes into play) into every backlog grooming and sprint planning session.
</li>
<li>Actively use BVIRs (whiteboards, flipcharts, etc.).</li>
<li>Use tables to represent the variations in data, flow conditions - virtually everything. Table format is the most powerful collaborative tool for refining requirements. Regardless of whether it happens later, it may or may not be represented in a table format in your ATDD tool. </li>
<li>Do not allow any abstractions in the examples. Avoid those "X"s and "Y"s etc. at all cost. You will be surprised how much your team will learn about the seemingly familiar user story once they replace all Xs and Ys with real values. </li>
<li>Stay timeboxed story-wise and move to the next story every 10-15 minutes. If not done with the story, no worries - you can return to it. Just don't let it go too deep and consume too much time.</li>
<li>Capture all agreed upon examples - these are your acceptance tests. Capture all open questions (to stakeholders or otherwise) and resolve them first.</li>
<li>Have Specification Workshops at every iteration - team self-discipline is key here. Scrum Masters can find this a real challenge for their facilitation, coaching and mentoring skills, which assist their team in adopting and sustaining Specification by Example as an effective cadence based activity. </li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjnkydhHtlwDUkKskg5NSvbfpAS-NYigJGNAjgjx7gRvsfbd0GHj2cDrzz6a_Zp-FTcipcXSPlF59_6xVG0nPm3j2maUMmUrI4vgFVZhUrTxBpfbv045XbbMfM_2EOVlMfUEfW925xFCX0/s1600/table-specification-by-example.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjnkydhHtlwDUkKskg5NSvbfpAS-NYigJGNAjgjx7gRvsfbd0GHj2cDrzz6a_Zp-FTcipcXSPlF59_6xVG0nPm3j2maUMmUrI4vgFVZhUrTxBpfbv045XbbMfM_2EOVlMfUEfW925xFCX0/s400/table-specification-by-example.png" width="400" /></a></div>
<br />
It is amazing how much a team can achieve when they know what they are building. User stories, as "containers" of value, in conjunction with concrete examples, represent an extremely powerful tool that makes a team extremely productive in delivering business value incrementally. </div>
Unknownnoreply@blogger.com10tag:blogger.com,1999:blog-2215754383829886994.post-63126778300006770192012-10-08T14:42:00.000-07:002012-10-08T14:48:59.783-07:00Is TDD Really Extreme?<div dir="ltr" style="text-align: left;" trbidi="on">
By Alex Yakyma.<br />
<br />
Many organizations and individuals used to believe that Test-Driven Development (TDD) is some kind of really extreme engineering practice, and that it is something that only real fanatics would use as a sustainable routine. That is partially the result of the "guilt by association" tendency with respect to TDD, which as we perfectly know originates from Extreme Programming (XP) and really is one of the key practices there. But is it really so extreme? Or is it extreme at all? There is one big reason that we should not think so.<br />
<br />
Quite often we witness a certain resistance among people, especially those who used to work in traditional (non-agile) environments, regarding TDD. They don't actually believe it works, along with most other agile engineering approaches such as emergent design, simplicity or continuous refactoring. According to them, design needs to be elaborated up-front and you can't "just develop" your software. Well, I can't agree with them more. In fact, we see how <a href="http://scaledagileframework.com/architectural-runway/">Intentional Architecture</a> works very well (hand-in-hand with <a href="http://scaledagileframework.com/emergent-design/">Emergent Design</a> practices) on a large scale and represents an important balance of forces in <a href="http://scaledagileframework.com/">Scaled Agile Framework</a>. I very much agree that you can't develop software without, at the very least, some up-front analytical thinking. Thus, the argument is understood, appreciated and is conceptually applicable. However, there is one little problem with such thinking...<br />
<br />
If we take a closer look at unit tests or component tests we will discover an interesting fact: tests that critique the behavior of classes or components actually behave just like their "clients" (figure 1).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-qv8-x1-BC74/UHNIKdZ3XfI/AAAAAAAAADk/5ice9yxs6R8/s1600/Test+Emulate+Client+Classes.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="237" src="http://1.bp.blogspot.com/-qv8-x1-BC74/UHNIKdZ3XfI/AAAAAAAAADk/5ice9yxs6R8/s320/Test+Emulate+Client+Classes.PNG" width="320" /></a></div>
<br />
<div style="text-align: center;">
<i>Figure 1. Tests simulate the behavior of "client" classes</i></div>
<br />
Thus developing classes and components along with the tests - and especially after the tests represents a way to think through the design prior to its actual implementation. Design is basically the way in which entities in the code are going to relate to and interact with each other; unit/component tests really provide a way to model that interaction up-front. That simply means that TDD is an example of a practice that tremendously supports up-front design. So how is it that it could cause any troubles for people that believe in intentional design effort? If someone thinks that it is possible to plan the entire system design weeks or even months up-front, why then would it cause such a big problem for them to define a much smaller piece just a few minutes away from its implementation? …Because that is exactly what we do in TDD with tests - we actually define internal system organization and behavior a little bit up-front.
<br />
<br />
Looks like the takeaway is quite simple - we shouldn't view XP practices (and especially TDD) as something really extreme. Sometimes just looking at something like this at a different angle helps people that used to work in more traditional process environments to find a clear rational behind agile engineering approaches. Meanwhile, it helps agile people realize that agile, in fact, does not at all neglect up-front analytical thinking but vice versa – utilizes it continuously.
</div>
Anonymousnoreply@blogger.com14tag:blogger.com,1999:blog-2215754383829886994.post-83732033474592297762012-09-05T08:31:00.001-07:002012-09-05T08:34:03.196-07:00Epic Splitting Techniques<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="separator" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em; text-align: center;">
<img border="0" height="100" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjU3Or8M3bwE2Q7In7Yz46480Lr80utMbqeuv2bN8cXqDguJ-5F1rzksm3f4AuZh50_tOuavsd7tfiE2lz-ZswF-DNfN_Rf6aTBEhMd3rdYwEoqNC3mDBeDnTpNInyiekN_2Q9mHKN_nzA/s200/Epics.PNG" /></div>
<br />
By Alex Yakyma.<br />
<br />
We just finished the Business Epic page in Scaled Agile Framework recently and it has a bunch of useful approaches of how to split business epics into smaller items (sub-epics and features). Following are the key methods used. We split epics by...<br />
<br />
<ol style="text-align: left;">
<li>Product / Subsystem / Component</li>
<li>Success Criteria (note that this is an analogue to user story acceptance criteria, however it stays at the higher level of abstraction and thus expresses business benefits rather than the requirements to the functionality. Hence the different name)</li>
<li>Major Effort first</li>
<li>Simple-to-Complex</li>
<li>Market Segment / Customer / Class of User</li>
<li>Defer System Qualities</li>
<li>Risk Reduction / Opportunity Enablement</li>
<li>Use Case Scenarios</li>
</ol>
More detail and actual examples for these methods can be found in the <a href="http://scaledagileframework.com/business-epic/">original SAFe article</a> on business epics. <br />
<br />
Prior to that we published the <a href="http://scaledagileframework.com/architectural-epic/">Architecture Epic page</a> which also has interesting considerations in terms of splitting and incremental implementation of large technical initiatives. </div>
Unknownnoreply@blogger.com8tag:blogger.com,1999:blog-2215754383829886994.post-73338082228213535082012-08-29T06:22:00.001-07:002012-08-29T06:24:35.105-07:00Fractals and Reliable Value Delivery in Agile Enterprise<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-yOrLbqRfNTg/UD4UmJksxuI/AAAAAAAAACw/9rwSJEGF_88/s1600/General+Fractal.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"></a></div>
By Alex Yakyma.<br />
<br />
<br />
<i>“A cloud is made of billows upon billows upon billows that look like clouds.”</i><br />
<br />
<i>-- Benoit Mandelbrot</i><br />
<br />
<a href="http://scaledagileframework.com/">Scaled Agile Framework</a> provides a model for large enterprises to harness the power of an individual agile team and replicate its key benefits to the higher levels of abstraction (such as Program and Portfolio). This process of repeatedly replicating a certain set of properties from the lower to the higher level is a definitive characteristic of <a href="http://en.wikipedia.org/wiki/Fractal">Fractals</a> - complex objects that look similar at different scales. This fractal perspective will help us identify the fundamental causes of delivery problems within an organization and ways to address them. <br />
<b style="color: #990000;"><br /><span style="font-size: large;">Fractal Pattern: Value, Timebox and Self-organized Team</span></b><br />
<br />
If we take a quick look at the Big Picture of agile enterprise as suggested by Scaled Agile Framework (further referred to as SAFe) we will see that all three levels - Team, Program and Portfolio - have a few things in common:<br />
<br />
<b>Value.</b> All three deliver value. Agile teams (or as we also used to call them - Define-Build-Test teams or shorter: DBT-teams) deliver user stories; programs (Agile Release Trains or ARTs) deliver features; and the portfolio level delivers epics. Unlike in the pre-agile times, every unit pushes <i>value</i> to the next level of abstraction. It is important to emphasize that such a focus on value implies WIP limits at all three levels of abstraction, protecting an organization from the trap entailed in using unfinished work as a measure of progress.<br />
<br />
<b>Timebox</b>. Agile teams stay on a synchronized sprint schedule, ARTs stay on a firm PSI schedule, and the portfolio level delivers epics within a larger timebox, typically the horizon of 2-3 PSIs. <br />
<br />
<b>Self-organized Team</b>. Agile teams self-organize around the delivery of stories; ARTs self-organize to land the features that are in the scope of the PSI; the Program Portfolio Management Team, Enterprise Architects and Business Epic Owners self-organize around facilitating the delivery of business epics. <br />
<br />
The three components we described above actually constitute the <i>fractal pattern</i> of agile organization (see Figure 1). <br />
<img border="0" height="366" src="http://1.bp.blogspot.com/-yOrLbqRfNTg/UD4UmJksxuI/AAAAAAAAACw/9rwSJEGF_88/s400/General+Fractal.PNG" width="400" /><br />
<i><span style="font-size: small;">Figure 1. Agile organization as a fractal structure. </span></i><br />
<br />
In the same way that fractals are used in different practical domains to provide a simple underlying pattern behind a complex system, in our case, a fractal view also helps to tame the complexity of an enterprise in a systematic way. <br />
<br />
<b style="color: #990000;"><span style="font-size: large;">The "Ground Level" of Scaling</span></b><br />
<br />
There is no feasible way to reflect all the possible aspects of a complex system in a single plain view: you can't describe all the nuances of human physiology or the behavior of a stock market in just a single view. Thus, every time that we build such a view, we have to neglect certain aspects. Such is in the case with agile enterprise and its representation as a SAFe Big Picture. One of the aspects that is not reflected in the (anyways overpopulated) Big Picture is, what I used to call the zero- or <i>ground-level</i>. This level will play an important role in our journey to the roots of the value delivery issues in an enterprise. So let's see what that level is...<br />
<br />
We define it as a <b><i>DBT-formation</i></b> (see my previous post: <a href="http://www.yakyma.com/2011/03/dbt-framework-for-story-implementation.html">DBT Framework for Story Implementation</a>), which is a temporary group of a few team members within a certain agile team that self-organize around the delivery of a specific user story. Quite typically it consists of 1-2 developers, a tester and the PO that is shared across all DBT-formations within the same team. After finishing a user story, a DBT-formation may dissolve (and typically does). The unit of value that they deliver is actually a vertical slice of a user story, a result of running a DBT-cycle. We see such cycles typically taking no more than 1-3 days for completion. Now we can see that DBT-formations fully satisfy the fractal pattern and thus, can be considered as a starting point of the enterprise fractal structure (Figure 2). <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-9YgTkzNmW5U/UD4V2cS9gwI/AAAAAAAAAC4/RufirUr2yZI/s1600/DBT-formation.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="http://3.bp.blogspot.com/-9YgTkzNmW5U/UD4V2cS9gwI/AAAAAAAAAC4/RufirUr2yZI/s400/DBT-formation.PNG" width="356" /></a></div>
<br />
<i>Figure 2. DBT-formation is the ground level of scaling. </i><br />
<br />
This is the scale of the fractal <i>where the actual work is being done</i>. As we will see in the next section, the "strength" of these units is extremely important for the entire organization. <br />
<br />
<b style="color: #990000;"><span style="font-size: large;">Absorbing the Vibration</span></b><br />
<br />
We now are going to consider a typical problem in any development at scale, which is when the organization fails to deliver according to its commitments. The typical symptom is either a failure to deliver at all (this is an extreme case, but it still happens) or the failure to achieve some of the priorities, which is something most readers have surely witnessed many times in their tech career. So how does this problem occur? The fractal structure gives us a good hint: if we fail to deliver an epic, we obviously go all the way down to the minimum quantum of value, which, in our case, is a vertical slice of a user story that is not delivered as expected. It is important to describe in more detail what "not delivered as expected" really means. Some typical problems are as follows:<br />
• The slice/story/feature/epic is not delivered at all<br />
• It is delivered but it's not what was intended by the PO<br />
• It is delivered but causes further logical or physical integration problems with other pieces<br />
<br />
In any of these cases, we would like to see what the possible impact is of such a disorder – which we will call a <b><i>vibration</i></b> – on the entire system. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-ZH6FckTzens/UD4WYYdOx3I/AAAAAAAAADA/s91M8cphwaM/s1600/Vibration.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="http://3.bp.blogspot.com/-ZH6FckTzens/UD4WYYdOx3I/AAAAAAAAADA/s91M8cphwaM/s400/Vibration.PNG" width="321" /></a></div>
<br />
<i>Figure 3. Vibration in the system. </i><br />
<br />
Well, first of all, if the vibration occurs within a DBT-formation that is currently working with a lower priority item, it becomes quite obvious that the impact is manageable; eventually we can always de-scope it without essentially trading off the final business value. However, in the opposite case, the impact can be huge – it will propagate all the way to the top level of our fractal organization and will result in a large-scale delivery issue (Figure 3). <br />
<br />
The following is an example of how easily things like these end up happening: a DBT-formation fails to deliver its first slice of a user login story using SSO, which other team members and agile teams are dependent upon. Now all the team members in this team begin to help this DBT-formation to finish its story on time, and they partially succeed by delivering just the first vertical slice and totally postponing their own stuff. This effectively delays the other agile teams in the program and forces them to re-organize their own work, which is alright, but they have already lost time and are unable to deliver all the functionality working under SSO because they got the first story too late in the PSI, so the program falls short on few of the priorities and considerably slows down the entire SSO epic, cutting across all programs in the program portfolio...<br />
<br />
Now let's see what a good scenario would look like. To understand what a good scenario is, let's analyze different scales of the fractal with regard to their capability of absorbing the vibration. Let's start from the top. <br />
<br />
<b>Portfolio Level</b>. If Program X in our portfolio underdelivers their part of an epic, then obviously it is highly unlikely that Program Y, which delivers the other part, could somehow absorb the vibration. This has quite a natural explanation as ARTs have their own quite isolated concerns - products and solutions that other ARTs simply can't help with due to the fact that they simply don't know the code base. <br />
<br />
<b>Program Level</b>. If agile team X causes a vibration within a program, then it is a little more likely that there will be one or a few teams who could absorb the shock. Especially if the program is mostly composed of feature teams, it has a chance, because it is quite possible that there are people on those teams that know the code base of concern to an extent sufficient to help. But let's keep in mind that this is not just about being able to help in principle, but about being able to help and still deliver your own priorities; otherwise the vibration will simply get propagated further in the fractal – both horizontally and vertically. <br />
<br />
<b>Team Level</b>. This is the likeliest level to absorb the vibration and prevent it from extending outside the team boundaries. Indeed, most good agile teams benefit from collective code ownership and thus, any other DBT-formation could help. <br />
<br />
The first important implication of this analysis is that<br />
<br />
<div style="color: #0b5394;">
<b><i>The ability to absorb vibration does not scale. It is highest at the team level and lowest at the portfolio level. </i></b></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-4PfIOoJX9l4/UD4W_yrhvjI/AAAAAAAAADI/tipQZtAtkHw/s1600/Absorbing+Ability.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="340" src="http://1.bp.blogspot.com/-4PfIOoJX9l4/UD4W_yrhvjI/AAAAAAAAADI/tipQZtAtkHw/s400/Absorbing+Ability.PNG" width="400" /></a></div>
<br />
<i>Figure 4. The ability to absorb the vibration at different levels of an enterprise. </i><br />
<br />
The simple takeaway is to try to identify the vibration as early as possible and absorb it at the team level, thereby preventing its further propagation and a large-scale failure (Figure 4). <br />
<br />
Below we provide a list of practices and conditions that contribute to the enterprise’s ability to absorb the vibration and to facilitate reliable delivery:<br />
• <b>The practical ability to de-scope</b> but preserve the essential value (at all levels, including the ground level). Each time that a problem occurs, the unit can prevent its further propagation by delivering key priorities and de-scoping the low-priority work. This is relevant to both an external and internal “consumer” of the functionality. So, just as a feature can be de-scoped but still effectively fulfill the user need, a user story or its tiny slice can be de-scoped to satisfy the other team dependency and keep the Agile Release Train on track. <br />
• <b>Collective code ownership</b> at the team level and basic elements at the program level. Peers are the first to absorb the vibration. But they can only do so when they are familiar with the code where the problem occurred. It is impossible for everyone to know everything in a large organization, but it is totally feasible to achieve 100% collective ownership at the agile team level and partial collective ownership at the program level. The former is achieved through collective work on user stories (where more than one developer works on a story as a team ground rule), while the latter is achieved by periodically taking the other team’s scope in your team’s backlog whenever it is beneficial for the program. <br />
• <b>Feature teams</b> rather than component teams. Collective code ownership at the portfolio level is close to 0% because agile programs deal each with their own products – this is totally natural and expected. However, what’s not natural or expected is the same kind of isolation for agile teams within the same program. Nevertheless this is exactly the case for programs comprised of component-oriented teams, as each team only knows their own component. However, feature teams imply a much broader outlook for each team and foster a fair degree of collective code ownership at the program level. <br />
• <b> Smaller user stories</b> (good splitting skills). Everything happens faster with smaller user stories, including the detection of vibration by peers and by the next immediate level. <br />
• <b>Multiple DBT cycles</b> for each user story involving the PO. User story is still too big a container for the team to be able to instantaneously react to unexpected turns. Vertical slices of a story provide a much better chance of a quick low-impact corrective action. <br />
• <b>Effective continuous integration</b> at team and program levels. CI prevents from the false sense of progress that a team and program may fall victim to in the case that a slice of work is finished but not fully integrated. <br />
• Actively functioning <b>Communities of Practice</b> (CoPs) in different aspects of engineering. CoPs essentially support the necessary learning process that lays the foundation for collective code ownership, shared practices, and solution domain knowledge. <br />
<br />
<b><span style="color: #990000; font-size: large;">Summary</span></b><br />
<br />
<i>Large-scale software development is always a hard task, especially because a large organization is a very complex system. Scaling agility to the enterprise level by using SAFe effectively creates a simple pattern (Value / Timebox / Self-organized Team), which allows us to look at the organization as a fractal. This view allows us to understand that there are important characteristics that influence the success of delivery, which do not scale throughout the levels of the fractal. This essentially implies that the organization has to develop its ability to absorb the vibration (delivery failure) at the lowest possible levels. </i><br />
<br /></div>
Anonymousnoreply@blogger.com20tag:blogger.com,1999:blog-2215754383829886994.post-30612447974351951852012-07-01T09:02:00.000-07:002012-07-01T09:06:30.930-07:00An Imperative Aspect of System Architect Role at Scale: Designing for Testability<div dir="ltr" style="text-align: left;" trbidi="on">
By Alex Yakyma.<br />
<br />
<i>The bigger the system, the harder it is to develop and maintain, but also the harder it is to test. What we see is that developers and testers of most of the larger organizations complaining that they can’t basically add a single unit- or functional test to their system, because in order to do so they would have to refactor it almost entirely. This is something very important to companies to think about and for system architects at program level to take as a serious action item. In this post we will consider all variety of aspects of how system design impacts its testability from economic to cultural impact on the organization and how to start improving to better right away.</i><br />
<br />
The whole concept of Design for Testability (DFT) shouldn’t be new to us. It progressed in microelectronic hardware product design in the last 50-60 years. The reason for DFT is simple: if you want to be able to test your hardware (say, integrated circuit) during the design stage and then also after each piece is manufactured and even afterwards when it all functions on the client side – you have to adjust your system design for that testability. What’s fundamentally important is that you can’t design the system first and then simply add this magic “feature” of testability – instead it is deep non-functional requirement that permeates the entire System Under Test (SUT) in all possible aspects. Software systems require testing and being able to test as you evolve the system becomes imperative.<br />
<br />
<div style="color: #990000;">
<b><span style="font-size: large;">The Economic Sense of DFT. </span></b></div>
<br />
Agile testing covers different business perspectives: on one hand it critiques the product and thus minimizes the impact of defects delivered to the user; on the other hand it supports iterative development by providing fast feedback within the continuous integration process. None of these factors can come into a play if the system does not allow for simple system/component/unit- levels of testing. This fact obviously means that agile programs that sustain testability thru their every design decision will enable the enterprise with:<br />
<br />
<i>- Shorter runway for <a href="http://scaledagileframework.com/scaled-agile-framework/portfolio/portfolio-vision/portfolio-vision-epic/">business epics</a> </i><br />
<i>- Shorter <a href="http://scaledagileframework.com/scaled-agile-framework/portfolio/architectural-runway/">architectural runway</a> </i><br />
<br />
In certain sense DFT reduces the impact of the big system and gives agile teams the luxury of working with something really manageable. That is why the role of a system architect is still important in agile at scale but it reflects totally different motivation: instead of defining big up-front system design (BDUF), agile architect helps establishing and sustaining effective product development flow. The <a href="http://scaledagileframework.com/economic-prioritization-with-weighted-shortest-job-first-wsjf/">WSJF prioritization model</a> based on the economics of Cost of Delay easily shows this if we take into account that <i>all jobs become shorter in the system that is designed for testability</i>.<br />
<br />
<div style="color: #990000;">
<span style="font-size: large;"><b> Impact on the System Architecture.</b> </span></div>
<br />
Practical knowledge suggests us that when we design for testability we actually arrive at a better design. Indeed typically DFT drives clear separation of concerns, layered architecture or service orientation, high cohesiveness of entities in the code etc.
We so often forget that tests actually always behave like the “clients”: unit test imitates the behavior of a corresponding client-class or classes invoking the target class methods. Same way component tests imitate the behavior of the client-components. Finally system-level functional tests imitate the end user – the “client” for the entire system. This means that if we are allowing for clear testability at these all levels – we are actually allowing for clear and understandable interfaces between classes, components, services and finally user interface and rest of the system.<br />
<br />
<b style="color: #990000;"><span style="font-size: large;">Cultural Impact.</span></b><br />
<br />
Designing for Testability can in no way be just system architect’s sole responsibility. DFT only works well when backed by all agile teams in the program. DFT is not a destination but an endless journey that continuously supports product development and is rather role collaboration between developers and testers on one hand and system architect on the other. It creates the culture of shared responsibility over the product development flow where architect, developers and testers are actively contributing to the system design and the contribution is always respected as its outcomes pretty soon become visible by everyone.
System design CoP (Community of Practice) is a good way of sharing knowledge between team representatives on how to maintain good design and system testability.<br />
<br />
<div style="color: #990000;">
<b><span style="font-size: large;">System Architect Role and DFT. </span></b></div>
<br />
When talking about designing for testability, here’s what system architect has to primarily take care of:
<br />
<table style="border: 1 px black;">
<tbody>
<tr>
<td style="border: 1 px black;">Choice of technologies</td><td>Besides fulfilling the main purpose, software libraries, frameworks, repositories and services should also support testability. For example, technologies that support inversion of control may not only be useful for designing a flexible system but also for testability.</td></tr>
<tr><td>The usage of a technology</td><td>For instance having too much logic at DB side (common problem of many-many products) makes testing almost impossible. So does the unreasonable usage of asynchronous message queues within the system.</td></tr>
<tr><td>Design conventions</td><td>Design patterns like façade, gateway, or observer foster testability. Such a common thing like using web service proxy class directly does just the opposite and good convention could be to always use some “abstract” interface directly which would interact with the proxy and thus allow to substitute one with a mock object whenever necessary.</td></tr>
<tr><td>Approach for creating fake objects</td><td>What tools and ways to use to create stubs, mocks and “spies” in the code that would support unit- and component testing.</td></tr>
<tr><td>Logging and creating dumps</td><td>Often in large systems some system-level tests fail but all the unit tests pass and thus diagnosing the root cause of the problem may be near to impossible without a good logging approach and ability to retrieve thorough memory (or protocol) dumps.</td></tr>
<tr><td>Flexible configuration</td><td>…that allows simple deployment to the test environment and easy linking of the test data sources and external mock objects as just a simple matter of updating the configuration files.
</td>
</tr>
</tbody></table>
<span style="font-size: x-small;"><i><b>Table 1</b>. The aspects of role of system architect to foster system testability. </i></span><br />
<br />
<div style="color: #990000;">
<span style="font-size: large;"><b>Where to Start? </b></span></div>
<br />
The above mentioned aspects may give the reader the immediate set of ideas that may spawn some architectural epics specific for their solution. In case of DFT as a driver for such epics, the incremental approach would work the best when instead of big redesign the teams should take the task piece by piece. This way not only we are always remaining in the context of our current features and stories that the teams are working on right now but also one of the most important aspects of DFT – the cultural aspect – can’t be achieved other than thru the set of incremental steps that demonstrate to the group that after every little design initiative it is easier to write the new tests at different levels of abstraction and actual team velocity gradually goes up.<br />
<br />
Let the teams take few current user stories and see, what is the minimum redesign effort that would let them write few unit tests in the areas where they previously couldn’t. Then share the findings and actual approaches with the others (e.g. at the nearest Design CoP meet-up). See what aspects described above (in Table 1) these findings may affect – are there new design guidelines for all teams or changes to system configuration etc.?<br />
<br />
We suggest using similar approach at the system level: let the <a href="http://scaledagileframework.com/scaled-agile-framework/program/system-team/">system team</a> or feature teams try automating system-level tests where they would previously fail but let them do it in the context of their current 1 or 2 features and so on.<br />
<br />
<i>When we are talking about agile testing and how important it is to start automating right now, we have to take into consideration that software systems are most often test-adverse. On one hand this is the sad fact about the industry on the other, when designing for testability, agile enterprise achieves great chance to outperform the competition as the runway for business and architectural epics becomes considerably shorter and the company can deliver much more value to their users.
</i></div>Anonymousnoreply@blogger.com10tag:blogger.com,1999:blog-2215754383829886994.post-2156344308680504052012-05-30T15:00:00.001-07:002012-05-30T15:29:57.641-07:00WIP Limit: Same Numbers but Different Outcomes for the Team<div dir="ltr" style="text-align: left;" trbidi="on">
<i>By Alex Yakyma. </i><br />
<br />
We know that WIP (Work In Progress) Limits are useful. They are useful at different levels of abstraction in the organization: portfolio, program or team (see posts by <a href="http://scalingsoftwareagilityblog.com/agile-portfolio-planning-and-business-kanban-system-tooling-overview/">Dean Leffingwell</a>, and <a href="http://www.infoq.com/articles/limit-wip-scrum">Sean McHugh</a>). Limiting WIP is one of the central themes in Lean Product Development as pointed out by Donald Reinertsen in his uber cool book "<a href="http://www.amazon.com/The-Principles-Product-Development-Flow/dp/1935401009">The Principles of Product Development Flow</a>". We even know that WIP Limit makes a lot of sense at the individual level as there evolved an individual productivity tool called <a href="http://en.wikipedia.org/wiki/Personal_Kanban">Personal Kanban</a>, which looks quite simple and logical. However, WIP Limits in software development are not as simple as they may seem. Software engineering is a knowledge-intensive, creative, intellectual type of work and this implies a whole bunch of interesting nuances. We are going to explore some of them now at the team level.<br />
<br />
So first of all, let's imagine a team consisting of one developer (and one tester, for instance). Assuming that he has a backlog of user stories, how many of them should he start working on at once? One, right? If it is just one, he won't be multitasking and thus will be totally focused on his current context of work. Well, not quite like that... In the time when I was a developer and then afterwards when working in other different capacities and observing the way other developers worked I was quite often seeing interesting pattern: a person takes a new story and starts slightly digging in that new direction while still working on the old one. And here's why it isn't always all that bad but often vice versa: we are not drilling holes in the wall or assembling chairs - we develop software and this is, as we said, uniquely intensive intellectual work. So let me give you an example: I work on the user story that would enable a search system user to not only see the links of the pages where the search phrase was found but also the short abstracts containing the phrase so I could at a glance see the context in which the phrase is used on the corresponding page. And then all of a sudden while still coding this story I take another one: "negative filtering by keywords" thus enabling the user to narrow down search results to those that do not contain the selected keyword. And it's not that I start coding it, no, I just read about it little bit, I talk to the people who dealt with something similar, I go home after work and when sitting in the bus, I give it some little thinking. Next day I seem to find an interesting idea (when brushing my teeth): in order to easily implement this one we need to start working with a binary vector on top of the array of all keywords in current filter criteria. Finally during the lunch same day with Andrew, the guy from another team, I just share my algorithmic problem that I anticipate in the context of this story and he simply gives me absolutely great idea of how to implement a lightweight comparison mechanism. Inspired by this direction of thinking I seem to know what to do with the rest of the open questions. That's all I did, I thought about it a little bit, talked to other people, slept on it... that's how it works - generating good ideas takes time and there has to be knowledge that eventually morphs into the idea in some miraculous way after some while.<br />
<br />
So now I finished coding my first story, maybe a bit slowed down by the distraction that I myself introduced, but I already have a plan in my mind of how I will approach the second story and I can start coding. After a bit of coding, when I see some of my ideas working and some still needed modification, which it took a bit of time to do, I'm certainly gradually moving forward with story #2 and it's just about time to pick another one from the backlog and just see what's in it, speculate a bit, discuss it a bit with someone, sleep on it and maybe in a short while (while still working on story #2) my brain will generate some good ideas...<br />
<br />
The takeaway is: <i>one story per person at a time may not be optimal and while coding one story I can start thinking and reading and just doing some slight background work on the next one and it will be more efficient! So in cases when real creative work is required, the optimum WIP Limit per person could be 2, not 1</i>. I know, I know, we have to avoid individual WIP Limits when talking about the team. But bare with me, this is just our thinking tool, we'll get there...<br />
<br />
Next trick is even better. What if we now have two devs on the team? Should they follow the same pattern? In other words limiting each devs WIP to 2 instead of 1? Looks like "yes" but this already gives us few alternatives: the stories can be different or can be the same. In other words there can be as many as four stories in progress due to such logic or just two! And the latter is really good approach. So see, with<i> individual</i> WIP Limits = 2 we have three possibilities for the <i>team</i> WIP Limit: 2, 3 or 4, depending on the overlap, and as we know, collaboration is king and we would most likely prefer it equal to 2.Let's now play it <b>backwards</b>: what if we set WIP Limit of the team of two devs equal to 2? Again, we have different alternatives: it could mean that they work each on different story or they are actively coding one story and "previewing" the other. And again, the latter might be of our preference. Thus...<br />
<br />
<i>Same WIP Limit at the team level may lead to different outcomes depending on the collaboration pattern that the team chooses. </i><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-L00hV5hIBTQ/T8ae9P-AEyI/AAAAAAAAACQ/jJNaO4d6VUw/s1600/Figure+1+-+Efficient+Collab+Pattern+with+WIP+Limit+2.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="http://1.bp.blogspot.com/-L00hV5hIBTQ/T8ae9P-AEyI/AAAAAAAAACQ/jJNaO4d6VUw/s400/Figure+1+-+Efficient+Collab+Pattern+with+WIP+Limit+2.JPG" width="400" /></a></div>
<div style="text-align: center;">
<i><span style="font-size: x-small;"><b>Figure 1</b>. Efficient collaboration pattern: WIP Limit = 2 and story "previewing". </span></i></div>
<br />
It is easy to see how to scale this logic further to a full-size agile team. When we talk about pairing we by the way do not necessarily assume pair programming. It can be just collaborative work (something we know by name of <a href="http://c2.com/cgi/wiki?SideBySideProgramming">side-by-side programming</a>, for instance). So the net result of such collaboration pattern is really interesting: much faster and higher quality results but with the same WIP Limit that equals to the number of developers on the team. This mix of pair work and previewing user stories becomes very useful for knowledge sharing and collective code ownership in the team. All that is needed is just to rotate the pairs over time. Because of the "previewing" the probability that someone (on the pair) will have something to learn from his team mate is now considerably higher. <br />
<br />
All of the above is totally applicable to Scrum teams (and was written with those in mind). We know that once the Scrum team has planned and committed to the Sprint scope, there can be different strategies of how to succeed with the Sprint. Some of them are better than the others. Today we covered one aspect related to collaboration and WIP Limits and I hope it was helpful. </div>Anonymousnoreply@blogger.com14tag:blogger.com,1999:blog-2215754383829886994.post-1860990716073243272012-05-16T13:41:00.000-07:002012-05-17T08:14:20.215-07:00Why Progressive Estimation Scale Is So Efficient For Teams<div dir="ltr" style="text-align: left;" trbidi="on">
By Alex Yakyma.<br />
<br />
<i>In this article we will show that progressive estimation scale, like Fibonacci sequence often used by agile teams, is more efficient than linear scale and provides the team with more information about the size of backlog items. We will use pretty basic principles of Information Theory to arrive at our results. Also we will formulate a hypothesis about normalization of the estimation base. </i><br />
<br />
In Agile we quite often see the examples of “progressive” estimation scale when estimating the size of backlog items. Most often it would be <i>Modified Fibonacci Sequence</i>: <i>0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100</i>. Less common is the scale used by XP proponents: <i>0, 1, 2, 4, split</i> (we will refer to this estimation scale as <i>XP Scale</i> further in the text). We call them <i>progressive</i> to reflect the fact that the values grow much faster than linearly. Also we often call these scales (not 100% accurately though in general case) <i>exponential</i>. In fact, XP scale is itself exponential and Fibonacci scale can be roughly approximated for the range of the values defined above with <i>f(x) = 1.6<sup>x-1</sup></i> as shown in the figure below:
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-iVp2BxSk4Yc/T7QOuWzzRhI/AAAAAAAAABM/nREHx0NKwoU/s1600/Approximating+Fibonacci+with+the+Exponent.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="336" src="http://4.bp.blogspot.com/-iVp2BxSk4Yc/T7QOuWzzRhI/AAAAAAAAABM/nREHx0NKwoU/s400/Approximating+Fibonacci+with+the+Exponent.PNG" width="400" /></a></div>
<br />
<i><span style="font-size: x-small;"><b>Figure 1</b>. Modified Fibonacci sequence approximated by exponential function for its range of values.</span></i><br />
<br />
The point we are making here is that both scales can be with some level of accuracy called “exponential”.<br />
<br />
Having said that, let’s ask ourselves a question of why are we using an exponential scale? As we well know, thousands of agile teams are applying these estimation scales very successfully. What makes exponential scale so useful?
We used to answer this question by referring to the fact that the bigger the size of a backlog item (say, <i>N</i> story points) the harder it is to say the difference between <i>N</i> and <i>N – 1</i>. It is true. However the statement itself is not a fundamental axiom but is just a corollary of more generic principles, which we are going to consider.<br />
<br />
<div style="text-align: left;">
<span style="color: #990000; font-size: large;"><b>Information Theory Perspective</b></span></div>
Let’s formulate a question at a little different angle. Let’s assume that we know (very-very roughly) that backlog item <i>U</i> is no bigger than <i>L</i> units of size (can be story points or ideal man-days, doesn’t really matter at this point), but can be any value from <i>0</i> to<i> L</i> with equal chances. Let’s also assume that we have an estimation technique that allows us to estimate the size of <i>U</i> with absolute precision of<i> P</i>. Let’s look at <i>how much information do we obtain about the size of U by applying our estimation technique</i>.
<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-YhVER_2Y_Yc/T7QPgdVnOMI/AAAAAAAAABc/q47FM32UeA0/s1600/Estimation+Precision.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="218" src="http://1.bp.blogspot.com/-YhVER_2Y_Yc/T7QPgdVnOMI/AAAAAAAAABc/q47FM32UeA0/s320/Estimation+Precision.PNG" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<i><span style="font-size: x-small;"><b>Figure 2</b>. Illustration of symbols: U is an arbitrary backlog item; L – maximum possible size of any backlog item from the backlog; P – absolute precision of estimation; the point on the horizontal axis linked to item U shows its size.</span></i><br />
<br />
As we well know from the basics of <i>Information Theory</i>, information (also called <i>mutual information</i> of two experiments, see <a href="http://en.wikipedia.org/wiki/Mutual_information">http://en.wikipedia.org/wiki/Mutual_information</a> for more detail) enclosed in experiment A regarding experiment B can be expressed as follows:
<br />
<br />
<i>I(A,B) = H(B) - H<sub>A</sub>(B)
</i><br />
<br />
Here<i> H(B)</i> is <i>entropy</i> (see <a href="http://en.wikipedia.org/wiki/Entropy_%28information_theory%29">http://en.wikipedia.org/wiki/Entropy_(information_theory)</a> for more detail), or in other words, the level of uncertainty of experiment <i>B</i>; <i> H<sub>A</sub>(B)</i> – is entropy of B after experiment <i>A</i> took place (also called <i>conditional entropy</i>). So now it is easy to interpret the amount of information enclosed in experiment A as the amount of uncertainty it reduces about experiment B.<br />
<br />
Let’s now apply this formula to our case. We have our two “experiments”, one of them <i>(B)</i> consists in finding the absolutely accurate size of our backlog item <i>U</i>. The other one<i> (A)</i> consists in applying our estimation technique and thus reducing the uncertainty to certain extent (i.e. obtaining some information). Without going into mathematical depth we will just note that by applying Shannon’s formula (actually a definition of mutual information) we get:<br />
<br />
<i>I(A,B) = log(L/P)</i><br />
<br />
where the logarithm base is not of extreme importance, can be any number (greater than <i>1</i>) based on the simple feature of logarithms (see <a href="http://en.wikipedia.org/wiki/Logarithm#Change_of_base">http://en.wikipedia.org/wiki/Logarithm#Change_of_base</a> for instance), but typically they use<i> 2</i> as the base for the logarithm which makes good sense from computational standpoint, as we eventually store all information in <i>binary</i> form.<br />
<br />
This latter equation gives us very interesting result: the information that we are obtaining out of estimation grows much slower than the precision of estimation. More specifically, it grows as quickly as logarithm function. Now from the graph of logarithm function below we can see why “little estimation effort helps a lot and big estimation effort helps little”:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-zjnIclCp94I/T7QPU8Kx7qI/AAAAAAAAABU/nshBmneor7Q/s1600/logarithm.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="281" src="http://4.bp.blogspot.com/-zjnIclCp94I/T7QPU8Kx7qI/AAAAAAAAABU/nshBmneor7Q/s640/logarithm.PNG" width="640" /></a></div>
<br />
<i><span style="font-size: x-small;"><b>Figure 3</b>. Logarithmic behavior of information about the size of an item as a result of estimation process. Horizontal axis represents relative precision (or more accurately, the value of L/P) and vertical axis represents information (in bits).</span></i><br />
<br />
And finally using exponential (or close to exponential) estimation scale becomes totally logical – it <i>adds valuable information faster</i>. Indeed any function <i>f(x) = a<sup>log<sub>b</sub>x</sup></i> grows faster than the <i>log<sub>b</sub>x</i> itself (here <i>a</i> and<i> b</i> are both greater than<i> 1</i>). In ideal case, which we certainly do not expect in practice, when <i>a = b</i>, this function simply becomes trivial linear function: <i>f(x) = x</i>. But since we are not trying to state that it is necessarily the case, we say “adds information faster” and avoid saying “adds information linearly”.<br />
<br />
<div style="text-align: left;">
<b><span style="color: #990000; font-size: large;">Normalization Hypothesis </span></b></div>
Another interesting question is, given that most of the teams use Fibonacci sequence as their estimation scale, can they somehow ensure that their “corrected information curve” (i.e. the graph of a corresponding function: <i>f(x) = a<sup>log<sub>b</sub>x</sup></i> ) will grow fast enough to be more useful than the linear scale? Apparently it is safe to say about logarithmic behavior of the “information curve”, but practically finding its exact logarithmic base does not seem an easy task. We can hope though that teams are able to empirically find the right usage of the Fibonacci scale to be able to obtain information efficiently. So what is that “right usage”?..<br />
<br />
For further simplicity (and as we shown before) we can use certain exponential function instead of Fibonacci sequence. Even if the base is fixed (say, <i>f(x) = a<sup>x</sup></i>) our team can change the function itself by… yep, “re-scaling” the story points. Indeed, if at some point they go for a new “meaning” of a story point by saying that, for instance, now two old story points is one new story point, then our function <i>f(x)</i> turns into another function <i>g(t) = f(2x)</i>, where <i>t = 2x</i>. Or conversely, <i>x = 0.5t</i>. If we substitute this expression for x in the formula above, we will get <i>g(t) = b<sup>t</sup></i>, where b is square root of a. <i>g(t)</i> is again an exponential function but with different base. Figure below shows an example of how rescaling impacts the “estimation scale curve” if we take two new story points for every three old story points:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-tVv8EZDhbkE/T7QQdfbQzjI/AAAAAAAAABk/_I2Cp2tpUKE/s1600/Rescaling+the+estimation+base.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="351" src="http://2.bp.blogspot.com/-tVv8EZDhbkE/T7QQdfbQzjI/AAAAAAAAABk/_I2Cp2tpUKE/s400/Rescaling+the+estimation+base.PNG" width="400" /></a></div>
<br />
<i><span style="font-size: x-small;"><b>Figure 4</b>. After re-scaling the estimation base by putting 2 “new” story points for 3 “old” story points the base of the exponential function (“the estimation function”) changes. Blue graph stands for old scale of estimation and red one stands for the new one.</span></i><br />
<br />
This by the way means that:<br />
<br />
<i>Changing the estimation basis in Fibonacci sequence is quite a responsible thing, often underestimated. It may get the team closer or further from efficient estimation. There’s only one ideal base for estimation and it is important to get close to it. </i><br />
<br />
But now we can consider an interesting fact that many agile teams could confirm:<br />
<br />
<i>After some time agile teams often “normalize” (i.e. re-scale story points until they feel really comfortable with it) by arriving at approximately the same estimation base in Fibonacci scale – a team has typically 30 – 60 story points as their average velocity for a two-week sprint. </i><br />
<br />
This of course depends on the team size and would be smaller for the smaller teams and bigger for larger teams. But maybe this is just the way teams optimize their estimation basis over time to efficiently manage the potentially available information. Based on this we formulate our...<br />
<br />
<i><b>Normalization Hypothesis:</b> Agile teams that normalize their estimation base over time, likely arrive at their optimal estimation capability (from the standpoint of information that they acquire about the backlog items they estimate). In other words, they empirically find such an exponential function that makes the “corrected information curve” close to linear. </i><br />
<br />
Although it looks like a bit of a journey to get to a better estimation base, we know we have simple stupid but reliable method to get started. By simply assigning <i>8</i> story points to each team member per sprint seams not a bad initial approximation. Indeed, considering the hypothesis above, it gives us <i>N*8</i> varying from <i>32</i> to <i>64</i> story points when <i>N</i> (the size of the team) varies from <i>4</i> to <i>8</i>. Learn more about this estimation base in (<a href="http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841">http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841</a>, Chapter 8, “Agile Estimating and Velocity”).
</div>Anonymousnoreply@blogger.com107tag:blogger.com,1999:blog-2215754383829886994.post-41638575321690005102012-03-15T00:51:00.041-07:002012-03-15T14:02:16.549-07:00Design And Refactoring Based On Scenarios<span style="font-style:italic;">By Alex Yakyma</span><br /><br />It is very interesting to observe how often we forget the "why's" as compared to the "what's" when talking about approaches and methods. Today we will tackle one such area that software teams should be very familiar with - system design and what we call the "best practices" of designing code (no irony here, it's just that "best practices" sometimes sounds as an oxymoron really).<br /><br />Businesses evolve and development teams have to catchup or even drive this constant change implementing new products, maintaining them thru their life cycle, and if possibly, even doing this efficiently. And as complex as code is per se, teams have to not as much try to "design it right first time" but rather learn how to keep it healthy during the life of a product. One of the primary methods to sanitize the "code smells" is <span style="font-style: italic;">refactoring</span> which can be applied at the different levels of abstraction from the entire system point of view up to a very low level (class-, method-, or statement level). The method itself is known for long time and a lot of books and blog posts published on this topic (some of them are worth very high praise like <a href="http://www.amazon.com/gp/product/0201485672?ie=UTF8&tag=martinfowlerc-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201485672">Martin Fowler's "Refactoring"</a> or <a href="http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?s=books&ie=UTF8&qid=1331799307&sr=1-1">Bob Martin's "Clean Code"</a>, I love these books and I suggest them).<br /><br />But here comes one big problem: both the programming paradigms (namely OOP) and refactoring patterns that reflect best practices within these paradigms spawn a gap between what system should do (let's call it<span style="font-style: italic;"> scenarios</span> for now; e.g.: "login scenario" or "book a flight scenario") and the way it is implemented. One may say: well, but code is low level of abstraction that implements the much more "abstract" requirements. That is only partially true, as the OO analysis suggests: entities of the business domain should be reflected in the system object model and their behaviors encapsulated respectively. So, in other words, there very likely to be classes like "Account", "Contact", "Lead", "Pipeline" etc if we are implementing a CRM system, for example. Of course there will be more, in fact, a whole bunch of auxiliary objects that perform system level functions (like controlling the UI, accessing external web services, or persisting data to a DB etc), but point is that <span style="font-style: italic;">the domain gets reflected in the code</span>. And that is without doubt a good thing. <span style="font-style: italic;">The Problem is though that neither of these classes (domain entities) directly cause defects in software, defects are not in entities in other words, defects lay in scenarios. And unlike domain entities, that are represented as solid "chunks" of code, scenarios are chaotically spread across the system and involve multiple different entities in different context each time</span>. To illustrate this: if you ask a tester on the team, what's the most severe defect in the current system build, he would say something like: zip code not validating during the sign-up - actually referring to a <span style="font-style: italic;">scenario</span>. Whilst if you ask a developer, where exactly this defect is - it would make her think harder as this scenario is not a kind of specific entity or structure in the code she could logically refer to.<br /><br />So what scenarios really are from the code perspective? For those more or less familiar with programming it is very easy to articulate as a program stack trace when the user interacts with the system in the context of a specific scenario. In other words it is (typically long) list of class methods called one after another (typically nested) and to perform a scenario in a pretty mature system you may have tens or even up to a hundred method calls in a particular user scenario. Pretty big number! Well, no wonder it is hard to diagnose the problem in the scenario fast if it takes 30 method calls to go end-to-end. So this spawns a first question:<br /><br /><span style="font-weight: bold; color: rgb(102, 51, 51);">why it takes so many method calls and how to make it less?</span><br /><br />The first thing that pops up is that how small or big are those methods. And here's the problem: one of the conceptual commandments of refactoring suggests that we keep method bodies as well as the list of input parameters short. Quite often it is taken to the extreme extent where the code is just a huge pile of a 5-line methods. And if you ask "Why?" you most likely will never hear a reasonable explanation. But it looks "good" and looks like someone applied an effort in keeping code "well structured". The other extreme side is huge methods. Then of course you may have a stack trace of user scenario consisting of only 5-7 calls but now the problem is how to find a defect in a long method body (that would also accept 15 parameters and depend on another 10 private fields in its class). Now we can apply this logic to designing and refactoring a software system:<br /><br /><span style="color: rgb(102, 51, 51); font-weight: bold;">design the system as a balance between its </span><span style="font-style: italic; color: rgb(102, 51, 51); font-weight: bold;">behavior</span><span style="color: rgb(102, 51, 51); font-weight: bold;"> and </span><span style="font-style: italic; color: rgb(102, 51, 51); font-weight: bold;">structure</span><span style="color: rgb(102, 51, 51); font-weight: bold;">. Apply OO design principles and approaches so that the code not only looks good but is also relatively easy to track and think of as part of specific scenarios.</span><span style="color: rgb(102, 51, 51);"> </span><br /><br />This relates to the entire whole set of OO design principles and concepts. For instance you can make a good use of Single Responsibility Principle to split up a big "stinky" class that lives there for quite a bit and everyone just adds and adds to it. But taken to the extreme point it may spawn tons of classes and deep hierarchies and usage chains that would simply make it impossible to track the logic when applying changes or even debugging a problem.<br /><br />The idea also reveals the other problem with refactoring - unfortunately it so often happens in a "context independent" manner. In other words it doesn't really make much sense to go ahead and restructure the "Account" class (sticking still to our CRM example) because we think we can make it better. It may end up dangerous after all. Instead we refactor it in the context of a scenario. This way we also think of the other scenarios that the change may affect. The good approach would be to pick your current user scenario that you work with, see what classes are affected and if, for example, class "Lead" has a big method which is called as a part of the scenario, then it is just the right time to split it. We split it only to the extent where it adds enough clarity but does not spawn a ton of unnecessary methods each containing 3 lines of code or so.<br /><br />We didn't touch automated testing as another important aspect of this problem, which we'll surely do in the next post or two.<br /><br />Finally, just to put it straight: I'm a big supporter of Object-Oriented Programming, Analysis and System Design and honestly think that it was one of the most significant advancements in the industry. It's not that some other paradigm (like Functional Programming) would solve it. At the same time we must be aware of the actual gap that we described between system behavior and its implementation. It's not just that we know about it but we now also know how to crucially mitigate the impact: we should code and refactor in the context of specific scenarios as opposed to modifying entities alienated from the behaviors associated with them.<br /><br /><center>* * *</center><br />Summary:<br /><ul><li>There's a gap between <span style="font-style: italic;">what</span> should be implemented (scenarios) and <span style="font-style: italic;">how</span> it is implemented (system design)</li><li>Unlike the domain entities, scenarios don't explicitly exist in the code<br /></li><li>Each scenario is typically spread uneven across the codebase and is hard to keep track of, modify or debug<br /></li><li>An easy way to illustrate this problem is just to observe a scenario stack trace - it is typically way too long<br /></li><li>Therefore system design should support a <i>balance</i> between manageable implementation of the scenarios and OOP principles</li><li>To support such a design, refactoring should be performed in the context of a scenario<br /></li><li>This also protects us from taking refactoring methods to the extreme edge which has a hidden negative effect on the system maintainability even though the code may look well-structured and elaborate<br /></li></ul>Anonymousnoreply@blogger.com9tag:blogger.com,1999:blog-2215754383829886994.post-87764595787894792512012-02-09T08:26:00.000-08:002012-02-09T09:21:20.207-08:00Kanban System In New Delhi Airport<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWbj7d9gmgJoXkCdztnRZWawHs6Psh8k66P7qgqwVLS70ohFZ0fOuQHLE2GbEajDJckzGantguodlgzwoOZ_rKapI01BG94LVwi2aQmFTp_KhCcv3iL-Ygsn-MqU8oaYxfjAcsyoJJTXo/s1600/sec-check.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWbj7d9gmgJoXkCdztnRZWawHs6Psh8k66P7qgqwVLS70ohFZ0fOuQHLE2GbEajDJckzGantguodlgzwoOZ_rKapI01BG94LVwi2aQmFTp_KhCcv3iL-Ygsn-MqU8oaYxfjAcsyoJJTXo/s400/sec-check.jpg" alt="" id="BLOGGER_PHOTO_ID_5707184775088550322" border="0" /></a>Few days ago I returned from my Agile consulting mission in Delhi, India for one of the local outsourcing vendors. On the way home I found quite an interesting thing...<br /><br />During the security check process while standing in the line and gradually approaching to the "belt" I noticed these (quite big) number plates, like the one on the picture here. And they apparently use them for two purposes:<br /><br />first, they have them in pairs with same number, so in the end, when you want to get your baggage that went thru the scanning, you just hand the officer your number plate and get your stuff in return. So it is to make sure that you get your own baggage.<br /><br />second, they don't use all the pairs, but give away only limited amount to control the "work-in-progress". This way only limited number of passengers are at the belt at any moment of time.<br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvTVXaBoxY8cMemuDKFqcGixCm4sewD99eT-vM3h_WuhgucMqtVQDzqkChOrkEtJHB5HE63QEAPcBT76_lBUintTK0Lw6kZHrUnJHB9kcthgO4REBPvbWYuFaehjC5uk0_dLKnWtPoo0E/s1600/kanban+cards.png"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 195px; height: 200px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvTVXaBoxY8cMemuDKFqcGixCm4sewD99eT-vM3h_WuhgucMqtVQDzqkChOrkEtJHB5HE63QEAPcBT76_lBUintTK0Lw6kZHrUnJHB9kcthgO4REBPvbWYuFaehjC5uk0_dLKnWtPoo0E/s200/kanban+cards.png" alt="" id="BLOGGER_PHOTO_ID_5707185068062131522" border="0" /></a><br />Interesting scenario, isn't it.<br /><br />It's actually not even Kanban, to be precise. It is CONWIP system, if we consider only the security check as a system. In <a href="http://en.wikipedia.org/wiki/CONWIP">CONWIP</a>, which is also an example of a pull system alternative to Kanban, there is no WIP limit on each step of the process instead there's one WIP limit for the system as a whole. So CONWIP actually means CONstant WIP. It may look not as "configurable" as Kanban but it is way easier to implement. I am especially big fan of this model as, unlike Kanban, it does not drive you to a kind of isolated phases in processes where phases actually have quite fuzzy boundaries like... in case of software development. From this perspective you can call Scrum as a very precise example of CONWIP in software development.<br /><br />Good luck with security checks!Unknownnoreply@blogger.com6tag:blogger.com,1999:blog-2215754383829886994.post-287722172945385082011-10-25T02:05:00.000-07:002011-10-25T02:16:20.497-07:00SAF is bornI <a href="http://www.yakyma.com/2011/10/scaled-agile-framework-meet-up-in.html">recently posted on our Scaled Agile Framework</a> (SAF) project. Today I want to present <a href="http://scalingleanagile.com/saf-is-born">a post by my colleague Drew Jemilo</a> where he describes his impressions of the first SAF summit in Colorado. Nice post and a cool picture with Flatiron Mountains on the background...<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjNAIXNr9txqtNUbVBtKB6GcRxQZ1hbVgM1M0J7v1cMm5CZQ_96TbBGm34RG3aPnjMar7FSJozPU1BFnGtFhGqimtp31p8XHZBylRrACWt1-e7FY0crrlKDi_w97vS_WGJhL8TeSgZmh8/s1600/Art-Is-Born-CEL8039-TheFive.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjNAIXNr9txqtNUbVBtKB6GcRxQZ1hbVgM1M0J7v1cMm5CZQ_96TbBGm34RG3aPnjMar7FSJozPU1BFnGtFhGqimtp31p8XHZBylRrACWt1-e7FY0crrlKDi_w97vS_WGJhL8TeSgZmh8/s400/Art-Is-Born-CEL8039-TheFive.jpg" alt="" id="BLOGGER_PHOTO_ID_5667355906771728226" border="0" /></a>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-2215754383829886994.post-82436492630804757592011-10-21T15:07:00.000-07:002011-10-31T07:44:21.984-07:00Scaled Agile Framework Meet-up in ColoradoI’m in Louisville, Colorado these days (the week of Oct 17) and it’s been about a year since I visited here last time. This time I have an absolutely exciting reason for visiting: the kick-off of the Scaled Agile Framework initiative. The five of us (<a href="http://http//scalingsoftwareagility.wordpress.com/">Dean Leffingwell</a>, <a href="http://scaledagile.com/">Colin O’Neill</a>, <a href="http://fastfrontier.com/">Drew Jemilo</a>, <a href="http://innate-agility.com/">Mauricio Zamora</a> and myself) convene to commence the collaborative effort around creation of Scaled Agile Framework (SAF) – a structured representation of knowledge and practices for scaling Agile delivery model to the enterprise level.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhV3GURitpLRDXffrUhsf6bIr-KICiyIyIH5qF3d9EI2gVPPiHP8IPBdwr3SUI3RDeoN7yosjB0lzcbM5lsKD1DwVRkErOoErpS6sVq9Li1RHJqrU-EwRp5W04_WJ8CPp91cfbqBnsUpA/s1600/At+the+table.JPG"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhV3GURitpLRDXffrUhsf6bIr-KICiyIyIH5qF3d9EI2gVPPiHP8IPBdwr3SUI3RDeoN7yosjB0lzcbM5lsKD1DwVRkErOoErpS6sVq9Li1RHJqrU-EwRp5W04_WJ8CPp91cfbqBnsUpA/s400/At+the+table.JPG" alt="" id="BLOGGER_PHOTO_ID_5666071951210760114" border="0" /></a><br /><br />Dean Leffingwell hosts us at his house (hopefully we are good guests, but I will have to check that with Dean).<br /><br />SAF will be a freely available internet resource representing a big picture of Agile at scale and a detailed outline of its “components”: from individual agile team level to enterprise portfolio level, from agile requirements to technical practices, from agile architecture to continuous improvement and so on – in other words covering all important aspects of Agile delivery at scale.<br />Even though this is our new initiative, the material that will be published isn’t some kind of a brand new stuff and frankly, the <a href="http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841">ASR book</a> by Dean covers much more depth on the topics. Nevertheless, the purpose of SAF is to present the well structured empirically proven knowledge to the industry – it will be publicly available and ready to be used by agile practitioners and consultants in different aspects of scaling.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQJXnklPCKRdMCJcK-PKxih4RBpv_vmrX6HM2tFKUuuCriea_puS8f8PoC2dQ3VpUwWE7kffZYlTok_kU9OITSTrCZbJXQolC368bb9OrmRjjZOIDn7jtX5ciQ72_crwlZmFDkyjXsFKI/s1600/SAF+BP.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQJXnklPCKRdMCJcK-PKxih4RBpv_vmrX6HM2tFKUuuCriea_puS8f8PoC2dQ3VpUwWE7kffZYlTok_kU9OITSTrCZbJXQolC368bb9OrmRjjZOIDn7jtX5ciQ72_crwlZmFDkyjXsFKI/s400/SAF+BP.png" alt="" id="BLOGGER_PHOTO_ID_5666072088289465378" border="0" /></a><br /><br />I’m thrilled with the idea that with SAF you will be finally able to use the "Big Picture" interactively and so, for instance, clicking on Inspect & Adapt (I&A) icon will redirect you to a web page that describes the technique. And same way it will work for “Agile Team”, “Epic”, “Demo”, “PSI”, “Agile Release Train” and so on and so forth. Basically 90% or more of the Big Picture objects will be navigable.<br />These days we are planning for the releases of the SAF, and executing the top priority items…<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQFCWgCy3eIUsy9kA_O6EHovTsppIazwsEJxCjRkjMKYAJ4UmHXjygXiaqoctBSeC9_yU7JeP_o8E8nc0VQY-cekYl8TWvGKn1xN7nAJqFtEWPfdqRd6t3aip4P-ftRsT8OYbb8SeYl9s/s1600/Our+kanban+board.JPG"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQFCWgCy3eIUsy9kA_O6EHovTsppIazwsEJxCjRkjMKYAJ4UmHXjygXiaqoctBSeC9_yU7JeP_o8E8nc0VQY-cekYl8TWvGKn1xN7nAJqFtEWPfdqRd6t3aip4P-ftRsT8OYbb8SeYl9s/s400/Our+kanban+board.JPG" alt="" id="BLOGGER_PHOTO_ID_5666072555889624770" border="0" /></a><br /><br />We already created the roadmap that we are totally glad to share with the community – it looks into a period of the next three month and represent a variant of incremental delivery of content and site features. Over time we will be reporting on the progress too…<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgoBuLzGYwRLjcJxc3AVIlTKzeD11B0fmRmbIAhA7mNk7G17FJWNVAFnd_xegjfDyDlkP-G0khuH6rqVlgidgkJXNw_Fz9tSej8-5ldQfFFWvqMK7W-m2p2EzoZPsgroBjBHOogk_9vDHs/s1600/SAF+Roadmap.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 263px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgoBuLzGYwRLjcJxc3AVIlTKzeD11B0fmRmbIAhA7mNk7G17FJWNVAFnd_xegjfDyDlkP-G0khuH6rqVlgidgkJXNw_Fz9tSej8-5ldQfFFWvqMK7W-m2p2EzoZPsgroBjBHOogk_9vDHs/s400/SAF+Roadmap.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5669667014983409170" /></a><br /><br />The website URL is <a href="http://www.scaledagileframework.net/">http://www.scaledagileframework.net/</a>. It is already there, you can browse thru the main aspects of SAF concept already that will be soon implemented in accordance with the roadmap. Our little “Sprint” in Colorado is gradually approaching its end and this is really good as most of the “meta-stories” are getting finished and it frees a way for content creation and publishing.Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-2215754383829886994.post-27487290737139645092011-09-25T09:54:00.000-07:002011-09-25T10:43:18.415-07:00The Legitimacy of Release BacklogWe heard this story tens or even hundreds of times: there's sprint backlog and product backlog in Scrum. Sometimes I hear even more specific statements, like: there should not be any other backlog at all, besides the two mentioned earlier. Question is whether release backlog is legitimate entity in Scrum or not? That's our target...<br /><br />So, before I start convincing you that there are very strong reasons to maintain one, let's agree upon the rules of the game: not everything states in Scrum axioms is necessarily a real life model but rather some kind of necessary simplification or abstraction. Let me give you an example... How many software companies do you know that have no engineering managers (or their equivalent)? I guess none! Even those claiming they adopted Scrum, they themselves still have engineering management. Now, as a Scrum primer, there's only three roles in Scrum, we know it: Team, PO, SM - no managers! See where I'm heading?.. It's like a chess game... total abstraction: you only have few kinds of chess pieces even though there's way more military ranks and arms in real life.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcU-PI9DdXlPpvlL7aDu4R8Wl1YQhhFGI3IVQKNWP3XvJydfrdaqQd3k0GYvFXcasOhK9NpE6ztVrIem4IqV6FmQt4MaQ_fo1Adeb7Ntx7dirkX-WOXCJHfO12HR_2MhC8ZJlEJ-sONYA/s1600/Chess.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 354px; height: 400px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcU-PI9DdXlPpvlL7aDu4R8Wl1YQhhFGI3IVQKNWP3XvJydfrdaqQd3k0GYvFXcasOhK9NpE6ztVrIem4IqV6FmQt4MaQ_fo1Adeb7Ntx7dirkX-WOXCJHfO12HR_2MhC8ZJlEJ-sONYA/s400/Chess.jpg" alt="" id="BLOGGER_PHOTO_ID_5656353192156751698" border="0" /></a><br /><br />So why do we need release backlog?<br /><br />Well, first of all business thinks that way. Business thinks in tangible releases and I can't say that that is a bad thing. Let's think about it for a second, what is a release as we know it? It is some kind of solid and logically consistent chunk that represents marketable value. We still assume that scope is variable but it does not mean that variability should be so high that we can't approximately say what will be released. Eventually, epics and stories that go into releases are some sort of "containers" (negotiable, the second term in the <a href="http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/">INVEST acronym by Bill Wake</a>) - their content may vary to some extent, but still business wants to know what containers (think of it as labels on the release product box; similar metaphor to "Product Box" game in <a href="http://www.amazon.com/Innovation-Games-Creating-Breakthrough-Collaborative/dp/0321437292">Luke Hohmann's "Innovation Games"</a>) will be included. Sounds legitimate, as product management, company leadership, their investors and users want to know.<br /><br />Next, Release backlog is impotant because it is bound to Release Planning. Only sprinting may not be enough, especially in the case of large scale distributed development. I saw this multiple times in case of big product development effort and even more so in case of outsourcing: Release Planning is the primary chance for teams and objectives alignment, obtaining shared context and building common understanding of "what it is we are working on". I witnessed the case in Mumbai (India) when after a two-day distributed release planning session one of the developers said at the retrospective meeting: "Before this planning session we didn't even really know each other in the program and now we are like a family..." - very strong comparison in India, I have to say... as family is everything.<br /><br />For a large scale development release planning is not even about "scoping" or "scheduling" but a chance to better express stakeholders' expectations, to convey business and technology vision to agile teams and get their understanding of what they can deliver resulting in a mutual committment. Sprint planning is simply too frequent and too local to get to this level of high-rank stakeholders involvement and direct teams-stakeholders collaboration.<br /><br />Next reason is that stakeholders like to not only see what's in the release but also what isn't. Sometimes it is very helpful to elaborate the Release N Plan and a draft plan for Release N + 1. This also provides a meaningful guideline for everyone in the company as to where are we heading as a business - sort of information product backlog will not necessarily convey to you. It may simply be hidden behind layers and layers of features and user stories. Instead quite often we use very straightforward and compact mechanism to express a release backlog - Release Objectives - very short statements of intent for the release. It is very easy to comprehend and having 15 such objective sheets for 15 teams in a program makes it much easier for stakeholders to understand and discuss what teams may actually deliver.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3Ege4Gp7_mreC9BPG8ymKUuOIyv9MYGjC0-3DecL0X9HjsbjBpgpx9fdKHRlnJFVMCxPjpiTXfBwcydopHnYkIbiLBbyMZkytmgGdOKQ4ECWdq5O1GOIBdpwSGY4XuGcn6SMND5-xkCk/s1600/Objectives.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 304px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3Ege4Gp7_mreC9BPG8ymKUuOIyv9MYGjC0-3DecL0X9HjsbjBpgpx9fdKHRlnJFVMCxPjpiTXfBwcydopHnYkIbiLBbyMZkytmgGdOKQ4ECWdq5O1GOIBdpwSGY4XuGcn6SMND5-xkCk/s400/Objectives.jpg" alt="" id="BLOGGER_PHOTO_ID_5656353954111208466" border="0" /></a><br /><br />What is sometimes offered as an alternative to a release planning and release backlog is mean velocity. So you simply make a projection against your product backlog. There's nothing wrong with the tool but only if you use it for rough approximation purposes. Other than that there may be serious trouble involved. Imagine distributed program, that has not yet finished their transition from component oriented to feature oriented group configuration, in which one of the Indian component teams leaves for 1-week vacation during Ganesh Chaturthi and prohibits entire program (including US teams) from delivering anything substantial in that sprint. It's hard to catch this if you don't go thru release planning exercise.<br /><br />Finally, when dealing with Release Backlog, we have a chance to spot and start fixing the root causes of problems with product development such as insufficient stakeholders' involvement, lack of business expertise on the side of engineering, etc.<br /><br />I don't even seriously touch the technology vision part in this post as it is itslef a huge topic. I can direct the reader to this great <a href="http://scalingsoftwareagility.files.wordpress.com/2008/08/principles_agile_architecture.pdf">outline of enterprise architecture concepts by Dean Leffingwell, Ryan Martens and Mauricio Zamora</a>. I will only mention one metaphor from there - architecure runway - the distance for an architecture epic to take off. The bigger the system the longer the runway, which is hard to argue. Now you see, it is useful to see what we can count on technologically in different points of time and best way to do so is via releases as major "consumers" of architecture and infrastructure epics.<br /><br />Topics that fall beyond basic axioms of a theory are most exciting and sensitive as they originate from the contraversies of practical applications. It's good we have them...Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-2215754383829886994.post-55243795297465584342011-09-21T11:47:00.000-07:002011-09-21T12:31:18.694-07:00Concurrent Unit Testing Kata in MumbaiLast week I ran a workshop for agile teams in Mumbai, which I'm so glad to visit again and again and see their progress. This time we plunged into Concurrent Unit Testing. I am lately avoiding the term TDD, not because there's anything wrong with the practice itself but sometimes I see this weird perception: "TDD is not for us", "it's too extreme" etc. Well, it is extreme, but who said extreme things aren't simple?<br /><br />Four hours of kata session (see previous posts to see how "kata" format works in different cases) was quite enough to kill a couple of myths. First myth, saying that writing tests before code isn't natural... I guess teams realized quite the opposite after their first few methods implemented after we specified their behaviors as JUnit tests. Second myth, saying that pair work is too extreme. I think guys didn't even notice that they started spending 100% time with a partner in front of a notebook.<br /><br />So, two people always sitting at the front table... writing tests, coding, talking out loud. What they do is on the projector. Everybody sees that and think about the next steps. Every 7-10 minutes we change one of the partners with someone from the group and move on, and then introduce another new person in the next 10 minutes and so on.<br /><br />The process is very smooth, we would only halt to emphasize something important to the audience, e.g.: "now, if we have a situation when a test compiles but causes run-time exception - this very likely means that we will be adding more tests to catch the problem with this test"... and then we would move on again.<br /><br />Couple more steps and our Enterprise Chat Server is now functioning and we move to its advanced features. Devs rushing to make further progress...<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMWJrTjbhW4JC_OU0fZ7EBfFgMQv_3DK3JBoXnu7hDSThCm1G-jN0bmFhlNdl-lttHA36QiKENP4Rjfv1Nbmgj2X5HjK5DLTgOHAH7-fgp1QC-WMMjkj1sAuD11WG5Y5FlOkHkOKE9Ah8/s1600/kata1.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 288px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMWJrTjbhW4JC_OU0fZ7EBfFgMQv_3DK3JBoXnu7hDSThCm1G-jN0bmFhlNdl-lttHA36QiKENP4Rjfv1Nbmgj2X5HjK5DLTgOHAH7-fgp1QC-WMMjkj1sAuD11WG5Y5FlOkHkOKE9Ah8/s400/kata1.jpg" alt="" id="BLOGGER_PHOTO_ID_5654887466286533538" border="0" /></a>Oh... and the polar teddy bear that I bought in Vienna for these guys as a prize for the best performance went to two guys this time, because it was really hard to decide who of them was a better agile dev. Now each of the two will own the bear for a sprint, because guys are from different scrum teams.<br /><br />It was fun... for everyone, even though it's hard work. Only Eclipse, JUnit and no Powerpoint slides.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-2215754383829886994.post-13408619741050170212011-08-23T00:04:00.000-07:002011-08-23T00:28:49.114-07:00Story Splitting KataLast Friday we had a beautiful kata on splitting user stories. This skill is extremely important for agile teams as they have to be able to reliably:
<br />
<br />a) Split user stories into smaller stories that fit into a sprint. And more so, good if they take few days, not a whole duration of a sprint, to keep the sprint outcome more predictable, and...
<br />
<br />b) Split these smaller stories in even smaller cuts (which still are user stories), not necessarily explicitly, so that one cut will be the result of a single "Define-Build-Test" cycle.
<br />
<br />We had six people + me, this is max to have kata exercise going really efficient. Especially this group was really and quite concentrated on the effort entire 90 minutes period. In the beginning the group comes up with the idea of a product that everyone can understand (in our case that was online currency converter supporting multiple different sources of exchange rates). Then we write first big epic and split it to as many user stories as we can. Eventually quantity translates into quality as we use different methods to split stories and acquire deeper and deeper understanding of the functionality and bounded context.
<br />
<br />Alex Ginda was assisting me along the process, agile master and the photographer :) I appreciate his effort and grateful to Luxoft training center for providing us with the facilities.
<br />
<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqmOuPFSUStkeQ5_6tGG6O6_iEutfbgzX5WDtrGtlgFNrUVSjGzRpAWQTSF4T0BggQeJ47hPl1ALTwmv6y7HO5GpHZ6uNi05tbAtPNf_QdP_3UafB3N9kCNkriTiq6NIxl10zxrPaFDL8/s1600/2.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 299px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqmOuPFSUStkeQ5_6tGG6O6_iEutfbgzX5WDtrGtlgFNrUVSjGzRpAWQTSF4T0BggQeJ47hPl1ALTwmv6y7HO5GpHZ6uNi05tbAtPNf_QdP_3UafB3N9kCNkriTiq6NIxl10zxrPaFDL8/s400/2.jpg" alt="" id="BLOGGER_PHOTO_ID_5643949408016699346" border="0" /></a>
<br />
<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgXUZ_riNYhqkZ-sZu-J7gNpPOPnj9YJ1HBTtlN_o58Xp0Ao4qcbijgYa8c32D7Crx9ukq95hubcc9oFev7IJ8ECjT_ay_vDoAYUuYGUyE69-Ip2kPSJy5wPNbaM4GIIHue1a4sNYA4RQ4/s1600/4.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 299px; height: 400px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgXUZ_riNYhqkZ-sZu-J7gNpPOPnj9YJ1HBTtlN_o58Xp0Ao4qcbijgYa8c32D7Crx9ukq95hubcc9oFev7IJ8ECjT_ay_vDoAYUuYGUyE69-Ip2kPSJy5wPNbaM4GIIHue1a4sNYA4RQ4/s400/4.jpg" alt="" id="BLOGGER_PHOTO_ID_5643949404014003074" border="0" /></a>Unknownnoreply@blogger.com6