tag:blogger.com,1999:blog-208439542024-03-07T07:25:46.371+01:00KallokainFrom the Trenches of Business Management ConsultingKallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.comBlogger305125tag:blogger.com,1999:blog-20843954.post-84044202625847158182024-02-04T22:40:00.000+01:002024-02-04T22:40:00.632+01:00Agile Requirements Structures, Part 1<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaV8v_k_yG8JwQztzE1BxwkVYprHoyP1Zdo7IZI69ozfDcRhbshp9zUIiEWOJPXRL4qmQSs8hBSwlPh43tUPRYiMgfpceEXrIgBYCvsU4cQslhh_zwarv3yce1vQi9Ri-iTgCQrfF6sFKxSQcBUDXUsNZ6BlMjhzq83I_K6HZeKGayhYrbYqe86A/s1920/Confused-by-Requirements.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1242" data-original-width="1920" height="414" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaV8v_k_yG8JwQztzE1BxwkVYprHoyP1Zdo7IZI69ozfDcRhbshp9zUIiEWOJPXRL4qmQSs8hBSwlPh43tUPRYiMgfpceEXrIgBYCvsU4cQslhh_zwarv3yce1vQi9Ri-iTgCQrfF6sFKxSQcBUDXUsNZ6BlMjhzq83I_K6HZeKGayhYrbYqe86A/w640-h414/Confused-by-Requirements.png" width="640" /></a></div><br /><p>If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them.</p>
<p class="p3"><span class="s1">There are many causes for this confusion. Here are some of the more common I have seen:</span></p>
<ul class="ul1">
<li>Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation.</li>
<li>The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it.</li>
<li>The organization has not documented its own requirements model very well.</li>
<li>The organization mixes two or more different requirements models, often without realizing it.</li>
<li>The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when <a href="https://www.smithsonianmag.com/history/stanley-meets-livingstone-91118102/">Henry Stanley found David Livingstone</a>.</li>
<li>The organization uses tools that locks it into a requirements model that is a poor match with the organization’s needs. Jira and Azure are the two worst offenders I know of.</li>
<li>The original requirements model the organization based its own requirements model on is confusing, and may have omissions, or outright bugs. (Looking at you, <a href="https://scaledagileframework.com/safe-requirements-model/">SAFe</a>!)</li>
<li>Some combination of the above.</li>
</ul>
<p class="p3"><span class="s1">Agile has two common types of requirements models, </span><em><span class="s2">User Story</span></em><span class="s1"> based models, and </span><em><span class="s2">Use Case</span></em><span class="s1"> based models. In this article, I’ll write about </span><em><span class="s2">User Story</span></em><span class="s1"> based requirements models. The two models can be mixed, sort of, but one needs to understand them both, or confusion will ensue.</span></p>
<p class="p3"><span class="s1">I won’t go into detail about each type of requirement. Rather, I’ll focus on the overall structure. I will provide links, mostly to the SAFe website, to pages where you can read more about each type of requirement.</span></p>
<p class="p3"><span class="s1">I’ll start by deconstructing the SAFe requirements model. This model can be quite confusing, but we will untangle it step by step, make a few adaptations, and come up with a model that is both understandable and useful. This model probably will not fit your organization as-is, but it can provide a base structure that is easier to adapt than the SAFe model, or the requirements-from-hell models in Azure and Jira.</span></p>
<p class="p3"><span class="s1">I’ll write in more detail about the various types of requirements in a future blog post.</span></p>
<h1 class="scr1"><strong><span class="s3">Untangling the SAFe requirements model</span></strong></h1>
<p class="p3"><span class="s1">Prepare to be confused! Here is the SAFe requirements model, as it is presented on the </span><a href="https://scaledagileframework.com/safe-requirements-model/"><span class="s1">SAFe website</span></a><span class="s1">:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYbRjH1uHBGNVhFCpywtVMlrCVfRQDTFv_-asF6d1f2a_-cDbEHSkp32kix3-Q-AwTJgnoUz5r5hkAyu-5_v-8jG8orGHCSuaBHUyzHTd5LpvW2bYHObTnhZvB305cCn2ESD9nFnPOMgxU_avsPC8t_l5AWnuCfFxoaiqVaJnkCn4sEOXv9y7RrA/s1920/SAFe-Requirements-Model.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1080" data-original-width="1920" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYbRjH1uHBGNVhFCpywtVMlrCVfRQDTFv_-asF6d1f2a_-cDbEHSkp32kix3-Q-AwTJgnoUz5r5hkAyu-5_v-8jG8orGHCSuaBHUyzHTd5LpvW2bYHObTnhZvB305cCn2ESD9nFnPOMgxU_avsPC8t_l5AWnuCfFxoaiqVaJnkCn4sEOXv9y7RrA/w640-h360/SAFe-Requirements-Model.png" width="640" /></a></div><p class="p2">If you find the above model easy to understand, you are way smarter than me. I need to untangle it, step by step, to understand what’s going on.</p>
<p class="p3"><span class="s1">First of all, this diagram is a re-purposed UML (Universal Modeling Language) Class Diagram. A Class Diagram is intended to show the relationships between classes when doing Object Oriented program design. It is good at modeling classes and subclasses, and realizations, where one object specifies behavior and another object executes it. Class Diagrams suck at modeling information hierarchies, which is what a requirements model is.</span></p>
<p class="p3"><span class="s1">Using this kind of diagram causes a mismatch between what we try to describe, and the way we describe it. In the world of information modeling, this is called an </span><em><span class="s2">impedance mismatch</span></em><span class="s1">.</span></p>
<p class="p3"><span class="s1">The diagram above uses the phrase “realized by” to describe levels in the requirements hierarchy, which makes the whole thing difficult to understand, especially for business people. An additional problem is that the diagram describes too many things at once.</span></p>
<p class="p3"><span class="s1">Let’s simplify a bit, and focus on the requirements hierarchy:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBfgkDfYM-f5cHkBz43P3HnJ71tcmX7ofWy8EqB73moXBo20CADMmraa8ongSirBReZFAycQ9qwVWaQ3uq0k-aeIaLa8Qc-JUsfHW-U8F6NXLwoXCERF4aIVLl5d2v5u7S3sxFMANbt1IzzESyG40XYYFqu6x1DkJKOaDD1RXF_mw4c-7fep4SMw/s1920/SAFe-Requirements-Hierarchy.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1080" data-original-width="1920" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBfgkDfYM-f5cHkBz43P3HnJ71tcmX7ofWy8EqB73moXBo20CADMmraa8ongSirBReZFAycQ9qwVWaQ3uq0k-aeIaLa8Qc-JUsfHW-U8F6NXLwoXCERF4aIVLl5d2v5u7S3sxFMANbt1IzzESyG40XYYFqu6x1DkJKOaDD1RXF_mw4c-7fep4SMw/w640-h360/SAFe-Requirements-Hierarchy.png" width="640" /></a></div><p class="p2">Drawn this way, using a hierarchical diagram, the SAFe structure still looks like an overcomplicated mess. It has one advantage though: We can begin figuring out what’s wrong with it!</p>
<p class="p3"><span class="s1">Taking it from the top, we have six different top entities in the structure. This is weird, because as in </span><a href="https://www.youtube.com/watch?v=sqcLjcSloXs"><span class="s1">Highlander</span></a><span class="s1">, there can be only one. Well, at least, we would expect there to be only one. We certainly would not expect it to be more different types of entities at the top than at the bottom.</span></p>
<p class="p3"><span class="s1">Let’s have a closer look!</span></p>
<p class="p3"><span class="s1">Look at the three types of Business Epic: Portfolio, Solution Train, and ART.</span></p>
<p class="p3"><span class="s1">Without going into details, in SAFe, a </span><a href="https://scaledagileframework.com/portfolio/"><span class="s1">SAFe portfolio</span></a><span class="s1"> is</span></p>
<p class="p4" style="text-align: left;"><span style="background-color: white;"><span class="s1">“…a </span><em><span class="s2">set of value streams</span></em><span class="s1"> that delivers a continuous flow of </span><em><span class="s2">valuable solutions</span></em><span class="s1"> to customers within a common funding and governance model.”</span></span></p>
<p class="p3"><span class="s1">For example, a portfolio could be a group of products. I emphasized a few words in the quote above, because they are important, as we will see.</span></p>
<p class="p3"><span class="s1">A </span><a href="https://scaledagileframework.com/solution-train/"><span class="s1">Solution Train</span></a><span class="s1"> is:</span></p>
<p class="p4"><span class="s1">“…the organizational construct used to build large solutions that requires the coordination of multiple ARTs and suppliers.”</span></p>
<p class="p3"><span class="s1">Putting these two quotes together, it is pretty obvious that a portfolio is higher in the organizational hierarchy than a Solution Train. This implies that a Portfolio Business Epic should be </span><em><span class="s2">higher</span></em><span class="s1"> in the information hierarchy than a Solution Train Business Epic.</span></p>
<p class="p3"><span class="s1">And yet, according to the SAFe Requirements Model diagram, they are on the same level. This looks suspiciously like an error in the original diagram.</span></p>
<p class="p3"><span class="s1">Before we draw conclusions, let’s look at the </span><em><span class="s2">ART Business Epic</span></em><span class="s1">:</span></p>
<p class="p3"><span class="s1">ART is an acronym that stands for </span><em><span class="s2">Agile Release Train</span></em><span class="s1">. An </span><a href="https://scaledagileframework.com/agile-release-train/"><span class="s1">Agile Release Train</span></a><span class="s1"> is:</span></p>
<p class="p4"><span class="s1">“…a long-lived team of Agile teams that incrementally develops, delivers, and often operates one or more solutions in a value stream.”</span></p>
<p class="p3"><span class="s1">It seems clear from the descriptions that, since a Solution Train coordinates several ARTs, and it is the ARTs that develops and delivers the solutions, a Business Solution Epic should be at a higher hierarchical level than a Business ART Epic.</span></p>
<p class="p3"><span class="s1">Thus we can form a hypothesis: The hierarchical order of Business Epics, from the top and down is: Portfolio Business Epic, Solution Train Business Epic, and last and least, ART Business Epic.</span></p>
<p class="p3"><span class="s1">If we check SAFe’s </span><a href="https://scaledagileframework.com/epic/"><span class="s1">Epic page</span></a><span class="s1">, we find that it is mostly about Portfolio Epics. There is one interesting paragraph:</span></p>
<p class="p4"><span class="s1">There are two types of epics, each of which may occur at different levels of the Framework. Business epics directly deliver business value, while enabler epics advance the Architectural Runway to support upcoming business or technical needs.</span></p>
<p class="p3"><span class="s1"> This confirms that there are Epics that “may occur at different levels”. In other words, there is a hierarchy of Epics. This directly contradicts the </span><em><span class="s2">structure</span></em><span class="s1"> in the diagram of the requirements model, but it is consistent with the </span><em><span class="s2">naming</span></em><span class="s1"> of the Epics in the same diagram. The quote does not say explicitly what the hierarchy is, but the order we hypothesized seems reasonable, so we will go with that.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjM7PPgNyiOAQAGdjkcBI0kMlCcf2lC9s5K0q1RE4OMGLPyqGET8pxnQnG7-c9BnvxQiTKTOZg4zDWEgbDcvRC9hO6wAT1FE64WpuaoLrtfXykf2foAuoHs0wCS8eUHv_lY77yOg5VOPy6pY9JZzd4q4orbH2Nb3IqyhFLsZC28tAkgedn5BZ3EkA/s1920/Fixing-SAFe-Business-Requirement-Hierarchy-Errors-01.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="800" data-original-width="1920" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjM7PPgNyiOAQAGdjkcBI0kMlCcf2lC9s5K0q1RE4OMGLPyqGET8pxnQnG7-c9BnvxQiTKTOZg4zDWEgbDcvRC9hO6wAT1FE64WpuaoLrtfXykf2foAuoHs0wCS8eUHv_lY77yOg5VOPy6pY9JZzd4q4orbH2Nb3IqyhFLsZC28tAkgedn5BZ3EkA/w640-h266/Fixing-SAFe-Business-Requirement-Hierarchy-Errors-01.png" width="640" /></a></div><br /><p class="p2">If we ignore the Enabler type entities for the moment, we can see in the original UML diagram that Business Capabilities are above Business Features, and Business Features are above User Stories.</p>
<p class="p3"><span class="s1">We now have:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHhKpRlcRvLAi6xt-c1WAxrjo7NACqrRqmB3UOSf5oL1rJr8F4uaKCKKJD0zPtbTFzvBwGbRs8lXGIVMquy4XpH6as3gA2NYzNOCrg4LeZ3zIDxrSaHykVy0nr7ZCRT3GM7Ph8HMqw35MerxpJMT0uBa_6z_EbvRTSywgageIxMmFn75G_yZkAvg/s1920/Partial-Business-Hierarchies-01.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="704" data-original-width="1920" height="234" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHhKpRlcRvLAi6xt-c1WAxrjo7NACqrRqmB3UOSf5oL1rJr8F4uaKCKKJD0zPtbTFzvBwGbRs8lXGIVMquy4XpH6as3gA2NYzNOCrg4LeZ3zIDxrSaHykVy0nr7ZCRT3GM7Ph8HMqw35MerxpJMT0uBa_6z_EbvRTSywgageIxMmFn75G_yZkAvg/w640-h234/Partial-Business-Hierarchies-01.png" width="640" /></a></div><p class="p2">We can tie this together, because the UML diagram says Epics are realized by Capabilities, which means all Epics are above Capabilities in the hierarchy.</p>
<p class="p3"><span class="s1">We get:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi64H7ZH65h3W7SQ3AuN5kM8UUYYLiIJMhrHZN451fkMQJPU9m0xBwOhLuIp8wsOn80lbBGPlX5T6UzLv63bB1TK4W15LPDJj1cj21H-6n_l6faDxuiLaulxEOoveUvnaV1sAtUQ2xEobbskoursFx0q6tP__dYrPOp-goh4sW810rQPfr8f6jvgA/s1920/Partial-Business-Hierarchies-02.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1080" data-original-width="1920" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi64H7ZH65h3W7SQ3AuN5kM8UUYYLiIJMhrHZN451fkMQJPU9m0xBwOhLuIp8wsOn80lbBGPlX5T6UzLv63bB1TK4W15LPDJj1cj21H-6n_l6faDxuiLaulxEOoveUvnaV1sAtUQ2xEobbskoursFx0q6tP__dYrPOp-goh4sW810rQPfr8f6jvgA/w640-h360/Partial-Business-Hierarchies-02.png" width="640" /></a></div><p class="p2">Note that Business Capability is an optional entity, so in the original UML diagram, any kind of Epic can contain a mix of Business Capabilities and Business Features. We will deal with that later. For now, we will assume Business Capabilities are always there.</p>
<p class="p3"><span class="s1">What about Enablers?</span></p>
<p class="p3"><span class="s1">According to the SAFe </span><a href="https://scaledagileframework.com/enablers/"><span class="s1">Enabler page</span></a><span class="s1">, Enablers are:</span></p>
<p class="p3"><span class="s1">“…backlog items that extend the architectural runway of the solution under development or improve the performance of the development value stream.”</span></p>
<p class="p3"><span class="s1">To decode that, we need to know what an </span><a href="https://scaledagileframework.com/architectural-runway/"><span class="s1">architectural runway</span></a><span class="s1"> is:</span></p>
<p class="p4"><span class="s1">“The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features with minimal redesign and delay.”</span></p>
<p class="p3"><span class="s1">So, an Enabler is a requirement to build a piece of technical infrastructure, or component, or a major refactoring needed to improve performance, or simplify a design.</span></p>
<p class="p3"><span class="s1">In other words, an Enabler is a task. Depending on the type of Enabler, it can be anything from a relatively small task, to a really, really big task.</span></p>
<p class="p3"><span class="s1">If we look at Enablers only, we can see in the original UML diagram that Enablers are structured exactly the same way as business requirements. The structures are intertwined, but we will start by looking at them separately:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGsqpsa5PTmpxx6-HlJ4PmZrGs1rqzd9EKnf3Q5ve-XcLlSU_QQYITbQ1aOpahP7pNWkvAb4EoyWEl2G721xklDgBpLuOIhY7zGBEtMz7rynAJ_d5OEkLO6S1FIUKYDZYJcu4tWs2xnGPYVLhu6N94lALiyEauD5TJgSGgi2-X8mLNTG3sEfxGNA/s1920/Business-Requirements-and-Enabler-Requirements-Separated.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1080" data-original-width="1920" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGsqpsa5PTmpxx6-HlJ4PmZrGs1rqzd9EKnf3Q5ve-XcLlSU_QQYITbQ1aOpahP7pNWkvAb4EoyWEl2G721xklDgBpLuOIhY7zGBEtMz7rynAJ_d5OEkLO6S1FIUKYDZYJcu4tWs2xnGPYVLhu6N94lALiyEauD5TJgSGgi2-X8mLNTG3sEfxGNA/w640-h360/Business-Requirements-and-Enabler-Requirements-Separated.png" width="640" /></a></div><p class="p2">To me, it is weird that an enabler can be at the top of the requirements hierarchy. An Enabler should always enable something on the business side. If you do not have that connection, it is easy to build a system with a lot of Enablers that serve no business purpose. This can happen in functionally organized organizations, where architects and the business side live in functional silos, with little contact with each other.</p>
<p class="p3"><span class="s1">It would be nice if we could see in the structure that an Enabler enables something with business value. Technically, we could do this with lateral links, for example, a link between Portfolio Business Epic and Portfolio enabler Epic. I would prefer to do without lateral links unless absolutely necessary, so let’s try it by modifying the hierarchy first:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7xpUDWYHCTCoHVoTf2TtVBkYJZ-8FDUvgW3LqCbOBUF17pyiBKz5mVQOiIu1oF47fELc4egVj_T_eerDFCy9AYn3BRJmPAX3ztZr-ldq4dCLTXCvlAz8ydI6x7sBwzpRNSwNfR-a1X0YJx47r2was3OiIG9cn02C-iaN8xRbkKiQqaO7f6B2mug/s1920/Business-Requirements-and-Enabler-Requirements-linked-01.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1242" data-original-width="1920" height="414" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7xpUDWYHCTCoHVoTf2TtVBkYJZ-8FDUvgW3LqCbOBUF17pyiBKz5mVQOiIu1oF47fELc4egVj_T_eerDFCy9AYn3BRJmPAX3ztZr-ldq4dCLTXCvlAz8ydI6x7sBwzpRNSwNfR-a1X0YJx47r2was3OiIG9cn02C-iaN8xRbkKiQqaO7f6B2mug/w640-h414/Business-Requirements-and-Enabler-Requirements-linked-01.png" width="640" /></a></div><p class="p2">This looks a little bit better, because now, Enablers are always tied to business value. The names look a bit weird. For example, it would make sense if a Portfolio Enabler Epic was named Portfolio Epic Enabler, because it is an Enabler that enables a Portfolio Epic.</p>
<p class="p3"><span class="s1">Let’s try it out:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvF7-eLSEbcFmbNu6VR-2LQsFuaLkW0TP2XUWqzcEddVodNWbH79VjTJEs2YvxbP6WjTWvW9gUQ3g8fxTGhR0Q_wqnDtNod27bXp5u0igzuzjS9l9xi-0g1JNGDb9YBtaY6_ek7L2LhkNqFn_8Sb7N2lyP_f6vh9NMnb5TtfvF2qE7yGi_AujS3A/s1920/Business-Requirements-and-Enabler-Requirements-linked-02.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1242" data-original-width="1920" height="414" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvF7-eLSEbcFmbNu6VR-2LQsFuaLkW0TP2XUWqzcEddVodNWbH79VjTJEs2YvxbP6WjTWvW9gUQ3g8fxTGhR0Q_wqnDtNod27bXp5u0igzuzjS9l9xi-0g1JNGDb9YBtaY6_ek7L2LhkNqFn_8Sb7N2lyP_f6vh9NMnb5TtfvF2qE7yGi_AujS3A/w640-h414/Business-Requirements-and-Enabler-Requirements-linked-02.png" width="640" /></a></div><p class="p2">In every organization I have worked with, people omit the word “business” when referring to business requirements. I’ll do the same, because the word “Enabler” still distinguishes the Enablers. I’ll also add Task as a sub-level to User Story, just so you won’t wonder why it isn’t there:</p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiE9TqvVbPMXiGsX19JwU4OHRoWIVsXfFa2nw51pCRpa91DJEU3FJKhDhQYLR7isWRG1xeHBumdkLAgEih2o16WLeRkJFhPp43PpRa0gVP6Kivqm_bBklUaftvtfcn1mCnqExKcaYI1AO6_ghXeJwwCKEUnuZBtP1Steozg_0SEQQF-sa6jF5yfCg/s1920/Business-Requirements-and-Enabler-Requirements-linked-03.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1242" data-original-width="1920" height="414" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiE9TqvVbPMXiGsX19JwU4OHRoWIVsXfFa2nw51pCRpa91DJEU3FJKhDhQYLR7isWRG1xeHBumdkLAgEih2o16WLeRkJFhPp43PpRa0gVP6Kivqm_bBklUaftvtfcn1mCnqExKcaYI1AO6_ghXeJwwCKEUnuZBtP1Steozg_0SEQQF-sa6jF5yfCg/w640-h414/Business-Requirements-and-Enabler-Requirements-linked-03.png" width="640" /></a></div><p class="p2">This structure is, I believe, a little bit easier to understand and customize.</p>
<p class="p3"><span class="s1">What’s the difference between a Task and a Story enabler? In this context, a Task must be executed to make one particular User Story work. A Story Enabler is a task that, when executed, enables more than one User Story. You may have noticed I am deviating a bit from the description of Enabler Stories in SAFe, but I do believe it is a deviation that makes sense.</span></p>
<p class="p3"><span class="s1">It is worth noting that depending on the organization, and project or program you are working in, any business requirement from Portfolio Epic to User Story could be the top level of the hierarchy.</span></p>
<p class="p3"><span class="s1">In a large company with portfolios of products, you will probably start at the Portfolio Epic level. For a small systems project, User Stories may be all you need. Anything in-between can be used as the top level, depending on your needs.</span></p>
<p class="p3"><span class="s1">Just do not start with an Enabler. If you do that, the organizing principle is disrupted, you will start doing work items in the wrong order, and the whole idea of delivering business value quickly goes down the drain.</span></p>
<p class="p3"><span class="s1">You may also wish to omit levels. In the SAFe requirements model, Business Capabilities and Enabler Capabilities are optional. You may wish to skip them too, or not. Depending on your organization, you might want to cut ART or Solution Train Epics.</span></p>
<p class="p3"><span class="s1">If you cut out one or more levels on the business requirement side, it is probably a good idea to cut out the corresponding Enabler levels too. If you do not have Capabilities, you probably do not need Capability Enablers.</span></p>
<p class="p3"><span class="s1">As I mentioned at the start, this is an experimental model. If you see any obvious flaws, please do comment. If you think it will hold up, let me know that too.</span></p>
<p class="p3"><span class="s1">Be seeing you!</span></p>
<p class="p5"><br /></p>
Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-76230109665173864262023-11-16T14:31:00.005+01:002023-11-27T22:07:53.568+01:00Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?<p></p><div class="separator" style="clear: both; text-align: left;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtyhjd85ijq-uLbxDcHoZgj3az9t4i4iPZ4LbXVEDmsKM-wtzt5-XQAkVseM9n_6RHIgFJTObZfukB5wjgD9GwlHpJrc2lb8uinXz9Bowso_je6-u1c7mh5KC76ZtwnzmOCUaTt3Uhg3kl9GNL6nJvOh5vtfFTtvs1LKrAnYvwjhB7k92y83oC_Q/s1920/Timeline%20-%20Methodology%20Wars%20v02.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="849" data-original-width="1920" height="284" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtyhjd85ijq-uLbxDcHoZgj3az9t4i4iPZ4LbXVEDmsKM-wtzt5-XQAkVseM9n_6RHIgFJTObZfukB5wjgD9GwlHpJrc2lb8uinXz9Bowso_je6-u1c7mh5KC76ZtwnzmOCUaTt3Uhg3kl9GNL6nJvOh5vtfFTtvs1LKrAnYvwjhB7k92y83oC_Q/w640-h284/Timeline%20-%20Methodology%20Wars%20v02.jpg" width="640" /></a></div></div><p></p><p class="p5"><em>The major software methodology wars since the mid 1950’s.</em></p><p></p><div class="separator" style="clear: both; text-align: left;">Someone was wrong on the Internet, so here we go…</div><p></p>
<p class="p3"><span class="s2">In a recent HBR article, </span><a href="https://hbr.org/2023/10/its-time-to-end-the-battle-between-waterfall-and-agile?utm_medium=email&utm_source=ecom_universe&utm_campaign=agilewaterfall_20231106&deliveryName=DM301752"><span class="s2">It’s Time to End the Battle Between Waterfall and Agile</span></a><span class="s2">, the author sets up a false premise, that there is a war between Waterfall methodology and Agile, that it must end, and that you can combine the approaches to get the best of both worlds.</span></p>
<p class="p3"><span class="s2">This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project.</span></p>
<p class="p3"><span class="s2">I got invaluable help from Alistair Cockburn. He fact checked the two time-line illustrations in the introduction. If you find screwups in the article text, those are purely mine.</span></p>
<p class="p5">Since the 1950’s there have been at least three major software development methodology wars. The first, starting in the 1950’s, gathering steam in the 1970’s and 1980’s, and petering out in the 1990’s, was a war between traditional heavyweight methodologies, with features like parallelization of activities, prototyping, and (sometimes) iterative development, and Waterfall, which has none of those things.</p>
<p class="p3"><span class="s2">The second methodology war was in the 1990’s and early 2000’s, between traditional, heavyweight methodologies and lightweight agile methodologies. The agile methodologies won, but the victory would not last for long. The agile movement had a civil war brewing even before it had won the war against traditional methodologies.</span></p>
<p class="p3"><span class="s2">The third methodology war started soon after the Agile Manifesto was published, and was a war between the </span><em><span class="s3">agile lightweight methodologies</span></em><span class="s2">, based on a combination of software development practices and management practices, and </span><em><span class="s3">Agile</span></em><span class="s2">, with a capital “A”, that focused on management almost exclusively. By 2010, the battle was more or less over, and </span><em><span class="s3">Agile</span></em><span class="s2"> with a capital “A” had beaten </span><em><span class="s3">agile</span></em><span class="s2"> with a lowercase “a” in terms of market share. (Yes, we did fight over whether to use a capital “A” or a lowercase “a” in those days, but there were also more serious things at stake, like the spread, and use, of good software development practices.)</span></p>
<p class="p3"><span class="s2">The reason why all of this is important, is that the software industry, at least parts of it, is now trying to revive Waterfall, not as a warning of a failed approach, but as a viable methodology. The past few months I have seen several job descriptions where companies proclaim that they need people for Waterfall projects. There are tons of articles that spread misinformation about Waterfall. The misinformation also proliferates on social media. Waterfall projects don’t just waste money, they grind people down, putting them under enormous pressure in no-win situations. It is the antithesis of good software development, and of good management.</span></p>
<p class="p3"><span class="s2">I wrote </span><a href="https://kallokain.blogspot.com/2023/09/waterfall-dark-age-of-software.html"><span class="s2">another blog post</span></a><span class="s2"> recently where I used historical documents to correct some of the misinformation. I also provided an example where I compared Waterfall style planning with both traditional heavyweight methods, and with Agile planning. Waterfall lost, even under conditions that are supposedly optimal for Waterfall. Then this HBR article, advocating for marrying the worst aspects of traditional methodologies with the worst aspects of agile frameworks and methodologies, started popping up everywhere I looked, and I…got a bit upset. Hence, this blog post.</span></p>
<p class="p3"><span class="s2">To understand why advocating for Waterfall software development is bonkers, it helps if we look back, to the origins of the approach, and how it was shaped by the realities of software engineering in the early 1950’s.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFwdTtf4wu12Efo0ryjch09Ik9s6c1yrAjxwbuJV89JMkSj-gpq45EusZJBWDaGAuQi2aKn5NuHZycyRGm5TDEqAKl3v0aBIoVBJdjLhzxtwcrckmfgn-qpMlUepfEXGLFxS-8ILxUgQgj7athRuDOejJjy8On4bkTyBZ9exnr8CPTdsdikvO5wQ/s4190/Timeline%20-%20Events%20HiRes%20v05.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="4190" data-original-width="3840" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFwdTtf4wu12Efo0ryjch09Ik9s6c1yrAjxwbuJV89JMkSj-gpq45EusZJBWDaGAuQi2aKn5NuHZycyRGm5TDEqAKl3v0aBIoVBJdjLhzxtwcrckmfgn-qpMlUepfEXGLFxS-8ILxUgQgj7athRuDOejJjy8On4bkTyBZ9exnr8CPTdsdikvO5wQ/w586-h640/Timeline%20-%20Events%20HiRes%20v05.jpg" width="586" /></a></div><br /><p class="p4"><br /></p>
<p class="p5"><em><span class="s3">Timeline covering some of the major events during the time period of the three methodology wars in this blog post.</span></em></p>
<h1 class="scr1"><strong><span class="s4">1953-1956 A.D.: In the beginning was SAGE!</span></strong></h1>
<p class="p3"><span class="s2">The </span><em><span class="s3">Semi-Automated Ground Environment</span></em><span class="s2"> (SAGE) was a system of networked computers used to coordinate data from many radar stations, and collate it into one unified picture. The SAGE development project started in 1953, and went operational in the late 1950’s. Developing the SAGE software was a huge undertaking at the time. It was the first software development project large enough to require a software development methodology, so the engineers at SAGE created one.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgImr8vGoY05ONaofdQTKVpsFc_gGOfWYlnZHPi5IPGhPm7EuWqz4Xqbs0BEuWjkizpl5XjIitLek0VbzRyoKS6-sEIFF-TTiSIdN4syqhNMrLTmt15QPYN0W2s9cYfneye01NV5kCn9diazrWw6IDtptJUvJhBXNmZtKxZwJvmFJskwtbRlGkd-g/s504/SAGE_computer_room.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="405" data-original-width="504" height="514" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgImr8vGoY05ONaofdQTKVpsFc_gGOfWYlnZHPi5IPGhPm7EuWqz4Xqbs0BEuWjkizpl5XjIitLek0VbzRyoKS6-sEIFF-TTiSIdN4syqhNMrLTmt15QPYN0W2s9cYfneye01NV5kCn9diazrWw6IDtptJUvJhBXNmZtKxZwJvmFJskwtbRlGkd-g/w640-h514/SAGE_computer_room.jpg" width="640" /></a></div>
<p class="p5"><em><span class="s3">Part of the SAGE computer room.</span></em></p>
<p class="p3"><span class="s2">SAGE used a centralized computer known as the </span><a href="https://en.wikipedia.org/wiki/AN/FSQ-7_Combat_Direction_Central"><span class="s2">AN/FSQ-7 Combat Direction Central</span></a><span class="s2">, or Q7, for short. The Q7 weighed about 250 tons, had 60,000 vacuum tubes, required 3 MW of energy to run, and could execute 75,000 instructions per second. For comparison, the neural engine in an </span><a href="https://appleinsider.com/articles/22/09/26/how-iphone-speeds-have-grown-in-the-last-5-years#:~:text=It%20didn't%20take%20long,11%20trillion%20operations%20per%20second."><span class="s2">iPhone 14 Pro can execute 17,000,000,000,000 (17 trillion) instructions per second</span></a><span class="s2">. The iPhone also weighs considerably less than 250 tons.</span></p>
<p class="p3"><span class="s2">Thanks to a 1956 paper written by Herbert D. Benington, a software engineer at SAGE, we know a lot about how the people at SAGE worked. Benington is often credited with creating Waterfall in the SAGE project. What is funny, is that Dr. Winston Royce, of NASA, is also often credited with creating Waterfall, but later, in 1970. What is even funnier, is that neither of them did it, and both were very much against Waterfall.</span></p>
<p class="p3"><span class="s2">I have written about Dr. Winston Royce and his 1970 paper in </span><a href="https://kallokain.blogspot.com/2023/09/waterfall-dark-age-of-software.html"><span class="s2">a previous blog post</span></a><span class="s2">. This time, I’ll focus on Benington’s 1956 paper, </span><a href="https://docplayer.net/133382-Production-of-large-computer-programs-herbert-d-benington.html"><span class="s2">Production of Large Computer Programs</span></a><span class="s2">.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEio17sSB2l-2mLqpGy-jNT0aLj8lUDaa4yFtRtbGaoF_2soPXXY-zK_-ANuYFveLiSQAZuXhHZrTcuZWlejXSDYOPT4a6o1Vd_Pkwn8kdi4I77mBhz9vBtBVUB5AMtdEHhWo3cPkbRfB_hXK75dfqY8X4kt8VkQ-D1Qf3U445BiFT9RS5ofxEkWYg/s2232/Blue-punch-card-front-horiz.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1004" data-original-width="2232" height="288" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEio17sSB2l-2mLqpGy-jNT0aLj8lUDaa4yFtRtbGaoF_2soPXXY-zK_-ANuYFveLiSQAZuXhHZrTcuZWlejXSDYOPT4a6o1Vd_Pkwn8kdi4I77mBhz9vBtBVUB5AMtdEHhWo3cPkbRfB_hXK75dfqY8X4kt8VkQ-D1Qf3U445BiFT9RS5ofxEkWYg/w640-h288/Blue-punch-card-front-horiz.png" width="640" /></a></div>
<p class="p5"><em><span class="s3">A punch card, similar to the ones used in the SAGE project.</span></em></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">Programs are prepared in machine language because automatic coding techniques developed to date do not guarantee the efficient programming required for a real-time system.</span></p><p class="p8"><span class="s2">— Production of Large Computer Programs, Herbert Benington</span></p></blockquote>
<p class="p3"><span class="s2">In the SAGE project, programmers wrote machine code instructions directly, using punch cards. A computer program was written on stacks of cards.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgk49hM0njtzEv_RDPQyWYRhnce5R-7hQ2vcMQvVJS0VlwqmQPm0PvrCpQ-nvHLY0q3w5pXB8bOqWysjftFZBvAnbAtRICdOf5kivT9Xm2zTswl5paGqKNtYADsh3X3PEEZGV011iOh5Q96cb6ARP0kVJwE1G0l6L6omBUjH7MOLyczjj17CD3r8A/s792/the-largest-punch-card-computer-program-was-from-the-1950s-v0-n73ut8v9tkpa1.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="792" data-original-width="580" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgk49hM0njtzEv_RDPQyWYRhnce5R-7hQ2vcMQvVJS0VlwqmQPm0PvrCpQ-nvHLY0q3w5pXB8bOqWysjftFZBvAnbAtRICdOf5kivT9Xm2zTswl5paGqKNtYADsh3X3PEEZGV011iOh5Q96cb6ARP0kVJwE1G0l6L6omBUjH7MOLyczjj17CD3r8A/w468-h640/the-largest-punch-card-computer-program-was-from-the-1950s-v0-n73ut8v9tkpa1.jpg" width="468" /></a></div>
<p class="p5"><em><span class="s3">A large computer program, written on punch cards. This is what the programs in the SAGE project looked like, before they were entered into the Q7 computer.</span></em></p>
<p class="p3"><span class="s2">Because of the way programs were written, and because computer time was very expensive, the engineers at SAGE paid close attention to economics:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">Let us assume an overhead factor of 100 percent (for supporting programs, management, etc.), a cost of $15,000 per engineering man-year (including overhead), and a cost of $500 per hour of computer time (this is probably low since a control computer contains considerable terminal equipment). Assuming these factors, the cost of producing a 100,000- instruction system program comes to about $5,500,000 or $55 per machine instruction.</span></p><p class="p8"><span class="s2">— Production of Large Computer Programs, Herbert Benington</span></p></blockquote>
<p class="p3"><span class="s2">$55 per machine instruction in 1956, recalculated with an </span><a href="https://tools.carboncollective.co/inflation/us/1956/1/#:~:text=%241%20in%201956%20has%20the,2023%20was%201.96%25%20per%20year."><span class="s2">inflation calculator</span></a><span class="s2">, works out to about $608 per machine code instruction today (SKR 6636, if you live in Sweden, like me). Today, we don’t even bother figuring out what it costs to produce one machine code instruction. A software developer today can produce many machine code instructions by writing a single line of code in a high level language. </span></p>
<p class="p9"><span class="s2">Writing a 100,000 machine code instruction system was a major undertaking in 1956. Today, hobbyist programmers write applications much, much larger than that, just for the fun of it.</span></p>
<p class="p3"><span class="s2">Because writing programs was so expensive, the SAGE engineers wanted to be very sure they did not make errors. Get one machine code instruction wrong, and fixing that instruction might not be enough. You could easily get cascading errors, making it necessary to rewrite large chunks of code, at prohibitive cost.</span></p>
<p class="p3"><span class="s2">The risk of errors was high. Writing machine code is difficult and risky at best. Doing it by punching holes in punch cards increases the risk a lot. Testing machine code was difficult and expensive. Today, a developer working with modern object-oriented languages can quickly write tests for small pieces of code, even before writing the code to be tested, using </span><a href="https://en.wikipedia.org/wiki/Test-driven_development"><span class="s2">Test-Driven Development</span></a><span class="s2">, or </span><a href="https://en.wikipedia.org/wiki/Behavior-driven_development"><span class="s2">Behavior-Driven Development</span></a><span class="s2">. In 1956, testing and fixing errors was not an easy task.</span></p>
<p class="p3"><span class="s2">So, if the risk of errors is very high, and finding and fixing the errors is incredibly expensive, what do you do? You try to prevent the errors. How do you prevent errors?</span></p>
<p class="p3"><span class="s2">The Waterfall advocates would have you believe the only solution is to follow a strictly linear process, with planning everything up front, before starting to code, then coding everything before starting to test. However, that was not quite what the SAGE team did.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhG_BLQBHf1T87nUze44m_MPoVdy9-M13y7xnXON8Y9MiEqljham_TxYLUld_qURk-piDDrkz85cIxLEkz4X8FZPsQQiaXBBN0k4BHezBjmjkP9mk7CEyymBegYbXKtS4lT4hMcX55bVHyU0PQbXvyr-GB2YKPDL2drYf2dkteWhttRwHZIDYFWTQ/s1057/Screenshot%202023-11-10%20173624.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1057" data-original-width="880" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhG_BLQBHf1T87nUze44m_MPoVdy9-M13y7xnXON8Y9MiEqljham_TxYLUld_qURk-piDDrkz85cIxLEkz4X8FZPsQQiaXBBN0k4BHezBjmjkP9mk7CEyymBegYbXKtS4lT4hMcX55bVHyU0PQbXvyr-GB2YKPDL2drYf2dkteWhttRwHZIDYFWTQ/w532-h640/Screenshot%202023-11-10%20173624.png" width="532" /></a></div>
<p class="p5"><em><span class="s3">An outline of the software development process from Benington’s 1956 paper. In 1983, Benington reissued the paper, and pointed out that very important parts of the process were missing in the original paper.</span></em></p>
<p class="p3"><span class="s2">If you had read Benington’s paper in 1956, it would be very easy to believe that Benington described a rigid, strictly top down process, proceeding from an overarching operational plan, through step by step refinement, until, finally, the program could be evaluated and released. However, that was not how they actually worked at SAGE, and it wasn’t Benington’s intent that it should be perceived that way.</span></p>
<p class="p3"><span class="s2">In 1983, Benington reissued his 1956 paper with a new foreword. What he wrote in the foreword is illuminating:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">When I got back into the computer programming business several years ago, I read a number of descriptions of top-down programming. The great majority seemed to espouse the following approach: we must write the initial top-down specification (for example, the A Spec), then the next one (typically, the B Spec), so we will know precisely what our objectives are before we produce one line of code. This attitude can be terribly misleading and dangerous.</span></p><p class="p8"><span class="s2">— Foreword to the 1983 reissue of Production of Large Computer Programs, Herbert Benington</span></p></blockquote>
<p class="p3"><span class="s2">“Terribly misleading and dangerous”, is what Benington himself thought about the Waterfall approach. Even in 1956, the SAGE engineers understood that a strict top down approach was not the answer. Even though the process was basically linear, they were not as rigid about it as Waterfall is, and they did one very important thing. They built prototypes!</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">I do not mention it in the attached paper, but we undertook the programming only after we had assembled an experimental prototype of 35,000 instructions of code that performed all of the bare-bone functions of air defense.</span></p><p class="p8"><span class="s2">— Foreword to the 1983 reissue of Production of Large Computer Programs, Herbert Benington</span></p></blockquote>
<p class="p3"><span class="s2">Prototyping is something that shows up over and over again in software development, because it is incredibly useful. Dr. Winston Royce proposed a method that used it in 1970. Some other heavyweight methods, including Boehm’s Spiral Model, and the </span><a href="https://en.wikipedia.org/wiki/Rational_unified_process"><span class="s2">Rational Unified Process</span></a><span class="s2"> (RUP) used it. Agile methodologies like Crystal Clear, Lean Software Development, Dynamic Systems Development Method (DSDM), and Adaptive Software Development (ASD), all use prototyping. Extreme Programming uses </span><em><span class="s3">spikes</span></em><span class="s2">, a kind of small, partial prototypes.</span></p>
<p class="p3"><span class="s2">Both Benington in 1956 and Royce in 1970 advocated for prototyping, as did most agile software development methods. In stark contrast, Waterfall, Scrum, and Agile (with a capital “A”) do not.</span></p>
<p class="p3"><span class="s2">In the foreword to the 1983 reissue of his paper, Benington writes about what the SAGE project could have done better:</span></p>
<blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><p class="p8" style="text-align: left;"><span class="s2">To underscore this point, the biggest mistake we made in producing the SAGE computer program was that we attempted to make too large a jump from the 35,000 instructions we had operating on the much simpler Whirlwind I computer to the more than 100,000 instructions on the much more powerful IBM SAGE computer. If I had it to do over again, I would have built a framework that would have enabled us to handle 250,000 instructions, but I would have transliterated almost directly only the 35,000 instructions we had in hand on this framework.</span></p></blockquote>
<p class="p3"><span class="s2">Thus, Benington wanted </span><em><span class="s3">more</span></em><span class="s2"> prototyping, not zero prototyping, as in Waterfall.</span></p>
<p class="p3"><span class="s2">Benington continues:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;">Then I would have worked to test and evolve a system. I estimate that this evolving approach would have reduced our overall software development costs by 50 percent.</blockquote><p class="p3"><span class="s2">This is interesting! In 1983, Benington wished the SAGE team would have used an evolving approach, based on prototyping and testing, in other words, an </span><em><span class="s3">emergent design</span></em><span class="s2">!</span></p>
<p class="p3"><em><span class="s3">Wow</span></em><span class="s2">! This is the same idea Extreme Programming, Crystal, and other agile methodologies would advocate in the 90’s and early 2000’s. Benington’s own estimate is that it would have reduced project cost by 50%!</span></p>
<p class="p3"><span class="s2">Benington also points out that software development had changed a lot since 1956. He listed the technical advances that he believed had the largest impact on project methodology. In Benington’s own words:</span></p>
<ul class="ul1">
<li>We now use higher-order languages in virtually all situations.</li>
<li>Almost all software development and unit testing are done interactively at consoles in a timesharing mode.</li>
<li>We have developed a large family of tools that allow us to do much precise design and flow analysis before coding. (I still say that we should use these techniques before we start finalizing our top-down requirements.)</li>
<li>We have developed organizational approaches that improve or at least guarantee the quality of the systems much earlier in the game. These include some of the structured languages, code reviews, walk-throughs, etc. </li>
</ul>
<p class="p3"><span class="s2">This is a </span><em><span class="s3">brutal</span></em><span class="s2"> takedown of Waterfall!</span></p>
<p class="p3"><span class="s2">Waterfall proponents today do of course not advocate that developers should write machine code using punch cards. However, they are advocating we should manage developers </span><em><span class="s3">as if</span></em><span class="s2"> they were writing machine code on punch cards…and that we should do it badly, without prototyping and with a top down approach Benington called “misleading and dangerous”.</span></p>
<p class="p3"><span class="s2">In 1956, Herbert Benington and his peers understood very well that the way you plan and manage projects must be adapted to the way people work.</span></p>
<p class="p3"><span class="s2">In 2023, managers, including Agile managers, have divorced the management methodologies and frameworks from what they manage, and the results are disastrous. Instead of trying to understand what the problem is, they are desperately seeking for a quick fix, something to latch on to, and Waterfall just happened to sound cool to them. What it is, and whether it works, does not matter, as long as it can be packaged and sold.</span></p>
<h1 class="scr1"><strong><span class="s4">Methodology War I, ca. 1957-1994: Traditional Methodologies vs. Waterfall approach</span></strong></h1>
<p class="p3"><span class="s2">The initial misunderstanding of Benington’s 1956 paper, that gave rise to the Waterfall approach, is very understandable. The paper omitted key practices, and over-emphasized working top down. Waterfall tended to produce large cost overruns and bad software, but it was easy to follow, step by step.</span></p>
<p class="p3"><span class="s2">The poor results from Waterfall was a problem, and that lead to the development of techniques, methods, and methodologies designed to improve software project results.</span></p>
<h2 class="scr2"><strong><span class="s5">1957-1963: Critical Path, PERT, and Monte Carlo</span></strong></h2>
<p class="p3"><span class="s2">The </span><a href="https://en.wikipedia.org/wiki/Critical_path_method"><span class="s2">Critical Path Method</span></a><span class="s2"> (CPM), a project scheduling method, was invented in 1957. With CPM, a project was broken down into relatively small work packages. The next step was to figure out how to sequence work packages, and which sequences could be done in parallel. The parallelization of work made it possible to massively reduce project lead times compared to Waterfall. This also reduced project cost. Because software could be released earlier than with Waterfall, it could be put to use earlier, and begin to generate revenue earlier.</span></p>
<p class="p3"><span class="s2">CPM projects sometimes, but not always, made multiple deliveries with partial functionality in each delivery. Waterfall projects cannot do that, because of the strictly linear sequencing of project activities. With Waterfall, you either have a big bang release at the end of the project, or the whole thing fizzles, you have nothing, and you must start over more or less from square one again. (This was one of the reasons Dr. Winston Royce criticized Waterfall in his </span><a href="https://dl.acm.org/doi/10.5555/41765.41801"><span class="s2">1970 paper</span></a><span class="s2">.)</span></p>
<p class="p3"><a href="https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique"><span class="s2">Program Evaluation and Review Technique</span></a><span class="s2"> (PERT) charts were invented in 1958. The main use was as a planning tool for CPM projects. With CPM, you plan by identifying the longest path of activities from the beginning to the end of the project. This makes it possible to identify which activities are critical on the Critical Path, and which activities are not, usually because they are on other paths. PERT charts made it easier to visualize the pathways through the project.</span></p>
<p class="p3"><span class="s2">A problem with CPM was that projects were often delayed. Not as much as with Waterfall, but serious enough. In 1963, Richard Van Slyke wrote a paper named </span><a href="file:///G:/My%20Drive/writing/field%20stones/van-slyke-1963-letter-to-the-editor-monte-carlo-methods-and-the-pert-problem.pdf"><span class="s2">Monte Carlo and the PERT Problem</span></a><span class="s2">, where he suggested using Monte Carlo simulation to improve project planning.</span></p>
<p class="p3"><span class="s2">The Monte Carlo method is a statistical simulation method originally developed by Stanislav Ulam at the Manhattan Project in 1946. Ulam got the idea while playing solitaire. He tried to figure out a way to calculate the probability of successfully laying out a 52 card Canfield solitaire. He soon realized that the method could also be used to solve nuclear physics problems.</span></p>
<p class="p3"><span class="s2">Over time, Monte Carlo simulation spread into project planning, finance, engineering, climate change research, computational biology, computer graphics, applied statistics, artificial intelligence, US Coast Guard search and rescue operations, and other areas. Today, it is even used by a few people in the Agile community.</span></p>
<h2 class="scr2"><strong><span class="s5">1962-1980: New languages begets new methodologies</span></strong></h2>
<p class="p3"><span class="s2">Computer programming changed a lot during the sixties and seventies, with the rise of high level languages. There had been high level languages around earlier, but in the sixties and seventies, we got languages that were more powerful and easier to use: APL (1962), PL/I (1964), BASIC (1964), Forth (1968), Pascal (1970), C (1972), Prolog (1972), SQL (1972), ML (1973), and MATLAB (1978-ish), to name just a few.</span></p>
<p class="p3"><span class="s2">These languages, and of course the corresponding advances in hardware, profoundly changed the nature of programming. With those changes came just as profound changes in software development methodology and economics.</span></p>
<h2 class="scr3"><strong><span class="s6">1970-1976: The most misunderstood methodology paper of all time</span></strong></h2>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhLI24nXjYW-s_GD-_B86OcCbBBEgX7Ml4dP_EXyqhlwRtKyAHVlMJ-vKVX4o4yVmDu2WRdyHHMOtJk-sJ7icieFvAcDj5Vl_qQatlHs-TfnfbLRlA0yPhEhYWtWnkbEV9Nu0FbXP8VTebqnQ36xkfo2_ouaObkeSjFrIEvPG_OEzwdvwOLaEFAVA/s3840/1970%20-%20Royce%20Paper.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1664" data-original-width="3840" height="278" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhLI24nXjYW-s_GD-_B86OcCbBBEgX7Ml4dP_EXyqhlwRtKyAHVlMJ-vKVX4o4yVmDu2WRdyHHMOtJk-sJ7icieFvAcDj5Vl_qQatlHs-TfnfbLRlA0yPhEhYWtWnkbEV9Nu0FbXP8VTebqnQ36xkfo2_ouaObkeSjFrIEvPG_OEzwdvwOLaEFAVA/w640-h278/1970%20-%20Royce%20Paper.jpg" width="640" /></a></div>
<p class="p5"><em><span class="s3">In his 1970 paper, Managing the Development of Large Computer Systems, Dr. Winston Royce argued against Waterfall, and for a method that used prototyping, iterations, and continuous contact with customers.</span></em></p>
<p class="p3"><span class="s2">There was a lot of dissatisfaction with the Waterfall approach in the 1960’s. This prompted Dr. Winston Royce of NASA to write a paper, </span><a href="https://dl.acm.org/doi/10.5555/41765.41801"><span class="s2">Managing the Development of Large Software Systems</span></a><span class="s2">, where he criticized Waterfall.</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">…the implementation described above is risky and invites failure.</span></p><p class="p8"><span class="s2">— </span><a href="https://dl.acm.org/doi/10.5555/41765.41801"><span class="s2">Managing the Development of Large Software Systems</span></a><span class="s2">, Dr. Winston Royce, 1970</span></p></blockquote>
<p class="p3"><span class="s2">Unfortunately, the Waterfall advocates were undeterred. They simply claimed that Dr. Winston Royce was with them.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkaKf7rR5uLDm7i5ehaJdETeI6CGP_v3PnBZpmLu-8OXSgxY7v2j0lqptpNhEXqiZrs2TdwG-olnKpnUVA-rdgZuFr-Tbkv0mRXau53SZNsOO7hyv1vPhPVNEb2BXOW1ND4OGeG1u03D6wAVED79jDbEm9ecV5zTw1zhKg4I_l0LjszNODTHf-zQ/s1078/1976%20Bell%20and%20Thayer%2001.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="331" data-original-width="1078" height="195" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkaKf7rR5uLDm7i5ehaJdETeI6CGP_v3PnBZpmLu-8OXSgxY7v2j0lqptpNhEXqiZrs2TdwG-olnKpnUVA-rdgZuFr-Tbkv0mRXau53SZNsOO7hyv1vPhPVNEb2BXOW1ND4OGeG1u03D6wAVED79jDbEm9ecV5zTw1zhKg4I_l0LjszNODTHf-zQ/w640-h195/1976%20Bell%20and%20Thayer%2001.jpg" width="640" /></a></div>
<p class="p5"><em><span class="s3"> From a 1976 paper Software Requirements: Are They Really a Problem? by T. E. Bell and T. A. Thayer. The problem with their praising of Royce, is that they praised him for the thing he was against.</span></em></p>
<p class="p3"><span class="s2">It is difficult to find out exactly who first misunderstood Winston Royce. T.E. Bell and T.A. Thayer are two of the main contenders though. In the 1976 paper </span><a href="https://static.aminer.org/pdf/PDF/000/361/405/software_requirements_are_they_really_a_problem.pdf"><span class="s2">Software Requirements: Are They Really a Problem?</span></a><span class="s2">, they praised Royce’s approach to software development. It becomes very apparent that something is wrong when you look at the illustration of what they praised.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMKjYRn5UEwDINWLylXJECTq4L4_nnLi589XybjbCVSoK8geNlLgMA3KUwmVwWlFJJVv5B8jTyODnjvbVbz7O2XoeNPRq3QKMePDWjoDrNC5w36NNF6k0IeBEffHp0l_2_tUa9szk_wGpo-VzAEA2JX-c_tRdY-9uwNXtLxSte3PYvV4Ig7t1WiQ/s2053/Bell%20and%20Thayer%2002.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1704" data-original-width="2053" height="532" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMKjYRn5UEwDINWLylXJECTq4L4_nnLi589XybjbCVSoK8geNlLgMA3KUwmVwWlFJJVv5B8jTyODnjvbVbz7O2XoeNPRq3QKMePDWjoDrNC5w36NNF6k0IeBEffHp0l_2_tUa9szk_wGpo-VzAEA2JX-c_tRdY-9uwNXtLxSte3PYvV4Ig7t1WiQ/w640-h532/Bell%20and%20Thayer%2002.png" width="640" /></a></div>
<p class="p5"><em><span class="s3">This is Figure 1 from Bell’s and Thayer’s paper. The model they are praising, the Waterfall model, is the model Royce argued against.</span></em></p>
<p class="p3"><span class="s2">Looking at Bell’s and Thayer’s figure 1 in their paper, it becomes clear they confused Royce’s description of the problems with Waterfall, with a description of a solution.</span></p>
<p class="p3"><span class="s2">This may well be one of the three biggest blunders in the history of software development methodology! (The other two would be moving from agile methodologies to Agile with a capital “A”, and trying to combine Agile and Waterfall.)</span></p>
<p class="p3"><span class="s2">It is worth noting that the Bell and Thayer paper </span><em><span class="s3">may</span></em><span class="s2"> be the first time the term “Waterfall” is used. If you are interested in a more detailed account of how Royce’s paper was misunderstood, you may wish to read a </span><a href="https://kallokain.blogspot.com/2023/09/waterfall-dark-age-of-software.html"><span class="s2">previous blog post of mine</span></a><span class="s2">.</span></p>
<h2 class="scr3"><strong><span class="s6">1980: Smalltalk-80 - The first object-oriented programming language</span></strong></h2>
<p class="p3"><span class="s2">In 1980, the first object-oriented language, Smalltalk-80, was released. This sparked yet another revolution in programming techniques, and software architecture, and would eventually enable the emergence of agile software development methodologies in the 90’s. Today, object-oriented languages like Java, C#, Python, and Ruby are all descended from Smalltalk-80, and use the same programming paradigm (though there are significant differences in how they apply the paradigm).</span></p>
<p class="p3"><span class="s2">New software development methodologies that, to varying degrees, took advantage of the improvements in technology and programming languages emerged throughout the 60’s, 70’s, and 80’s. These methodologies were in competition with Waterfall, but also with each other.</span></p>
<h2 class="scr2"><strong><span class="s5">1988-1994: The rise of the spiral, and the death of Waterfall</span></strong></h2>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXQXjZnqiQyVl26kdGlinZNTGebocod6vGhC7edgLyAgQJT1-iX1QI1bZbdaRpgbTGcGpHK9XKbWUkMwk98veoTFTAxGxUxO9mK1Y1-mOwlrIKj7CVA3aFVhPukka-oUyoEYuUnyCTdvD5FFpqXcm8CmIdv2Pzp9jVuYEX2sUngqrwpqtyHvCbTg/s730/Spiral_model_(Boehm,_1988).png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="600" data-original-width="730" height="526" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXQXjZnqiQyVl26kdGlinZNTGebocod6vGhC7edgLyAgQJT1-iX1QI1bZbdaRpgbTGcGpHK9XKbWUkMwk98veoTFTAxGxUxO9mK1Y1-mOwlrIKj7CVA3aFVhPukka-oUyoEYuUnyCTdvD5FFpqXcm8CmIdv2Pzp9jVuYEX2sUngqrwpqtyHvCbTg/w640-h526/Spiral_model_(Boehm,_1988).png" width="640" /></a></div>
<p class="p5"><em><span class="s3">Barry Boehm’s Spiral Model of Software Development was designed to solve problems with the Waterfall approach.</span></em></p>
<p class="p3"><span class="s2">In 1988, Barry Boehm’s paper </span><a href="https://www.cse.msu.edu/~cse435/Homework/HW3/boehm.pdf"><span class="s2">A Spiral Model of Software Development and Enhancement</span></a><span class="s2"> revolutionized software development methodology. It was a fully iterative method, it used prototyping, and it was explicitly intended to solve the problems with Waterfall:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">A primary source of difficulty with the waterfall model has been its emphasis on fully elaborated documents as completion criteria for early requirements and design phases. For some classes of software, such as compilers or secure operating systems, this is the most effective way to proceed. However, it does not work well for many classes of software, particularly interactive end-user applications. Document-driven standards have pushed many projects to write elaborate specifications of poorly understood user interfaces and decision support functions, followed by the design and development of large quantities of unusable code. </span></p><p class="p8"><span class="s2">— <span class="Scrivener-converted-space"> </span>A Spiral Model of Software Development and Enhancement, by Barry Boehm, 1988.</span></p></blockquote>
<p class="p3"><span class="s2">By this time, the enthusiasm for Waterfall was diminishing on all fronts. Waterfall simply did not deliver. It was an anachronism from the days of punch cards, and the problems were glaringly obvious for all to see…except maybe for the US Department of Defense.</span></p>
<p class="p3"><span class="s2">In 1988, the US Department of Defense released </span><a href="https://en.wikipedia.org/wiki/DOD-STD-2167A"><span class="s2">DOD-STD-2167A</span></a><span class="s2">, a military standard for how to run software projects. Unfortunately, though the standard did not prohibit more modern methodologies, it was written in a way that encouraged Waterfall projects.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQM2Ov5ffairkiELjCe7WQut_Kr0Evat1nOLgBFUAQTJx0zW9VEMt7TzW5WLoK2_rhfZYkOpd2bWsCOPQGyxXtVGxHH9TebJXzVoTv9C3HNjTS223vzUfX_CIrVtxL3V_EJuYw1zJV_ggoImolMetukApLUndA634Wml0F8X1yugDkXUn-wf33aw/s1920/MIL-STD-498%20Page%2033.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1444" data-original-width="1920" height="482" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQM2Ov5ffairkiELjCe7WQut_Kr0Evat1nOLgBFUAQTJx0zW9VEMt7TzW5WLoK2_rhfZYkOpd2bWsCOPQGyxXtVGxHH9TebJXzVoTv9C3HNjTS223vzUfX_CIrVtxL3V_EJuYw1zJV_ggoImolMetukApLUndA634Wml0F8X1yugDkXUn-wf33aw/w640-h482/MIL-STD-498%20Page%2033.jpg" width="640" /></a></div>
<p class="p5"><em><span class="s3">From a presentation about MIL-STD-498 produced by the Software Productivity Consortium in 1994.</span></em></p>
<p class="p3"><span class="s2">Waterfall projects kept failing, and new, improved methodologies kept cropping up, for example James Martin’s </span><em><span class="s3">Rapid Application Development</span></em><span class="s2"> (RAD), in 1991. In the beginning, RAD was basically a way of creating prototypes very rapidly, but it would inspire the development of several true agile software development methodologies.</span></p>
<p class="p3"><span class="s2">DOD-STD-2167A did meet with heavy criticism because it locked military contractors into using bad methodology, and also locked them out of using technical improvements. In 1994, it was replaced by </span><a href="https://apps.dtic.mil/sti/citations/ADA282003"><span class="s2">MIL-STD-498</span></a><span class="s2">, a standard designed to rectify some of the earlier mistakes. It explicitly removed the Waterfall model implied by the previous standard.</span></p>
<p class="p3"><span class="s2">By this time, Waterfall had little or no credibility. No one would deliberately choose to run a Waterfall project, even though badly run projects still could devolve into Waterfall.</span></p>
<h1 class="scr1"><strong><span class="s4">Methodology War II, ca. 1992-2005: Agile methodologies vs. Traditional Methodologies</span></strong></h1>
<p class="p3"><span class="s2">The traditional methodologies continued to develop during the 90’s. They still had a heavy emphasis on documentation, and projects could sometimes end up producing a lot of documentation, but no working software. They were still a marked improvement over Waterfall. In the late 90’s, the </span><em><span class="s3">Unified Process</span></em><span class="s2">, and the </span><em><span class="s3">Rational Unified Process</span></em><span class="s2">, two very closely related iterative heavyweight methods emerged.</span></p>
<p class="p3"><span class="s2">To give you an idea of how administration heavy these projects could be:</span></p>
<p class="p3"><span class="s2">In 2005 I worked as a consultant for a large company using a heavyweight methodology. In my first meeting with my team, we introduced ourselves. It turned out we were eight managers and administrators, and a single developer.</span></p>
<p class="p3"><span class="s2">What was my job? I was the process navigator. It was my job to figure out what the next step in our process was, what documents we needed to produce to pass each of the fourteen gates, what permissions we needed to proceed at each stage, and a lot of other things.</span></p>
<p class="p3"><span class="s2">The project eventually ground to a halt due to process errors. For example, we used a new version of the methodology, released just the week before our project started. At one point, we needed to produce a document in order to pass a gate. To produce the document, we needed access to certain information, but we were not allowed to access the information until after we had passed the gate.</span></p>
<p class="p3"><span class="s2">At another point in the project, we needed permission from a department in another country in order to proceed. I managed to find the name of a contact person, but when I called him up, he told me he could not give us permission to proceed, because he did not work at that department anymore. It had been closed down for three years.</span></p>
<p class="p3"><span class="s2">Then I found out, after a bit of digging, that we were the fourth team trying to build the same thing. Each time a project was started, it ran into problems like the ones I’ve described. The project ground to a halt. Then, instead of fixing the process problems, the company restarted the same project, but with new people, over, and over again.</span></p>
<p class="p3"><span class="s2">It is no wonder that some people wanted to create new, more flexible and responsive software development methodologies.</span></p>
<h2 class="scr2"><strong><span class="s5">1991-1998: The Rise of Agile Software Development Methodologies</span></strong></h2>
<p class="p3"><span class="s2">Rapid Application Development (RAD) (1991), an important advancement in methodology, inspired the development of at least two agile methodologies </span><em><span class="s3">Adaptive Software Development</span></em><span class="s2"> (1994) by Jim Highsmith and <span class="Scrivener-converted-space"> </span>Sam Bayer, and </span><a href="https://en.wikipedia.org/wiki/Dynamic_systems_development_method"><span class="s2">Dynamic Systems Development Method</span></a><span class="s2"> (DSDM) (1994).</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnsBwUc5_efrb4HAVE-NJd2lU6PcRvmgR-Zz9vI7pSFuSESbFnBT1PvGHnQpSuD436c9IkdyKYMsEY5bED9ePoWzLpBJ8TKJwjowV1px3VvsZfmp1xxCcfALFzf2KKf6kz4UIBXlUhGlMqL4d2XZ8bEhupNdeHWi2Da-zGaOSkeuywQa5e4EC-Aw/s854/XP%20-%20A%20system%20of%20Supporting%20Practices.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="525" data-original-width="854" height="394" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnsBwUc5_efrb4HAVE-NJd2lU6PcRvmgR-Zz9vI7pSFuSESbFnBT1PvGHnQpSuD436c9IkdyKYMsEY5bED9ePoWzLpBJ8TKJwjowV1px3VvsZfmp1xxCcfALFzf2KKf6kz4UIBXlUhGlMqL4d2XZ8bEhupNdeHWi2Da-zGaOSkeuywQa5e4EC-Aw/w640-h394/XP%20-%20A%20system%20of%20Supporting%20Practices.jpg" width="640" /></a></div>
<p class="p5"><em><span class="s3">Extreme Programming (XP) is a system of supporting practices. For a long time, XP was considered the heart of agile.</span></em></p>
<p class="p3"><span class="s2">Likewise, the agile methodology </span><a href="https://en.wikipedia.org/wiki/Extreme_programming"><span class="s2">Extreme Programming</span></a><span class="s2"> (XP) (1996), created by Kent Beck and Ron Jeffries, was partially inspired by Boehm’s Spiral Method. Like the Spiral Method, the overarching idea with Extreme Programming was to reduce risk. Extreme Programming did this, to a large extent, by taking advantage of programming techniques made possible by Smalltalk-80, the first object-oriented language.</span></p>
<p class="p3"><span class="s2">Extreme Programming was, very deliberately, designed as a system of supporting practices. Used together, these practices kept the development project stable, and developers sane.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiM_53qR4C_kuJfu3HMPp1nLfwUrdv8wH0djcf3UJ2kHDTdAQLCic2kzjutGArpWDiowgFjxGVjwOF8TCBtZOD749GzsHT4yBXLvgnldP45Pc0gXxLNp4bsOmiBL9bGucuSVfo4VugEyhZ5MWKA7Z7FsG5aJD9CGW3NIqwv_HprGcUBDsmI6dMEwQ/s1454/XP%20Feedback%20Loops.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1068" data-original-width="1454" height="470" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiM_53qR4C_kuJfu3HMPp1nLfwUrdv8wH0djcf3UJ2kHDTdAQLCic2kzjutGArpWDiowgFjxGVjwOF8TCBtZOD749GzsHT4yBXLvgnldP45Pc0gXxLNp4bsOmiBL9bGucuSVfo4VugEyhZ5MWKA7Z7FsG5aJD9CGW3NIqwv_HprGcUBDsmI6dMEwQ/w640-h470/XP%20Feedback%20Loops.jpg" width="640" /></a></div>
<p class="p5"><em><span class="s3">Extreme Programming feedback loops lasted from mere seconds with Pair Programming, to months with Release Plans.</span></em></p>
<p class="p3"><span class="s2">Extreme Programming also borrowed ideas about feedback loops from </span><a href="https://en.wikipedia.org/wiki/Systems_thinking"><span class="s2">Systems Thinking</span></a><span class="s2">, specifically the idea of using multiple feedback loops to keep a system, in this case a project, on track.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWD7xlDcPtr2iWCem4rfwVX6sONHQq8NB-5a70NH6Dcqz29sUK2goD2wWXT7OG8WnXBcTvkhVERkL2VBZ18uTdANLjhmBJhYYKb2Yq4KHhvfMi2O3fqDORwyHqjmg3cVech1jDJCaAeRvS_rOjf1XRKoWlNDfl6YWoDt5hAjEvt2HqZHKTcWrhvw/s1454/Scrum%20as%20an%20XP%20Wrapper.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1130" data-original-width="1454" height="498" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWD7xlDcPtr2iWCem4rfwVX6sONHQq8NB-5a70NH6Dcqz29sUK2goD2wWXT7OG8WnXBcTvkhVERkL2VBZ18uTdANLjhmBJhYYKb2Yq4KHhvfMi2O3fqDORwyHqjmg3cVech1jDJCaAeRvS_rOjf1XRKoWlNDfl6YWoDt5hAjEvt2HqZHKTcWrhvw/w640-h498/Scrum%20as%20an%20XP%20Wrapper.jpg" width="640" /></a></div>
<p class="p5"><em><span class="s3">Scrum is “deliberately incomplete”. The intent was that it should serve as a wrapper around other agile methodologies. Often, that other methodology was Extreme Programming.</span></em></p>
<p class="p3"><a href="https://en.wikipedia.org/wiki/Scrum_(software_development)"><span class="s2">Scrum</span></a><span class="s2">, created by Ken Schwaber and Jeff Sutherland, arrived publicly with a paper published in 1994. This was followed up by the first book about Scrum in 1995. At the time, Scrum was a bit of an odd duck in the agile community, because it had no software development practices. It focused entirely on management practices, and was marketed as a wrapper around other agile methods. </span></p>
<p class="p3"><span class="s2">Developers were not very interested in Scrum, because it did not have any software development practices. However, Scrum had a hidden feature that, a few years later, would give it a decisive advantage in the third methodology war, the </span><em><span class="s3">agile civil war</span></em><span class="s2">.</span></p>
<p class="p3"><em><span class="s3">Crystal</span></em><span class="s2"> (1994-1995), by </span><a href="https://en.wikipedia.org/wiki/Alistair_Cockburn"><span class="s2">Alistair Cockburn</span></a><span class="s2">, was a whole family of agile methodologies. Cockburn held that agile methodologies should be adapted according to the type of project. He rated projects on two properties, size and criticality. Most agile methodologies at the time were designed for small systems development, with a single team, and relatively low criticality, usually no higher than loss of discretionary money. Crystal could be adapted from 6-200 people, and a criticality from loss of comfort to loss of life.</span></p>
<p class="p3"><span class="s2">There were several other agile methodologies. Compared to heavyweight methodologies, they minimized administrative overhead, and were designed to enable quick change. Most had software engineering practices that enabled </span><em><span class="s3">emergent design</span></em><span class="s2">. That is, the software architecture could evolve during the course of a project, just as Herbert Benington had recommended in 1983.</span></p>
<p class="p3"><span class="s2">1994 was the year things started to come together for the agile software development methodologies. Alistair Cockburn, Jim Highsmith, Ken Schwaber and Jeff Sutherland, all published their first methodology papers that year. All of them also wrote and published books about their methodologies in the following year.</span></p>
<p class="p3"><span class="s2">Though the pieces were in position, agile software development wasn’t quite a movement yet. While working on this blog post, I asked Alistair Cockburn to review the timeline pictures in the introduction. He told me that by 1997-1998, the creators of some of the methodologies had begun talking to each other, and that was when a sense of community began to build.</span></p>
<p class="p3"><span class="s2">It is important to understand that at this time, the agile movement was to a large extent a software developer and software engineer movement. The methodologies combined good software development practices with good management practices, and that is what made them so successful.</span></p>
<p class="p3"><span class="s2">Just like Herbert Benington and the other SAGE engineers in 1956, and Dr. Winston Royce in 1970, the agile software engineers designed methods that took advantage both of advancements in technology and programming languages, and the latest advancements in management.</span></p>
<p class="p3"><span class="s2">Though Scrum existed, it was not a major part of the movement, and would not come into focus until after the Agile Manifesto was published in 2001.</span></p>
<h2 class="scr2"><strong><span class="s5">2001: The Agile Manifesto</span></strong></h2>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.</span></p><p class="p8"><span class="s2">Now, a bigger gathering of organizational anarchists would be hard to find, so what emerged from this meeting was symbolic—a Manifesto for Agile Software Development—signed by all participants.</span></p><p class="p8"><span class="s2">— </span><a href="https://agilemanifesto.org/history.html"><span class="s2">History: The Agile Manifesto page</span></a><span class="s2"> at the Agile Software Development Manifesto website</span></p></blockquote>
<p class="p3"><span class="s2">Contrary to popular opinion, the Agile Software Development Manifesto did not mark the start of the agile movement. As we have seen, it had been brewing for a long time. The various agile methodologies started to coalesce into a movement around 1997-1998.</span></p>
<p class="p3"><span class="s2">Nor is the Agile Software Development Manifesto a recipe for how to do agile development. It is a </span><em><span class="s3">symbolic</span></em><span class="s2"> statement, outlining the parts the participants at the meeting in Snowbird could agree on.</span></p>
<p class="p3"><span class="s2">To understand what the Manifesto is a symbol of, it helps to look at who came up with the idea, who the people who signed it were, and what they represented. Knowing that will help us understand what happened during the following Agile Civil War. Understanding the Agile Civil War helps us understand the current state of Agile, why the entire Agile movement is in trouble now, and why we get hare-brained, but influential, ideas about combining dysfunctional Agile with dysfunctional Waterfall. We might, just might, also gain some insight into what to do actually improve software development, for users, for developers, and for everyone else involved</span></p>
<p class="p3"><span class="s2">Fortunately, looking up who took the initiative to the Snowbird meeting is easy to do, because the information is available on the </span><a href="https://agilemanifesto.org/"><span class="s2">Agile Manifesto website</span></a><span class="s2">.</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">The meeting at Snowbird was incubated at an earlier get together of Extreme Programming proponents, and a few "outsiders," organized by Kent Beck at the Rogue River Lodge in Oregon in the spring of 2000.</span></p><p class="p8"><span class="s2">— </span><a href="https://agilemanifesto.org/history.html"><span class="s2">History: The Agile Manifesto page</span></a><span class="s2"> at the Agile Software Development Manifesto website</span></p></blockquote>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">In September 2000, Bob Martin from Object Mentor in Chicago, started the next meeting ball rolling with an email; "I'd like to convene a small (two day) conference in the January to February 2001 timeframe here in Chicago. The purpose of this conference is to get all the lightweight method leaders in one room. All of you are invited; and I'd be interested to know who else I should approach."</span></p><p class="p8"><span class="s2">— </span><a href="https://agilemanifesto.org/history.html"><span class="s2">History: The Agile Manifesto page</span></a><span class="s2"> at the Agile Software Development Manifesto website</span></p></blockquote>
<p class="p3"><span class="s2">The Agile Manifesto meeting was initiated by Extreme Programming proponents, these were extremely dedicated software engineers. Kent Beck did not just create eXtreme Programming, he also created (according to Beck himself “re-discovered”) </span><a href="https://en.wikipedia.org/wiki/Test-driven_development"><span class="s2">Test-Driven Development</span></a><span class="s2">, invented </span><a href="https://en.wikipedia.org/wiki/XUnit"><span class="s2">xUnit</span></a><span class="s2">, and with Ward Cunningham, the less known, but very useful, </span><a href="https://en.wikipedia.org/wiki/Class-responsibility-collaboration_card"><span class="s2">Class-Responsibility-Collaboration Cards</span></a><span class="s2"> (CRC Cards).</span></p>
<p class="p3"><a href="https://en.wikipedia.org/wiki/Robert_C._Martin"><span class="s2">Bob Martin</span></a><span class="s2"> (“Uncle Bob”), who took the initiative to the conference in Snowbird, is also a very influential software engineer. His company, Object Mentor, provided training on Extreme Programming. He is also credited with coining the acronym </span><a href="https://en.wikipedia.org/wiki/SOLID"><span class="s2">SOLID</span></a><span class="s2">, encompassing five important object-oriented software design principles. Martin has also done important, and very influential, work on software development metrics.</span></p>
<p class="p3"><a href="https://www.kaizenko.com/a-behind-the-scenes-look-at-the-writing-of-the-agile-manifesto/"><span class="s2">It was Bob Martin that came up with the idea of writing an agile manifesto</span></a><span class="s2">.</span></p>
<p class="p3"><span class="s2">Ok, now we know the people who got the ball rolling were some of the most hardcore software engineers in the world. What about the people who attended? </span><a href="https://agilemanifesto.org/authors.html"><span class="s2">Who were they</span></a><span class="s2">? Let’s do a walk-through:</span></p>
<ul class="ul1">
<li><em>Mike Beedle</em><span class="s7">: Software Engineer and methodologist. A proponent of XBreed, a method that combined Scrum and Extreme Programming.</span></li>
<li><em>Arie van Bennekum</em><span class="s7">: Methodologist and DSDM proponent.</span></li>
<li><em>Alistair Cockburn</em><span class="s7">: Software engineer, methodologist, and creator of the Crystal family of agile methodologies.</span></li>
<li><em>Ward Cunningham</em><span class="s7">: Software engineer. Inventor of the Wiki, and co-inventor of Class-Responsibility-Collaboration Cards. Extreme Programming Proponent.</span></li>
<li><em>Martin Fowler</em><span class="s7">: Chief scientist at Thoughtworks. Software engineer. Has written several influential books. Extreme Programming proponent.</span></li>
<li><em>Jim Highsmith</em><span class="s7">: Methodologist. Proponent of Adaptive Software Development.</span></li>
<li><em>Andrew Hunt</em><span class="s7">: Software engineer. Proponent of Pragmatic Programming.</span></li>
<li><em>Ron Jeffries</em><span class="s7">: Software engineer. Co-creator and proponent of Extreme Programming.</span></li>
<li><em>Jon Kern</em><span class="s7">: Software engineer and methodologist. Proponent of Feature-Driven Development (FDD).</span></li>
<li><em>Brian Marick</em><span class="s7">: Software testing consultant and programmer.</span></li>
<li><em>Robert C. Martin</em><span class="s7"> (“Uncle Bob”): Software engineer. Extreme Programming proponent.</span></li>
<li><em>Ken Scwaber</em><span class="s7">: Methodologist and software developer. Co-creator of Scrum.</span></li>
<li><em>Jeff Sutherland</em><span class="s7">: Methodologist and computer scientist. Co-creator of Scrum</span></li>
<li><em>Dave Thomas</em><span class="s7">: Software engineer. Co-authored The Pragmatic Programmer with Andrew Hunt.</span></li>
</ul>
<p class="p3"><span class="s2">Present at the convention, signatories, but not listed at authors:</span></p>
<ul class="ul1">
<li><em>Kent Beck</em><span class="s7">: Software engineer. Co-creator of Extreme Programming. </span></li>
<li><em>James Grenning</em><span class="s7">: Extreme Programming proponent.</span></li>
<li><em><a href="https://en.wikipedia.org/wiki/Stephen_J._Mellor">Steve Mellor</a></em><span class="s7">: Computer scientist.</span></li>
</ul>
<p class="p3"><span class="s2">Of the seventeen, how many were people that actually programmed, i.e. software engineers, software developers, and software scientists?</span></p>
<p class="p3"><span class="s2">Based on the information on the Agile Manifesto website, </span><em><span class="s3">fifteen out of seventeen wrote, or had written, code</span></em><span class="s2">!</span></p>
<p class="p3"><span class="s2">I may be off by a couple of people, but it is pretty clear that the Agile Manifesto was, for the most part, written by people who wrote code. Like Herbert Benington, </span><a href="https://en.wikipedia.org/wiki/Winston_W._Royce"><span class="s2">Dr. Winston Royce</span></a><span class="s2">, and </span><a href="https://en.wikipedia.org/wiki/Barry_Boehm"><span class="s2">Barry Boehm</span></a><span class="s2"> before them, they understood how programmers work, because they did that kind of work themselves.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZ30C_6V9skx26BPj_kTbYKnjSxC0JenpXmoLTcP_HzVsAmL9J_FKV64Fdg6ETU1i6IiPjUW-yk3yGuHPtvh_QfS7e0LNNtX0mbsR_Vze_I-afhgf207MByQ9DsDMCgbCGwcqDjwueX5Yr-euKnhu7VemaAl51SqRqRQBMrLJO2VXJmuSoxfOvMg/s1351/Agile%20Software%20Development%20with%20Scrum%2001.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="299" data-original-width="1351" height="142" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZ30C_6V9skx26BPj_kTbYKnjSxC0JenpXmoLTcP_HzVsAmL9J_FKV64Fdg6ETU1i6IiPjUW-yk3yGuHPtvh_QfS7e0LNNtX0mbsR_Vze_I-afhgf207MByQ9DsDMCgbCGwcqDjwueX5Yr-euKnhu7VemaAl51SqRqRQBMrLJO2VXJmuSoxfOvMg/w640-h142/Agile%20Software%20Development%20with%20Scrum%2001.jpg" width="640" /></a></div>
<p class="p5"><em><span class="s3">Excerpt from Mike Beedle’s part of the introduction to Software Development with Scrum, written by Mike Beedle and Ken Schwaber. Published in 2002.</span></em></p>
<p class="p3"><span class="s2">Most of the agile methodologies are complete, containing both management and software development practices. The exceptions are </span><em><span class="s3">Pragmatic Programming</span></em><span class="s2">, which is a collection of useful programming techniques, not a method, and </span><em><span class="s3">Scrum</span></em><span class="s2">. Scrum is not a methodology per sé, but a framework that can be used as a methodology wrapper. In the early days, Scrum was billed as a </span><a href="https://www.amazon.com/Agile-Software-Development-Scrum/dp/0130676349/ref=sr_1_1?crid=35UN6OP54UXOR&keywords=scrum+beedle&qid=1699886438&s=digital-text&sprefix=scrum+beedle%2Cdigital-text%2C144&sr=1-1"><span class="s2">wrapper around Extreme Programming</span></a><span class="s2">.</span></p>
<h2 class="scr2"><strong><span class="s5">2001-2005: Agile Victory?</span></strong></h2>
<p class="p3"><span class="s2">The Agile Software Development Manifesto was a landmark in the development of the Agile movement. The playing field was fairly even. If there was a leading agile methodology at the time the Agile Manifesto was written, it was Extreme Programming.</span></p>
<p class="p3"><span class="s2">My development team adopted Extreme Programming in 2002. (I remember it as 2001, but a friend who was also on the team, insists it was 2002. His memory may be more reliable than mine.) We did not stop there though. We learned as much as we could from as many methods we could: Crystal, Pragmatic Programming, Feature-Driven Development, and Adaptive Software Development. We picked up ideas from most of them.</span></p>
<p class="p3"><span class="s2">There were a couple of exceptions. We looked at DSDM, but it was not a good fit for the things we were doing, and the way we did them. We also looked at Scrum, but frankly, we were a bit baffled, because everything Scrum brought to the table was well covered by the other methodologies. We did not see any use for it. I missed completely that Scrum had one key advantage that would eventually make it victorious in the Agile Civil War.</span></p>
<p class="p3"><span class="s2">In the years 2001-2005, the popularity of Agile methodologies exploded. With the Agile Manifesto, agile methodologies had reached, and passed, a </span><a href="https://en.wikipedia.org/wiki/Tipping_point_(sociology)"><span class="s2">tipping point</span></a><span class="s2">. For us developers, the future looked very bright.</span></p>
<p class="p3"><span class="s2">2003 was a particularly important year. That was when Mary and Tom Poppendieck published their book </span><a href="https://www.amazon.com/Lean-Software-Development-Agile-Toolkit-ebook/dp/B00HEL13HW/ref=sr_1_1?crid=EGN797YQP4EA&keywords=lean+software+development&qid=1699890360&s=digital-text&sprefix=lean+software+development%2Cdigital-text%2C139&sr=1-1"><span class="s2">Lean Software Development: an Agile Toolkit</span></a><span class="s2">. LSD (not an official acronym, but I have used it since 2003) was revolutionary. It connected agile methodologies with Lean principles, queuing theory, and Cost of Delay economics.</span></p>
<p class="p3"><span class="s2">Earlier work on agile economics had focused on the value of practices. Lean Software Development gave us an overarching economic framework. Suddenly, it was possible to explain to a manager why agile methodologies provided an economic advantage over traditional methods. The book also opened up possibilities to tweak and improve existing methodologies. The book was all about working smarter, not harder. It was also a darn good read.</span></p>
<h1 class="scr1"><strong><span class="s4">Methodology War III, ca. 2001-2010: Agile Civil War</span></strong></h1>
<p class="p3"><span class="s2">The growing popularity of agile methodologies in the years following the publishing of the Agile Manifesto led to a demographic shift in the movement. Up until 2001, most people interested in agile methodologies were software engineers. Agile methodologies were not even on the radar of most managers. Following the Agile Manifesto, that quickly changed.</span></p>
<p class="p3"><span class="s2">Suddenly, company after company wanted to go agile. That created a problem. What to do with all project managers, requirements engineers, and other administrative personnel that had worked in heavyweight methodology projects? There was little room for them in an Extreme Programming project, because in those, everyone, regardless of what else they did, also wrote code. In Scrum, however, there were no software development practices, but there were two administrative roles, Scrum Master, and Product Owner.</span></p>
<p class="p3"><span class="s2">The non-programmer roles in Scrum made it possible for companies to move people from the old way of doing things to the new. Scrum also had what would become a really decisive advantage: </span><em><span class="s3">Certifications</span></em><span class="s2">!</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">“In Okinawa, belt mean no need rope to hold up pants.”</span></p><p class="p8"><span class="s2">— Mr. Miyagi, in the movie Karate Kid, 1984</span></p></blockquote>
<p class="p3"><span class="s2">Ken Schwaber set up </span><a href="https://en.wikipedia.org/wiki/Scrum_(software_development)"><span class="s2">Scrum Alliance</span></a><span class="s2"> in 2002, an organization where companies could buy courses that in a mere two days transformed anyone into a Scrum </span><em><span class="s3">Master</span></em><span class="s2"> (later also Product Owner)</span><span class="s2">. Previous experience with software development was not necessary.</span></p>
<p class="p3"><span class="s2">Companies loved it: Send a project manager in, and two days later, you got a </span><em><span class="s3">master</span></em><span class="s2"> of Scrum back, with a certification to prove it. No need to train people yourself. No need to organize for continuous training, because anyone can be a master in just two days. It’s right there in the name, so it has to be true, right?</span></p>
<p class="p3"><span class="s2">Of course, a Scrum Master has to </span><a href="https://www.scrumalliance.org/get-certified/scrum-education-units"><span class="s2">renew her or his license every two years</span></a><span class="s2">, or all that mastery goes POOF! And disappears. There is also a program where you can earn Scrum Education Units (SEU) by taking courses, and doing volonteer work for the Scrum Alliance. There are also courses for Product Owners, courses in Agile Leadership, and software development courses. Details are a bit sketchy, but it looks like the developer courses focus almost exclusively on TDD and CI/CD. This is a very small subset of the basic things a developer needs to know. The content of the leadership courses are even sketchier. There are descriptions of the general areas they focus on, but nothing on the specific practices taught.</span></p>
<p class="p3"><span class="s2">It’s a beautifully closed system, a walled garden, where people are taught Scrum and a bare minimum of everything else. It is worth noting that the agile software engineering practices taught by the Scrum Alliance are not nearly enough to fill in the gaps in the Scrum framework. If the developers know TDD (including refactoring) and CI/CD, the methodology will still be incomplete, albeit a little less so.</span></p>
<p class="p3"><span class="s2">This setup was very appealing to the people who control the money and make the decisions in most large companies, so the Scrum business model became very successful. It became so successful that other agile methodologies were pushed out.</span></p>
<p class="p3"><span class="s2">This was of course very annoying to proponents of other agile methodologies. Part of it was because it stung that Scrum suddenly was so much more successful than everyone else, but there was also a very real worry that with loss of large bodies of knowledge in software engineering, queuing theory, economics, and management, the agile movement would eventually wither and die.</span></p>
<p class="p3"><span class="s2">Newcomers to agile soon got the idea that the agile movement began with the Agile Manifesto. Scrum proponents began rewriting history, so that other methodologies got a much less prominent role in the development of agile methodologies. They also re-branded the new version of Agile, based almost entirely on the principles in the manifesto, as Agile, with a capital A.</span></p>
<p class="p3"><span class="s2">Here is an example of the rewriting that took place. These quotes are from a book published in 2019, but the same kind of rewrite happened much earlier:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">In the late nineties, some of the most successful software developers and programmers began putting their heads together in order to come up with a brand-new approach which could encompass the needs and characteristics of the software industry. This led to the emergence of the Agile Manifesto in 2001.</span></p><p class="p8"><span class="s2">— Scrum Fundamentals: A Beginner’s Guide to Mastery of The Scrum Project Management Methodology, by Jeff Cohn</span></p></blockquote>
<p class="p3"><span class="s2">Note that there is no mention that Extreme Programmers took the initiative to the meeting. Nor is there any mention of which methodologies that were represented.</span></p>
<p class="p3"><span class="s2">Cohn does mention Extreme Programming in previous passages:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">And so, the nineties brought about innovations in the field of programming and software development. One of the new methods that emerged is known as “extreme programming” or XP. This led to one of the most popular versions of the Windows operating system known as “Windows XP.”</span></p><p class="p8"><span class="s2">— Scrum Fundamentals: A Beginner’s Guide to Mastery of The Scrum Project Management Methodology, by Jeff Cohn</span></p></blockquote>
<p class="p3"><span class="s2">…and…</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">Extreme programming became one of the precursors to what would eventually become known as Agile.</span></p><p class="p8"><span class="s2">— Scrum Fundamentals: A Beginner’s Guide to Mastery of The Scrum Project Management Methodology, by Jeff Cohn</span></p></blockquote>
<p class="p3"><span class="s2">No mention of the other agile methodologies. No mention of the role Extreme Programming played in the creation of the manifesto. This is a radical rewrite of the historical record on the Agile Manifesto website.</span></p>
<p class="p3"><span class="s2">The purpose of the Agile Manifesto was also retconned.</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">The group of 17 minds which came together to develop the Agile Manifesto was intent on building a list of ideas and concepts in a framework which could serve their own industry. Nevertheless, the Agile Manifesto wasn’t just about the software industry; it was intended to have a cross-cutting appeal which could lead it to be applied to virtually any known industry.</span></p><p class="p8"><span class="s2">— Scrum Fundamentals: A Beginner’s Guide to Mastery of The Scrum Project Management Methodology, by Jeff Cohn</span></p></blockquote>
<p class="p3"><span class="s2">This is utter nonsense! You may recall what is written about the purpose of the manifesto on the manifesto website:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p8"><span class="s2">On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.</span></p><p class="p8"><span class="s2">Now, a bigger gathering of organizational anarchists would be hard to find, so what emerged from this meeting was symbolic—a Manifesto for Agile Software Development—signed by all participants.</span></p><p class="p8"><span class="s2">— </span><a href="https://agilemanifesto.org/history.html"><span class="s2">History: The Agile Manifesto page</span></a><span class="s2"> at the Agile Manifesto website</span></p></blockquote>
<p class="p3"><span class="s2">To boil it down a bit:</span></p>
<ul class="ul1">
<li>The manifesto was written by representatives for several agile methodologies: Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming. The methodologies came first! The manifesto was extracted from the ideas in the methodologies, and represented the common ground of the methodologies, nothing more.</li>
</ul>
<ul class="ul1">
<li>The manifesto is <em><span class="s8">symbolic</span></em>! It is <em><span class="s8">not</span></em> a “list of ideas and concepts in a framework”.</li>
<li>The manifesto is a manifesto for agile <em><span class="s8">software</span></em> development! It was <em><span class="s8">not</span></em> “ intended to have a cross-cutting appeal which could lead it to be applied to virtually any known industry”.</li>
</ul>
<p class="p3"><span class="s2">Why rewrite history in this way?</span></p>
<ul class="ul1">
<li>It reduces interest in other methodologies than Scrum.</li>
<li>It makes it possible to sell Agile everywhere, and so, expands the business.today, we have Agile HR, Agile Finance, Agile, Agile Healthcare, etc.</li>
</ul>
<p class="p3"><span class="s2">Principles are, to a certain extent, transferable between different areas. Methodologies, on the other hand, are not transferable in the same manner. Methodologies are also harder to create, because you must understand </span><em><span class="s3">how</span></em><span class="s2"> to implement the principles in a specific area of endeavor. That cannot be done without domain specific knowledge.</span></p>
<p class="p3"><span class="s2">It is also relatively easy to create the </span><em><span class="s3">illusion</span></em><span class="s2"> that a principle is understood. For example:</span></p>
<p class="p8"><span class="s2"><i>Responding to change over following a plan</i></span></p>
<p class="p3"><span class="s2">A coach like me can talk about the importance of responding to change over following a plan to just about any audience. The catch is that implementations are very different in different domains. If you do not know how to translate the principle into methods, the principle will remain a fond wish. Some examples of how the principle can be translated:</span></p>
<ul class="ul1" style="text-align: left;">
<li><em>Emergent design</em><span class="s7"> in software development requires knowledge about how to create loosely coupled designs. A methodology has methods for this, like:</span>
<ul class="ul1">
<li>Iterative development (Not incremental development! Big difference. Scrum and SAFe have shifted the focus from iterative to incremental. Probably because iterative development requires higher levels of software engineering skills.)</li>
<li>Test-Driven Development(TDD)</li>
<li>Design Patterns</li>
<li>Continuous Integration/Continuous Deployment</li>
<li>Domain-Driven Design</li>
</ul></li>
<li>In the military you might find:
<ul class="ul1">
<li>Commander’s Intent</li>
<li>Reversed Command Chains</li>
<li>Generic rules about what to do when the plan fails, i.e. “take the high ground…”</li>
</ul></li>
<li>In the automotive industry
<ul class="ul1">
<li>Single Minute Exchange of Die (SMED) made it possible to respond to different kinds of orders by producing small quantities of different cars on the same production line. This gave Toyota an economic advantage over all other car manufacturers in the world after WWII, and helped pave the way for Toyota’s success.</li>
</ul></li>
<p class="p3"><span class="s2">What Agile, with a capital “A”, did was that it raised a set of symbolic statements to the status of principles, and then focused on packaging and selling them. It moved away from methodologies and practical implementation of the ideas.</span></p>
<p class="p3"><span class="s2">The software engineering based methodologies could not compete. Learning them required both time and effort. Scrum and Agile promised relatively quick and easy fixes.</span></p>
<h2 class="scr2"><strong><span class="s5">2008: Agile in Decline</span></strong></h2>
<p class="p3"><span class="s2">In 2008(-ish) I held a presentation at an Agile convention in Malmö, Sweden. I began by talking about the astonishing results you could get with agile methodologies: 5-6 times faster development. Every time I presented an example the audience cheered and clapped.</span></p>
<p class="p3"><span class="s2">Then I asked: “How do you think that can be? The developers can’t type 5-6 times faster. They can’t think 5-6 times faster. How can they deliver 5-6 times faster?”</span></p>
<p class="p3"><span class="s2">The audience went dead quiet. Nobody knew. In a room full of Agile practitioners and experts, it turned out nobody knew how Agile worked. Nor did they know if it really worked for themselves, just that studies said it had worked for someone else.</span></p>
<p class="p3"><span class="s2">I am pretty sure lots of folk there could quote the Agile principles from the Manifesto though.</span></p>
<p class="p3"><span class="s2">In this particular case, if you know a little bit about queuing theory, Lean, or Theory of Constraints (TOC), the question is easy to answer.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgEAkeXmDS6vmSOI4hVT0IPDEj2aFwq-A74Ws8Ll8u0fuFy591rswYjBGVg5ZryHRqaLwy5dOu1vMSca-8MQjebw2sV7U9cNLtT3BxrrIsjNqWu_OXDKDArn4bccKU4j2Ds00VxBq4ONrol5idXvz2I0C7RPq7STJBH2wpqZ-gKbBDnJVZ66NkN4A/s320/Bild%2009%20cmp_batch_sizes.gif" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="240" data-original-width="320" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgEAkeXmDS6vmSOI4hVT0IPDEj2aFwq-A74Ws8Ll8u0fuFy591rswYjBGVg5ZryHRqaLwy5dOu1vMSca-8MQjebw2sV7U9cNLtT3BxrrIsjNqWu_OXDKDArn4bccKU4j2Ds00VxBq4ONrol5idXvz2I0C7RPq7STJBH2wpqZ-gKbBDnJVZ66NkN4A/w400-h300/Bild%2009%20cmp_batch_sizes.gif" width="400" /></a></div>
<p class="p5"><em><span class="s3">In this animation the yellow and the blue projects do exactly the same things, and work equally fast, but the blue project finishes in half the time. Why?</span></em></p>
<p class="p3"><span class="s2">The little animation above shows you why agile projects finish first: It shows work flowing from start to finish, in two projects, Blue and Yellow. The projects start at the same time, and do exactly the same things. At every stage in the process, both teams work at exactly the same velocity.</span></p>
<p class="p3"><span class="s2">Despite all these things being equal, team Blue finishes in half the time of team Yellow. The one difference, is the length of the iterations. Team Blue has iterations half the length of team Yellow’s iterations. Because of this, team Blue has twice as many iterations as team Yellow. Pieces of work is transferred much more often, wait times are cut in half, and the work is finished faster.</span></p>
<p class="p3"><span class="s2">There are a number of ways to limit work in the process to achieve this effect: Iteration duration, kanban (as in the original Lean method), TOCs Drum-Buffer-Rope, CONWIP. They are all a little different, and which one you choose depends on what works best in your situation.</span></p>
<p class="p3"><span class="s2">…except that since we do not teach those things in Agile anymore, it is a bit optimistic to believe you will get that kind of effect. For example, I fairly often see large “Agile” projects that follow the rules of iteration lengths and WIP limits in Scrum or Kanban, but get zero effect, because nobody knows that limiting WIP for each team in a project is not the same as limiting WIP for the project as a whole.</span></p>
<p class="p3"><span class="s2">By 2010 the Agile Civil War was over. Agile won. Agile software development methodologies lost. Much of the original body of knowledge was discarded.</span></p>
<h1 class="scr1"><strong><span class="s4">Waterfall - The Slowest There Is!</span></strong></h1>
<p class="p3"><span class="s2">We are not quite done with the animation above yet. It shows one of the many reasons why Waterfall projects are such a bad idea:</span></p>
<p class="p3"><span class="s2">What is the absolutely slowest way for a team to finish the project?</span></p>
<p class="p3"><span class="s2">It is to have only one iteration. (Team Yellow, the slow team, has four iterations in the animation. Imagine them having only one iteration. They will be four times slower than they currently are, and eight times slower than team Blue.)</span></p>
<p class="p3"><span class="s2">How many iterations does a Waterfall project have?</span></p>
<p class="p3"><span class="s2">Only one!</span></p>
<p class="p3"><span class="s2">That means, it is theoretically impossible for Waterfall projects to be as fast as Agile projects.</span></p>
<p class="p3"><span class="s2">Waterfall is also slower than any methodology that supports parallelization of work, like the Critical Path Method (CPM), the Spiral Method, and RAD. Waterfall is slower than anything allowed in the MIL-STD-498 US Department of Defense standard from 1994. Waterfall is slower than the method the SAGE project </span><em><span class="s3">actually</span></em><span class="s2"> used in 1953-1956.</span></p>
<p class="p3"><span class="s2">This also means Waterfall is much more expensive than any other software development method in the world.</span></p>
<p class="p3"><span class="s2">In the 2009 book </span><a href="https://www.amazon.com/Principles-Product-Development-Flow-Generation-ebook/dp/B00K7OWG7O/ref=sr_1_1?crid=1FK5KBF9LFLH4&keywords=flow+reinertsen&qid=1699981531&s=digital-text&sprefix=flow+reinertsen%2Cdigital-text%2C138&sr=1-1"><span class="s2">Flow: The Principles of Product Development Flow</span></a><span class="s2">, Donald Reinertsen lists other problems with having to much work in process:</span></p>
<ul class="ul1">
<li>Increased variability</li>
<li>Increased risk</li>
<li>Increased cycle time</li>
<li>Decreased efficiency</li>
<li>Decreased quality</li>
<li>Decreased motivation</li>
</ul>
<p class="p3"><span class="s2">Advantages? None! It’s all bad.</span></p>
<h1 class="scr1"><strong><span class="s4">The Worst of Two Worlds: Agile + Waterfall</span></strong></h1>
<p class="p3"><span class="s2">Waterfall is the worst thing that came out of traditional methodologies. Agile, with a capital “A”, is the worst thing that came out of the agile movement.</span></p>
<p class="p3"><span class="s2">Combining two bad things is unlikely to produce good results. There are also number of ways that Waterfall and Agile come into direct conflict. Let’s break it down:</span></p>
<ul class="ul1">
<li>Waterfall is optimized for machine code programming using punch cards, with extremely high cost of change. Agile is optimized for developers working with object-oriented languages at a interactive terminals, with very fast feedback, and low cost of change. (The original agile methodologies were designed to actively reduce the cost of change, while Agile more or less makes the assumption that cost of change is low. This is one of the reasons why Agile is in trouble.)</li>
<li>Waterfall is a push process. Agile relies on pull processes. Combining push and pull processes does not work very well. You are likely to see bloody wars between people in the push parts of the process and people in the pull parts.</li>
</ul>
<ul class="ul1">
<li>Waterfall uses a single iteration, and maximizes Work-In-Process. Agile uses short iterations and strives to minimize Work-In-Process.</li>
<li>Waterfall strives to eliminate feedback loops, so you can move people out of a project as soon as the phase they are working on is finished. Agile has many complete iterations, with lots of feedback loops, so you need to keep teams as stable as possible over the duration of a project.</li>
<li>Waterfall locks requirements as early as possible. Agile uses emergent design to respond to requirements changes. (Well, Agile does that when done right. Not if it has degraded too much.)</li>
<li>Waterfall uses functional teams. Agile uses cross-functional teams.</li>
<li>Waterfall breaks work down into functional units of work. Agile breaks work down into vertically sliced units of work. If you use Waterfall style breakdown, you can’t do small frequent deliveries, and Agile project economics goes down the drain. If you do Agile style breakdown, you can’t maximize resource utilization, and Waterfall style project economics goes down the drain.</li>
<li>Both Waterfall and Agile have dysfunctional ideas about how to plan large projects. They fail to take statistical variation and probability distribution of work package duration into account. (Neither Waterfallers, nor Agilists like to do math, so for the most part, they ignore it.)</li>
<li>Waterfall is based on Theory X management. Agile is based on Theory Y management.</li>
<li>Waterfall uses Cost Accounting. Agile projects (when run correctly) use Lean or Throughput Accounting, rolling budgets, and Profit & Loss models.</li>
</ul>
<p class="p3"><span class="s2">…and so on. </span></p>
<p class="p3"><span class="s2">You can’t just switch out one of the things above, without switching the others. They are connected. Another problem is that, while there are plenty of things wrong with Agile, no matter what part of Waterfall you swap in, the situation gets even worse.</span></p>
<p class="p3"><span class="s2">That does not mean we are helpless though. There are lots of things that can be done. There are also several large bodies of knowledge that can be helpful.</span></p>
<h1 class="scr1"><strong><span class="s4">What to do instead: The Best of Agile + the Best of Traditional Methods + New Solutions</span></strong></h1>
<p class="p8"></p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><span class="s2">“Thanks! Though, now I have to think again.”<br /></span><span class="s2">— Henrik Mårtensson (Yep! That’s me!) after statistician Fredrik Johansson sent Henrik a paper on Monte Carlo simulation.</span></blockquote><p></p>
<p class="p3"><span class="s2">If we seriously want to fix the current problems in software development, rather than desperately flailing about grasping for straws, maybe, just maybe, we should try to understand what the problems are, and then start experimenting with solutions, learning as we go.</span></p>
<p class="p3"><span class="s2">I am not going to give you a recipe for solving your problems. While the problems with Agile usually are similar, the causes may be different. The degrees of freedom in finding solutions are also different. Thus, while you can get a lot of inspiration from what others have done, copying it right off is unlikely to work.</span></p>
<p class="p3"><span class="s2">I will however give you a few examples that can work in some situations, for some organizations. It is </span><em><span class="s3">not</span></em><span class="s2"> a To Do list! Use it for inspiration.</span></p>
<h2 class="scr2"><strong><span class="s5">Learn from the past, but don’t copy it!</span></strong></h2>
<p class="p3"><span class="s2">If we do not learn from the past, we are doomed to repeat old mistakes. If we do learn from the past, we get a better understanding of our current situation, and the trajectory we are on.</span></p>
<p class="p3"><span class="s2">The entire Agile+Waterfall hybrid discussion exists because we have trouble learning from the past. It’s proponents can’t distinguish between Waterfall and traditional methods, for one thing. That makes it difficult to pick up the useful things that can be found in traditional methods. It also makes it easy to bring in the really bad parts of Waterfall. (Which would be just about any part of it, in case you are still wondering.)</span></p>
<p class="p3"><span class="s2">The history of Waterfall has been completely rewritten. What was a series of misunderstandings and failures, have been retconned into a story about valuable treasure buried easily accessible just below the surface. The history of traditional, heavyweight methodologies is entirely ignored at worst, and confused with Waterfall at best. Agilists have similar problems with memory loss and the creation of an alternate history.</span></p>
<p class="p3"><span class="s2">My advice is, do not rely on authorities, not even me! Go to the original sources and check for yourself.</span></p>
<p class="p3"><span class="s2">I have provided plenty of links to source material in this article, but I recommend that in addition to checking them out, you should also do your own searches. You may, probably will, turn up important information that I missed. Just be very cautious about accounts of events that are written long after the event itself, by people who were not there.</span></p>
<p class="p3"><span class="s2">Personally, in most cases, I do not even bother with articles that do not link to their source material. I do read the source material when links are available, and as you have noted, I often find that the source material says something completely different from what the article author claims.</span></p>
<h2 class="scr2"><strong><span class="s5">Training</span></strong></h2>
<p class="p3"><span class="s2">Early agile methodologies were simpler than traditional methods, but you still had to learn a lot in order to use them. For highly motivated managers and developers, this is not a problem. Learning stuff is fun! Seeking out new knowledge is fun! Practicing is fun!</span></p>
<p class="p3"><span class="s2">If you are not a total nerd, or if you are a nerd who also wants a life when you are not working, you may need a bit of help. I am not a big fan of pre-packaged courses. They can be a good way to get started, but they do have a tendency to be a bit superficial, and their source material is often a bit questionable.</span></p>
<p class="p3"><span class="s2">If you can, build your own learning program, and your own learning organization. Do not be too narrowly focused in what you learn. Great insights often come from combining different areas of knowledge. Here are some areas you might want to look into, in random order:</span></p>
<ul class="ul1">
<li>Software engineering</li>
<li>Systems Thinking</li>
<li>Complexity Science</li>
<li>Queuing Theory</li>
<li>Statistics</li>
<li>Economics
<ul class="ul1">
<li>Profit & Loss statements</li>
<li>Cost of Delay</li>
<li>Lean and Throughput Accounting</li>
</ul></li>
<li>The Deming Knowledge System</li>
<li>Lean</li>
<li>Theory of Constraints</li>
<li>Agile methodologies (Start with Lean Software Development)</li>
<li>Traditional methodologies (Read up on queuing theory first)</li>
<li>Photography (You wont get better at software development, but it is a nice hobby. There are other nice hobbies you can use to decompress, or so I’ve heard.)</li>
</ul>
<p class="p3"><span class="s2">Some companies encourage employees to use four hours (may vary) each week to learn and practice. If so, make the best of it. Build an informal network of learners. If necessary, build a formal network of learners. Personally, I have found that informal networks work best. They are usually broader in scope, and more enthusiast-driven.</span></p>
<h2 class="scr2"><strong><span class="s5">Forget the movements, manifestos, and fads. Just figure out how to do the work!</span></strong></h2>
<p class="p3"><span class="s2">Theory is highly useful, but movements, manifestos, and fads tend to be superficial and have less value than it initially looks. Focus on things that interest you, and things that actually help you get the work done.</span></p>
<p class="p3"><span class="s2">If you join a movement, do not get so caught up in it that you forget to keep track of other points of view. Don’t get caught up in cults.</span></p>
<p class="p3"><span class="s2">When you find something that looks interesting, don’t just go by information from the enthusiasts, check out what the critics say too. It may save you from wasting years on stuff that does not work.</span></p>
<p class="p3"><span class="s2">By the way, Scrum Theory, is not theory. It is a set of hypotheses. Be aware of the difference.</span></p>
<h2 class="scr2"><strong><span class="s5">Actively reduce the cost of change</span></strong></h2>
<p class="p3"><span class="s2">To handle changing requirements, you need software that is easy, and cheap, to change. Your main tools to accomplish that, will probably be a set of software engineering tools.</span></p>
<p class="p3"><span class="s2">Have a look at Extreme Programming, the Crystal family of methodologies, S.O.L.I.D. by Robert Martin, Pragmatic Programming, Domain-Driven Design, and Design Patterns to get started, but don’t stop there.</span></p>
<h2 class="scr2"><strong><span class="s5">Parallelization</span></strong></h2>
<p class="p3"><span class="s2">To plan a large project well, you need to be able to plan parallel activities. Start by having a look at Critical Path Method (CPM), Critical Chain from TOC, and Blitz Planning from the Crystal methodologies.</span></p>
<p class="p3"><span class="s2">It will pay off to also know a bit of queuing theory (WIP control, transfer batches, etc.). You need to know enough statistics to be able to figure out whether your time estimates work or not. If they don’t, you will need Monte Carlo simulation and aging analysis, and enough statistics to figure out if </span><em><span class="s3">they</span></em><span class="s2"> work.</span></p>
<h2 class="scr2"><strong><span class="s5">Monte Carlo Simulation</span></strong></h2>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEFeYt5AY7qcptCxyKcHyBxEBD9wXAp3MDXSzjaLOgvO3OA2MIee5rANDtokZU67EYzvmgFaPRTnqXfqWjrfLRJkAxKU2KS2biYBn_t4wTJOHhBxlPf-pF_1u57mtD9xlAEodnwNmSZdKLh1mvQUnNvIUbVT5dq5cCPM_unJBxeCN2ImnxUheShQ/s1995/Scatterplots%20-%20Estimates%20vs.%20Cycle%20Times.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="663" data-original-width="1995" height="212" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEFeYt5AY7qcptCxyKcHyBxEBD9wXAp3MDXSzjaLOgvO3OA2MIee5rANDtokZU67EYzvmgFaPRTnqXfqWjrfLRJkAxKU2KS2biYBn_t4wTJOHhBxlPf-pF_1u57mtD9xlAEodnwNmSZdKLh1mvQUnNvIUbVT5dq5cCPM_unJBxeCN2ImnxUheShQ/w640-h212/Scatterplots%20-%20Estimates%20vs.%20Cycle%20Times.jpg" width="640" /></a></div>
<p class="p5"><em><span class="s3">Scatterplots showing why neither Agile nor Waterfall estimation methods work.</span></em></p>
<p class="p3"><span class="s2">Monte Carlo simulation is a way to make a </span><em><span class="s3">prognosis</span></em><span class="s2"> based on previous data. Use when estimates are uncertain. (My experience is that is pretty much all the time).</span></p>
<p class="p3"><span class="s2">Measure the </span><em><span class="s3">correlation coefficient</span></em><span class="s2"> between estimates and actual duration in order to figure out whether your estimates work. You can also use </span><em><span class="s3">scatter plots</span></em><span class="s2">, as in the figure above.</span></p>
<p class="p3"><span class="s2">Did I mention you need to know a little bit about of statistics to plan a large project effectively? If you are a manager, understanding it on a conceptual level may be good enough, if you also hire a project statistician.</span></p>
<h2 class="scr2"><strong><span class="s5">Aging analysis</span></strong></h2>
<p class="p3"><span class="s2">Aging analysis is a good alternative when you have no clue what the business value and/or duration of work packages is.</span></p>
<h2 class="scr2"><strong><span class="s5">Use Cases</span></strong></h2>
<p class="p3"><span class="s2">User stories are intended for small projects with on site users. For large projects, or when users will not be readily available. Look at the stuff Alistair Cockburn and Ivar Jacobson are working on.</span></p>
<h2 class="scr2"><strong><span class="s5">Dependency Jar</span></strong></h2>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxJoqP_oNmazUT4_yN2ikE3YQHNlL5Ree5U-MLCAfqjwaZffRK-xpEPi_4Z65ryyyHsN7bpfNNXnQPPSM_2L8KyQLDjOMwy6sty966WYQ67yQmnxuHEnCt9cRhg2BTEThOVr4_6cjdBlWoFFVhywjd_8A2r7_JBGlVHloRHlANqQBWKU79kcAgYQ/s4032/Dependency%20Jar%20IMG_1905.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="3024" data-original-width="4032" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxJoqP_oNmazUT4_yN2ikE3YQHNlL5Ree5U-MLCAfqjwaZffRK-xpEPi_4Z65ryyyHsN7bpfNNXnQPPSM_2L8KyQLDjOMwy6sty966WYQ67yQmnxuHEnCt9cRhg2BTEThOVr4_6cjdBlWoFFVhywjd_8A2r7_JBGlVHloRHlANqQBWKU79kcAgYQ/w640-h480/Dependency%20Jar%20IMG_1905.jpg" width="640" /></a></div>
<p class="p3"><span class="s2">A very simple tool for identifying what kind of dependencies a team has. This one is my little invention.</span></p>
<p class="p3"><span class="s2">Every time a developer is delayed by something, they write a note about it and drop it in the jar. If the delay is more than a day, they write a note each day.</span></p>
<p class="p3"><span class="s2">Empty the jar at the end of each iteration, organize the notes in classes, and try to fix the most serious causes of delay.</span></p>
<p class="p3"><span class="s2">Works for short periods of time, until the developers get tired of it, and you. Still, it can be very helpful. My experience is that you can identify about four times more dependencies than you can at planning sessions, like SAFe’s PI planning. Mileage varies though.</span></p>
<h2 class="scr2"><strong><span class="s5">Parallel experiments</span></strong></h2>
<p class="p3"><span class="s2">When there is something you do not know, device multiple experiments, and run them in parallel. Stop failing experiments as early as possible. If you have more than one experiment that succeeds, see if you can combine them to get an even better solution.</span></p>
<h2 class="scr2"><strong><span class="s5">Prototyping</span></strong></h2>
<p class="p3"><span class="s2">Build prototypes to test ideas, and see whether they work. A prototype may be very simple, a paper prototype, perhaps built using CRC cards. It may also be a functioning miniature version of the thing you are building. Focus on the things you are most uncertain about.</span></p>
<h1 class="scr1"><strong><span class="s4">Beware disinformation: The HBR article and the London Crossrail Project</span></strong></h1>
<p class="p3"><span class="s2">Be very careful about which sources you believe. Whenever possible, go to the original sources, and look for yourself!</span></p>
<p class="p3"><span class="s2">For example, the Harvard Business Journal article that got me started writing this article, is utterly confused about nearly everything. The author refers to several building projects, claims that they used Waterfall, and were very successful. Then he claims that this is proof Waterfall works great for software projects. There are several things wrong with this:</span></p>
<ul class="ul1">
<li>Software development projects and building projects have very different cost of change. The correlation between estimates and actual implementation times is likely to be different. Task duration distribution probabilities are different. All of this means you need to adapt the methodology you use for the context you use it in. You can't just pick a methodology used in a building project, start using it for a software development project, and expect it to work.</li>
<li>Building projects do not necessarily use Waterfall! Building projects use very effective parallelization of tasks, prototyping, WIP control, databases with task duration times, decoupling of workflows… Some building projects adapt Lean processes.</li>
<li>I checked one of the projects the article refers to, The London Crossrail project, and it is not even close to using Waterfall. Nor was it a great success.
<ul class="ul1">
<li>Project planning began in 1974. The building project started 2008, and finished in 2019. In other words, 34 years of planning, 11 years of execution, for a total of 45 years. This is <em><span class="s8">not</span></em> a speed record! For comparison, <a href="https://en.wikipedia.org/wiki/Empire_State_Building">the Empire State Building</a> took about eight months to build in 1930-1931, including planning time. Planning of the Empire State Building was done in parallel with building it.</li>
<li>The goal was to facilitate London’s “continued development as a world city and sustain its position as the financial centre of Europe”. (See <a href="https://learninglegacy.crossrail.co.uk/documents/execution-strategy-delivering-londons-elizabeth-line/">The Execution Strategy for Delivering London’s Elisabeth Line</a>, page 2.) Brexit was in 2020, so that goal fell apart soon after the project finished in 2019.</li>
</ul></li>
<p class="p3"><span class="s2">If you want to know how good building projects really work, and how the </span><em><span class="s3">Empire State Building</span></em><span class="s2"> was built in about eight months, I suggest you watch Mary Poppendieck’s famous presentation </span><a href="https://www.infoq.com/presentations/tyranny-of-plan/"><span class="s2">The Tyranny of the Plan</span></a><span class="s2">. You can also read a </span><a href="https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of-the-plan/"><span class="s2">transcript of the presentation</span></a><span class="s2">, if you prefer that.</span></p>
<p class="p3"><span class="s2">Finally, let’s have a closer look at the project I mentioned, the </span><em><a href="https://learninglegacy.crossrail.co.uk/learning-legacy-themes/project-and-programme-management/initiation-and-development/"><span class="s3">London Crossrail Project</span></a></em><span class="s2">.</span></p>
<p class="p3"><span class="s2">Before anyone started building anything, a pre-study, </span><a href="https://learninglegacy.crossrail.co.uk/wp-content/uploads/2016/02/PPM_SRA-London-EastWest-Study.pdf"><span class="s2">the London West-End study</span></a><span class="s2"> was made. The study identified three major delivery packages:</span></p>
<ul class="ul1">
<li>Paddington-Liverpool Street</li>
<li>Wimbledon-Liverpool Street</li>
<li>Wimbledon-Hackney</li>
</ul>
<p class="p3"><span class="s2">The people doing the prestudy created an economic model of the three delivery packages, and calculated Net Present Value for each alternative. The model included cost of delay, and effects of capital cost increases, and six other criteria. They also assessed regional metros and regional express. This allowed the project to prioritize according to business value. Then they made their recommendations.</span></p>
<p class="p8"></p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><span class="s2">In the light of the assessment it is our recommendation that the Paddington to Liverpool Street Regional Metro should progress to the project definition stage and should form the backbone of the 20 year programme.<br /></span><span class="s2">— </span><a href="https://learninglegacy.crossrail.co.uk/wp-content/uploads/2016/02/PPM_SRA-London-EastWest-Study.pdf"><span class="s2">The London West-End Study</span></a><span class="s2">, page 17</span></blockquote><p></p>
<p class="p3"><span class="s2">In other words, they used an </span><em><span class="s3">iterative</span></em><span class="s2"> approach with </span><em><span class="s3">multiple partial deliveries</span></em><span class="s2">, and prioritized them according to </span><em><span class="s3">business value</span></em><span class="s2">. That is a lot more like Agile than it is like Waterfall.</span></p>
<p class="p3"><span class="s2">To top it off, the project was designed to allow for changing requirements:</span></p>
<p class="p8"></p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><span class="s2">A scheme exists for the extension of the existing Heathrow Express line from the central area of the Airport, under the site of the proposed Terminal 5 to join up with the South West network in the Staines area. It is envisaged that this would be constructed as an adjunct to the Terminal 5 works and would only proceed if consent for Terminal 5 is forthcoming.<br /></span><span class="s2">— </span><a href="https://learninglegacy.crossrail.co.uk/wp-content/uploads/2016/02/PPM_SRA-London-EastWest-Study.pdf"><span class="s2">The London West-End Study</span></a><span class="s2">, page 18</span></blockquote><p></p>
<p class="p3"><span class="s2">That is </span><em><span class="s3">emergent design</span></em><span class="s2">! The architecture is extended </span><em><span class="s3">if</span></em><span class="s2"> the requirements change.</span></p>
<p class="p3"><span class="s2">Summing up, the London Crossrail project was a Waterfall+Agile hybrid, kind of. The 34 years of up front planning was what you can expect from a very large Waterfall project. Once construction started, you had a far more agile project:</span></p>
<ul class="ul1">
<li>iterations</li>
<li>multiple deliveries</li>
<li>prioritisation according to business value</li>
<li>emergent design in response to changing requirements</li>
</ul>
<p class="p3"><span class="s2">I have no idea why the article author used the London Crossrail project as an example of a successful Waterfall project, when it clearly was not.</span></p>
<p class="p3"><span class="s2">I can understand how someone that is not a methodologist gets Waterfall and traditional methodologies mixed up, but this is the author of the </span><em><span class="s3">Harvard Business Review Project Management Handbook</span></em><span class="s2">, a visiting professor in seven business schools. He ought to be able to distinguish between Waterfall, traditional methodologies, Agile, and agile software development methodologies. He also ought to know that starting the project with 34 years of planning does not make it a good template for how to run a successful software project. It’s not really a good way to start a successful building project either.</span></p>
<p class="p3"><span class="s2">There is always the possibility that I got it wrong, and he knows something I don’t, but in this case I doubt it. There are gaps in the historical record from 1956 to the present, but the key papers, and writings of people who were present at the time, are available, and what they say is pretty clear:</span></p>
<p class="p3"><span class="s2">Waterfall sucks!</span></p></ul></ul>Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-34371776122172287222023-09-24T21:36:00.009+02:002023-11-16T15:35:28.742+01:00Waterfall - The Dark Age of Software Development Has Returned!<p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkafBLue0pIQE7gmFxaKFCcOfEtBTr4rwk3EfmxRsFc3ZldhJuovk65Y0sJnBoF8mqLnqYYFWq1Il0Q7c9HdrzwSr2K05YLhGjRTDyRuWfIoGRcivTUVKTD-KC8M39Sg_zGe5MF9IuUAwyf86gPgb01kTfGzVosernX_6Kgjk0yWNl8Jn1IvmVrg/s2400/Waterfall_DAP_Watercolor.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1800" data-original-width="2400" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkafBLue0pIQE7gmFxaKFCcOfEtBTr4rwk3EfmxRsFc3ZldhJuovk65Y0sJnBoF8mqLnqYYFWq1Il0Q7c9HdrzwSr2K05YLhGjRTDyRuWfIoGRcivTUVKTD-KC8M39Sg_zGe5MF9IuUAwyf86gPgb01kTfGzVosernX_6Kgjk0yWNl8Jn1IvmVrg/w640-h480/Waterfall_DAP_Watercolor.png" width="640" /></a></div><p></p><p class="p3"><span class="s1"></span></p><blockquote><span class="s1">I honestly beleave it iz better tew know nothing than two know what ain’t so.<br />— Everybody’s Friend, 1874, by Josh Billings</span></blockquote><p></p>
<p class="p4"><span class="s1">To my horror, more and more often the past few years, I have seen people advocating for using the Waterfall method of software development. I have also seen it in job descriptions, for example “we use a mix of Agile and Waterfall”.</span></p>
<p class="p4"><span class="s1">Why am I horrified? Because Waterfall was never intended to become a software development method. Waterfall is now, as it was from the beginning, a way to describe why many large software development projects fail.</span></p>
<p class="p4" style="text-align: center;"><em><span class="s2">There is no scenario where Waterfall is a good approach to software development</span></em><span class="s1">!</span></p>
<p class="p4" style="text-align: left;"><span class="s1">To back up that statement, let’s go back to the origin of Waterfall, a whitepaper by Dr. Winston Royce, </span><em><a href="https://dl.acm.org/doi/10.5555/41765.41801"><span class="s2">Managing the Development of Large Software Systems</span></a></em><span class="s1"> from 1970.</span></p>
<h1 class="scr1"><strong><span class="s3">The Origin of Waterfall</span></strong></h1>
<p class="p4"><span class="s1"><i><b>Note</b>: The origin of Waterfall goes back quite a bit further than 1970. In another, later article, <a href="https://kallokain.blogspot.com/2023/11/waterfall-vs-agile-battle-of-dunces-or.html" target="_blank">Waterfall vs. Agile: Battle of the Dunces or a Race to the Bottom</a>, I go back to the 1956 article by Herbert Benington that kicked it all off. Worth noting that Benington did not like Waterfall either.</i></span></p><p class="p4"><span class="s1">I have seen articles by Waterfall advocates referring to Dr. Winston Royce and his paper. In most cases it is obvious the article authors have never read it! The paper does not say what they think it does. It actually says the opposite! Here is an example, from an article advocating Waterfall:</span></p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p style="text-align: left;">
It’s a thorough, structured methodology and one that’s been around for a long time, because it works.</p><p class="p3" style="text-align: left;"><span class="s1">— </span><a title="https://www.projectmanager.com/guides/waterfall-methodology"></a><a href="https://www.projectmanager.com/guides/waterfall-methodology"><span class="s1">The Ultimate Guide…Waterfall Model</span></a><span class="s1">, ProjectManager.com</span></p></blockquote><p class="p3" style="text-align: left;"><span class="s1"></span></p>
<p class="p4"><span class="s1">Not true! As I will show in this article, Waterfall has been around for a long time because of lack of competence, unfortunate and downright weird misunderstandings, and a badly written US DoD standard.</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p3"><span class="s1">Dr. Winston W. Royce at the Lockheed Software Technology Center introduced the concept in a paper published in 1970 on his experience developing software for satellites.</span></p><p class="p3"><span class="s1">— </span><a href="https://www.techtarget.com/searchsoftwarequality/definition/waterfall-model"><span class="s1">waterfall model</span></a><span class="s1">, TechTarget article by Ben Lutkevich</span></p></blockquote>
<p class="p4"><span class="s1">The above statement is technically true, but misleading. Royce did introduce the concept in his paper. What both articles I quoted left out, is what Royce wrote about the Waterfall approach. Here is an example:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p3"><span class="s1">…the implementation described above is risky and invites failure.</span></p><p class="p3"><span class="s1">— </span><a href="https://dl.acm.org/doi/10.5555/41765.41801"><span class="s1">Managing the Development of Large Software Systems</span></a><span class="s1">, Dr. Winston Royce, 1970</span></p></blockquote>
<p class="p4"><span class="s1">Just a few lines later in Dr. Royce’s paper:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><p class="p3" style="text-align: left;"><span class="s1">The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs. </span></p></blockquote>
<p class="p4"><span class="s1">I’d like to draw your attention to the last sentence. It is worth repeating: </span></p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><p class="p4" style="text-align: left;"><em><span class="s2">In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs</span></em><span class="s1">.</span></p></blockquote>
<p class="p4"><span class="s1">Actually, Dr. Royce underestimated the cost overruns with waterfall projects. Even the successful ones cost a lot more than an agile project, if the agile project uses an agile method that supports both Cost of Change reduction, and small batch transfers, like Extreme Programming, one of the Crystal family of methods, or Lean Software Development.</span></p>
<p class="p4"><span class="s1">Dr. Royce did believe in breaking a project down into a linear sequence of phases, but, and it is an important but, he understood very well that feedback, and thus making corrections iteratively, are necessary. He understood very well that Waterfall is risky, and that the risk of very large cost overruns is high.</span></p>
<p class="p4"><span class="s1">Note that this was in 1970. Object oriented programming languages, and modern software design, had not been invented yet! There were no design patterns, no Domain-Driven Design, no Test-Driven Design, no automated testing, no refactoring, or refactoring patterns. Barry Boehm’s groundbreaking work on software economics would not be published until eleven years later. It was ten years before the Lean revolution changed the manufacturing industry, so only a few people, who were either scientists or working at Toyota, understood things like the effects of batch transfer sizes and Work-In-Process. AI assisted software development existed only in Science-Fiction stories, usually with horrible consequences.</span></p>
<p class="p4"><span class="s1">There were </span><a href="https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique#Next_step,_creating_network_diagram_by_hand_or_by_using_diagram_software"><span class="s1">PERT</span></a><span class="s1"> (1958) and </span><a href="https://en.wikipedia.org/wiki/Gantt_chart"><span class="s1">GANTT</span></a><span class="s1"> (1910-1915) charts. </span><a href="https://en.wikipedia.org/wiki/Critical_path_method"><span class="s1">Critical Path</span></a><span class="s1"> (1957) did also exist. That means an important idea, </span><em><span class="s2">parallelization of independent tasks</span></em><span class="s1">, did exist. However, Waterfall is strictly linear and sequential, so waterfall projects do not take advantage of this.</span></p>
<p class="p4"><span class="s1">We will delve into that in more depth, but we are not done with Dr. Royce’s paper yet. The waterfall approach described by Dr. Royce, and now advocated as a method, looked like this:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioaupYpZSvMdm0A1rbbszV4o11yRUqEl1hNyZcQA3tMzLm_J92JPvstelPXAdE0U9EFwu61WUYeSeSkcrfcJRIFYHGus6Z5MOf9OvWmsiqTa3NShX8vcCj-oULQZK-_YNI-paKk-kv3Ar_H975KugLheHflbuuSR5lztv21Yu2D1G1u_76SJjHRQ/s1282/Screenshot-2023-09-21-171534.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="862" data-original-width="1282" height="430" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioaupYpZSvMdm0A1rbbszV4o11yRUqEl1hNyZcQA3tMzLm_J92JPvstelPXAdE0U9EFwu61WUYeSeSkcrfcJRIFYHGus6Z5MOf9OvWmsiqTa3NShX8vcCj-oULQZK-_YNI-paKk-kv3Ar_H975KugLheHflbuuSR5lztv21Yu2D1G1u_76SJjHRQ/w640-h430/Screenshot-2023-09-21-171534.png" width="640" /></a></div>
<p class="p5"><em><span class="s2">Figure 2: The picture above shows what Dr. Royce </span></em><em><span class="s2">warned about</span></em><em><span class="s2">! It is a fundamentally unsound way of developing software that leads to increased lead times, increased risk, and vastly increased cost, even under the best possible conditions. The resulting increased stress makes Waterfall projects horrible working environments.</span></em></p>
<p class="p4"><span class="s1">Dr. Royce’s picture of Waterfall projects is on page two in his paper. In the following pages, he presents a succession of more and more sophisticated project models, all involving feedback loops and multiple iterations.</span></p>
<p class="p4"><span class="s1">I will not show you all the intermediate versions. Do read Dr. Royce’s paper if you want the nitty-gritty details. I will show Dr. Royce’s final illustration:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTMGDH93gzu8j4uc4-nAwiE9RzUQnz9p5v_bQcuezoCxz_IKR-doIJYI_HeKZrnTHAWzKjRldXZlyJp_ggyJLvg6mua5pmOJmVQDJjeiXKe4wymeSAlaIWYRwQjaTR4f50wyaJ6Oz0ctGkDuaM3O39IKE8F3TvvX0XkYK9AO6k7xPopWJ6tkKq1Q/s2817/Royce-Figure-10.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="2114" data-original-width="2817" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTMGDH93gzu8j4uc4-nAwiE9RzUQnz9p5v_bQcuezoCxz_IKR-doIJYI_HeKZrnTHAWzKjRldXZlyJp_ggyJLvg6mua5pmOJmVQDJjeiXKe4wymeSAlaIWYRwQjaTR4f50wyaJ6Oz0ctGkDuaM3O39IKE8F3TvvX0XkYK9AO6k7xPopWJ6tkKq1Q/w640-h480/Royce-Figure-10.png" width="640" /></a></div>
<p class="p5"><em><span class="s2">Figure 3: Dr. Royce’s project model. This model has prototyping, and iterative development. It is not anywhere close to Waterfall development!</span></em></p>
<p class="p4"><span class="s1">In Dr. Royce’s model, development starts with a preliminary design phase. The purpose of this is to determine constraints, like storage capacity, timing, and other operational constraints. Then, a preliminary version, a prototype, is built.</span></p>
<p class="p4"><span class="s1">Prototyping is not done in Waterfall projects. On the other hand, it is done in some agile methods. For example </span><a href="https://en.wikipedia.org/wiki/Dynamic_systems_development_method"><span class="s1">Dynamic Systems Development Method</span></a><span class="s1"> (DSDM), one of the original agile methods, uses rapid prototyping. </span><a href="https://mdevelopers.com/blog/what-is-lean-software-development"><span class="s1">Lean Software Development</span></a><span class="s1"> and the </span><a href="https://www.researchgate.net/publication/234820806_Crystal_clear_a_human-powered_methodology_for_small_teams"><span class="s1">Crystal</span></a><span class="s1"> family of methods also advocate prototyping. Extreme Programming has a practice called </span><a href="https://en.wikipedia.org/wiki/Spike_(software_development)"><span class="s1">Spike</span></a><span class="s1">, which sometimes, but not always, entails building prototypes. Even SAFe advocates prototyping, as part of Design Thinking. (In practice, I have never seen a SAFe project that actually uses Design Thinking and prototyping, but it is there in the </span><a href="https://scaledagileframework.com/design-thinking/"><span class="s1">method description</span></a><span class="s1">.)</span></p>
<p class="p4"><span class="s1">Dr. Royce was also big on involving the customer:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p3"><span class="s1">For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.</span></p><p class="p3"><span class="s1">— </span><a href="https://dl.acm.org/doi/10.5555/41765.41801"><span class="s1">Managing the Development of Large Software Systems</span></a><span class="s1">, Dr. Winston Royce, 1970</span></p></blockquote>
<p class="p4"><span class="s1">The above quote is definitely not Waterfall, where all requirements are gathered up front. It does, however, fit with agile ideas of continuously involving customers.</span></p>
<p class="p4"><span class="s1">Dr. Royce’s software development model is not agile, but it is much closer to agile than any Waterfall project will ever be.</span></p>
<h2 class="scr2"><strong><span class="s4">The Great Misunderstanding</span></strong></h2>
<p class="p4"><span class="s1">Why on Earth do so many people believe Waterfall is a good model for developing software? I do not have a good answer, at least not one that is polite. However, the misunderstanding goes pretty far back.</span></p>
<p class="p4"><span class="s1">Royce never used the word “waterfall” in his paper. One of the first uses, perhaps the very first (though this is uncertain) use of the word in a software development context, is from a 1976 paper on software requirements by T.E. Bell and T.A. Thayer:</span></p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p3"><span class="s1">The same top-down approach to a series of requirements statements is explained, without the specialized military jargon, in an excellent paper by Royce [5]; he introduced the concept of the "waterfall" of development activities. In this approach software is developed in the disciplined sequence of activities shown in Figure 1.</span></p><p class="p3"><span class="s1">— </span><a href="https://static.aminer.org/pdf/PDF/000/361/405/software_requirements_are_they_really_a_problem.pdf"><span class="s1">Software Requirements: Are They Really a Problem?</span></a><span class="s1">, T. E. Bell and T. A. Thayer, TRW Defense and Space Systems Group Redondo Beach, California, 1976</span></p></blockquote>
<p class="p4"><span class="s1">Note the reference to Figure 1 in the quote. Let’s look at Figure 1 from the paper:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhC0TpEaPCl3IzGm0vvRkNEMrZVi8wcWC6b6LISvl_14XBavQS9fSJe8pgDHHedCLi1kAV0AG5WqPz7MHxzHpY0pA5u3UjxatbXgByBUiqyXk_Mq-A5ehc8S8R5yJ2ahhx6vKj3vnl81fpoR7N3r7fGwyhgvrKZvAJMDuY50r9rfQFbbf-QoXdRYw/s2053/Bell-and-Thayer-Fig-01.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1704" data-original-width="2053" height="532" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhC0TpEaPCl3IzGm0vvRkNEMrZVi8wcWC6b6LISvl_14XBavQS9fSJe8pgDHHedCLi1kAV0AG5WqPz7MHxzHpY0pA5u3UjxatbXgByBUiqyXk_Mq-A5ehc8S8R5yJ2ahhx6vKj3vnl81fpoR7N3r7fGwyhgvrKZvAJMDuY50r9rfQFbbf-QoXdRYw/w640-h532/Bell-and-Thayer-Fig-01.png" width="640" /></a></div>
<p class="p5"><em><span class="s2">Figure 4: This is the figure in Bell and Thayer’s paper, that purportedly shows the project model Royce advocated. It does not! This is the model Royce warned about!</span></em></p>
<p class="p4"><em><span class="s2">It’s the wrong diagram!</span></em><span class="s1"> Bell and Thayer copied the wrong diagram from Royce’s paper, and then claimed that this was the idea Royce advocated. As far as I can tell from the paper by Bell and Thayer, they did not even bother to read Royce’s paper. They just looked at the diagram on page two in Royce’s paper and went “Yep, that’s the way to do it!”</span></p>
<p class="p4"><span class="s1">We now know that “Waterfall Method” is all a big misunderstanding, but why did something as bonkers as this spread? Enter the US military!</span></p>
<p class="p4"><span class="s1">In 1988 the US Department of Defense released a standard for working with software contractors, </span><a href="http://everyspec.com/DoD/DoD-STD/DOD-STD-2167A_8470/"><span class="s1">DOD-STD-2167A</span></a><span class="s1">. This standard may not have been the best move, at least not for US tax payers.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWT8TTFz-KYbfEj0Hf42n27ttjR-mHM_RWHkW2rW9DLomOb_zhLYgoFt8kT4V_V7cePZ-dgviXOwzyDcVOmFRKETF9L-xMwydT-LtLakcMPzIgvRtoNdXLRufKY3FY4PPIdTLgtJu1i80vfNjI75SIaqV1EEaFRJCtPRfxrP1ptMd1hZI1XWDKoQ/s2197/DOD-STD-2167A-Fig-01.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1124" data-original-width="2197" height="328" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWT8TTFz-KYbfEj0Hf42n27ttjR-mHM_RWHkW2rW9DLomOb_zhLYgoFt8kT4V_V7cePZ-dgviXOwzyDcVOmFRKETF9L-xMwydT-LtLakcMPzIgvRtoNdXLRufKY3FY4PPIdTLgtJu1i80vfNjI75SIaqV1EEaFRJCtPRfxrP1ptMd1hZI1XWDKoQ/w640-h328/DOD-STD-2167A-Fig-01.png" width="640" /></a></div>
<p class="p5"><em><span class="s2">Figure 5: The figure above is from the DOD-STS-2167A document. It shows the basic processes for developing both hardware and software, and it is a Waterfall process.</span></em></p><p class="p5"><span class="s2">To be fair, the US DoD did not explicitly forbid more sane approaches:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijSuP-DS_0cPnDnvGY4opPYfDV97AdhxYnytfGX2j5GVMSJO7TI9g2z1jYhq45qWFdKvhtDEapfSmsAg7uTKS0c4m1dL66xxBM05UCnwTAGyosMhnc6NvVlhVz6nePOaVMyZKHVP-tdbvxVjTZPszDdUvz9IdpXFQaIKW3EgMuGED_D0tZ1aO_EA/s1411/DOD-STD-2167A-Quote-01.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="493" data-original-width="1411" height="224" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijSuP-DS_0cPnDnvGY4opPYfDV97AdhxYnytfGX2j5GVMSJO7TI9g2z1jYhq45qWFdKvhtDEapfSmsAg7uTKS0c4m1dL66xxBM05UCnwTAGyosMhnc6NvVlhVz6nePOaVMyZKHVP-tdbvxVjTZPszDdUvz9IdpXFQaIKW3EgMuGED_D0tZ1aO_EA/w640-h224/DOD-STD-2167A-Quote-01.png" width="640" /></a></div>
<p class="p4"><em><span class="s2">Figure 6: As the excerpt shows, the standard allowed iterative and recursive approaches to software development. It did not mandate them though.</span></em></p>
<p class="p4"><span class="s1">It is worth noting that while DOD-STS-2167A does allow iterative and recursive processes, the mandatory formal reviews and audits makes practical implementation more or less impossible. The rules push development processes to be sequential.</span></p><p class="p4"><span class="s1">Also, from the perspective of a contractor, if you can choose between an approach that require much less training, and which allows you to make a lot of money due to delays and cost overruns, and an approach that will require you to spend money on extra training for your people, and will simultaneously reduce project lead time and cost, so you will make much less money, which approach would you choose?</span></p>
<p class="p4"><span class="s1">It’s no surprise that the contractors went with getting the most money.</span></p>
<p class="p4"><a href="https://en.wikipedia.org/wiki/DOD-STD-2167A#Criticism"><span class="s1">DOD-STS-2167A was criticized</span></a><span class="s1">, of course, but that didn’t help much. For a period of time, Waterfall was the way to do things. Eventually, in the 90’s, agile methods emerged as a response to Waterfall, and various Waterfall-inspired approaches. (No, agile did not begin with the Agile Manifesto. The methods existed before that. Take a look at </span><a href="https://agilemanifesto.org/authors.html"><span class="s1">the original authors of the manifesto</span></a><span class="s1">, and the methods they represented.)</span></p>
<h1 class="scr1"><strong><span class="s3">Waterfall vs. Critical Path</span></strong></h1>
<p class="p4"><span class="s1">So far, we have established that Dr. Winston Royce, unfairly credited with advocating Waterfall, actually advocated replacing Waterfall with an early form of iterative development. We have also established that the whole crackpot idea of Waterfall being a good approach for software development can be traced back to a monumental misunderstanding of the idea in a 1976 whitepaper, and a 1988 military standard of ill repute.</span></p>
<p class="p4"><span class="s1">Let’s look closer at </span><em><span class="s2">why</span></em><span class="s1"> Waterfall is a bad idea. First of all, Waterfall projects have strictly sequential phases! One type of activity does not start until the previous type of activity ends. This is bad because it becomes difficult, and expensive, to fix mistakes in a phase, if the mistake is discovered in a later phase.</span></p>
<p class="p4"><span class="s1">The reason it is so expensive, is that fixing that mistake made in an earlier phase, often triggers a cascade of massive changes. For example, if a mistake in requirements analysis is discovered while testing, this may trigger a redesign of the whole software.</span></p>
<p class="p4"><span class="s1">The Waterfall advocates counter argument is that we will use Waterfall only in projects where the requirements are well understood up front. Unfortunately, that argument does not hold up.</span></p>
<p class="p4"><span class="s1">Let’s assume for the sake of argument, that we have a project where all requirements can be gathered up front. Furthermore, we will assume that all the work, in all the phases, is executed perfectly, with no mistakes. Waterfall still looses big!</span></p>
<p class="p4"><span class="s1">Let’s look at a sample Waterfall project from </span><a href="https://www.wrike.com/project-management-guide/faq/what-is-waterfall-project-management/"><span class="s1">an article advocating Waterfall</span></a><span class="s1">, and then rework it using only a project planning method from the 1960’s, <span class="Scrivener-converted-space"> </span>Critical Path.</span></p>
<p class="p4"><span class="s1">First, let’s look at the Waterfall plan from the article. I won’t steal their picture of the plan. Instead, I’ve made a simplified sketch. I did add names to each role though, so I can refer to Anna, rather than “the wireframe builder”, and Eve, rather than using the very unappealing term “content creator”.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhdSIzS_4_NGLTDb2gloroCINVcSHVnVMCuQFniAlSw5zS88AcGpnddeGsGO1ogfSCAK1bopjGMKbjEI0cOZYmgkOCwaP7kE84Kz7_VklJS4pFU-3fNfiuIsAItITTWyE3RCfomw3XKbzczLFUqbOfCifKQRhIjXR3-Ewc5Omm3rc7kSyi90N0zyg/s2233/Planning-Waterfall.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="796" data-original-width="2233" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhdSIzS_4_NGLTDb2gloroCINVcSHVnVMCuQFniAlSw5zS88AcGpnddeGsGO1ogfSCAK1bopjGMKbjEI0cOZYmgkOCwaP7kE84Kz7_VklJS4pFU-3fNfiuIsAItITTWyE3RCfomw3XKbzczLFUqbOfCifKQRhIjXR3-Ewc5Omm3rc7kSyi90N0zyg/w640-h228/Planning-Waterfall.png" width="640" /></a></div>
<p class="p5"><em><span class="s2">Figure 7: Waterfall project plan from the article </span></em><em><a title="https://www.wrike.com/project-management-guide/faq/what-is-waterfall-project-management/"></a><a href="https://www.wrike.com/project-management-guide/faq/what-is-waterfall-project-management/"><span class="s2">What Is Waterfall Project Management?</span></a></em><em><span class="s2"> </span></em><em><span class="s2"> </span></em></p>
<p class="p4"><span class="s1">The first thing to note is that there are some oddities in the original Waterfall plan in the article. For example, team members are expected to work two out of the three weekends. (Weekend days are grayed out.) For another, testing is supposed to be finished on day 19, but nothing is uploaded to the website until day 24.</span></p>
<p class="p4"><span class="s1">I do not know if the above oddities are intentional, or planning mistakes. Let’s fix this by keeping the estimated times for the activities, but giving everyone weekends off. We will also cut a few days from the schedule by uploading immediately when testing has finished, instead of five days later:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEitOxZAG7D2Kqbvshw9XjaghukjCdMnCBxmmr7V67j8y7SGGgswV6ECDWfVp5-OsVsrPNxDTt8H-czris5d4T4oRst15j3rfo5NuVtthyfbE0M5s8T4GooyNrBuJ7QgKJbWA3uJCCHzSIsx3jLjRwUdOQLySObWY3cBzrX-opVY-095UD2oHt3KCQ/s2233/Planning-Waterfall-02.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="796" data-original-width="2233" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEitOxZAG7D2Kqbvshw9XjaghukjCdMnCBxmmr7V67j8y7SGGgswV6ECDWfVp5-OsVsrPNxDTt8H-czris5d4T4oRst15j3rfo5NuVtthyfbE0M5s8T4GooyNrBuJ7QgKJbWA3uJCCHzSIsx3jLjRwUdOQLySObWY3cBzrX-opVY-095UD2oHt3KCQ/w640-h228/Planning-Waterfall-02.png" width="640" /></a></div>
<p class="p5"><em><span class="s2">Figure 8: Corrected Waterfall project plan, where team members get the weekends off.</span></em></p>
<p class="p4"><span class="s1">So, now we have a Waterfall plan that does not force team members to work weekends. We have also cut some unnecessary lag time. The net effect is that the project will take 24 calendar days, just as before. We will upload a few hours later on the 24th day though.</span></p>
<p class="p4"><span class="s1">One drawback of the Waterfall approach is IOTTMCO (Immediately Obvious To The Most Casual Observer): Because no activity is allowed to begin until the previous activity has finished, the project takes longer than it has to.</span></p>
<p class="p4"><span class="s1">For example, Eve, the content creator, is not really dependent on Anna, the wireframe builder (well, designer) to finish building the wireframe version of the pages in order to begin. Actually, Eve probably has ideas that would enable Anna to improve her design, if she got the input. That means Eve and Anna should work together, in parallel, preferably sitting next to each other in the same room.</span></p>
<p class="p4"><span class="s1">What about Thor? Is he from Asgard? Yes, but he is also a kick ass web developer. What does he need to get started? He needs an overall idea of the web page design, and the structure of the web site. He most certainly does </span><em><span class="s2">not</span></em><span class="s1"> need a complete set of wireframe models from Anna to get started. Let’s bring Thor in early, so he can join the initial design meeting with Anna and Eve.</span></p>
<p class="p4"><span class="s1">What about Jane, the tester? She could start testing as soon as Thor has one web page up and running. It does not even have to be a complete page. She can test functionality as soon as Thor has built it. A tester does more than just checking functionality though. A tester also checks the structure of the web site, to see if the pages are easy to navigate, and that the flow is logical. That means Jane can have useful input even at the wireframe stage. So, bring her in early too. Jane can’t finish testing until Thor is done building it, so we will keep her on the job as long as Thor, plus one extra day.</span></p>
<p class="p4"><span class="s1">Let’s see what the schedule looks like now:</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTIO_rKGcRE2OfICfFmmn5ZKJp-5HVUuIvsWPD00qKgTjUgwv-i59VCUeoGbW5WaXjSEsJ3vJLZfZHiC4nY0wupaueXXKDRaSiJtGNy_L4WYUm9iiFGnPy8xngQ9QX9_Fb5iyIVgYur0SQVPPLkR83QM_bZQD6ppi4bCe-SCgL-A-RW9ne9Jfr4Q/s2233/Planning-Critical-Path-01.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="796" data-original-width="2233" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTIO_rKGcRE2OfICfFmmn5ZKJp-5HVUuIvsWPD00qKgTjUgwv-i59VCUeoGbW5WaXjSEsJ3vJLZfZHiC4nY0wupaueXXKDRaSiJtGNy_L4WYUm9iiFGnPy8xngQ9QX9_Fb5iyIVgYur0SQVPPLkR83QM_bZQD6ppi4bCe-SCgL-A-RW9ne9Jfr4Q/w640-h228/Planning-Critical-Path-01.png" width="640" /></a></div>
<p class="p5"><em><span class="s2">Figure 9: Critical Path Method plan with parallelization of activities. The Critical Path is the longest sequence of dependent activities, in this case 15 days.</span></em></p>
<p class="p4"><span class="s1">Look at that! We now have a 15 day project instead of a 24 day project. We reduced the project lead time with 9 days. </span><em><span class="s2">That is a 37.5% (9/24=0.375=37.5%) reduction in lead time</span></em><span class="s1">!</span></p>
<p class="p4"><span class="s1">To put it another way, if we use Critical Path as the base planning method, and switch to Waterfall, </span><em><span class="s2">Waterfall planning delayed the project by 60%</span></em><span class="s1"> (9/15=0.6=60%).</span></p>
<p class="p4"><span class="s1">Note that we did nothing Agile here. We have compared Waterfall planning with the Critical Path Method (CPM), a method that has been around since the late 1950’s. The Critical Path is the longest stretch of dependent activities, in this case, Jane’s activities. (I have omitted dependencies to each team member’s individual work packages, to keep things simple.)</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1lit67U4UOqZu-smMykoWQpeJR2cM8rhklMMohvbL6mIOxZgQZ6YLSuUJ2-mzM7ng1HI9flf6muzUv9rFCYa5YgCj-7UXqBCinM55SrOrjXF7zYaXbSPjC8Rbgb0X2DZo89parLuuZztoHLHyJ_yMB_RI0bSBmyFKKx0gpC-vTyH7oXS0iVbsQQ/s2233/Planning-Critical-Path-02.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="796" data-original-width="2233" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1lit67U4UOqZu-smMykoWQpeJR2cM8rhklMMohvbL6mIOxZgQZ6YLSuUJ2-mzM7ng1HI9flf6muzUv9rFCYa5YgCj-7UXqBCinM55SrOrjXF7zYaXbSPjC8Rbgb0X2DZo89parLuuZztoHLHyJ_yMB_RI0bSBmyFKKx0gpC-vTyH7oXS0iVbsQQ/w640-h228/Planning-Critical-Path-02.png" width="640" /></a></div>
<p class="p5"><em><span class="s2">Figure 10: The difference between Critical Path and Waterfall planning leads to increased project costs, lost revenue, reduced market share (and more revenue loss), and shortened lifecycle (and even more revenue loss).</span></em></p>
<p class="p4"><span class="s1">So, compared to Critical Path planning, the Waterfall approach increased delivery time by 60%, or 9 days. That means, the website cannot generate revenue for those 9 days. That may not sound like a lot, but for a large project, a 60% delay can be the difference between a successfully launched project and a market flop.</span></p>
<p class="p4"><span class="s1">A delayed project means increased project cost, and loss of revenue due to the delayed launch. Quite often, a delayed launch means reduced market share, and a shorter lifecycle for the product. Add all that up, and it is a lot of money.</span></p>
<p class="p4"><span class="s1">In a real, large, project, we can use </span><em><span class="s2">Profit & Loss statements</span></em><span class="s1"> to forecast the </span><em><span class="s2">Cost of Delay</span></em><span class="s1"> we get by using Waterfall instead of Critical Path. Delving into that would require an article of its own though, so I won't.</span></p>
<p class="p4"><span class="s1">I should mention, while we are on the topic, that the Critical Path algorithm is quite a bit more complicated than I’ve shown here. I’ve simplified things to avoid getting lost in unimportant details. For a large project, there are alternatives to Critical Path, i.e. Critical Chain, that may give more optimal results.</span></p>
<h1 class="scr1"><strong><span class="s3">Waterfall vs. Agile</span></strong></h1>
<p class="p4"><span class="s1">Now that we have used Critical Path, a planning method from the late 1950’s to soundly trounce Waterfall, can we trounce Waterfall even more?</span></p>
<p class="p4"><span class="s1">It turns out that </span><em><span class="s2">sometimes</span></em><span class="s1"> we can, but not necessarily always. Enter agile methods!</span></p>
<p class="p4"><span class="s1">Assuming that we have a well run Critical Path project, agile methods will not enable us to reduce total project lead time, but it may enable us to deliver value sooner, which adds up to substantially increased total value.</span></p>
<p class="p4"><span class="s1">A, usually unexamined, assumption in both Waterfall and the Critical Path Method, is that we do a single delivery at the end of the project. What if we can split the delivery up, so <span class="Scrivener-converted-space"> </span>we can do multiple smaller deliveries?</span></p>
<p class="p4"><span class="s1">In our web site example, what if we could deliver a minimal set of web pages the first week, after only three days of work? We could then, perhaps, make a second delivery at the end of the second week, and a third and final delivery at the end of the project. Let’s try it!</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjV6t2A-Dmn5G-a4bCRaTSwEyjs98sV4VqGVTV0RM2uxEoKWtdKTS3Ojl-lA2uJf1yzC1XjdQ30d8rS-wO8kjNXHjzZugyHMH45RHCmHdYtE1jjkE4NqeMJJtFsRyqaVQ2j7o84FIsZ5vNTyK_Mu9IIFPrdh-OJQjDz85qhadDjCesm0h0Tw-gMvQ/s2233/Planning-Agile-01.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="796" data-original-width="2233" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjV6t2A-Dmn5G-a4bCRaTSwEyjs98sV4VqGVTV0RM2uxEoKWtdKTS3Ojl-lA2uJf1yzC1XjdQ30d8rS-wO8kjNXHjzZugyHMH45RHCmHdYtE1jjkE4NqeMJJtFsRyqaVQ2j7o84FIsZ5vNTyK_Mu9IIFPrdh-OJQjDz85qhadDjCesm0h0Tw-gMvQ/w640-h228/Planning-Agile-01.png" width="640" /></a></div>
<p class="p5"><em><span class="s2">Figure 11: With agile methods, we do small, frequent deliveries, which enables us to get revenue from working software much earlier than with Critical Path or Waterfall planning. However, this does not work in all kinds of projects.</span></em></p>
<p class="p4"><span class="s1">In this scenario we make a first, very minimal, delivery after 3 days, a second delivery after 10 days, and the third and final delivery after 15 days. That means we can start generating revenue after 3 days, We make revenue for 12 days more than with Critical Path, and for 21 days more than with Waterfall.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirFf8htAoNFQCsA8hv8GWB8BwNoD_WlEnQ3Gk1p_x6W5iLBvuDXy1fOJ9f1x9UcG6kB3nDp8z290M9jWKxpmStti83WWKRZblLfJzCzuiVt_JRv4ORrZxWJP5HHtKI-nOldxplQ2hkRpXcrxiH6vI1Z3uVsoQbzyKQ3PPLPwirSk6nw3zVBt4yjA/s2233/Economic-Comparison.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="796" data-original-width="2233" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirFf8htAoNFQCsA8hv8GWB8BwNoD_WlEnQ3Gk1p_x6W5iLBvuDXy1fOJ9f1x9UcG6kB3nDp8z290M9jWKxpmStti83WWKRZblLfJzCzuiVt_JRv4ORrZxWJP5HHtKI-nOldxplQ2hkRpXcrxiH6vI1Z3uVsoQbzyKQ3PPLPwirSk6nw3zVBt4yjA/w640-h228/Economic-Comparison.png" width="640" /></a></div><p class="p2"><i>Figure 12: As we can see in the picture above, CPM is more profitable than Waterfall. Agile is more profitable than CPM, if we can make multiple deliveries. Even if we cannot make multiple deliveries, Agile would still beat Waterfall hands down.</i></p>
<p class="p4">From an economic perspective, agile methods win hands down <i>if </i>it is possible to slice the project into multiple deliveries. If that is not possible, agile and Critical Path look pretty even. In practice, Critical Path planning, and similar methods, do have some advantages over agile planning when it comes to reducing lead time in large projects. (The exception is the Crystal family of methods, which handles work package breakdown and parallelization better than other agile methods. Maybe on par with Critical Path.)</p><p class="p4">Neither agile, nor Critical Path, ever comes close to being as bad as Waterfall, under any circumstances.</p>
<p class="p4"><span class="s1">Reviving Waterfall is a giant leap more than fifty years back in time. Waterfall leads to delays, and cost overruns, it reduces the quality of software, and makes developers incredibly stressed.</span></p>
<p class="p4"><span class="s1">I for one, do not want the bad old times back! </span></p><p class="p4"><span class="s1">We should look forward instead. Build on the knowledge of software development and software project management we have gathered over the past half century. Learn from both failures and successes, and develop better ways of working.</span></p>
<p class="p6"><br /></p>
Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-55541098492037024742023-08-31T14:59:00.001+02:002023-08-31T14:59:41.250+02:00Are You Still Using the Wrong Control Levers in your Agile projects? Part Four: Levers that Work!
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEip3XYXYcqzoajonHpx7VspCkcp8Spw0bKBhpFcE9sSojT31W4USMGGdjthmjjzav0bRmpGHDJItkefx5EuZrfbqNrAgMNShp9QHIYtaKVWBSp3y7f4gMwZcBpHBqvzhD4eFOFP05w-KF76nGEHlaNxbVTnT6FF9kmVXMLfZPTTgPTZIZQdJ1KdUg/s2482/Goal%20Map%2001.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2482" height="450" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEip3XYXYcqzoajonHpx7VspCkcp8Spw0bKBhpFcE9sSojT31W4USMGGdjthmjjzav0bRmpGHDJItkefx5EuZrfbqNrAgMNShp9QHIYtaKVWBSp3y7f4gMwZcBpHBqvzhD4eFOFP05w-KF76nGEHlaNxbVTnT6FF9kmVXMLfZPTTgPTZIZQdJ1KdUg/w640-h450/Goal%20Map%2001.jpg" width="640" /></a></div>
<p class="p4"><em><span class="s3">Simplified Goal Map showing three top level project/program goals, linked to a business goal. </span></em></p>
<p class="p5"><span class="s4">Welcome to Part Four in the (as originally planned) three part series on high level controls for large software development projects.</span></p>
<p class="p5"><span class="s4">First, a brief recapitulation of the first three parts of this series:</span></p>
<p class="p5"><span class="s4">In </span><a href="https://kallokain.blogspot.com/2023/01/are-you-still-using-wrong-control.html"><span class="s4">the first part</span></a><span class="s4"> I wrote about how using Cost and Capacity to control an agile software project can trap an organization in a hire and fire cycle that increases project duration and cost.</span></p>
<p class="p5"><span class="s4">In </span><a href="http://kallokain.blogspot.com/2023/01/are-you-still-using-wrong-control_14.html"><span class="s4">the second part</span></a><span class="s4">, I wrote about how to optimize a project for delivering maximum </span><em><span class="s3">business value</span></em><span class="s4">. I also wrote about a common mistake companies do, which will disable the Business Value lever, so it no longer works as intended.</span></p>
<p class="p5"><span class="s4">In </span><a href="http://kallokain.blogspot.com/2023/08/are-you-still-using-wrong-control.html"><span class="s4">the third part</span></a><span class="s4">, I described a very common set of levers called The Iron Triangle. <span class="Scrivener-converted-space"> </span>I also described a set of four levers used in the original version of Extreme Programming. I showed that both of these models have their pros and cons. Both can be useful, but neither is very close to the Holy Grail of high level project control levers.</span></p>
<p class="p5"><span class="s4">In the </span><a href="http://kallokain.blogspot.com/2023/08/interlude-cost-of-agile.html"><span class="s4">interlude</span></a><span class="s4">, I went off-track a bit, discussing agile project economics, and the frequent lack thereof.</span></p>
<p class="p5"><span class="s4">In this, the fourth and final part, we will put together a simple system that provides a solid basis for managing a large project at a high level. It is not very comprehensive, and by no means complete, but it provides a good starting point. That, in itself, is better than what I have seen in most large projects.</span></p>
<h1 class="scr1"><strong><span class="s5">Agile or Not?</span></strong></h1>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhu012CYvayC5Rq1V2ZvK7M7e6Jl4EZUmmIWpQXIVrwyz9-gsgpdogSECtXuDEuX3CHbxCZDVFlGVAsN1zMH0-PuQYoTJQ2bQHKs9-0dfZBVH-Cbqd-rzmoDTCe4yPxrx6F5XVSWmQknjDBbXtfvogIPlkt5fzcf9bprshY00kVtE1Wu5v-wv2IXQ/s2481/Waterfall%20vs.%20Agile.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1114" data-original-width="2481" height="288" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhu012CYvayC5Rq1V2ZvK7M7e6Jl4EZUmmIWpQXIVrwyz9-gsgpdogSECtXuDEuX3CHbxCZDVFlGVAsN1zMH0-PuQYoTJQ2bQHKs9-0dfZBVH-Cbqd-rzmoDTCe4yPxrx6F5XVSWmQknjDBbXtfvogIPlkt5fzcf9bprshY00kVtE1Wu5v-wv2IXQ/w640-h288/Waterfall%20vs.%20Agile.jpg" width="640" /></a></div>
<p class="p4"><em><span class="s3">Before starting an agile project, make sure that you really can use the many small deliveries (A+B) economic model. If you cannot, then agile may reduce value, because agile projects do not optimize for the Critical Path. The figure is from</span></em><em><span class="s3"> </span></em><em><a href="http://kallokain.blogspot.com/2023/01/are-you-still-using-wrong-control_14.html"><span class="s3">Part 2</span></a></em><em><span class="s3">.</span></em></p>
<p class="p5"><span class="s4">Before we start picking the best control levers for our agile project, it’s a good idea to figure out whether we really have an agile project or not. If we don’t, agile methods may not be the best way to manage the project. At the very least, we need to adapt the steering mechanism to the kind of project we do have.</span></p>
<p class="p5"><span class="s4">At worst, if upper management believes the project is of one type, but it really is of another type, the smartest thing to do may be to give the project a pass (if you are lucky enough to be able to do that).</span></p>
<p class="p5"><span class="s4">From a very high level perspective, what is it that makes a project agile? Let’s have a look at the most important factors:</span></p>
<ul class="ul1" style="text-align: left;">
<li>The project can be set up to have many, small deliveries of working software <em><span class="s6">to the end user</span></em>.
<ul class="ul1">
<li>This is a prerequisite for the agile economic model to work as intended. See the section <em><span class="s6">How to Deliver Business Value the Agile Way</span></em> in <a href="http://kallokain.blogspot.com/2023/01/are-you-still-using-wrong-control_14.html">Part 2</a>.</li>
</ul></li>
<li>Requirements are likely to change a lot during the course of the project. The project can be set up to handle these quickly changing requirements:
<ul class="ul1">
<li>Requirements can be written so they describe small <em><span class="s6">vertical slices</span></em> of functionality. See section <em><span class="s6">The Decline and Fall of the User Story</span></em> in <a href="http://kallokain.blogspot.com/2023/01/are-you-still-using-wrong-control_14.html">Part 2</a>.</li>
<li>Developers have the skills and training necessary to do rapid change and redesign.
<ul class="ul1">
<li>The codebase must be <em><span class="s6">continuously and aggressively refactored</span></em> in order to keep the code loosely coupled. (If you want more information about why refactoring is essential, read my rant <a href="http://kallokain.blogspot.com/2023/08/interlude-cost-of-agile.html">Interlude: The Cost of Agile</a>.)
<ul class="ul1">
<li>Developers need high levels of skill in <em><span class="s6">Refactoring</span></em> and <em><span class="s6">Refactoring Patterns</span></em>.</li>
<li>Developers need software design skills, such as <em><span class="s6">Domain-Driven Design</span></em>, or equivalent.</li>
</ul></li>
<li>To enable refactoring, testing <em><span class="s6">must</span></em> be automated.
<ul class="ul1">
<li>Developers need skills such as <em><span class="s6">Test-Driven Design</span></em> (TDD), <em><span class="s6">Behavior-Driven Design</span></em> (BDD), or equivalent.</li>
</ul></li>
<ul class="ul1">
<li>Development teams are decoupled, with as few dependencies between them as possible. This allows teams to work as fast as possible, without waiting for other teams. It also prevents unfinished work to build up in queues between teams. This implies the teams mainly (but usually not exclusively) are organized around value streams, rather than functional areas. Note that value streams, by definition, can exist only if the project really is set up to make small deliveries of value to the end user. </li>
</ul>
</ul></li></ul></li></ul>
<p style="text-align: left;">If the project fits the criteria above, there is a reasonable chance it can be run as an agile project. If it does not fit these basic criteria, the agile economic model will not work as intended. You may easily end up increasing costs by using agile, instead of reducing them.</p><p style="text-align: left;"><br />On the other hand, you can, in most cases, still get a lot of value out of agile practices and techniques, but you need to combine them with techniques that do not exist in the agile domain, such as Critical Path or Critical Chain. (Please do not interpret that as “mix with waterfall project management”. Never, under any circumstances, do waterfall projects! I’ll save the details about why that is a monumentally bad idea for another article.)</p><p style="text-align: left;"><br />Ok, now that we have assured ourselves we have at least the most basic requirements for running an agile project covered, let’s pick some high level control levers.<br /></p>
<h1 style="text-align: left;">First Pick: Business Value</h1>
<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhipa-DZwRDFbvOMSmou3OtH6oAh8WFNLrFmJctoE6rfZSuE98QyxbhJmjLOPCX2PxbPrHT90XvBj3ix8woUPpH2uHuf5t6tzQmQi3Q71Eae5Thh1UJmsvhdapcPd4biwfbNbDC-D2gJIux9vPhbm7VULScwW2-oWV9qTRnqduXA6FISUwpe05RFA/s2482/Business%20Value.jpg" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="1749" data-original-width="2482" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhipa-DZwRDFbvOMSmou3OtH6oAh8WFNLrFmJctoE6rfZSuE98QyxbhJmjLOPCX2PxbPrHT90XvBj3ix8woUPpH2uHuf5t6tzQmQi3Q71Eae5Thh1UJmsvhdapcPd4biwfbNbDC-D2gJIux9vPhbm7VULScwW2-oWV9qTRnqduXA6FISUwpe05RFA/s400/Business%20Value.jpg" width="400" /></a></div>
<br /><span class="s4">My first pick is </span><em><span class="s3">delivered business value</span></em><span class="s4">! Business value cannot be measured using a single metric, but you can use a combination of metrics. Here are a few suggestions. A good economist or accountant may be able to come up with better ones:</span><br /><ul class="ul1" style="text-align: left;"><li><em>Revenue</em><span class="s7">: This is revenue from the value stream created by the project. It’s the gross income, before subtracting expenses. An agile project delivers value to the end user long before the project is finished (a program doesn’t even have an end date). The end user pays for each delivery, and that creates a revenue stream. Combine that with rolling budgeting, and an agile project/program is at least partially self-funding.</span><ul class="ul1"></ul></li><li><span class="s7"><br />If the revenue stream is zero, then you should start questioning the way your agile project or program works. It is either a dysfunctional agile project, or not an agile project at all.</span></li><ul class="ul1"><li></li><li><em>Profit & Loss</em><span class="s7">: As calculated in P&L statements. This is straight out of the </span><em>Lean Software Development</em><span class="s7"> book by Mary and Tom Poppendieck. P&L statements can be used to determine the current state, and to make economic forecasts.</span></li><li><em>Customer turnover</em><span class="s7">: The customer turnover rate. This is the percentage of lost customers over a specified time period.</span></li></ul><li><em>Throughput</em><span class="s7">: Measured in goal units (User Stories, Features, Epics, or other vertically sliced requirement) per time unit (iteration, Sprint, Program Increment, or similar). Note that this is really a proxy for business value, and can be misleading under some circumstances. Interpreted correctly, it can also be very valuable. If this drops to zero, or just never rises above zero, the entire project/program is busy creating partially built software. <br /><br />Zero Throughput is not good! Sometimes it is unavoidable, but agile methodology is not designed to deal with those cases. If it happens, the thing to do is to determine whether there is a blockage in the value stream that can be removed, or whether the project methodology must be adapted to work under non-agile circumstances.</span></li><ul class="ul1"></ul></ul>The above are just a few suggestions. There is a bunch of other metrics that may be more useful depending on your situation. The key thing is, I want to know how the many small deliveries the project makes affect the business.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>I’ll give you a practical example:<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>I am currently working on a book. (Very, very slowly!) It is an art photography book, so I need to make text and illustrations work together on the page. Because of this, I am writing directly in a layout program, Affinity Publisher.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>After I began writing the book, Serif, the company that makes Publisher, released a new version of the program. The new version had support for book files. That wasn’t mission critical for me, but it did make working on the book a lot easier. I could break each chapter into a separate file, and have a book file that kept the chapters together.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>The update was free, so Serif did not get any money from me, but the probability of me staying with Affinity Publisher for future projects went up. Score one for reduced customer turnover!<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>As I write this, Serif has yet a new version of Publisher in beta test. This version has cross-reference support. Judging from the beta test reports, it is fairly good cross-reference support, not the sad dogs breath version you will find in MS Word, and all the Word clones out there. If you have used a professional document processor, like Adobe FrameMaker, you have a fairly good idea of what I mean.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>If the next release of Affinity Publisher has cross-reference support as good as is indicated in the beta test forum, then my customer loyalty will certainly go up a notch again. This upgrade is also free, but my willingness to shell out money for the version 3.0 upgrade, when that day comes, definitely increases.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>In the case of an application like Publisher, the manufacturing company can of course measure the number of downloads of the upgrades, and monitor reactions in the user forums on their website, to get an idea of the business value of the features they implement.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><h2 style="text-align: left;"><strong><span class="s8">Changing the Business Value Lever</span></strong></h2><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>There are lots of things that can, and should, be done to push the Business Value lever in the desired direction. Here are a few basic ones.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><h2 style="text-align: left;"><strong><span class="s9">Weighted Shortest Job First (WSJF)</span></strong></h2><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">We can change the Business Value lever </span><em><span class="s3">if</span></em><span class="s4"> we can figure out the relative value of different requirements. We can do that using a formula called Weighted Shortest Job First (WSJF). I’ll just outline the basic idea here. Please do read up on the relevant literature before using it. (I recommend you read </span><em><span class="s3">both</span></em><span class="s4"> the SAFe article about WSJF, </span><em><span class="s3">and</span></em><span class="s4"> Donald Reinertsen’s book </span><em><span class="s3">The Principles of Product Development Flow: Second Generation Lean Product Development</span></em><span class="s4"> before using WSJF.) The WSJF formula looks like this:</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><em><span class="s3">WSJF</span></em><span class="s4"> = </span><em><span class="s3">Cost of Delay</span></em><span class="s4"> / </span><em><span class="s3">Duration</span></em><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">The </span><em><span class="s3">Cost of Delay</span></em><span class="s4"> can be calculated a couple of ways. SAFe provides a formula, but very little information on how to use it in practice. The formula in SAFe was lifted from Dean Leffingwell’s book </span><em><span class="s3">Agile Software Requirements</span></em><span class="s4">, so you can find more specific information there. Mary and Tom Poppendieck also calculate Cost of Delay, but they use Profit & Loss statements in the book </span><em><span class="s3">Lean Software Development</span></em><span class="s4">. You may want to try both methods, and compare results. Reinertsen also shows how to calculate Cost of Delay using P&L statements in </span><em><span class="s3">The Principles of Product Development Flow</span></em><span class="s4">.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Most of the time WSJF is calculated for Features, Capabilities, or other kinds of collections of User Stories. Individual User Stories are often to small to fiddle around with when estimating business value. Doing it for a group of User Stories, that will be developed together, is usually more practical.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Next, we need to estimate how long it will take to develop a Feature, or whatever unit of Business Value we have chosen.. The traditional way to do this is to torture developers until they come up with a credible sounding lie. Personally, I prefer using statistical methods, like Monte Carlo simulation. With Monte Carlo simulation, the project management can choose how certain they want forecasts to be. The developers are not directly involved, so they can’t be blamed if a forecast is wrong. (Instead, you can blame an Excel sheet, a piece of software, or statistics.)<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Third, you add a time factor, that increases the longer the Feature has been waiting in a queue. This ensures that even low priority Features will eventually be implemented. Without the time factor, a low priority Feature can be pushed to the back of the queue over and over again, so that it is never implemented. Watch it a bit here, because a Feature can deprecate in value over time, to the point of having zero value by the time it is implemented.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">One thing that should not be overlooked, is that you can often </span><em><span class="s3">increase</span></em><span class="s4"> business value by </span><em><span class="s3">removing</span></em><span class="s4"> features! A lot of software have a lot of crap functionality that no one uses. The only thing such functionality does, is making the user interface more complicated, and devaluing the software. As I have mentioned elsewhere, I once worked with a company that, by its own estimates, lost about eighteen million dollars per year in sales due to implementing a lot of junk functionality and having a correspondingly cluttered User Interface.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>So, basically, you want to dump crappy ideas, and order the rest according to Cost of Delay divided by development time + plus a time factor adjustment.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><h2 style="text-align: left;"><strong><span class="s9">Use Alternative Scheduling Methods</span></strong></h2><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>The past few years the agile community has locked in on Weighted Shortest Job First (WSJF) as if it is the one and only planning method that is worth using. That is far from true.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">WSJF requires that you can quantify both Cost of Delay and job duration with at least some degree of accuracy. That is not always the case. For example, a couple of years ago, I worked in a project where the business people flat out refused to provide estimates about business value. Instead, they tried to get the developers to do that. In such a situation, it is probably bet to treat the value of all Features as equal, and do the </span><em><span class="s3">Shortest Job First</span></em><span class="s4"> (SJF).</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">In a similar vein, if job duration cannot be determined at all, and yes, I’ve seen those projects too, it is best to use </span><em><span class="s3">High Delay Cost First</span></em><span class="s4"> (HDCF).</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>If you know nothing about anything, and research don’t yield any improved results, well, you can do Features in random order. At least they get done.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">Note that everything I’m writing about scheduling here applies to </span><em><span class="s3">vertical slices of functionality</span></em><span class="s4">! I’ve seen projects trying to apply WSJF scheduling to tasks, and that simply does not work. For one thing, a task does not have business value. Business value is what you get when you implement several related tasks, and the implemented pieces of software </span><em><span class="s3">interact with each other</span></em><span class="s4">!</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>By the way, I mentioned I’ve seen projects trying to apply WSJF scheduling to tasks. What do they do when they discover that does not work? Most Product Owners just fudge it and assign some arbitrary rank. One project found a really creative solution: They redefined the term “Business Value”. But I digress. Let’s move on…<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><h2 style="text-align: left;"><strong><span class="s9">Reduce the Cost of Change: Refactor Agressively</span></strong></h2><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">As I mentioned in my rant </span><a href="http://kallokain.blogspot.com/2023/08/interlude-cost-of-agile.html"><span class="s4">Interlude: The Cost of Agile</span></a><span class="s4"> a fundamental idea in agile software development is to keep the Cost of Change low by having </span><em><span class="s3">all</span></em><span class="s4"> developers </span><em><span class="s3">continuously</span></em><span class="s4"> refactoring the codebase, as part of the routine when writing code. This is usually done through practices like Test-Driven Design (TDD) or Behavior-Driven Design (BDD). To put it a bit harshly, developers that do not do this, should not be trusted writing production code.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>On a higher management level, you basically have two options:<div><ul class="ul1" style="text-align: left;"><li>Hire only developers who know TDD, BDD, or similar techniques.</li><ul class="ul1"></ul><li>Train the developers you do have, so they learn to keep the Cost of Change low.</li></ul><span class="s4">I am much in favor of the </span><em><span class="s3">train the developers</span></em><span class="s4"> option. Of course, to do that, you need to build a training organization within the company, and you need to hire and develop people with long term goals in mind.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>While you are at it, do the same for managers. You might be positively surprised.</div><div><h2 style="text-align: left;"><strong><span class="s9">Parallelize Processes</span></strong></h2><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>If you can structure the project as multiple independent parallel processes, then you can reduce project lead time, and Business Value will go up.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Sounds easy, but most organizations I have worked for fail miserably at this. They talk the talk, Value Streams, blah, blah, Agile Release Trains, blah, blah, but when they organize the teams, they do it around functions, just like they have always done, with the same miserable results they have always had (or even worse). The only thing they actually use, is the new terminology. The way they organize stays the same.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>The problem is that agile methods are not designed for parallelizing the work in large projects, because most of them are designed for small systems development. When you do small systems development, it is okay to simplify planning down to putting all work items in a single queue per team. This does not work when we scale up projects. We need to parallelize the work, and we cannot do that if everything is in a single queue.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">There </span><em><span class="s3">is</span></em><span class="s4"> an agile planning method that does parallelize work. It’s </span><em><span class="s3">Blitz Planning</span></em><span class="s4">, from the </span><em><span class="s3">Crystal</span></em><span class="s4"> family of methods by Alistair Cockburn. You might want to check it out.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Parallelize for real, and you have a leg up on most other projects, agile or otherwise.</div><div><h1 style="text-align: left;"><strong><span class="s5">Second Pick: Queues</span></strong></h1><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCcr8RJL50SsRgo_KuzoNIHinX4nkExj5Ql7J8Vye3pG--GSM_d4iX4WWfdySXHxeg4FU9numwH-SlodXMWGUkJM3twW89Taudy0I7X5iFymTGN-J941w9SPn4xARGIzX-zgYh5SRgw0pM5-DHkUwvg1oHvgzQL3CODdvA4S2eXQHIPtbrNuuE1A/s2481/Queues%20Lever.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2481" height="283" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCcr8RJL50SsRgo_KuzoNIHinX4nkExj5Ql7J8Vye3pG--GSM_d4iX4WWfdySXHxeg4FU9numwH-SlodXMWGUkJM3twW89Taudy0I7X5iFymTGN-J941w9SPn4xARGIzX-zgYh5SRgw0pM5-DHkUwvg1oHvgzQL3CODdvA4S2eXQHIPtbrNuuE1A/w400-h283/Queues%20Lever.jpg" width="400" /></a></div><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>My second pick is queues, both in front of, and in, the development process. Why, because the queues predict lead times. By monitoring queue sizes, I can determine the overall state of the project:<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul><li><em>Queue size is constant over time</em><span class="s7">: The teams are working at an overall stable rate of production. On average, each iteration, the teams deliver as much working functionality as they take onboard. This is ideal conditions for time estimates and statistical forecasts. (I still would not trust estimates though.)</span></li><ul class="ul1"></ul><li><em>Queue size increases over time</em><span class="s7">: Increasing queues is a strong warning signal! It means delays, and thus lead times, and costs are growing. The delays in time to market means reduced cash flow, a shorter life cycle, and heavily reduced total profitability. Teams are taking on more work each iteration than they can finish, so people will be stressed out. There is risk of people burning out, or leaving. Time estimates made by developers, and forecasts made by statistical methods, will underestimate how long it will take to implement requirements, often by a lot.</span></li><ul class="ul1"></ul><li><em>Queue size reduced over time</em><span class="s7">: This means lead time is shrinking. Projected total project cost is shrinking. There is less risk of developers being overloaded with work, though this can still occur locally, even if the overall picture looks good. Of course, if reducing queues is taken too far, the development teams will be starved for work, but this is a rare occurrence in practice. Another potential problem is a blockage in producing requirements. This is also fairly rare, but worth checking for. Forecasts are likely to </span><em>overestimate</em><span class="s7"> the how long it takes to implement functionality.</span></li></ul>What I’ll aim for, is a stable sweet spot, where lead times are fairly short, forecast reliability high, and people have comfortable working conditions.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Note that if you look at aggregated values, things can look good overall, despite a disaster occurring locally. Looking at overall queue sizes, or using any other metrics, does not replace going to gemba, and talking to people who do the actual work. The metrics just supplement that.</div><div><h2 style="text-align: left;"><strong><span class="s8">Changing Queue Size</span></strong></h2><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Set project/program level Work-In-Process (WIP) limits, and stick to them! Then, when you can see that you have a stable system (check the queue size), try reducing the WIP limit a little, and see what happens. If the results are good, repeat the process. If the results are bad, back off a bit and restore the WIP limit to what it was previously.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">That is basically it. There are finer points to it that would fill a book. You can find many of those finer points in Reinertsen’s </span><em><span class="s3">The Principles of Product Development Flow: Second Generation Lean Product Development</span></em><span class="s4">.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>In just about every large “agile” project or program I have seen, Scrum Masters do their best to hold WIP as low as possible by getting developers to pull tasks and stories through, and finish them, before taking on more work. Sprint backlogs are limited in size by the Sprint planning process.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>This is all very good, but…<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">Nobody pays the slightest attention to half-finished material that builds up </span><em><span class="s3">between</span></em><span class="s4"> collaborating teams! In most projects, all teams have their own separate Product Backlog, and that is usually where the half-finished stuff hides out. Nobody thinks about setting WIP limits on the Product Backlogs, or even whether it is a good idea for all teams to have separate Product Backlogs.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><blockquote>If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>— The 2020 Scrum Guide</blockquote>The purpose of the above passage in the Scrum Guide, is to avoid creating hiding places for unfinished work. Of course, most companies I have seen ignore this, and go right ahead and create them anyway.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Scrum Masters, who should know better, go along without a peep. Product Owners don’t say anything either, but they at least have a valid reason: If you do what the Scrum Guide says, most Product Owners will be out of their current jobs. For example, most SAFe projects I have seen, have way more Product Owners than they should have, sometimes 15-20 times as many.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">Note that I am </span><em><span class="s3">not</span></em><span class="s4"> advocating firing 90%-95% of all Product Owners. I am advocating for giving them constructive work, instead of destructive work, and changing their job titles to something appropriate.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>There should, in most cases, be one Product Owner per product. Most organizations I have seen, solve this back asswards, and start calling every subsystem that has a dedicated team working on it, a “product”. It is easier to do that, than solving the actual problem with too many internal queues.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Setting strict high level WIP limits for the entire project or program helps solve the problem. Even if the internal structure of the project is bonkers, an overall WIP limit makes it more difficult to hide partially finished work in internal queues, whether they are called Product Backlogs or something else.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Of course, to make the project work well, you do need to set up a sane project structure, and it is much easier to do that early on, than late in the project. Also, the value of solving the problem is greater the earlier you do it.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">While individual teams often use a method called kanban to set WIP limits, I would advice using </span><em><span class="s3">Constrained Work in Process</span></em><span class="s4"> (CONWIP) at the project or program level.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>CONWIP is simple. You set a WIP limit. Once the WIP limit for the entire group has been reached, you do not add another unit of work to the system of teams until a unit of work has been finished.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>For example, suppose you have eight teams working on a product. The teams are set up to work in parallel, so they can work on one Feature each simultaneously. Try setting the WIP limit to eight Features initially, and see how that works out. Experiment by adjusting up, or down, until the teams find the sweet spot, where the lead times are short, and Cost of Delay is low, and people have enough to do, so capacity cost isn’t too high.</div><div><strong><span class="s5"><br /></span></strong></div><div><h1 style="text-align: left;"><strong><span class="s5">Third Pick: Scope</span></strong><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcVgyYgHLSCJ3SY8gSPAOxho6AQW18HOE5wJU946vzy7-JDFyfq06JEwC0ZMh4VfV96zMSMdB7lwM_mIW1nka2fqz_cmflrnP1KvXrMoqsLTUNucDJQ16Euf5zuE1ZmJiuuJOlA2n3pVD1-aGp8zgzybr4ltXcAPuAuz9onetn-FZJJMSxp-dcEA/s2481/Scope%20Lever.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2481" height="283" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcVgyYgHLSCJ3SY8gSPAOxho6AQW18HOE5wJU946vzy7-JDFyfq06JEwC0ZMh4VfV96zMSMdB7lwM_mIW1nka2fqz_cmflrnP1KvXrMoqsLTUNucDJQ16Euf5zuE1ZmJiuuJOlA2n3pVD1-aGp8zgzybr4ltXcAPuAuz9onetn-FZJJMSxp-dcEA/w400-h283/Scope%20Lever.jpg" width="400" /></a></div></h1><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>My third pick is Scope. Agile projects and programs must have control of the scope! The reason is the inherent uncertainty built into even the best estimates and forecasts.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>First of all, when a project starts, no one, not even the customers, know what the customers want. This will be discovered during the project. Quite often, things customers want at the start of a project, turn out to be completely unnecessary, or even undesirable, later on.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Second, forecasts are uncertain. Estimates are even more uncertain. To make delivery dates, projects need flexibility. The easiest way to achieve that, is to be flexible about scope.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Let’s revisit the Affinity Publisher cross-reference feature. Serif had planned to include cross-references in their 2.1 release. As it turned out, beta testers did not like the original design of the feature, and it was slaughtered in the online beta release forum. Serif decided to redesign the feature. To do that, they needed more time, so they reduced the scope of the 2.1 release, and will now include it in the 2.2 release instead.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>What do the users think of this delay? They, and that includes me, are very positive to it. I’ll much rather have a great cross-reference feature a couple of months later, than a smells-like-a-dead-fish MS Word look-alike feature right now. The same goes for the other users who really need a great cross-reference feature.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">One important caveat: When reducing scope, reduce the number of </span><em><span class="s3">vertically sliced</span></em><span class="s4"> requirements! That way, you can track what you are doing, and you minimize the work of tracking down dependencies.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>I have seen projects where management tries to reduce scope by reducing the number of functional units. That is, they try to reduce the number of large tasks. When they do that, they need to track all dependencies of all functional units they want to remove, and that ends in madness. Partially, of course, because they did not pay attention to refactoring and creating a loosely coupled emergent design in the first place.</div><div><h1><strong>Putting it Together</strong></h1></div><br /><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5wb8UgkXaNiU6Cj0TeGXPVkBSARvjWIDA9108f7qstyWGsaPqyIO-pL3ahY1MCWJ0IFNyG20d7UqLR9rXCZIMaELQ4hu2eKZiVQj-ir4RIS30Dyz2n4GNrcjlwLf5Tkl1AM9h5AgzT_ZmoH_hoRdrCaKp5ixM9AkKnA0C3TXGc2DqlpvcqrRMgg/s2482/Goal%20Map%2001.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2482" height="450" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5wb8UgkXaNiU6Cj0TeGXPVkBSARvjWIDA9108f7qstyWGsaPqyIO-pL3ahY1MCWJ0IFNyG20d7UqLR9rXCZIMaELQ4hu2eKZiVQj-ir4RIS30Dyz2n4GNrcjlwLf5Tkl1AM9h5AgzT_ZmoH_hoRdrCaKp5ixM9AkKnA0C3TXGc2DqlpvcqrRMgg/w640-h450/Goal%20Map%2001.jpg" width="640" /></a></div><p style="text-align: left;"><span class="s4">Let’s put what we have got together with a Goal Map from TOC’s </span><em><span class="s3">The Logical Thinking Process</span></em><span class="s4">. I am using a variant that shows not only goals and sub-goals, well Critical Success Factors, if you want to use the correct terminology, it also maps behaviors and metrics to the goals.</span></p><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>As we have shown, there is a hierarchical relationship between our goals. In the project, our main concern is to maximize Business Value for the customer. We can do that by moving the Business Value lever directly, for example by using Weighted shortest Job First, or by decoupling and parallelizing processes.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>However, changing the scope lever also impacts the Business Value. So does optimizing queue sizes. Therefore, the levers are connected.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>I have added an overarching business goal for the company, maximizing the Return On Investment now and in the future. Few companies make things for purely altruistic reasons. They want to make a profit, so we should connect the project/program to that.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Note that I drew the connecting arrow using a dashed line. That is because we, just about everyone involved with agile methods, make the assumption that if we build what the customer really needs, then the customer will buy our product, and be happy with it.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>The only snag is, humans are not that logical! We often make bad choices, even though we really ought to know better. That applies to software development, and it applies to buying and using software products too.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Still, we will let it stand for now. Fixing that little problem is way outside the scope of this article series. Just keep it in mind, if you build a fantastic piece of software that nobody wants to buy or use. The problem may be psychological, rather than technical. Sometimes, you may even have to dumb a product down in order to get it accepted. Been there, done that!</div><br /><div><h1 style="text-align: left;"><strong><span class="s5">Metrics Do Not Replace Talking to People!</span></strong></h1><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>I have mentioned it in the article, but it deserves to be mentioned again: Top level control levers, and metrics, are a complement to talking to people in the project. The levers and metrics are topics for conversation. They can be used as conversation starters and action triggers. They in no way replace talking to people!<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>The project management method you use, whether it be Scrum, SAFe, or something else, will define a bunch of meetings with various people. Pay attention to which meetings are really useful to the people participating in them. Keep the useful ones. Cut down on the rest, and if everyone is still happy, ditch them, and check if people are still happy.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Originally, agile methods cut meetings to a barely sufficient minimum, so that developers could get on with the work. Today, developers often see agile as nothing but a bunch of useless and boring meetings that block them from getting stuff done. Unfortunately, they can present a pretty good case for that. Watch out for meeting-creep. You may wish to go back to the original agile methods, like eXtreme Programming and Crystal, and see what kind of meetings were deemed worth having.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>In meetings, people will tell you what they think you want to hear. Bad news has a tendency to disappear, or at least get delayed and softened. One fix for that is to encourage people to give you bad news. Commend and praise them for it!<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">Another, is to </span><em><span class="s3">Go to Gemba</span></em><span class="s4">. (Also known as </span><em><span class="s3">management-by-walking-around</span></em><span class="s4">.) Go to the places where the work is actually done, and talk to the people actually doing the work. Bring a pen and a notebook. Note down any problem you may be able to help fix. This should be nearly all of them, since you are a high level manager. After awhile, when people see that you are serious about helping out, they will tell you things that never come up in the meetings.</span></div><div><h1 style="text-align: left;"><strong><span class="s5">Coming Up: The Rejects - Why they Didn’t Make It, and What I Did With Them Instead</span></strong></h1><p style="text-align: left;">This part is about twice as long as the other parts in the article series, and as it turns out, there are still some things to say about control levers for large projects.</p><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>When I picked my favorite levers, I discarded a bunch of others:<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul><li>Capacity</li><ul class="ul1"></ul><li>Cost</li><ul class="ul1"></ul><li>Duration</li><ul class="ul1"></ul><li>Quality</li><ul class="ul1"></ul><li>Cycle Time</li></ul>That I did not choose these as control levers does not mean they are useless. There are other things that can be done with them, and that is what I will write about in part five.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Also, I did put a few constraints on basic properties of agile projects and programs. A lot of projects that purport to be agile simply are not. Unfortunately, knowing that does not help, so I am considering writing a sixth part about what to do if you find yourself managing a pretend-to-be-agile project. Please let me know if that is of interest.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">I do realize I am considering writing part five and six in a three part article series. Well, that is why agile projects need flexible scope. This article, and the previous one, </span><a href="http://kallokain.blogspot.com/2023/08/interlude-cost-of-agile.html"><span class="s4">Interlude: The Cost of Agile</span></a><span class="s4">, constitute a good example:</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">I had intended to write one article, saw that it was getting really big, and would take a long time to finish, so I split it into two deliveries, </span><a href="http://kallokain.blogspot.com/2023/08/interlude-cost-of-agile.html"><span class="s4">Interlude: The Cost of Agile</span></a><span class="s4">, and this article. Thus, I could deliver value to my readers, my end users, faster, by </span><em><span class="s3">reducing the scope of the first delivery</span></em><span class="s4">.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Assuming that at least one reader found something practically useful in that first delivery, they could act sooner, and get the benefits of said value for a longer time. Thus, the total value of the benefits of the advice in the article increased.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>That is exactly how agile methods work! It’s a litmus test. If a project does not work like that, its not agile, no matter how well you follow the Scrum ceremonies, and regardless of whether you have RTEs and are organized into ARTs, or whatever.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul><span class="s4">Then, of course, while writing about the control levers I find useful for large projects, I stumbled on the idea that there is also value about writing about the discarded controls. They are far from useless, even if they are not the primary control levers. Thus, </span><em><span class="s3">I increased the scope, in order to increase the value</span></em><span class="s4">, and I did it while writing Part Four, not while planning the original three parts.</span><br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>That is also how agile methods work!<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Both reducing and increasing scope can increase business value. It is all a matter of context.<br /><ul class="ul1" style="text-align: left;"><ul class="ul1"></ul></ul>Got to stop writing now, so I can begin on the next part.</div><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br />Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-75249272699905217522023-08-24T16:27:00.000+02:002023-08-24T16:27:06.204+02:00Interlude: The Cost of Agile<p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWjJYnhHiBcEjTuIO3fMaB9N37VDYMBJYMnTpEKjkkN97SHSxGDT-gqy-TiZ_c7TrCVQVDFvfc606mAQtB-iJ9Z4qtVul1Uj-a7PSSGAp3-4n8eoSw7pD_G2fWREafk645C-8UfDYhFfCFyddXQRjbSAu7MY2gwGHnLC0XrsSQWnmalJ-8OSC7_A/s2481/Evaporating%20Cloud%20-%20Invest%20or%20not.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2481" height="452" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWjJYnhHiBcEjTuIO3fMaB9N37VDYMBJYMnTpEKjkkN97SHSxGDT-gqy-TiZ_c7TrCVQVDFvfc606mAQtB-iJ9Z4qtVul1Uj-a7PSSGAp3-4n8eoSw7pD_G2fWREafk645C-8UfDYhFfCFyddXQRjbSAu7MY2gwGHnLC0XrsSQWnmalJ-8OSC7_A/w640-h452/Evaporating%20Cloud%20-%20Invest%20or%20not.jpg" width="640" /></a></div><p></p>
<p class="p5"><em><span class="s3">Agile software development requires significant long term investments in developer skill. Most “Agilists” choose not to talk about it.</span></em></p>
<p class="p3"><span class="s2">I had just begun working on part four in my three part blog post series </span><em><span class="s3">Are You Still Using the Wrong Control Levers in your Agile projects?</span></em><span class="s2">, when I found myself writing a section about agile project economics. The section was rather long, and didn’t quite fit with the rest of part four, so I decided to break it out, and make it a separate blog post instead. This is it! I do hope you enjoy reading it.</span></p>
<p class="p3"><span class="s2">In case you wonder why there are four parts (five if you count this interlude) in a three part blog post series, well, requirements changed, and the scope increased…</span></p>
<p class="p3"><span class="s2">Agile methods have great benefits, both in human, and economic terms. There are also costs. Thus, going agile, if it is done seriously, requires thinking a bit about the trade-offs that must be made.</span></p>
<p class="p3"><span class="s2">Most companies don’t consider the trade-offs. What they do is they set up an “Agile transformation program”, and make the assumption that the cost of the program is equivalent to the cost of going agile. It’s not even close! The costs are much higher than that. Unfortunately, since most companies don’t pay those costs, they don’t get the correspondingly great benefits either.</span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuB0rNsx8mxPrXMUTFItagFqclCIoJxUYZvcETqvxoEG1LTTwW1QZQxdh0ejYY9FgwmrssVs93LcK_20e7H07bFXehj6D4EokluMtjVMBxSljbq5EOS6s3Z6x58fhdK-y2hSFK8TI8loHdi0Dkyqgcswj2qvlIkX1zUvkLEUOzKh4D2R4BKR1BHw/s2481/Scrum%20is%20a%20Wrapper.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2481" height="452" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuB0rNsx8mxPrXMUTFItagFqclCIoJxUYZvcETqvxoEG1LTTwW1QZQxdh0ejYY9FgwmrssVs93LcK_20e7H07bFXehj6D4EokluMtjVMBxSljbq5EOS6s3Z6x58fhdK-y2hSFK8TI8loHdi0Dkyqgcswj2qvlIkX1zUvkLEUOzKh4D2R4BKR1BHw/w640-h452/Scrum%20is%20a%20Wrapper.jpg" width="640" /></a></div>
<p class="p5"><em><span class="s3">Scrum is intended to be a wrapper around agile software development practices. A large part of the economic benefits of using agile, comes from the software development practices.</span></em></p>
<p class="p3"><span class="s2">For starters, nearly every organization that goes agile chooses to use Scrum, but Scrum is not a complete agile method. It’s just a thin communications wrapper around a team that uses agile software development practices. If you want agile performance, you must identify core agile software development practices, and train developers to use them.</span></p>
<p class="p3"><span class="s2">For a company that uses a lot of consultants in its projects, this training cost will quickly get prohibitively high, which means to go agile, such a company must shift from using consultants to using full time employees. They will also invest a lot of money in training their employees. This means they will not be able to grow or shrink their staff as quickly as before. People become long term investments instead of short time investments.</span></p>
<p class="p3"><span class="s2">On the up-side, the company will have well trained staff that is a lot more flexible than before, and that can be utilized for competitive advantage. It does require top management to unlearn the way they currently think about managing their company, and learn new ways.</span></p>
<p class="p3"><span class="s2">Few managers are interested in going back to school, no matter how useful it </span><em><span class="s3">potentially</span></em><span class="s2"> is. It is worth remembering, from their perspective, they will have no idea if all the new stuff they have to learn is useful until </span><em><span class="s3">after</span></em><span class="s2"> they have learned it, and tried it out. Most will not even know they have to learn new stuff.</span></p>
<h1 class="scr1"><strong><span class="s4">Every Agile Team has Economists Onboard…They Just don’t Know It!</span></strong></h1>
<p class="p3"><span class="s2">Any software development team, agile or not, can be seen as an economic engine: The inputs are requirements and coffee. The output is software functionality that has value (positive or negative) for users.</span></p>
<p class="p3"><span class="s2">Who does the work of maximizing the value of the output from the economic engine?</span></p>
<p class="p3"><span class="s2">If you are using Scrum, and have read the Scrum Guide, you might think it is the Product Owner.</span></p>
<p class="p6"><span class="s2">The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.<br />— The 2020 Scrum Guide</span></p>
<p class="p3"><span class="s2">Note the word “accountable”. What it means is that the Product Owner does not necessarily do the actual work. The Product Owner is just the one who has to justify various decisions to the powers that be. In most Scrum projects, the Product Owner does assign business value to items in the Product Backlog. That is then combined with time estimates from developers and the result determines the actual priority. The idea is to produce the maximum business value per time unit, usually a two week Sprint.</span></p>
<p class="p3"><span class="s2">Thus, estimates made by the developers also have a lot of impact on the business value of the output.</span></p>
<p class="p3"><span class="s2">However, the developers make other economic decisions, without the involvement of the Product Owner.</span></p>
<p class="p3"><span class="s2">For example, </span><em><span class="s3">it is the developers who decide how high the cost of adding, changing, or removing requirements will be</span></em><span class="s2">!</span></p>
<p class="p3"><span class="s2">Wait, what? How do the developers do that? The developers decide how complicated the code is. They decide whether the code will be tightly coupled, with many dependencies, or loosely coupled, with few dependencies. They decide whether classes and methods are easy to understand and work with, or whether developers will have to spend hours, days, weeks, or even more, understanding how a piece of code works, before they can change it.</span></p>
<p class="p3"><span class="s2">The developers also decide whether changing a piece of code is a safe operation, or if it is dangerous, with a high probability of introducing new bugs each time the code is touched.</span></p>
<p class="p3"><span class="s2">Good developers make these decisions very deliberately, and use various tools and programming techniques to implement the decisions. Other developers usually don’t think much about it. They just write the code they need to solve their immediate problem. Of course, there is a very wide range between the extremes I have described, and most developers are somewhere in-between. No matter where they are on the scale, and how they approach software development, developers make decisions that have economic impact many times each day they work.</span></p>
<p class="p3"><span class="s2">We already know that requirements will change often. That is why we chose to use an agile method in the first place. Thus, the decisions made by developers while writing code will be an important cost driver, up, or down, depending on the decisions made.</span></p>
<p class="p3"><span class="s2">Of course there are many things a developer may do, or not do, that has an economic impact. It would be nice though, if we could identify key drivers that have a lot of impact. Early agile methods did just that. For example, eXtreme Programming identified </span><em><span class="s3">refactoring</span></em><span class="s2"> as a key economic driver:</span></p>
<p class="p6"><span class="s2">Refactoring is a discipline of design that codifies these recurring patterns of changes. These refactorings can occur at any level of scale. Few design decisions are difficult to change once made. The result is systems that can start small and grow as needed without exorbitant cost.<br />— Beck, Kent; Andres, Cynthia. Extreme Programming Explained: Embrace Change (p. 90). Kindle Edition.</span></p>
<p class="p3"><span class="s2">In 2003, Tom and Mary Poppendieck described agile methods in terms of project economics, and did a very good job of it. They too, identified refactoring as a key economic driver:</span></p>
<p class="p6"><span class="s2">…refactoring is a key method for avoiding waste in providing business value to customers. A well-designed code base is the foundation of a system that can respond to the needs of customers both during development and throughout the useful life of the system.</span></p>
<p class="p6"><span class="s2">— Poppendieck, Mary; Poppendieck, Tom. Lean Software Development (Agile Software Development Series) (pp. 144-145). Pearson Education. Kindle Edition. </span></p>
<p class="p3"><span class="s2">When developers refactor code, they can easily break code that does work. Automated refactoring functionality in development tools does reduce this risk, but more is needed:</span></p>
<p class="p6"><span class="s2">A key tool that goes hand in hand with refactoring, and in fact makes refactoring possible, is automated testing.<br />— Poppendieck, Mary; Poppendieck, Tom. Lean Software Development (Agile Software Development Series) (p. 145). Pearson Education. </span></p>
<p class="p3"><span class="s2">The idea of using automated tests to make refactoring safe, came from eXtreme Programming:</span></p>
<p class="p6"><span class="s2">Refactoring, [automated] unit testing, and immediate feedback as you code are now an integral part of our toolset. Moreover, since we are “eating our own dog food” we use these practices in our day-to-day development.<br />— Beck, Kent; Andres, Cynthia. Extreme Programming Explained: Embrace Change (p. 18). Pearson Education. </span></p>
<p class="p3"><span class="s2">Over time, agile mutated from a set of methods for software development to much more generic ideas about managing projects. In order to make agile more generically applicable, things that were specific to software development were excised and forgotten (or killed off and buried in the back yard, depending on your point of view).</span></p>
<p class="p3"><span class="s2">Because the agile economic model was dependent both on management practices (vertical slicing), and software development practices (refactoring, Test-Driven Design, iterative development) it didn’t fit with methods that focused exclusively with management.</span></p>
<p class="p3"><span class="s2">None of my “modern” books about working as a Scrum Master, or Product Owner, mentions refactoring. Well, one of them mentions that it is a term that is too technical to use:</span></p>
<p class="p6"><span class="s2">You should avoid technical actions, such as “I want to create a database” or “I want to refactor that nasty piece of code.” These technical actions are solution oriented and should be done instead as part of a separate, more business-oriented user story.<br />— Don, McGreal; Jocham Ralph. The Professional Product Owner: Leveraging Scrum as a Competitive Advantage (p. 197). Pearson Education. Kindle Edition. </span></p>
<p class="p3"><span class="s2">Beyond that, refactoring is not mentioned again. None of my more recently written agile project management books has anything sensible to say about project economics, at least when it comes to modeling the internals of a development team, or system of teams.</span></p>
<p class="p3"><span class="s2">Most of the material I have found, focuses on looking at teams from the outside, using things like Net Present Value (NPV) and Weighted Shortest Job First (WSJF).</span></p>
<p class="p3"><span class="s2">The one exception I have seen, is SAFe:</span></p>
<p class="p6"><span class="s2">With continuous refactoring, the useful life of an Enterprise’s investment in software assets can be extended as long as possible. Users can continue to experience a flow of value for years to come. Refactors enable an emergent design, ensuring the system continues to meet future business needs.<br />— SAFe 6, https://scaledagileframework.com/refactoring/</span></p>
<p class="p3"><span class="s2">Then again, the SAFe refactoring article is considered an advanced topic, not fundamental to making agile methods work. Also, while the SAFe article describes both small and large scale refactoring, it seems biased towards large scale refactoring, while the original agile methods preferred to make refactoring a part of the everyday work routine. EXtreme Programmers do large refactorings too, but they are relatively rare. Small scale refactoring is done every time an eXtreme Programmers writes a method.</span></p>
<p class="p3"><span class="s2">I have never, ever, seen an argument for discarding the fundamental practice of refactoring. Instead, agilists just stopped talking about it, and about the economic impact of agile software development practices. This made agile much easier to adopt (and easier to sell), but it also reduced its value.</span></p>
<p class="p3"><span class="s2">On the upside, the few companies that are willing to take agile methods seriously, can gain significant advantages by reducing the cost of change during both development and maintenance, and extending product lifecycles. It does require investing in developer skills, and creating work environments where developers like to work.</span></p>
Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-54366574781334390622023-08-09T16:37:00.000+02:002023-08-09T16:37:52.060+02:00Are You Still Using the Wrong Control Levers in your Agile projects? Part 3: The Iron Triangle vs. The Gang of Four<p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4VwWPy3LaQ95mQLJVx8-3IedrBu77OCxn1QGpXCRxQWyBwSb5dJCfX1ybPBls199TIuExxL3SJ3CToQpobeFZaZzraMED82l_J2rlIfDWPBys5shz7zfFAFZSpNAZy5h1kuFxHE8Bgwrfk2v6-fqaRB2QMLiEC_66Y7HFIpMP1dXSy0rA2G9k1g/s4596/ron%20Triangle%20and%20GoF%20v01.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="4596" height="153" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4VwWPy3LaQ95mQLJVx8-3IedrBu77OCxn1QGpXCRxQWyBwSb5dJCfX1ybPBls199TIuExxL3SJ3CToQpobeFZaZzraMED82l_J2rlIfDWPBys5shz7zfFAFZSpNAZy5h1kuFxHE8Bgwrfk2v6-fqaRB2QMLiEC_66Y7HFIpMP1dXSy0rA2G9k1g/w400-h153/ron%20Triangle%20and%20GoF%20v01.jpg" width="400" /></a></div><p></p><p>Welcome back! Or, if this is the first time you visit, welcome!</p><p>It’s been awhile since I wrote the first two parts in this series about high level project control levers, their use, and abuse. This is the third and final part. In it, we will have a look at two control lever systems, the classic Iron Triangle, and the somewhat less well known Four Lever system from the first edition of Extreme Programming.</p><p>First, a brief recapitulation of the first two parts of this series:</p><p>In the <a href="http://kallokain.blogspot.com/2023/01/are-you-still-using-wrong-control.html" target="_blank">first part</a> I wrote about how using Cost and Capacity to control an agile software project can trap an organization in a hire and fire cycle that increases project duration and cost.</p><p>In the <a href="http://kallokain.blogspot.com/2023/01/are-you-still-using-wrong-control_14.html" target="_blank">second part</a>, I wrote about how to optimize a project for delivering maximum business value. I also wrote about a common mistake companies do, which will disable the Business Value lever, so it no longer works as intended.</p><p>You can read each part, including this one, as a standalone article. To get as complete an understanding as possible, I do recommend you endure the pain of reading all three. I’ve done my best to reduce the pain as much as possible.</p><h1 style="text-align: left;">The Iron Triangle</h1><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxPObRkHAqrRnvO4ih5RS4jka7ClhUVbo9dBog0uP8MH1k99gQ2wlL8wFxq032AvvRd03GVOVrc_DWJMbyMevzhz8hm4wbtgtac6ZZVI_b4O691xkHFnXRQbnHN7cr8kmG1FCvTx7e0nubapsO3druRzDvwP0LRR9ikNEyv0yKc6z0HCQ-YIwVYA/s2481/Iron%20Triangle%20v01.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2481" height="283" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxPObRkHAqrRnvO4ih5RS4jka7ClhUVbo9dBog0uP8MH1k99gQ2wlL8wFxq032AvvRd03GVOVrc_DWJMbyMevzhz8hm4wbtgtac6ZZVI_b4O691xkHFnXRQbnHN7cr8kmG1FCvTx7e0nubapsO3druRzDvwP0LRR9ikNEyv0yKc6z0HCQ-YIwVYA/w400-h283/Iron%20Triangle%20v01.jpg" width="400" /></a></div><p>The Iron Triangle is the classic set of project constraints: Scope, Duration, Cost. The idea is that if you change any one of these, the other two will also change. The trick is to maintain an optimal balance. If you do that, you will have a successful project.</p><p>Quality is considered the result of managing Scope, duration, and Cost. Thus, in this model, Quality is not itself a control lever. It is worth noting that Quality is used more in the meaning fit for purpose, rather than free from defects.</p><h2 style="text-align: left;">Problem One: The Variable Lockdown Fallacy</h2><p>A still fairly popular way of screwing both Project Managers and development teams over, is to lock all three variables before the project even begins. That way, it becomes impossible, or at least very difficult, to compensate for even fairly small deviations from the original plan.</p><p>Of course, if management locks the steering variables from the start, you can be pretty sure that the original plan is…not very realistic. It will serve as an excellent basis for playing blame games and punishing the innocent though.</p><p>Fortunately, this form of abuse seems to be less common than it used to be. I still see it in project descriptions now and then.</p><h2 style="text-align: left;">Problem Two: Decoupling from Business Value</h2><p>When used as intended, that is, a set of controls for managing the project, the Iron Triangle works a bit better. There is one rather glaring flaw though:</p><p>The Cost, Duration, and Scope controls are decoupled from delivered Business Value!</p><p>Wait! What?!</p><p>The Iron Triangle model assumes that if the project delivers the agreed Scope, at optimal Cost, and Duration, the project is a success. That is not quite true. I’ll illustrate with two stories:</p><h2 style="text-align: left;">Story One: Perfect Product, but Not Viable</h2><p>I worked in my first real development project as a programmer. It was around 1980, and I was sixteen or seventeen years old. It was a combined software/hardware project. There were a couple of hardware people in the project, and I was the one and only programmer. The project was lead by the manager of the marketing department of the company we worked for. He was one of the best project managers I have ever worked for. On top of that, he was a very nice and supportive person. I learned a lot from him.</p><p>We did have a time constraint: six months! After that, I would do my military service, and would of course not be available to work on the project.</p><p>Judged by Iron Triangle criteria, the project was a resounding success! We finished about a week before my time at the company was up. The software and hardware worked flawlessly together, and the data presentation model I had created exceeded all expectations. Scope - Check! Duration - Check! Cost - Check! Perfect!</p><p>Not quite! The day before I left, the manager told me the equipment we had built would be mothballed, and never used. He was very careful to explain why: We had developed a product for internal use at the company. The same week we finished the project, another company released a commercial product that did the same thing. The company decided to use the commercial product instead, because the maintenance costs would be much lower. It was the correct decision to make. I am still, more than forty years later, very grateful that my manager took the time to explain the basis for the decision.</p><h2 style="text-align: left;">Story Two: Feature Fatigue</h2><p>Several years ago I got commissioned by a large company to figure out why one of their flagship products didn’t sell nearly as well as expected. It was a big job, and I spent six months traversing the entire production chain end to end, finding out what problems people had, and what solutions they proposed. I also talked to customers who had bought the product, and prospective customers that did not buy the product. The latter group provided vital insights.</p><p>I organized the data I collected using The Logical Thinking Process, a set of problem solving tools from the Theory of Constraints (TOC) management paradigm. One afternoon, I sat staring at a Current Reality Tree, a model I had built to give me an overview of the current situation. I was trying to find root causes of known problems, but the pieces didn’t quite fit. Something was missing.</p><p>Then it struck me: Feature Fatigue! We had a giant organization set up to crank out new features at maximum velocity, but many features were of interest to only a single customer. This was due to the organization using sales people to collect and prioritize requirements. The sales people often used promises of new features to make a sale: “If you buy now, I’ll make sure your feature request gets top priority.”</p><p>The inevitable result was that the application was flooded with junk features. These features may have been of interest to one customer, but to everyone else, they were useless and just made the software clunky and difficult to use.</p><p>Thus, delivering the agreed scope actually reduced the value of the product!</p><h2 style="text-align: left;">Don’t Use Scope as a Proxy for Business Value!</h2><p>In both stories above, success as measured by the Iron Triangle, did not translate into delivered business value. Why the discrepancy? Because while scope is a perfectly valid thing to measure and control, it is not usable as a proxy for Business Value.</p><p>The iron triangle is useful for keeping projects on track, but it is not enough! By itself, it will tell you nothing about whether a project is going in the right direction. It will only tell you whether it is going somewhere, or if it is just burning money while standing still.</p><p>Of course, the argument about using vertically sliced requirements in <a href="http://kallokain.blogspot.com/2023/01/are-you-still-using-wrong-control_14.html" target="_blank">Part 2</a> holds when using the Iron Triangle too. Your requirements must be vertically sliced, otherwise you can’t measure how much of the Scope that has actually been implemented. If you can’t do that, you won’t know whether you are burning through money too fast, or not. Nor will you have any basis for estimating the duration of the project. Thus, the entire Iron Triangle model collapses.</p><p>On the other hand, if you have vertically sliced requirements, and if you keep track of delivered business value, and the revenue you get from it, then the Iron Triangle is useful.</p><h1 style="text-align: left;">The Gang of Four - The Extreme Programming Way (sort of)</h1><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgdNUw3Ox2wfA79WemtdAWXCvSnI2I7ZpMCaQGIZ3SyV7RPfiU5t4E60eo_kiji3Y9ytsllp8aQwBpqk4yOFFA9booUMchVvxlJrpwQuqUbPY8yil-jS4HkmXeusmnuuopTEl6K-LSJG1-uufu0mB2DKXFcECWxHpdTGv-nc15sKy_1fkwjlm7nSg/s2481/GoF%20-%20XP%20Levers%20v01.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2481" height="283" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgdNUw3Ox2wfA79WemtdAWXCvSnI2I7ZpMCaQGIZ3SyV7RPfiU5t4E60eo_kiji3Y9ytsllp8aQwBpqk4yOFFA9booUMchVvxlJrpwQuqUbPY8yil-jS4HkmXeusmnuuopTEl6K-LSJG1-uufu0mB2DKXFcECWxHpdTGv-nc15sKy_1fkwjlm7nSg/w400-h283/GoF%20-%20XP%20Levers%20v01.jpg" width="400" /></a></div><p>In the First edition of <i>Extreme Programming Explained</i>, Kent Beck described four high level project controls, and how to use them. The controls were Scope, Duration, Cost, and Quality.</p><p>An interesting difference from the Iron Triangle, is that while the triangle regards quality as the result of managing Scope, Duration, and Cost correctly, Beck regarded Quality as a very powerful control lever in its own right.</p><p>According to Beck, the Quality lever should almost always be pushed up! Higher quality, from a software developer’s perspective, means fewer defects, and code that is decoupled, well written, and easy to work with. The higher the code quality, the faster you can deliver features, and the more fun it is to work with the code. Of course, delivering features faster does bring Cost and Duration down.</p><p>It is worth noting that while none of the control levers ensure that delivered features have Business Value, this is handled by the User Story prioritization system that is also part of Extreme Programming. Thus, unlike the Iron Triangle, the XP four lever system is explicitly designed to support a system for maximizing Business Value.</p><p>An important idea was that the customer could pick three of the control levers, while the XP team would control the fourth. Since duration and cost were usually more or less fixed, and giving the team control over quality meant they would have the right to deliver hopelessly buggy software, customers usually took control of Duration, Cost, and Quality, and left Scope for the team.</p><p>In the second edition of <i>Extreme Programming Explained</i>, Kent Beck and his co-writer Cynthia Andres, did away with the entire system, declared explicitly that Quality is not a control variable, and gave the XP team control of the Scope, as the one and only control variable. Features are still prioritized according to value, so there is a method for delivering Business Value in the second edition too.</p><p>Unfortunately, while the first edition of <i>Extreme Programming Explained</i> was very well structured, and provided clear, easy to use advice, the much expanded second edition looks like it was written by a raccoon on speed. The descriptions are fuzzy, it’s incoherent, there is no longer a sense that the pieces fit together in a well designed <i>system </i>for producing software.</p><p>Summing up, the Four Lever system has two advantages over the Iron Triangle system:</p><p></p><ul style="text-align: left;"><li>It explicitly supports, and is subordinate to, a prioritization system designed to maximize Business Value per time unit.</li><li>It makes explicit that Quality does not just happen. It is a control lever that can be moved by practices such as Pair-Programming, Test-Driven Design, and Continuous Integration. It is also made very clear that Quality should be pushed up, in order to reduce Duration and Cost.</li></ul><p></p><p>The main disadvantages are:</p><p></p><ul style="text-align: left;"><li>There is some risk of abuse. For example, a customer can grab the Scope lever, and use it to overload the project team.</li><li>The original description of the model is in the 1st edition of <i>Extreme Programming Explained</i>, which is out of print. If you want to use the model, you will have to rely on secondary sources, like the <i>Extreme Programming Pocket Guide</i>, by Chromatic, which describe the original version of Extreme Programming.</li></ul><p></p><h1 style="text-align: left;">Coming up: Levers that Work!</h1><p>If you have followed this article series from the start, you may have noticed that none of the different sets of levers I have described is really good. They are not necessarily incredibly bad, but none of them is what I would pick if I had to run a large, multi-team project or program.</p><p>Which levers would I choose, and why? That will be revealed in <i>Part Four: Levers that Work!</i></p><div><br /></div>Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0Gothenburg, Sweden57.70887 11.9745629.398636163821152 -23.18169 86.019103836178843 47.13081tag:blogger.com,1999:blog-20843954.post-25483238990982020732023-01-14T00:13:00.002+01:002023-08-09T16:40:44.595+02:00Are You Still Using the Wrong Control Levers in your Agile projects? Part 2: Business Value, it's Use and Abuse<p class="p5"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgpNwhvTVkqPeRB7hKDRPGnW6hoxL0h79hkUafaYAXf4sHH1wY0WRgU_X1yGrVQnlVsd8bYPhE3TjMO-ZsYlJ3nZ9TnG3PZqM9aGAXMn2qSGZtL4r7e_pXGP8Vhgnmzu0C60-umtzDUcqLPxqT4-KEElS0CPW4zHKHgickZsxAYBDmjtKHtwMY" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1749" data-original-width="2482" height="281" src="https://blogger.googleusercontent.com/img/a/AVvXsEgpNwhvTVkqPeRB7hKDRPGnW6hoxL0h79hkUafaYAXf4sHH1wY0WRgU_X1yGrVQnlVsd8bYPhE3TjMO-ZsYlJ3nZ9TnG3PZqM9aGAXMn2qSGZtL4r7e_pXGP8Vhgnmzu0C60-umtzDUcqLPxqT4-KEElS0CPW4zHKHgickZsxAYBDmjtKHtwMY=w400-h281" width="400" /></a></div><p></p><p class="p4">In the <a href="https://kallokain.blogspot.com/2023/01/are-you-still-using-wrong-control.html">first part</a> of this article series, I wrote about how using Cost and Capacity to control an agile software project can trap an organization in a hire and fire cycle that increases project duration and cost.</p>
<p class="p4">This time, we will take a closer look at an agile control lever that works very well, except when it doesn’t: <em><span class="s3">Business Value</span></em>.</p><p></p>
<p class="p4">When used right, the Business Value lever can be the most powerful tool you have to steer an agile project or program towards success. When used wrong, and it often is, the Business Value lever can be completely disabled, leaving management to pull a lever that no longer works, and no longer has the ability to steer the project.</p>
<h2 class="scr1"><strong><span class="s4">How to Deliver Business Value the Agile Way</span></strong></h2>
<p class="p6"></p><blockquote>Deliver working software frequently, from a<br />couple of weeks to a couple of months, with a<br />preference to the shorter timescale.<br />— Principles behind the Agile Manifesto, <a href="https://agilemanifesto.org/principles.html">https://agilemanifesto.org/principles.html</a></blockquote><a href="https://agilemanifesto.org/principles.html"></a> <p></p>
<p class="p4">Let’s start by looking at how the Business Value lever is supposed to work:</p>
<p class="p4">Most of the original agile methods, often called <em><span class="s3">lightweight methods</span></em>, were designed for small systems development. There was usually a single team, and that team built something that could be sliced up in many small deliveries that had value to a customer. For example, a website, or a payroll system, can be built <span class="Scrivener-converted-space"> </span>and delivered with minimal functionality. After that, new functionality can be delivered in small increments at relatively short intervals.</p>
<p class="p5"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjZ4-HyxqjLQcmRUCY3ZU7j_zY7qU9YtBv2RY91D4AZpcU1MeOGE-K6q323T7tGA_rSbqm3yyFwUSiaQutdmY9pY4avCFNhBVv-6ve8xasXSZLdaMSWD5sZSdzmPqcSOO-p8dqi5KX-JEdQOy9JuA5aVm7zzxVq5nDqcp6n1JgWbBWkjw3RAso" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1114" data-original-width="2481" height="288" src="https://blogger.googleusercontent.com/img/a/AVvXsEjZ4-HyxqjLQcmRUCY3ZU7j_zY7qU9YtBv2RY91D4AZpcU1MeOGE-K6q323T7tGA_rSbqm3yyFwUSiaQutdmY9pY4avCFNhBVv-6ve8xasXSZLdaMSWD5sZSdzmPqcSOO-p8dqi5KX-JEdQOy9JuA5aVm7zzxVq5nDqcp6n1JgWbBWkjw3RAso=w640-h288" width="640" /></a></div><em><span class="s3">The illustration shows how many small, fast deliveries begin to generate business value early, giving agile projects a head start on waterfall projects. In small systems development, small deliveries are deliveries to end users.</span></em><p></p>
<p class="p5">In order to deliver in small increments, you need a way of slicing up the application you are building. Thus, the <em><span class="s3">User Story</span></em> was born! A User Story is a short, non-technical description of something a user wants to do, written from the user’s perspective. The User Story was not the only way, nor the first, to describe <em><span class="s3">vertical slices</span></em>, little pieces of functionality that worked end-to-end, but it became the most popular.</p>
<p class="p5"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEh0SnE4F9t7EyL5LFNsItAewppfW0VzV8EcVd01gIkzgEsnU6E4RG9eums20uzDRc8xiqo5Qhctt5iuiroKlrT2y_ruWbDARIbxogIkFohg4rk3uD6PBXuJXiEHWh3xS37Nd9hQYcCgS_2EVE6ouanZZPusbkupq38sgRCOpO5HP7GxBA-N79M" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="780" data-original-width="2481" height="202" src="https://blogger.googleusercontent.com/img/a/AVvXsEh0SnE4F9t7EyL5LFNsItAewppfW0VzV8EcVd01gIkzgEsnU6E4RG9eums20uzDRc8xiqo5Qhctt5iuiroKlrT2y_ruWbDARIbxogIkFohg4rk3uD6PBXuJXiEHWh3xS37Nd9hQYcCgS_2EVE6ouanZZPusbkupq38sgRCOpO5HP7GxBA-N79M=w640-h202" width="640" /></a></div>Originally, User Stories were written on index cards, by an end user, in a freeform format. That worked very well. Some User Stories had a lot of value to end users, others had less. What you did to maximize business value was to sort the index cards from most valuable to least valuable, and start working from the top of the stack of cards.<p></p>
<p class="p5"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhp1Q_Hwd0boh5USklsT0EMO_QEiDG4FSxxpXlUi_dPG10lIhkYSOS1nEOz6gLpE7Q_dxN9DfHfzHHP2IvOTOqng9xZCOb1az1pdNHYixl4XJPOnEc78WrpAsGecoIkNKg9PShF08eUavn0swxp8jShLgICYZsvtfbOXsrP3Ry6QaGku-Ob7J8" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1749" data-original-width="2481" height="452" src="https://blogger.googleusercontent.com/img/a/AVvXsEhp1Q_Hwd0boh5USklsT0EMO_QEiDG4FSxxpXlUi_dPG10lIhkYSOS1nEOz6gLpE7Q_dxN9DfHfzHHP2IvOTOqng9xZCOb1az1pdNHYixl4XJPOnEc78WrpAsGecoIkNKg9PShF08eUavn0swxp8jShLgICYZsvtfbOXsrP3Ry6QaGku-Ob7J8=w640-h452" width="640" /></a></div>User Stories provided an alternative to Critical Path for organizing the work. If you read the first article in this series, you may remember that the Critical Path is defined as the longest stretch of dependent activities in a project. Critical Path made it possible, when it worked, to minimize the total duration and cost of a project. User Stories, and vertical slicing, made it possible to deliver value much sooner.<p></p>
<p class="p4">With Critical Path and Waterfall methods, if you had a twelve month project, you would not see any business value from the project until after 12 months. With an agile method, you would get something of value after one or two months, and then, with each delivery, the business value would increase.</p>
<p class="p4">Getting business value sooner meant making money sooner. If you have ever played around with a Profit & Loss statement, you know that shipping working software just a little bit faster can have enormous impact on the total business value over the product life cycle.</p>
<p class="p4">Critical Path became obsolete, replaced by User Stories, and the idea of shipping a minimal product as quickly as possible, followed by incremental increases in functionality.</p>
<h2 class="scr1"><strong><span class="s4">The Decline and Fall of the User Story</span></strong></h2>
<p class="p6"></p><blockquote>…user stories are based on real customers who will use the product once it’s released. As such, the Product Owner may choose to talk to potential customers in order to get a feel for what they want. There could be focus group discussions, interviews and any other kind of research needed in order to gain the intelligence needed to create a viable user story.<br />— Cohn, Jeff. Scrum Fundamentals: A Beginner’s Guide to Mastery of The Scrum Project Management Methodology </blockquote><p></p>
<p class="p4">In the beginning User Stories worked very well, but then something happened: Scrum became the dominant agile method! Scrum did away with the idea that an end user should write the User Stories, and inserted an intermediary, the <em><span class="s3">Product Owner</span></em>.</p>
<p class="p4">Note the phrase “the Product Owner <em><span class="s3">may</span></em> choose to talk to potential customers” in the quote above. The Product Owner should talk to end users, but isn’t required to. In many large organizations, it’s difficult for a Product Owner to even find an end user.</p>
<p class="p5"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEh6N38fJ04YpiKtr23AUli1iDBKTJ4Vzli6tZ97CYZi-YtticgpxxGgnXlId-kwpkRtqDSU996X-R8YgKthOh2Y8ukRxRhCcyQ8F0p5_fIdN5r0NJn8RmBSpX5yXVdjIvLWyOuDhncP8SnphLhNcae0ZHhtKiF3WjCOLCe05CNEvK3MupEby48" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1277" data-original-width="2481" height="330" src="https://blogger.googleusercontent.com/img/a/AVvXsEh6N38fJ04YpiKtr23AUli1iDBKTJ4Vzli6tZ97CYZi-YtticgpxxGgnXlId-kwpkRtqDSU996X-R8YgKthOh2Y8ukRxRhCcyQ8F0p5_fIdN5r0NJn8RmBSpX5yXVdjIvLWyOuDhncP8SnphLhNcae0ZHhtKiF3WjCOLCe05CNEvK3MupEby48=w640-h330" width="640" /></a></div><em><span class="s3">The illustration shows the difference between Scrum and most other agile methods when gathering requirements. Even in the best case, Scrum inserts an extra degree of separation.</span></em><p></p>
<p class="p4">With most original agile methods, like eXtreme Programming (Kent Beck), Crystal (Alistair Cockburn), and Lean Software Development (Mary and Tom Poppendieck), it was explicit that the organization would have to change in order to support agile teams. One such change would be tearing down organizational barriers, so the development team could meet and talk to users directly.</p>
<p class="p5"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgMHzWCRNUmAjc-rAz3ATIcpTcdkHCVpQ5izl7LNE1St932bOq_6UW9L91lsyrI77JQr98QYpY8Ugf230kL8DK4YbMOI4xBqp1TC7kX5eb-jGARDl412TmWJytqbNyoSLd00FDLeYT4fHUXztutvS7jaLop-5e4fLU2IzpjaIjupyH2TQpUj64" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1749" data-original-width="2481" height="452" src="https://blogger.googleusercontent.com/img/a/AVvXsEgMHzWCRNUmAjc-rAz3ATIcpTcdkHCVpQ5izl7LNE1St932bOq_6UW9L91lsyrI77JQr98QYpY8Ugf230kL8DK4YbMOI4xBqp1TC7kX5eb-jGARDl412TmWJytqbNyoSLd00FDLeYT4fHUXztutvS7jaLop-5e4fLU2IzpjaIjupyH2TQpUj64=w640-h452" width="640" /></a></div><em><span class="s3">The illustration shows the Crystal approach: An expert user, a business expert, and a designer/developer collaborate creating lightweight use cases. The designer/developer is part of the development team. This maintains a single degree of separation, while adding a broad business perspective, a deep understanding of what users do, and how they work, while also capturing more initial information and being scalable to larger, multi-team projects.</span></em><p></p>
<p class="p4">It is worth noting that some agile methods, notably Crystal, took a more scalable approach to requirements management. Crystal used lightweight use cases instead of user stories. Use cases also represent vertical slices of functionality. However, they capture a lot more information than user stories, while still being reasonably quick and easy to create. The use cases were created by a troika, an <em><span class="s3">expert user</span></em>, a <em><span class="s3">business expert</span></em>, and a <em><span class="s3">designer/developer</span></em>. Crystal was explicit about the high degree of expertise needed to create good requirements.</p>
<p class="p4">Scrum took a different path. Instead of changing the organization, Scrum inserted the Product Owner as an intermediary, isolating the development team from the organization around it. This was attractive to management in many organizations, because they did not have to change how they worked. Instead, the team could be treated more or less like a black box. </p>
<p class="p4">Isolating development teams from users came at a cost:</p>
<p class="p8" style="text-align: center;">Loss of information!</p>
<p class="p4">In some organizations, the Product Owner works in close contact with the users. In those organizations, inserting an extra degree of separation might not matter much. In other organizations, where there is less contact between Product Owner and end users, the information loss may be substantial, and significantly reduce business value.</p>
<p class="p4">Note that User Stories are not complete requirements. Originally, they were intended as placeholders for conversations between developers and end users. With Scrum, developers will have those conversations with the Product Owner instead. For this to work well, the Product Owner must have both deep and broad knowledge of <em><span class="s3">the end user’s area of expertise</span></em>! However, the <a href="https://scrumguides.org/download.html">Official Scrum Guide</a> does not require Product Owners to have any such expertise. Instead, Scrum focused on accountability:</p>
<p class="p6"></p><blockquote>The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.<br />— The Scrum Guide, p. 5, <a href="https://scrumguides.org/download.html">https://scrumguides.org/download.html</a></blockquote><a href="https://scrumguides.org/download.html"></a><p></p>
<p class="p4">The Scrum Guide goes into more detail about the areas of accountability, but is silent on the corresponding skills needed to do the job well. This focus on areas of accountability in lieu of skills is not limited to the Product Owner role. All other roles in Scrum are defined the same way.</p>
<p class="p4">Eliminating skill requirements contributed to making Scrum an easy sell. Unfortunately, the lack of skill requirements lead to an overall reduction in skill levels for all Scrum roles, compared to other agile methods.</p>
<p class="p6"></p><blockquote>Why would user stories being vertically sliced matter?<br />— Agile Way of Working responsible in a major SAFe program</blockquote><p></p>
<p class="p4">Many, perhaps most, Product Owners did not get much training in capturing requirements. Nor did they learn why vertical slicing was important. At the same time, they had to do a difficult job. Instead of an end user writing a story, a Product Owner had to <em><span class="s3">imagine</span></em> what an end user would write, and then write that. To make it worse, the Product Owner often had to do it without expertise in the subject matter, and without expertise in the relevant business processes. The Product Owner job became very difficult indeed, and that could not help but reduce the quality of User Stories.</p>
<p class="p5"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjMmJbjg9qnEkuxsIUOPo4CDt1jp2tazI9HF8lelJsZT-2RKW3CzT526uzbHKVj0S8Rehkp41qeCeSVT01oK9Au0VEdOSs3CB6AtODd2UkYSPtl5HQgp3WVUUP7COZopKDuyZhqVPxVE0WfzWJnCA0UpcnhQkvDyqExfVD5MaCm8khwtBOFyRo" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1749" data-original-width="2481" height="452" src="https://blogger.googleusercontent.com/img/a/AVvXsEjMmJbjg9qnEkuxsIUOPo4CDt1jp2tazI9HF8lelJsZT-2RKW3CzT526uzbHKVj0S8Rehkp41qeCeSVT01oK9Au0VEdOSs3CB6AtODd2UkYSPtl5HQgp3WVUUP7COZopKDuyZhqVPxVE0WfzWJnCA0UpcnhQkvDyqExfVD5MaCm8khwtBOFyRo=w640-h452" width="640" /></a></div>What happened was <span class="Scrivener-converted-space"> </span>that Product Owners in many companies wrote task descriptions instead, because that was what they knew how to do. They still called them stories though.<p></p>
<p class="p4">The problem with this is that we do not have anything that structures the tasks into vertical slices of functionality anymore. Product Owners were supposed to organize the work order from the item with the highest business value to the item with the lowest, but <em><span class="s3">tasks don’t have business value</span></em>!</p>
<p class="p4">Business value is an emergent property of a vertical slice of functionality, or a set of vertical slices of functionality! That rarely stopped anyone from trying to do the impossible though. I have occasionally met Product Owners, and other people, who suspect that something fishy is going on with how we write requirements, but they are few and far between.</p>
<p class="p4">So, why does it matter whether a team uses User Stories or tasks?</p>
<p class="p5"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgCrN5HzGsNgmQAquVWEVPLeatUba7PSHQ1gOXzFIbx6EkA45WKVg28jutNXd3C_kl9XBjufpZE-xROytyKpY085uC--NVhrvvxF1EvwGLqvnhkKMrUuiGt-kkFxKGD_Y_U-h3fDqPnvVeuxazbnDxbdr3oe41r4XfGCSMTYw3lHXE22s5DuYk" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1591" data-original-width="2482" height="410" src="https://blogger.googleusercontent.com/img/a/AVvXsEgCrN5HzGsNgmQAquVWEVPLeatUba7PSHQ1gOXzFIbx6EkA45WKVg28jutNXd3C_kl9XBjufpZE-xROytyKpY085uC--NVhrvvxF1EvwGLqvnhkKMrUuiGt-kkFxKGD_Y_U-h3fDqPnvVeuxazbnDxbdr3oe41r4XfGCSMTYw3lHXE22s5DuYk=w640-h410" width="640" /></a></div>It matters, because when the teams work with tasks, they do not usually complete all tasks in a vertical slice in one go. They may work on a front end task, and then move on to another front end task, or work on a business rule, and then move on to another business rule, without connecting anything end-to-end.<p></p>
<p class="p5"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjwwkA3FvQWPgTaalOitRl89CYXAHMI5-bHtgn_2uXIPIlkB71jscmDhWNW-OeZ8m7ILeZ_ozTkcX4Gyjvultr2bkmK0JE3lJTCiI4ljHnBHt2HTL42nPhLsLUrBHDrC1oCbT069TuYOntPZTw1AIV_DB9kSbQFPJpqbaVsGzeS_2bkVO-9UwU" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="537" data-original-width="2482" height="138" src="https://blogger.googleusercontent.com/img/a/AVvXsEjwwkA3FvQWPgTaalOitRl89CYXAHMI5-bHtgn_2uXIPIlkB71jscmDhWNW-OeZ8m7ILeZ_ozTkcX4Gyjvultr2bkmK0JE3lJTCiI4ljHnBHt2HTL42nPhLsLUrBHDrC1oCbT069TuYOntPZTw1AIV_DB9kSbQFPJpqbaVsGzeS_2bkVO-9UwU=w640-h138" width="640" /></a></div>We have now <em><span class="s3">disabled the Business Value control lever</span></em>!<p></p>
<p class="p4">Whenever I see this phenomenon, teams still do deliveries, and still do demos. It’s just that they do internal deliveries, and the demos are Powerpoint presentations, or demos of some internal function of interest only to developers. End users cannot use the software in the internal delivery. End users are never invited to these demos.</p>
<p class="p4">Companies that do this can be even worse off than they were before agile, because they first got rid of the Critical Path based project management they had before, and then disabled the vertical slicing which was supposed to replace Critical Path management.</p>
<p class="p6"></p><blockquote>Yeah. And don't try to tell us there is no way to go but up because the truth is, there is always more down.<br />— Gunn, in the Angel TV-series episode Happy Anniversary</blockquote><p></p>
<p class="p4">Confusing user stories with tasks causes big enough problems when doing small systems development. What happens when you scale up to large projects with many teams?</p>
<p class="p5"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgi-dR1F7hE6QQk4k2NREekTJ4wmcH0B8i1v0HtCwn5F9FyBMIrP_mtsS4yohMCRRUhoxCnTTzrWjwznE7vwUuN0d3_pPUv-UmvHiYVsh-Q7V2ZKwS3AXcvxForOx9rXbST35PJ3UrFxjig8Atv96r2WA9WSBZ77JTMp0lW0UQ9yE5OC3WCSZ8" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1659" data-original-width="2482" height="428" src="https://blogger.googleusercontent.com/img/a/AVvXsEgi-dR1F7hE6QQk4k2NREekTJ4wmcH0B8i1v0HtCwn5F9FyBMIrP_mtsS4yohMCRRUhoxCnTTzrWjwznE7vwUuN0d3_pPUv-UmvHiYVsh-Q7V2ZKwS3AXcvxForOx9rXbST35PJ3UrFxjig8Atv96r2WA9WSBZ77JTMp0lW0UQ9yE5OC3WCSZ8=w640-h428" width="640" /></a></div>When we scale up, and teams become responsible for functional units in the system architecture, they also become dependent on each other. The teams have the same dependencies the system architecture has.<p></p>
<p class="p4"><em><span class="s3">If</span></em> front facing teams worked with real User Stories, <em><span class="s3">then</span></em> we could break those stories down into tasks that supporting teams worked on, and continue producing vertical slices of software.</p>
<p class="p4">We <em><span class="s3">could</span></em> also design the system architecture so that each team can handle a vertical slice of functionality.</p>
<p class="p4">In most cases, we would have to balance the two approaches.</p>
<p class="p4">What I have seen happening though, is that everyone keeps working on tasks. Architectural dependencies are not resolved. Team topology is ignored. Work consequently slows down, a lot!</p>
<p class="p4">I worked in one large project some years ago where deliveries were slowed down by a factor of 50! In other words, what should have been a two week user story took two years to implement instead.</p>
<p class="p4">Most other projects I have seen have had similar problems.</p>
<h2 class="scr1">Mirror, Mirror on the Wall, Tell Me Which is the Most Fake User Story of Them All</h2>
<p class="p4">As far as I know, no method has done more to confuse the issue of user stories versus tasks than the Scaled Agile Framework (SAFe).</p>
<p class="p4">SAFe has a <a href="https://www.scaledagileframework.com/safe-requirements-model/">requirements model</a> with two kinds of <a href="https://www.scaledagileframework.com/story/">stories</a>: User Stories, and enabler stories.</p>
<p class="p4"><em><span class="s3">User stories</span></em> are, according to SAFe, vertical slices of functionality, but SAFe does not mention why that is important, or what happens to SAFe’s own requirements prioritization system if they are not. Then SAFe tops it off by introducing <em><span class="s3">enabler stories</span></em>, which are a kind of tasks.</p>
<p class="p4">Hierarchically, both user stories and enabler stories are the children of <a title="https://www.scaledagileframework.com/features-and-capabilities/"></a><a href="https://www.scaledagileframework.com/features-and-capabilities/">features</a>. There are two kinds of features, business features, which are vertical slices of functionality, and enabler features which are a kind of tasks created by architects. Both kinds of features may contain either kind of story.</p>
<p class="p4">Moving up the hierarchy to <em><span class="s3">business capabilities</span></em> and <em><span class="s3">enabler capabilities</span></em>, both of them may contain both business and enabler features.</p>
<p class="p4">The top level is the <a title="https://www.scaledagileframework.com/epic/"></a><a href="https://www.scaledagileframework.com/epic/">epic</a>. There are three main types, <em><span class="s3">portfolio epic</span></em>, <em><span class="s3">solution epic</span></em>, and <em><span class="s3">program epic</span></em>. Any type of epic may be of one of two subtypes, <em><span class="s3">business epic</span></em> and <em><span class="s3">enabler epic</span></em>, which gives you a total of six different kinds of epic.</p>
<p class="p4">Any kind of epic may contain any kind of capability, and any kind of feature. Any of these work items may be standalone. You may, for example, have enabler stories and enabler features who are standalone and not connected to anything that has any business value.</p>
<p class="p4"> It’s a mess! I don’t think anyone has a grip on it. I may be wrong, but I haven’t met anyone who has figured it out yet.</p>
<h2 class="scr1"><strong><span class="s4">What’s Bad for the Geese, May Be Good for the Gander</span></strong></h2>
<p class="p4">All of the confusion about agile requirements is bad for the industry as a whole, but it is actually an opportunity for those who manage to fix their user stories. When user stories describe vertical slices of functionality, the Business Value lever starts working, and that means the basic mechanism for making small, fast deliveries is working.</p>
<p class="p4">That, in turn, makes it possible to use other control levers more effectively.</p>
<p class="p4">Next: <em><span class="s3"><a href="http://kallokain.blogspot.com/2023/08/are-you-still-using-wrong-control.html">Part 3: The Iron Triangle vs. The Gang of Four</a></span></em>.</p>
Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-41293657112823282932023-01-09T17:15:00.001+01:002023-01-14T00:20:23.524+01:00Are You Still Using the Wrong Control Levers in your Agile projects? Part One: Cost and Capacity - The Levers of Death
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZWS7kP8ZnuGsb5NZppi8KtAUbG5yZaPr5p2sPhmYRa_VgDor3EJP36Zc88nlkSt4TV-SaStl2aFrBpIN9OKo4JyUNVGDlU9Y5xgm7Hg5tm06nzFHpnBzF2XvA8b48eZtgzBkM73NPpFXnPnPQ2gA32GsUiFvbr0j4UPtMMMFF0TII0v4t3EI/s4217/All%20Control%20Levers.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="4217" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZWS7kP8ZnuGsb5NZppi8KtAUbG5yZaPr5p2sPhmYRa_VgDor3EJP36Zc88nlkSt4TV-SaStl2aFrBpIN9OKo4JyUNVGDlU9Y5xgm7Hg5tm06nzFHpnBzF2XvA8b48eZtgzBkM73NPpFXnPnPQ2gA32GsUiFvbr0j4UPtMMMFF0TII0v4t3EI/w640-h266/All%20Control%20Levers.jpg" width="640" /></a></div><p class="p5"><em><span class="s3">Which levers should you use? When should you use them? Which levers should you avoid using? There is a subtle hint in the illustration.</span></em></p>
<p class="p4">Agile methods brought us new ways of developing software, and new ways of managing software projects, programs, and product development. Unfortunately, I have seen very few, if any, organizations that make good use of the powerful new management tools they have at their disposal. Instead, they continue to use the same tools they used before agile, often with predictably bad results.</p>
<p class="p4">In this series of articles I’ll provide a walk through of high level controls, their pros, cons, and how they relate to each other.</p>
<h1 class="scr1"><strong><span class="s4">The Levers of Death: Capacity and Cost</span></strong></h1>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhElk7NFpgZ6tLUKsFaOtjoYP_KHfIr5jvHjCPXsbRvkiM7BtBPoXIm9Zv95rQRdmUdn3A6_CEKIemPQrqDKOGOGUUTLWI_K2kvzYGK9awbx8NxI0-ucQLdw6qLzXYxFkyuzvbyuFbExgkJwMtC3x2YATpBheDkJDDvHDvfhFPgHGstJIomxe8/s2482/Capacirty%20and%20Cost.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2482" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhElk7NFpgZ6tLUKsFaOtjoYP_KHfIr5jvHjCPXsbRvkiM7BtBPoXIm9Zv95rQRdmUdn3A6_CEKIemPQrqDKOGOGUUTLWI_K2kvzYGK9awbx8NxI0-ucQLdw6qLzXYxFkyuzvbyuFbExgkJwMtC3x2YATpBheDkJDDvHDvfhFPgHGstJIomxe8/w320-h225/Capacirty%20and%20Cost.jpg" width="320" /></a></div><p class="p5">Let’s start with the Levers of Death, <em><span class="s3">Capacity</span></em> and <em><span class="s3">Cost</span></em>. These levers are the ones I see used most often. They are not necessarily bad in and of themselves (well, firing people <em><span class="s3">is</span></em> bad), but they are easy to misuse, and often poorly understood.</p>
<p class="p4">In most organizations I have worked in, it is assumed Capacity and Cost controls are rather straightforward:</p>
<p class="p4"><em><span class="s3">Capacity</span></em> - Increase capacity, i.e. hire more people, when you want a project to speed up. This of course also increases cost.</p>
<p class="p4"><em><span class="s3">Cost</span></em> - Cut Cost, i.e. fire people, when the project gets to expensive. What is too expensive or not, is usually measured against a predetermined budget. Usually a yearly budget. Cutting cost is expected to reduce capacity, but the implications of that are often quietly ignored, because, what else can you do, right?</p>
<p class="p4">As we will see, the problems with the hiring and firing approach outweigh the benefits. Fortunately, there are better alternatives, controls that both provide more effective economic control, and are more humane. I’ll explore both bad and good control levers in this article series, but we will start with two baddies: Cost and Capacity.</p>
<h2 class="scr2"><strong><span class="s5">Problem 1: Vital Information is Missing</span></strong></h2>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEieQ2usTLOo5wciT_Awdm1tpnYq9-2I-59EklseVV83c3wHc9pxX_g41LfEBLz5adOBLNn-o4D8xyeCs4enZrzduYsOKuwKm9lQyJYqodRTKRQAF_2KQUX5YoOHDUcc560jJwhD4fPlVCELO5TKbUNbNGVLZ1IfPLjXF3BXtx-M7n5t4nhDdY4/s2482/Critical%20Path.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2482" height="450" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEieQ2usTLOo5wciT_Awdm1tpnYq9-2I-59EklseVV83c3wHc9pxX_g41LfEBLz5adOBLNn-o4D8xyeCs4enZrzduYsOKuwKm9lQyJYqodRTKRQAF_2KQUX5YoOHDUcc560jJwhD4fPlVCELO5TKbUNbNGVLZ1IfPLjXF3BXtx-M7n5t4nhDdY4/w640-h450/Critical%20Path.jpg" width="640" /></a></div><p class="p5"></p><blockquote><p class="p5">The critical path (or paths) is the longest path (in time) from Start to Finish; it indicates the minimum time necessary to complete the entire project.</p>
<p class="p7">— The ABCs of the Critical Path Method, by F. K. Levy, G. L. Thompson, and J. D. Wiest, Harvard Business Journal, September 1963</p></blockquote><p class="p7"></p>
<p class="p4">When agile methods became popular, they were intended to <em><span class="s3">replace</span></em> older methods of management. That lead to chucking older practices overboard, because they were not needed anymore. Unfortunately, the capacity and cost levers were supposed to be, if not chucked overboard altogether, at least relegated to third rate status, but managers in many companies held on to them as primary project controls.</p>
<p class="p4">To make it worse, when organizations use them now, they do it without benefit of information they had 25 years ago. The reason is that some of the decision support needed to use Capacity and Cost effectively, actually was chucked overboard.</p>
<p class="p4">One such missing piece of information is the Critical Path. The critical path is the longest path, in time, from start to finish in a project. The critical path is extremely important in old style waterfall projects, because it determines the duration of the entire project.</p>
<p class="p4">If you know the critical path, then you also know that along the critical path you have a capacity bottleneck. </p>
<p class="p4">When you wanted to add capacity, the trick was to locate the capacity bottleneck, and add capacity there, and nowhere else. This will sound very familiar to anyone who uses the <em><span class="s3">Theory of Constraints</span></em> (TOC) management paradigm, and the TOC project management method, <em><span class="s3">Critical Chain</span></em>.</p>
<p class="p4">Conversely, if you wanted to reduce cost, you made very sure to reduce it in places that were <em><span class="s3">not</span></em> the bottleneck, and preferably not on the critical path.</p>
<h2 class="scr3"><strong><span class="s6">“Dr. Livingstone, I presume?”</span></strong></h2>
<p class="p4">Before we look closer at why we need to know the critical path and the project bottleneck before we should even think about hiring and firing, we need to look at a problem the critical path idea was not designed to handle:</p>
<p class="p7">In projects with a lot of variation, like software, and product, development, the critical path, and the main bottleneck moves around, a lot!</p>
<p class="p4">The reason for the critical path and the project bottleneck moving around, is simple: Random variation!</p>
<p class="p4">When you build something new, which is what software development is all about, you do not have well defined lists of activities. Instead, you are doing exploratory work, with very limited ability to predict the future. To make it worse, the more detailed your predictions, the more wrong they will be.</p>
<p class="p4">Imagine, for a moment, that you are Henry Livingstone, on March 21, 1871. It’s the first day of your attempt to find the explorer David Livingstone, who had vanished in central Africa, several years later. You have prepared carefully for the rescue expedition, but it would be folly to make a predetermined plan of exactly where to go to find Stanley, and exactly how long it will take.</p>
<p class="p4">Livingstone’s expedition faced enormous dangers, or impediments, as Livingstone would have called them if he had been a Scrummaster: Crocodiles ate the pack animals, tse-tse flies gave them deadly diseases. Dozens of porters abandoned the expeditions, or died from dysentery, smallpox, malaria, and other diseases. Livingstone had been spotted near Lake Tanganyika, so Stanley had a general idea of where to go, but he had to pick up more along the way. He heard a rumor about a white man in the town Ujiji, and went there, not knowing whether he would find Livingstone, or not. By luck, he did!</p>
<p class="p4">Software development is like that. You can’t make detailed plans and schedules, but you can prepare.</p>
<p class="p4">Unfortunately, the whole critical-path-and-bottleneck idea requires that you can plan and schedule with a great deal of accuracy. If you can’t plan in detail, you can’t identify the critical path. If you can’t identify the critical path, it’s difficult to identify the bottleneck in the process. If the bottleneck, and the critical path, keeps moving around, a good decision about where to hire and fire today, will become a bad decision tomorrow.</p>
<p class="p4">There are things you can do to mitigate the problems with critical path, but I’ll leave that for another article series. In the more than 40 years I have worked in software development, I have yet to see a software project implement anything close to a useful solution.</p>
<p class="p4">Today, when companies have scrapped the whole idea of critical path management, fixing the problems with it, is of little relevance.</p>
<p class="p4">Instead, we will look at what happens when an organization uses the Capacity and Cost levers without knowing what the critical path and the project bottleneck is.</p>
<h2 class="scr2"><strong><span class="s5">Problem 2: Adding Capacity Adds Work-In-Process</span></strong></h2>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhA6JutjaY_VNkkzemV8g7O0DkUGg7OHLXz40Sl7cx_gNx7N2RgiYyEVKmpcXQZcJ380FDVdZ4RUuC_-AgCjxAs96O6Ltx2xkA9aD_yC077l9yN5QTqj82Q3R6IF02uzcjQMCGQ9oP_9Mp5rpwyZuKuj_8PI4zEYOL-n5zqYfRVH-R_RKRQROQ/s2481/Critical%20Path%20Adding%20Capacity.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2481" height="452" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhA6JutjaY_VNkkzemV8g7O0DkUGg7OHLXz40Sl7cx_gNx7N2RgiYyEVKmpcXQZcJ380FDVdZ4RUuC_-AgCjxAs96O6Ltx2xkA9aD_yC077l9yN5QTqj82Q3R6IF02uzcjQMCGQ9oP_9Mp5rpwyZuKuj_8PI4zEYOL-n5zqYfRVH-R_RKRQROQ/w640-h452/Critical%20Path%20Adding%20Capacity.jpg" width="640" /></a></div><p class="p5">When you do not know where the critical path bottleneck is, and you add more people to a project, you are more likely to add people in other locations than the bottleneck, than to actually hit the bottleneck itself. That means most of the people you add won’t contribute to speeding up the project. Instead, they will add to Work-In-Process (WIP), queues of unfinished work in the process.</p>
<p class="p4">The larger the queues you have, the larger your lead times will be. Unfinished work in queues also add risk, because you won’t know whether the stuff will actually work with all the other stuff you build until you test it end-to-end. There are plenty of techniques for mitigating that risk, but you can’t eliminate it. Besides, most companies I have worked with are rather poor at this kind of risk mitigation.</p>
<p class="p4">Build up enough WIP, and your critical path will shift to the path where most of the added WIP is, which will <em><span class="s3">increase</span></em> project duration.</p>
<p class="p4">Thus, adding people won’t buy you the added capacity you think it will.</p>
<h2 class="scr3"><strong><span class="s6">Communications Overhead</span></strong></h2>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmvUZYS7bYPW6UrgY45o172mYfkeX_jF8HRGCs298GcDjSxzHtPp03qIk-iOGwlkZCEEaiZONU-vJj8QnJ5UxDV9UBZ8_RnjOhmsk2exoDAYr12oWp0rHWlmc7SCoxOz2CbEzL3tG3RhAZaZOmxCPinBtthq8hh1yTxGDy8K6ZNbq9hNrbvWg/s2508/Communications%20Overhead.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="744" data-original-width="2508" height="190" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmvUZYS7bYPW6UrgY45o172mYfkeX_jF8HRGCs298GcDjSxzHtPp03qIk-iOGwlkZCEEaiZONU-vJj8QnJ5UxDV9UBZ8_RnjOhmsk2exoDAYr12oWp0rHWlmc7SCoxOz2CbEzL3tG3RhAZaZOmxCPinBtthq8hh1yTxGDy8K6ZNbq9hNrbvWg/w640-h190/Communications%20Overhead.jpg" width="640" /></a></div><p class="p5"><em><span class="s3">The Illustration shows how adding more nodes to a network, i.e. adding team members to a team, or adding teams to a project, causes quadratic growth in communications overhead.</span></em></p>
<p class="p4">On top of the WIP problem, adding more people will add communications overhead. The communications overhead can start out small for a small project, but it will grow quadratically while you add people linearly. This means when you add more people, productivity per person will go down.</p>
<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p class="p7">I have 30 people in the project. The problem is I need only 5 people.</p><p class="p7">— Project manager, in a project I worked in around 2005</p></blockquote>
<p class="p4">Worst case, you can actually reduce capacity when you add people! I have worked in 200 people projects that could have moved a lot faster if there had been only 20 people in the project.</p>
<p class="p4">The short of it is that adding more people will add cost, that we know for certain, but whether it will actually shorten project duration is a bit hit and miss. The larger your project, the higher the probability it will be a miss.</p>
<h2 class="scr3"><strong><span class="s5">Problem 3: Cutting Cost Reduces Bottleneck Capacity</span></strong></h2>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEieIdDiyRaqQgEEtQUg6agfRwGqZRifdz0Vz4eQ6BtHLBIyhcRJ2Bu2VfhKeziPVm2BeKQFOhWetYTQewKnGIVc86nm-L3tRt1Iv7w5BXfleOE798jI-3oIlLPlbv94yVFs6i3J1QBuzifjpfialTQp_CYp9Gv9vlqSaMQnuWjWTSh-ke5o-vE/s2481/Critical%20Path%20Cutting%20Cost.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2481" height="452" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEieIdDiyRaqQgEEtQUg6agfRwGqZRifdz0Vz4eQ6BtHLBIyhcRJ2Bu2VfhKeziPVm2BeKQFOhWetYTQewKnGIVc86nm-L3tRt1Iv7w5BXfleOE798jI-3oIlLPlbv94yVFs6i3J1QBuzifjpfialTQp_CYp9Gv9vlqSaMQnuWjWTSh-ke5o-vE/w640-h452/Critical%20Path%20Cutting%20Cost.jpg" width="640" /></a></div><p class="p5">When management, often belatedly<a href="#fn1"><sup>[*]</sup></a>, discover that adding people added a lot of cost, but did not shorten project duration as much as they had hoped, or at all, the natural reaction is to cut costs, in order to make the budget targets.</p>
<p class="p4">Unfortunately, if you have 100 people in your project, add 100 more, and then cut 100, you won’t be back where you started. <em><span class="s3">You will be worse off than before</span></em>!</p>
<p class="p4">Why is that? Because we do not know where the bottleneck is, and because the bottleneck often jumps around, it is highly likely that cost cuts affect the bottleneck, either permanently, or intermittently. When that happens, <em><span class="s3">the entire project is delayed</span></em>.</p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPPwRhYFIdypG5bak-pxO_8-_HIfplM8_C3ZaYnd9mg7OgMx441w4ZRddf6udbEi3vS-JZRb5HlfYeXTuzbUGAEzzt3XKzuCW-W8i2S11QbGzAbuHJW66uA2diR75kuQxUB8CGiO8gFjioMZFT5OA7nUyJy_UekL2kd_SY65GYhI7y9zadi0k/s2482/Bottleneck%20-%20Capacity%20Reduction.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1749" data-original-width="2482" height="450" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPPwRhYFIdypG5bak-pxO_8-_HIfplM8_C3ZaYnd9mg7OgMx441w4ZRddf6udbEi3vS-JZRb5HlfYeXTuzbUGAEzzt3XKzuCW-W8i2S11QbGzAbuHJW66uA2diR75kuQxUB8CGiO8gFjioMZFT5OA7nUyJy_UekL2kd_SY65GYhI7y9zadi0k/w640-h450/Bottleneck%20-%20Capacity%20Reduction.jpg" width="640" /></a></div><p class="p5"><em><span class="s3">The illustration shows how reducing capacity at a bottleneck can have much greater effect on duration and cost than expected.</span></em></p>
<p class="p5">Here is an example from a project I worked in:</p>
<p class="p4">Several years ago I was the Scrummaster for a development team where higher level management from time to time pulled one person from the team to work outside the team.</p>
<p class="p4">The team had 7 members, so both the team and management expected the remaining capacity to be 86% (6/7 = 0.857 ≈ 86%). However, this is true only if all team members are full stack developers, and if they all are equally productive.</p>
<p class="p4">The team had 5 developers and 2 testers. The testers were the bottleneck. Unfortunately, the person pulled from the team was one of the testers. That reduced the total team capacity to 50% (1/2 = 0.5 ≈ 50%).</p>
<p class="p4">If that team had been the bottleneck in the entire software development project removing the tester for 1 week would mean adding 1 week to <em><span class="s3">the duration of the entire project</span></em>. That also adds 1 week of cost for the entire project, way more money than management had expected.</p>
<p class="p4">Note that if you have, for example, a large SAFe program, with several Agile Release Trains (ART), and 7-10 teams in each ART, you could double the duration of the project by firing that single tester…unless you figure the problem out and hire a new tester. If you do that, and the critical path and the bottleneck then jumps to somewhere else, then the new hire will just contribute to creating more WIP, and you are back to <em><span class="s3">Problem 2: Adding Capacity Adds Work-In-Process</span></em>.</p>
<p class="p4">The point is that cutting just a few people from a project may have a disproportionate effect on project duration and cost, and <em><span class="s3">you do not know where it is safe to cut cost!</span></em> Sometimes it works, sometimes it makes the situation worse.</p>
<h2 class="scr2"><strong><span class="s5">Problem 5: The Hire and Fire Death Spiral</span></strong></h2>
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXdW2u8TXLrHpkJHUDRMEzAt0RGc_KsACEztQo1vx0hPi8dPB8B8601eO5sTwLRMrRHp3SohBQ_LTGKbAUj5-_OGYkRrbjskPZVjT4TPjEgMGHo-ZKIpMBnLGlsxhSJoLZGE8_SLG523Nbo3ROK_886k93Tqwx2unhNhMoje6WUrs-bYnCgEw/s2482/Hire%20and%20Fire%20Death%20Spiral.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1131" data-original-width="2482" height="292" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXdW2u8TXLrHpkJHUDRMEzAt0RGc_KsACEztQo1vx0hPi8dPB8B8601eO5sTwLRMrRHp3SohBQ_LTGKbAUj5-_OGYkRrbjskPZVjT4TPjEgMGHo-ZKIpMBnLGlsxhSJoLZGE8_SLG523Nbo3ROK_886k93Tqwx2unhNhMoje6WUrs-bYnCgEw/w640-h292/Hire%20and%20Fire%20Death%20Spiral.jpg" width="640" /></a></div><br /><p style="text-align: left;">Using the Capacity and Cost levers can easily drag a software development project into a kind of economic death spiral:</p><p class="p4">It starts with WIP going up due to statistical variation. More WIP means work will have to wait in queues, which means delays, which means cycle times go up for many teams. This means the project is delayed.</p>
<p class="p4">Because of the delays, deadlines are broken. Management tries to fix this by adding more people. This increases communications overhead. It also adds capacity off the critical path, which leads to more WIP accumulating. The net result is that the project does not speed up as much as expected, but it now costs more.</p>
<p class="p4">It is common that management keeps trying to speed the project up by adding even more people. This is less and less effective each time. This is partly because the communications overhead goes up quadratically when people are added. Another part is that the larger the project is, the higher the probability of missing the critical path altogether when adding new people.</p>
<p class="p4">Eventually management will notice that not only does the project not move forwards as expected, it also burns through money at an alarming rate. That is when the cost cuts come. Some of those cost cuts are likely to hit the critical path. When that happens, project duration goes up. Cost per day does go down, but the increased duration means there are many more days, so total cost goes up.</p>
<p class="p4">Cost cuts continue until management notices that we now have even more delays, so management starts hiring more people, and the <em><span class="s3">Hire and Fire</span></em> cycle starts over again.</p>
<p class="p4">The whole thing continues until the project either stumbles over the finishing line, or the organization gives up and pulls the plug on the whole mess.</p>
<p class="p4">Very, very rarely, management stops, decides the whole depressing cycle is daft, and decides to find a better way. When that happens, management often goes for the sweet promise of increased <em><span class="s3">Business Value</span></em>.</p>
<p class="p4">Next: <em><span class="s3"><a href="https://kallokain.blogspot.com/2023/01/are-you-still-using-wrong-control_14.html">Part 2: Business Value, its Use and Abuse</a></span></em>.</p>
<hr />
<p class="p5"><a id="fn1"></a><a href="#fnlink1">[*]</a> Agile methods have a built-in early warning system, <i>monitoring queues</i>. Unfortunately, organizations that rely on the Capacity and Cost levers usually do not use queue monitoring, at least not very well.</p>Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-3204455784062768902021-11-01T14:45:00.000+01:002021-11-01T14:45:13.956+01:00OKRs - not as Great as You Think!<div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-0Xx5uGXEZGQ/YX_mgKdvHDI/AAAAAAAB3Ss/sVzo-emgL08_0RfFzDeW_aBIbAEMncOBACLcBGAsYHQ/s2048/Cracked%2BOKRs%2Bv02.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1093" data-original-width="2048" height="342" src="https://1.bp.blogspot.com/-0Xx5uGXEZGQ/YX_mgKdvHDI/AAAAAAAB3Ss/sVzo-emgL08_0RfFzDeW_aBIbAEMncOBACLcBGAsYHQ/w640-h342/Cracked%2BOKRs%2Bv02.jpg" width="640" /></a></div><br /><p>Recently, I made a short Linkedin post that was quite critical of OKRs, Objectives and Key Results. The post got a few likes, and comments who both agreed and disagreed with me. I found one of the comments that disagreed with me particularly interesting, because it referenced <a href="https://www.linkedin.com/pulse/implementing-okrs-tale-from-trenches-brett-crosby/?trk=v-feed" target="_blank">an article</a> that was very positive to OKRs.</p><p>That article contained pretty much everything that makes me doubt that OKRs are useful. I’ll walk through it, but first, here is my original Linkedin post:</p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p>Here is why I do not trust OKRs, in three quotes:</p><p>"When a measure becomes a target, it ceases to be a good measure."</p><p>-Goodhart's Law, <a href="https://lnkd.in/dUgcBEMT">https://lnkd.in/dUgcBEMT</a></p><p>"The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor."</p><p>-Campbell's Law, <a href="https://lnkd.in/dFyeu4K3">https://lnkd.in/dFyeu4K3</a></p><p>"Key Results benchmark and monitor how we get to the objective. Effective KRs are specific and time-bound, aggressive yet realistic. Most of all, they are measurable and verifiable. You either meet a key result’s requirements or you don’t; there is no gray area, no room for doubt."</p><p>-What is an OKR? Definition and examples, <a href="https://lnkd.in/dqtTqYp8">https://lnkd.in/dqtTqYp8</a></p><p>In other words, the OKR system is designed to implement the kind of target setting Goodwin and Campbell warn about.</p><p>Judging from what I have seen, OKRs are a great way to train people to fudge results.</p><p>Add in that OKRs oversimplify the dependencies between different objectives, and that OKR data is usually presented with to few data points to be useful in decision making, and I have a difficult time understanding the enthusiasm.</p><p>I do like metrics, but I doubt that successful companies that use OKRs became successful because they used OKRs.</p><p>#strategy #management #leadership</p></blockquote><p>Let’s look at the article used as evidence that OKRs work, and see whether it holds up. The article is named <a href="https://www.linkedin.com/pulse/implementing-okrs-tale-from-trenches-brett-crosby/?trk=v-feed" target="_blank">Implementing OKRs. A tale from the trenches</a>.</p><h2 style="text-align: left;">The case of the misleading case</h2><p>First of all, the article describes a single case of a company that implemented OKRs, set ambitious targets, and then saw the company meet those targets. That is problematic, because one, or even a few, cases do not prove, or disprove anything.</p><p>Look at the picture below.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-DIn1Wy4U3Io/YX_mYE4tI2I/AAAAAAAB3S0/krdH7TewWQ0P8v6GUk97-8xvrdL3F4mJwCPcBGAYYCw/s1749/OKRs%2B-%2BNot%2Bas%2Bgreat%2Bas%2Byou%2Bthink%2B-%2BCase%2BBased%2BEvidence.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1241" data-original-width="1749" height="454" src="https://1.bp.blogspot.com/-DIn1Wy4U3Io/YX_mYE4tI2I/AAAAAAAB3S0/krdH7TewWQ0P8v6GUk97-8xvrdL3F4mJwCPcBGAYYCw/w640-h454/OKRs%2B-%2BNot%2Bas%2Bgreat%2Bas%2Byou%2Bthink%2B-%2BCase%2BBased%2BEvidence.jpg" width="640" /></a></div><br /><p>Which of the three cases in the picture is closest to the truth? The author of the article clearly believes it is Case 1, but there is no evidence of that. The truth may be closer to Case 2, or Case 3.</p><h2 style="text-align: left;">Selection bias and lack of scientific research</h2><p>When in doubt, turn to science! I googled “okr scientific research”, and a few other sets of search terms, but found no statistical studies, or metastudies.</p><p>The closes I got, was a question on Quora:</p><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><p style="text-align: left;">“Is there any peer-reviewed research showing that the Objectives and Key Results (OKR) model actually improves efficiency, productivity, or overall company performance?”</p></blockquote><p>Unfortunately, because of the selection bias inherent in the way the question was phrased any answers won’t be much use. Studies that do not show that OKRs work, will never be included in the answers. What you need is studies that prefer statistically significant results. Preferably, we should have metastudies, because they produce better results than any single study can.</p><p>As far as I can tell, the research on OKRs is so inadequate that we cannot turn to direct scientific research to either prove or disprove whether it works.</p><h2 style="text-align: left;">People burning bright, but not for long…</h2><p>We can, however, use indirect methods to evaluate whether OKRs are likely to work, or not. You create an OKR by setting an agressive, relatively short term, goal, and a target value to reach.</p><p>The article author did this by setting nine BHAGs, Big, Hairy Audicious Goals, figured out what reasonable targets would be, and then doubled them. In the words of the article author:</p><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><p style="text-align: left;">We took those numbers and we doubled them. Why? Because a) why not? That way if we aimed for twice the volume of our plan and we missed by half, we’d still hit our plan. If we actually hit those goals, even better! And b) because you are only supposed to get 70% on your OKRs. These are stretch goals, so come on, stretch a bit. Yeaaaah, that’s it.</p></blockquote><p>The article then continues, describing how quarterly OKRs were set, followed by individual OKRs. The author also asked advice about OKRs on Facebook. That probably yields as reliable advice as asking about Covid-19 advice on Facebook.</p><p>Did it work? The article author is convinced it did:</p><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><p style="text-align: left;">When Brew and I traveled on business, shit got done! Decisions were made! Targets were hit!</p></blockquote><p>He also has a credible sounding explanation for why the targets were hit:</p><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><p style="text-align: left;">Once you see what other people are signing up for, and you see the plans they are putting in place to achieve them, you get religion. You believe they are going to hit their goals. And you don’t want to be the only one not hitting her goals. So you work. You work hard. Instead of watching what everyone else is doing and reacting, you start focusing much more on achieving your Objectives and just assume they’ll hit theirs. OKRs help everyone focus, and that drives results.</p></blockquote><p>The author does not specify exactly what OKRs they used, but he does provide three examples of OKRs he believes are good ones:</p><p></p><ul style="text-align: left;"><li>Increase leads from 300 to 700</li><li>Improve conversion funnel efficiency by 30%</li><li>Increase sales volume by 70%</li></ul><p></p><p>Sounds pretty clear cut: OKRs are a recipe for success…or is there something wrong with this picture?</p><p>Yes, there is something wrong! For one thing, the author claims success comes from everyone working harder. Note that working harder and working smarter are two very different things.</p><p>Leads increase from 300 to 700. That is an increase of 133%. If that increase in results came from working harder, it is reasonable to assume there was a corresponding increase in effort. If people worked 40 hour weeks before OKRs, with a 133% increase, they would now work more than 93 hours per week.</p><p>Did they work 93 hours per week? We do not know, because there was no OKR for that, but it is quite possible that the OKR system pushed people to work way more than is sustainable. What happened to personnel turnover? The article did not mention that either, so we do not know.</p><p>Good metrics are not isolated from each other. They are linked into a system. Such a system would have metrics that prevent people from being overworked. A good metrics system should also be designed to be self-correcting. You have both leading and trailing metrics. You use the leading metrics to guide behavior changes, and trailing metrics to see if you actually got the results you thought you’d get.</p><p>OKRs do none of that. OKRs are treated as independent. That is why, with OKRs, it is easy to turn a workplace into a 93 work-hour per week sweatshop.</p><p>On the other hand, we do not know that people worked more hours. There might be some other explanation.</p><p>I do not have data from the article author’s company, but I do have data from the project teams I lead, so let’s use some of my project data, and see where it gets us. First let’s compare productivity data for two periods, similar to what you would get if you used OKRs. Let’s go:</p><p></p><ul style="text-align: left;"><li>Period 21: 4 value units</li><li>Period 22: 47 value units</li></ul><p></p><p>Wow! From 4 units to 47 units! That is an increase of 1075%! How audacious target setters we must have been! What a Big Hairy Audacious Goal we must have had!</p><p>Lets look at the productivity the quarter after that:</p><p style="text-align: left;"></p><ul style="text-align: left;"><li>Period 23: 19 value units</li></ul><p></p><p>That is a drop of 60%. How could the geniuses of the previous quarter turn into such bumbling idiots? Off with their heads!</p><p>Well, that last thing might be overreacting a bit. Let’s look at why we have such huge increases and decreases in results.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6PYLz4gx-2BUjQEaj-sg2QKFsMJqVKYxyPj5krbowqZLhVqKEP0ThOERHZdRzfZPhIgJwAjguFZMPK3-2GUY4MfOzYJwqxtltvq06ut1-Wp8I2O6BCkJrkyN0ZL3hY2vhVv3R/s1749/OKRs+-+Not+as+great+as+you+think+-+Stable+System+with+Variation.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="758" data-original-width="1749" height="278" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6PYLz4gx-2BUjQEaj-sg2QKFsMJqVKYxyPj5krbowqZLhVqKEP0ThOERHZdRzfZPhIgJwAjguFZMPK3-2GUY4MfOzYJwqxtltvq06ut1-Wp8I2O6BCkJrkyN0ZL3hY2vhVv3R/w640-h278/OKRs+-+Not+as+great+as+you+think+-+Stable+System+with+Variation.jpg" width="640" /></a></div><p>The picture above is a <i>Process Behavior Chart</i>, also known as a Process Control Chart. It shows that although we have a lot of variation in productivity, the variation always stays within the upper and lower process limits. These limits are calculated using a statistical method. I won’t go into details in this article. The important thing is that the system is stable within the process limits. All the variation is random.</p><p>With OKRs, this randomness cannot be distinguished from actual change, so it is entirely possible that the 133% increase in leads the OKR article author has in his example, is entirely due to random variation.</p><p>I don’t know, and neither does he! The difference is, Process Behavior Charts make it possible to distinguish real change from random variation. OKRs do not do that. Even worse, OKRs lead you to believe you understand a situation, and that you control it, while you really don’t.</p><h2 style="text-align: left;">Targets corrupt!</h2><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhN_LpqztmO575_jcJfTvvSOy1sOqy36aWqdqHqDMi-Uu0W9UPaSDt8Pfr90hJJOD4RMz__vo8stqEMWLh9ql9sD5l_17bqN1VbqiHpJfCkmk8DdHRM0MMDgCvFw4nJnXNi9a_Z/s1749/OKRs+-+Not+as+great+as+you+think+-+Targets+in+a+Stable+System+with+Variation.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="758" data-original-width="1749" height="278" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhN_LpqztmO575_jcJfTvvSOy1sOqy36aWqdqHqDMi-Uu0W9UPaSDt8Pfr90hJJOD4RMz__vo8stqEMWLh9ql9sD5l_17bqN1VbqiHpJfCkmk8DdHRM0MMDgCvFw4nJnXNi9a_Z/w640-h278/OKRs+-+Not+as+great+as+you+think+-+Targets+in+a+Stable+System+with+Variation.jpg" width="640" /></a></div><p>What happens when you set a target? Lets look at the same Process behavior Chart, but this time I have marked some target levels. I have also color graded the area from zero to the upper process limit, in colors from green to red. The more green, the easier it is to make a target. The more red, the more difficult it is to reach a target.</p><p>It is important to remember, that we are looking at the system as it actually is. To get the system to behave differently, we need to change it in some way. If we set targets and empower people, but do not teach how to change the system, they have only a few alternatives:</p><p></p><ul style="text-align: left;"><li>Hope they get lucky. Works once in awhile, but the game tends to be stacked against the people doing the actual work, especially since OKRs mandates setting targets without providing any method of figuring out what a reasonable target is.</li><li>Work more hours. Common, and often works in a very short perspective, but not sustainable over time. Can have disastrous side effects, like increasing personnel turnover, which drains the organization of competence, and destroys organizational memory.</li><li>Cheat. Usually the safest option. Risk of discovery is small. Even if discovered, risk of punishment is not that high.</li><li>Teach themselves how to change the system, change the system, and then pray that they really were as empowered as they were told they were. If they were not, punishment for doing actual change is usually swift and unmerciful. This is difficult, time consuming, dangerous, and often provides little benefit to the people who do it, even if the change succeeds.</li></ul><p></p><p>There are 25 data points in the series. If we want a 70% chance of success, that is we want 17 data points at the target level or higher, we should set the target at around 5. That is well below the average, which is slightly above 20.</p><p>Setting the target to a 70% success rate based on future performance would require a time machine. If you don’t have one, trying will just be silly.</p><p>Let’s assume for a minute that you know the average productivity is 20. Note that with OKRs, you don’t bother with averages, so you need something else to provide that information. If you set the target at double the average, 40, you have a 20% chance of reaching it, even if you do not change anything about how you work. I’d say doubling the average sounds like an aggressive target.</p><p>That means, in our example, 20% of the times you set a target that is double the average, you will trick yourself into believing that OKRs work. People like writing about their successes much more than they like writing about their failures, so the people who write about OKRs are likely to come from a group that sets target like this, or, since they usually do not know what the average is, have set the targets way into the green.</p><p>It is a popular belief that if you empower the people who do the work, they will start doing the systemic improvements necessary to meet audacious targets. Unfortunately, that requires that they also know how to improve the system. Sometimes people do, but most of the time, they don’t. Why not? One reason that stands out is that neither schools, nor workplaces, teach effective methods for improving systems. Universities sometimes do, </p><p>Plenty of such methods exist. There is a plethora of different improvement methods based on complexity thinking, systems thinking, and statistics. Some of these methods have tools that are fairly easy to use, like Five Why in Lean/TPS, or Evaporating Clouds in The Logical Thinking Process (which is one of the tool sets in the Theory Of Constraints). Others, like Process Behavior Charts, are more difficult to use. Easy or hard, they all have one thing in common:</p><p style="text-align: center;"><b>They are rarely taught!</b></p><p style="text-align: left;">Imagine that someone sets a target for you, and you have no idea how to achieve it. Imagine that whoever sets the target also tells you “you are empowered to do whatever it takes to reach the target, just don’t fail”.</p><p>If the target looks possible to achieve, you will almost certainly continue the way you are used to, and hope for the best.</p><p>If the target is way out there, and looks impossible to achieve, there is only one thing to do:</p><p style="text-align: center;"><b>You cheat!</b></p><p>Some years ago, I worked for a company that set very challenging targets for its sales people, in several different markets. I was in close contact with people from one of the markets, and they told me how they had to cheat to meet their targets. They hated it! It’s just that they had to. They told me all the other markets were in a similar position, and did the same thing.</p><p>In their case, they did not manipulate the total number of units sold, but they did mess around with the dates when things were sold, and that was enough to ensure that they were on target often enough to avoid getting punished for missing them.</p><p>In software development, which I usually work with, management likes to set targets like “80% automated test coverage” for an application. That is particularly useless, because the need for tests varies between different parts of an application. In general, it is useless to write tests for something called accessor methods, but there are a lot of accessor methods, and they are easy to write automated tests for, so that is what often happens.</p><p>Another little trick: If management measures software development team velocity, usually in story points per sprint, or stories per sprints, and sets a target, story points and stories will magically shrink. As a result, velocity will go up, and the target is met, without anything real changing at all.</p><p>If we look to research on target setting, it corroborates the stories above.</p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p>Here we found that participants who were given a specific performance goal for how much revenue they had to earn were almost twice as willing to use unethical methods to achieve it than those given a vague goal, irrespective of their moral justification.</p><p>— When Tough Performance Goals Lead to Cheating, by Colm Healy and Karen Niven</p></blockquote><p>The above quote is from an HBR article about a scientific study with 106 participants.</p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p>We found that people with unmet goals were more likely to engage in unethical behavior than people attempting to do their best. This relationship held for goals both with and without economic incentives. We also found that the relationship between goal setting and unethical behavior was particularly strong when people fell just short of reaching their goals.</p><p>— Goal Setting as a Motivator of Unethical Behavior, June 2004, The Academy of Management Journal, by Maurice E Schweitzer (University of Pennsylvania), Lisa D. Ordóñez (The University of Arizona), and Bambi Douma (University of Montana)</p></blockquote><p>Here is a quote from a third study:</p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p>Our study finds that cheating in goal-based systems occurs due to financial rewards to cheating and to social comparison framing. Assigning a goal on its own without increased pay or social comparison framing did not lead to an increase in cheating relative to a do-your-best counterfactual. However, the use of either financial rewards or social comparison framing led to cheating.</p><p>— Why do goal-based incentives cause cheating? Unpacking the confounding effects of goals, social comparisons and pay, by Matthew Chao (Williams College), and Ian Larkin (UCLA Anderson School of Management)</p></blockquote><p>We do need a lot more research about the effects of setting goals and targets. As far as I can tell, setting goals, by itself, does not cause significant problems. However, when we offer financial rewards, or compare people’s performance, then we invite cheating.</p><p>If a target is tied to a reward, then people will be prone to cheat to get the reward. The same way, if a target is used for social comparison, as in “Helen reached the target, and you didn’t”, then we also invite cheating.</p><p>I haven’t found any scientific research about targets tied to punishment, but since we are geared to react even more strongly to punishment than to rewards, it is highly likely that fear of punishment makes us cheat too.</p><h2 style="text-align: left;">Goals blinds us to creative solutions!</h2><p>Goals do make us more focused. When we do something relatively simple, that only requires increased effort, that can indeed be effective. However, our working lives are often way more complex than that.</p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><p>With goals, people narrow their focus. This intense focus can blind people to important issues that appear unrelated to their goal (as in the case of Ford employees who overlooked safety testing to rush the Pinto to market). The tendency to focus too narrowly on goals is compounded when managers chart the wrong course by setting the wrong goal…</p><p>— Goals Gone Wild: The Systematic Side Effects of Over-Prescribing Goal Setting, by Lisa D. Ordóñez Maurice E. Schweitzer Adam D. Galinsky Max H. Bazerman</p></blockquote><p>Case studies and anecdotes are no substitute for scientific research, but if you got the research, they can be used to illustrate a point, so let’s do that:</p><p>Several years ago, I worked directly for the CTO of a company that had hired a sub-contractor to improve its IT infrastructure. The project was not going well, and failure would mean the sub-contractor would not get a new contract, and that would mean firing a lot of personnel. This was during a raging global financial crisis, and if there was one thing you did not want to do, it was lose your job.</p><p>The sub-contractor management set as a goal to minimize the damage to their company from missing the contract. Everything they did was focused on whom to fire, when to fire, what severance packages should look like, and other damage control measures.</p><p>I asked my CTO if I could get a shot at helping the sub-contractor make the project deadline, and he okayed it. There were benefits for both organizations if the sub-contractor made the deadline, and, of course, to the people who would keep their jobs.</p><p>The sub-contractor was less than enthusiastic about having me meddle in what everyone knew was a hopeless situation, but the CTO I worked for could be very persuasive when he wanted to be, so I got permission to make an attempt.</p><p>The development team was already working as hard as it could. There simply wasn’t enough hours in a day to add more overtime.</p><p>I began with an information gathering and brainstorming workshop using a method called Crawford Slip. Then, I showed the team how to set up a kanban board. They were less common back then than they are today. I would have preferred to stay with the team throughout the improvement project, but that proved impossible. Nobody wanted to spring for the cost of having me around full time.</p><p>Instead, I told the team to photograph the kanban board twice a week, and email me the photos. I spent several weeks doing nothing but recording the team velocity, and using the data from the brainstorming session to build a Current Reality Tree (CRT). The CRT is a problem solving tool from the Logical Thinking Process toolkit.</p><p>Then, I traveled back to the team, showed the project manager what I had found, and made a few suggestions. You can see the results in the graph below.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhnX1RMgG_KlTmH5xw-vLOoE0CFRqe7UFniZOp2QojjbCfYc_jBYNZtRUATv3BoOwZh4QzEW975TYkkfn1KbLNz9b1nUKtZ5ALnfAS8DUjhsjquV4Ss7yKLAum3LwFEAHmJHsN3/s1749/OKRs+-+Not+as+great+as+you+think+-+Real+Improvement+02.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1064" data-original-width="1749" height="390" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhnX1RMgG_KlTmH5xw-vLOoE0CFRqe7UFniZOp2QojjbCfYc_jBYNZtRUATv3BoOwZh4QzEW975TYkkfn1KbLNz9b1nUKtZ5ALnfAS8DUjhsjquV4Ss7yKLAum3LwFEAHmJHsN3/w640-h390/OKRs+-+Not+as+great+as+you+think+-+Real+Improvement+02.jpg" width="640" /></a></div><p>I met with the project manager week 40. Week 41, productivity went up. Week 42, it went up again. After that, it held steady around a new baseline. In two weeks, the average output increased by 316%.</p><p>Remember, they were already working as much overtime as they could, so the productivity did not come from working harder. It came from working smarter.</p><h2 style="text-align: left;">What does it mean to work smarter?</h2><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9yYJSEJo1HuJ8dKvF97ee9LLW-lZS8sIAfTW6D97RG6ed1g5ZzfavVUGB9i3ctu_JaKRxGiw7A0xUPh34MeN40OuCt-Ib4sKlXyc6nzO7Jrw6Q2ldyplZrVzxvm9Ta3azyjiZ/s1749/OKRs+-+Not+as+great+as+you+think+-+Effects+of+Eliminating+Multitasking+Part+1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="714" data-original-width="1749" height="262" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9yYJSEJo1HuJ8dKvF97ee9LLW-lZS8sIAfTW6D97RG6ed1g5ZzfavVUGB9i3ctu_JaKRxGiw7A0xUPh34MeN40OuCt-Ib4sKlXyc6nzO7Jrw6Q2ldyplZrVzxvm9Ta3azyjiZ/w640-h262/OKRs+-+Not+as+great+as+you+think+-+Effects+of+Eliminating+Multitasking+Part+1.jpg" width="640" /></a></div><p>So, what does it mean to work smarter? You need to understand the process, find problem areas, and then fix them. The picture above shows the situation before we made changes. The developers worked on a bunch of jobs, all with high priority, and all broken down into several tasks. Since everything had high priority, they tried to start each job as soon as possible.</p><p>When they had finished one task, they immediately began working on another. The problem was that the new task they started working on, had nothing to do with the preceding task. They switched back and forth between working on different jobs. This lead to tasks belonging to different jobs getting interleaved, and this pushed lead times to become longer.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjg7l3-g63ZbURU6Lx1vx2Ogo4C0eB5bnmPjHlpZZySn8HYMGfjetbS0QCrRxxy4YcRfJg_XCKyF1rneZx8X40-H_IinWG-LvMhkZoAthyXwio9j1vcKGP0RxoMYZgWNvvxjEjB/s1749/OKRs+-+Not+as+great+as+you+think+-+Effects+of+Eliminating+Multitasking+Part+2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="714" data-original-width="1749" height="262" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjg7l3-g63ZbURU6Lx1vx2Ogo4C0eB5bnmPjHlpZZySn8HYMGfjetbS0QCrRxxy4YcRfJg_XCKyF1rneZx8X40-H_IinWG-LvMhkZoAthyXwio9j1vcKGP0RxoMYZgWNvvxjEjB/w640-h262/OKRs+-+Not+as+great+as+you+think+-+Effects+of+Eliminating+Multitasking+Part+2.jpg" width="640" /></a></div><p>What we did was reorganizing the tasks, so that all tasks belonging to the highest priority job were finished first. Then all the tasks belonging to the second highest job were done, and so on.</p><p>One counter-intuitive thing is that we delayed starting work, in order to finish sooner.</p><p>In reality, the benefits are much larger than the diagram shows, because when you eliminate multitasking, you eliminate having to spend time on switching tasks. You do not need to change your tool setup as often, you do not need to backtrack to try to remember what you did the last time, and you do not need to figure out what the heck you were planning to do. That adds up to a lot of time saved.</p><p>Of course, eliminating multi-tasking is only one of the things you can do. For practical purposes, there are nearly always dozens, or hundreds, of improvements you can do. Once you have made an improvement, that often opens up the way for other improvements.</p><p>With OKRs, there would have been no improvement, because working harder was not the answer. Understanding the process, and eliminating a major problem, that did the trick.</p><p>It’s worth noting that a change like this is a sustainable change. No one is pushed to work harder. The developers can actually deliver more value while working less. That leaves more time for thinking, which can be used to find new things to improve.</p><p>How did things turn out? Well, the company managed to deliver, it got the contract it was after, and when I checked a year later, they had managed to keep all the personnel.</p><p>Had they used OKRs to just push to work harder, people, they would have had close to zero chance of finishing the work in time, and getting the contract.</p><h2 style="text-align: left;">Summing up</h2><p>It’s time to sum this article up:</p><p></p><ul style="text-align: left;"><li>There is very little research on the efficacy of OKRs. The existing material consists mostly of testimonies and case studies</li><ul><li>Testimonies and case studies are notoriously unreliable. We should not base our beliefs about OKRs, or anything else, on them.</li></ul><li>While we cannot use scientific research to tell whether OKRs work, there is research on the building blocks of OKRs.</li><ul><li><b>Agressive target setting</b>: Setting agressive targets increases cheating substantially</li><li><b>Use of single data points</b>: Using single data points can be, and very often is, incredibly misleading. Metrics systems should, by default, use long data series. </li></ul><li>OKRs ignore the effects of variation, and that is a great way to trick people into making bad decisions. We need some way of separating random variation within the system from special cause variation. We also need to detect trends in the data. Process Behavior Charts does all of this, but there are other methods that can be used.</li><li>OKRs do not tell us why we reach a target, or why we fail. It may be that we have improved something, or it may be that we got lucky, or unlucky.</li><li>OKRs do not tell us whether a change, if there is one, is sustainable, or if it will cause detrimental side effects.</li><li>OKRs present dependent variables as if they are independent. This is bound to cause confusion, and bad decisions. To be useful, a metrics system must link things together, so that we do not inadvertently cause big harm when we make a small improvement.</li><li>OKRs makes us focus on reaching targets, and this can make us blind to creative solutions. In other words, OKRs can prevent you from reaching the goals set by the OKRs.</li></ul><p></p><p>There you have it: There is very little that speaks in favor of OKRs, and a lot of reasons to be suspicious.</p><p>In addition, we can easily create metrics systems that do not have the problems that OKRs have.</p><p>You can use Goal Maps, S&T trees, or strategy maps, to build a model of the organizations goals, and how they interact with each other. (I think Goal Maps and S&T trees work better than Strategy Maps for this, but that is a matter open to debate. There are also other ways to do the mapping.)</p><p>Add using Process Behavior Charts, or some other way to distinguish between systems noise and special cause changes, and you have a good start.</p><p>Of course, any metrics system has limitations, so you should be aware that in some situations, cause and effects based metrics systems cease to function. That happens when your organization dives into complexity. You don’t have cause and effect anymore, but you still have statistical dispositions, which means that while a Goal Map is less trustworthy, it is probably not totally useless. When you have true chaos, which happens only rarely, you have no causality, so you need to use other methods. (Check out <a href="https://publications.jrc.ec.europa.eu/repository/handle/JRC123629">Cynefin</a>, if you are interested.)</p><p>Most of the time though, a good metrics system will help, but OKRs probably won’t.</p>Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-13780700012106549112021-01-24T19:13:00.001+01:002021-01-24T19:13:40.391+01:00Tempo 2.0 - Section 3.4 Value Stream Maps<p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-KVPh_pIyvZs/YA228TiKkOI/AAAAAAAB1Z0/k91FCHAF-MIFVDjqiP5BkFsT8J2Ya-cugCLcBGAsYHQ/s2048/Waterfall%2Bin%2BJungle%2Bv01.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1365" data-original-width="2048" height="266" src="https://1.bp.blogspot.com/-KVPh_pIyvZs/YA228TiKkOI/AAAAAAAB1Z0/k91FCHAF-MIFVDjqiP5BkFsT8J2Ya-cugCLcBGAsYHQ/w400-h266/Waterfall%2Bin%2BJungle%2Bv01.jpg" title="Following a Value Stream is a bit like exploring an uncharted landscape" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Mapping a Value Stream is an adventure, a bit like exploring an uncharted landscape.</td></tr></tbody></table></p><p><span face="Arial, sans-serif" style="font-size: 12pt;">If
you are serious about improving the way your organization works</span><span face="Arial, sans-serif" style="font-size: 12pt;">… Let me rephrase that: If you are serious about improving
any process, for an organization, for yourself, or for a friend, you will
sooner or later need information about what the relevant value streams look
like. You also need a simple, yet useful, way to map the information. Having
that enables you to figure out where to focus your efforts.</span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">A <i style="mso-bidi-font-style: normal;">value stream map</i> is easy to learn, yet very useful, tool for
mapping value streams.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">The purpose of a value
stream map is to help you identify <i style="mso-bidi-font-style: normal;">waste</i>
in a value stream. A value stream map tells you how much of the time that a
goal unit<a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-03.1%20Your%20company%20is%20a%20system%20-%20The%20Monty%20Hall%20Problem/Value%20Stream%20Maps.rtf#_ftn1" name="_ftnref1" style="mso-footnote-id: ftn1;" title=""><sup><span style="mso-special-character: footnote;"><!--[if !supportFootnotes]--><sup><span face=""Arial",sans-serif" style="font-size: 12pt; line-height: 107%; mso-ansi-language: EN-GB; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-GB; mso-fareast-theme-font: minor-fareast;">[1]</span></sup><!--[endif]--></span></sup></a>
spends in the value stream that is <i style="mso-bidi-font-style: normal;">value
adding time</i> and how much is <i style="mso-bidi-font-style: normal;">non-value
adding</i> time.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm 6pt; mso-layout-grid-align: none; mso-pagination: none; text-autospace: none;"><b style="mso-bidi-font-weight: normal;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Waste, schock, and
incredulity</span></b><span face=""Arial",sans-serif" style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm 6pt; mso-layout-grid-align: none; mso-pagination: none; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Schock
and incredulity are common reactions the first time someone sees a value stream
map. Does it really take that much time to produce a single goal unit? Do we
really have <i style="mso-bidi-font-style: normal;">that much</i> wasted time?<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">The harsh reality is
that in most value streams, goal units spend a lot of time waiting. Often, the
non-value adding time is 99% of the total time, or more.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">How can you have 99%
waste in a process without anyone complaining about it?<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">I once worked as an
interface designer for a very large enterprise software system. Designing and
constructing an interface took about a week, and each connection between two
subsystems had its own custom-designed interface. There were many, many
subsystems, and two subsystems could have several different connections.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Interfaces were
deployed once per year. The project had been ongoing for about seven years.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">That meant an interface
spent on average six months either in a requirements queue before it was
designed, or after design and construction, in another queue waiting to be
deployed. Thus, for a week of value-adding time (design and construction), we
had about 25 weeks of non-value adding time.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">A ratio of 1:25, means
we have 4% value adding time, and thus, 96% non-value adding time.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">But wait, there is
more! I wasn</span><span face=""Arial",sans-serif" style="font-size: 12pt; mso-fareast-font-family: "Times New Roman";">’t the only interface designer. We
produced about 60 interfaces per year. In seven years, that is about 420
interface designs.</span><span face=""Arial",sans-serif" style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">How many interface <i style="mso-bidi-font-style: normal;">designs</i> did we need? <i style="mso-bidi-font-style: normal;">One!</i> We could have built the whole thing
with one standardized interface, for example HTTPS<a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-03.1%20Your%20company%20is%20a%20system%20-%20The%20Monty%20Hall%20Problem/Value%20Stream%20Maps.rtf#_ftn2" name="_ftnref2" style="mso-footnote-id: ftn2;" title=""><sup><span style="mso-special-character: footnote;"><!--[if !supportFootnotes]--><sup><span face=""Arial",sans-serif" style="font-size: 12pt; line-height: 107%; mso-ansi-language: EN-GB; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-GB; mso-fareast-theme-font: minor-fareast;">[2]</span></sup><!--[endif]--></span></sup></a>,
which is used for the vast majority of computer connections on the Internet.
Instead of making a custom data format for each interface, we could have
managed with about five standardized data formats.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Sticking to just the
interfaces, we need to divide those 4% value-adding time by 420. That means we
are down to 0.0095% value adding time, and 99.99% non-value adding time.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Note that we had two
different types of waste:<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">One type was caused by
having partially finished work laying around, instead of finishing the work and
deploying it, so it could be used. Assuming that there was good economic
reasons for building each connection, there was an economic cost attached to <i style="mso-bidi-font-style: normal;">not</i> having the connection.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">The other type of waste
was building things that should not have been built in the first place.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Of course, if you have
420 times as many designs as you ought to have, then you will need quite a lot
of people to build the stuff, which means you will need more administrative
personnel. The costs do not stop there, because you will need extra people
maintaining all the extra stuff the project built, and there will be delays in
maintenance too, which will cost even more</span><span face=""Arial",sans-serif" style="font-size: 12pt; mso-fareast-font-family: "Times New Roman";">…</span><span face=""Arial",sans-serif" style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">A company can easily
create cost cascades that plague them for decades, and the funny thing is,
identifying such costs, and stopping the bleeding, is usually a low priority.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Identifying and fixing
problems like the ones in the story, requires a lot more than knowing how to
make a value stream map, but value stream maps are a good place to start.
Sooner or later, you will have to present your findings to other people, and
value stream maps are very helpful there too.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm 6pt; mso-layout-grid-align: none; mso-pagination: none; text-autospace: none;"><b style="mso-bidi-font-weight: normal;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Value Stream Map
Example</span></b><span face=""Arial",sans-serif" style="font-size: 12pt;"><o:p></o:p></span></p>
<div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1HMH1c1h1rwaETaxEpn241GZ4iN-EEcJC8eBMHMgq8reiQQrD0avG9c11wY9hb_ZjhZ_cxxYIG_OA3Gf1FN9wfeRYYNS171GW2ilwSeKXzvIprJ9GMduMy363xgesqrVJVwbE/s2515/A-03+Value+Stream+Maps.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1251" data-original-width="2515" height="199" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1HMH1c1h1rwaETaxEpn241GZ4iN-EEcJC8eBMHMgq8reiQQrD0avG9c11wY9hb_ZjhZ_cxxYIG_OA3Gf1FN9wfeRYYNS171GW2ilwSeKXzvIprJ9GMduMy363xgesqrVJVwbE/w400-h199/A-03+Value+Stream+Maps.jpg" width="400" /></a></div>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;"><i>Figure: Value Stream
Map</i><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">The figure above shows
a value stream map for a software development company. It shows how a single
goal unit, a user story, travels from requirements gathering to the point where
customers start paying for it.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">The greatest delay,
3,200 hours, is between the initial Profit & Loss estimate, and the monthly
meeting where work is prioritized. The queueing time is about two years. This
means the greatest delay is in an administrative process that is executed
before a development team even knows there is a requirement.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">It is very common in
software development that the greatest delays occur before, or after, the
software development team is working on a user story. And yet, most companies
would, in this situation, focus on improving the way developers work.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">The mistake happens
because no one examines what the value stream looks like before the improvement
work begins.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm 6pt; mso-layout-grid-align: none; mso-pagination: none; text-autospace: none;"><b style="mso-bidi-font-weight: normal;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Reducing waste with a
Value Stream Map</span></b><span face=""Arial",sans-serif" style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; margin: 12pt 0cm 6pt; mso-layout-grid-align: none; mso-pagination: none; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Some
years ago, I worked with a software development team that had not released
anything to production for 3-4 months. We set about fixing a number of things
that kept the team from delivering, and got to the point where the team
released software once every two weeks, and could release more often than that,
if they were asked to.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">After the improvements,
how long was our lead time? It was still 3-4 months!<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">I mapped out what
happened to a user story <i style="mso-bidi-font-style: normal;">after</i> the
team was done implementing it. It turned out it went on to a team that both
trained users, and tested the software.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">The problem was that
when a new piece of functionality had been implemented, they tested it, wrote
training materials, and held a course in a single batch, before approving a
user story for release. We very politely asked them if they could test and
approve user stories before writing the training material and holding the
courses.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">They said, </span><span face=""Arial",sans-serif" style="font-size: 12pt; mso-fareast-font-family: "Times New Roman";">“No, problem!”</span><span face=""Arial",sans-serif" style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">From then on, we could
release software as often as the business side wanted.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">The reason it was so
easy to make such a major improvement, was that the team</span><span face=""Arial",sans-serif" style="font-size: 12pt; mso-fareast-font-family: "Times New Roman";">’s Product Owner was an employee at the company, and knew
the people in the training and testing department really well.</span><span face=""Arial",sans-serif" style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">I contributed my
theoretical knowledge about how processes and queues ought to work, he
contributed both detailed knowledge about how the processes actually worked at
his company, and his power to influence processes via his network of contacts,
and friends, at the company.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Neither of us could
have done it alone, and that illustrates an important point: When you try to
fix something, you must work <i style="mso-bidi-font-style: normal;">with</i>
people at the company, and you must do it <i style="mso-bidi-font-style: normal;">all
the way through the change</i>. Handing off a change plan and expecting someone
who hasn</span><span face=""Arial",sans-serif" style="font-size: 12pt; mso-fareast-font-family: "Times New Roman";">’t been a part of developing it,
does not work! It does not work if you are a consultant like me, and it does
not work if you are a manager, or leader.</span><span face=""Arial",sans-serif" style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">It is often difficult
to get an overview of a process. Most companies are still divided into
function-oriented parts, where each part is interested in its own little piece
of the value stream, and little or nothing else. Most of the time, like in the
story above, the greatest delays occur where there are organizational borders.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">Worth mentioning that </span><span face=""Arial",sans-serif" style="font-size: 12pt; mso-fareast-font-family: "Times New Roman";">“organizational borders” does not mean just departmental
borders. For example, when you have multi-team projects or programs, borders
between teams can be, and often are, a major source of delays.</span><span face=""Arial",sans-serif" style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">If you are mapping a
value stream across organizational borders, you will not always be able to find
someone who is responsible for the whole value stream. If so, you will have to
follow a goal unit as it travels through the organization, without having
approval from a senior manager. Technically, this is easy to do, but you might
want to have your CV prepared, in case you find out where someone has buried a
skeleton or two.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">If you find someone who
is responsible for the whole process, it is likely that that person does not
know in detail how the process works, or where the delays are.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">If you are lucky, as I
have been on several occasions, you will find a friend, someone who is as
curious about what is going on as you are. You might get a bit of support, but
do not expect that person to take personal risks for you, especially if you are
a consultant. Even if it looks to you that they could just magically whisk you
out of trouble when you have found something sensitive, that is probably not
the case in reality.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">By the way, do not
mistake the organization chart for the reality. You are liable to find that
goal units travel weird and mysterious ways before arriving at their
destination. I have, on occasion, found that some work items do not actually
have a destination. That is, they are still produced, but the intended
recipient may have disappeared in a re-organization frenzy years before.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; tab-stops: 26.95pt; text-autospace: none;"><span face=""Arial",sans-serif" style="font-size: 12pt;">It is part of what
makes value stream mapping such an adventure.</span></p><p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt; mso-layout-grid-align: none; mso-pagination: none; text-autospace: none;"><b><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;">Takeaways</span></b><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;"><o:p></o:p></span></p><p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-layout-grid-align: none; mso-list: l0 level1 lfo1; mso-pagination: none; tab-stops: 12.0pt 36.0pt; text-autospace: none; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt; mso-fareast-font-family: Arial;">●<span style="font-family: "Times New Roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;">The purpose of a <i>value stream map</i> is to help you identify
<i>waste</i> in a value stream.<o:p></o:p></span></p><p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-layout-grid-align: none; mso-list: l0 level1 lfo1; mso-pagination: none; tab-stops: 12.0pt 36.0pt; text-autospace: none; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt; mso-fareast-font-family: Arial;">●<span style="font-family: "Times New Roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;"> In most value streams, goal units spend a lot
of time waiting. Often, the non-value adding time is 99% of the total time, or
more.<o:p></o:p></span></p><p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-layout-grid-align: none; mso-list: l0 level1 lfo1; mso-pagination: none; tab-stops: 12.0pt 36.0pt; text-autospace: none; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt; mso-fareast-font-family: Arial;">●<span style="font-family: "Times New Roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;">There is more than one
type of waste in processes. For example: Partially finished work waiting in
queues, and building things you do not need.<o:p></o:p></span></p><p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-layout-grid-align: none; mso-list: l0 level1 lfo1; mso-pagination: none; tab-stops: 12.0pt 36.0pt; text-autospace: none; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt; mso-fareast-font-family: Arial;">●<span style="font-family: "Times New Roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;">To find waste, you need
to look at the whole value stream, across team and departmental borders.<o:p></o:p></span></p><p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-layout-grid-align: none; mso-list: l0 level1 lfo1; mso-pagination: none; tab-stops: 12.0pt 36.0pt; text-autospace: none; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt; mso-fareast-font-family: Arial;">●<span style="font-family: "Times New Roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;">You need theoretical
knowledge, a good understanding of actual processes, and a strong network of
people willing to help you in the organization.<o:p></o:p></span></p><p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-layout-grid-align: none; mso-list: l0 level1 lfo1; mso-pagination: none; tab-stops: 12.0pt 36.0pt; text-autospace: none; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt; mso-fareast-font-family: Arial;">●<span style="font-family: "Times New Roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;">Involve people <i>from the start!</i> If you hand over a plan
to someone who has not been involved in creating it, execution will often fail.<o:p></o:p></span></p><p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-layout-grid-align: none; mso-list: l0 level1 lfo1; mso-pagination: none; tab-stops: 12.0pt 36.0pt; text-autospace: none; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt; mso-fareast-font-family: Arial;">●<span style="font-family: "Times New Roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;">Get a sponsor within
the organization if you can, but do not expect them to work miracles if you get
in trouble investigating a value stream. At best, they can advice you where to
be careful, and what to steer clear of.<o:p></o:p></span></p><p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-layout-grid-align: none; mso-list: l0 level1 lfo1; mso-pagination: none; tab-stops: 12.0pt 36.0pt; text-autospace: none; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt; mso-fareast-font-family: Arial;">●<span style="font-family: "Times New Roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;">Value stream mapping is
a lot of fun.<o:p></o:p></span></p><p class="MsoNormal" style="line-height: normal; margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-layout-grid-align: none; mso-list: l0 level1 lfo1; mso-pagination: none; tab-stops: 12.0pt 36.0pt; text-autospace: none; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt; mso-fareast-font-family: Arial;">●<span style="font-family: "Times New Roman"; font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Arial",sans-serif; font-size: 12.0pt;">There is a lot more to
value stream mapping than this introduction. Be aware that there is a lot more
to learn.</span></p>
<div style="mso-element: footnote-list;"><!--[if !supportFootnotes]--><br clear="all" />
<hr align="left" size="1" width="33%" />
<!--[endif]-->
<div id="ftn1" style="mso-element: footnote;">
<p class="MsoNormal" style="line-height: normal; margin-bottom: 0cm; mso-layout-grid-align: none; mso-pagination: none; text-autospace: none;"><a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-03.1%20Your%20company%20is%20a%20system%20-%20The%20Monty%20Hall%20Problem/Value%20Stream%20Maps.rtf#_ftnref1" name="_ftn1" style="mso-footnote-id: ftn1;" title=""><sup><span face=""Arial",sans-serif" style="font-size: 12pt;"><span style="mso-special-character: footnote;"><!--[if !supportFootnotes]--><sup><span face=""Arial",sans-serif" style="font-size: 12pt; line-height: 107%; mso-ansi-language: EN-GB; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-GB; mso-fareast-theme-font: minor-fareast;">[1]</span></sup><!--[endif]--></span></span></sup></a><span face=""Arial",sans-serif" style="font-size: 12pt;"> </span><span face=""Arial",sans-serif" style="mso-bidi-font-size: 12.0pt;">A goal unit is
the unit of measure you use to measure your goal. In agile software
development, user stories, features, and epics are common goal units. For a car
factory value stream, the unit might be a car. For an accounting system, the
goal units are money.</span><span face=""Arial",sans-serif" style="font-size: 12pt;"><o:p></o:p></span></p>
</div>
<div id="ftn2" style="mso-element: footnote;">
<p class="MsoNormal" style="line-height: normal; margin-bottom: 6pt; mso-layout-grid-align: none; mso-pagination: none; text-autospace: none;"><a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-03.1%20Your%20company%20is%20a%20system%20-%20The%20Monty%20Hall%20Problem/Value%20Stream%20Maps.rtf#_ftnref2" name="_ftn2" style="mso-footnote-id: ftn2;" title=""><sup><span face=""Arial",sans-serif" style="font-size: 12pt;"><span style="mso-special-character: footnote;"><!--[if !supportFootnotes]--><sup><span face=""Arial",sans-serif" style="font-size: 12pt; line-height: 107%; mso-ansi-language: EN-GB; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-GB; mso-fareast-theme-font: minor-fareast;">[2]</span></sup><!--[endif]--></span></span></sup></a><span face=""Arial",sans-serif" style="font-size: 12pt;"> HTTPS has been around
since 1994, so, even though the project was many years ago, no cutting edge
technology was required.<o:p></o:p></span></p>
</div>
</div>Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-1880613856060361322020-12-04T15:33:00.004+01:002020-12-04T15:33:55.203+01:00Tempo 2.0 - Section 3.3 Value Streams and Process Flows<p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZ_gcmo2Yh0CBFLRJ1bLR_cTcQYVEmH_4jxBqhrJ9abUUylYrGjmeWV6FK_EV_Z7ZdGZOhTuhONfQPzz4I8lfLZ0v3v5Ah_YltFr6T5ARoPbLG3Q3jBnNcx6pYU5-sQEPTAulX/s2048/A-03+Taylors+Mistake+v01+final+v01+No+Quotation.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1365" data-original-width="2048" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZ_gcmo2Yh0CBFLRJ1bLR_cTcQYVEmH_4jxBqhrJ9abUUylYrGjmeWV6FK_EV_Z7ZdGZOhTuhONfQPzz4I8lfLZ0v3v5Ah_YltFr6T5ARoPbLG3Q3jBnNcx6pYU5-sQEPTAulX/w400-h266/A-03+Taylors+Mistake+v01+final+v01+No+Quotation.jpg" width="400" /></a></div><p></p><p></p><blockquote><p>…that the greatest prosperity can exist only as the result of the greatest possible productivity of the men and machines of the establishments— that is, when each man and each machine are turning out the largest possible output.</p><p>— <i>The Principles of Scientific Management</i>, by Frederick Taylor, 1911.</p></blockquote><p></p><p>The 20th century was a century of economic growth and technological development never seen before in the history of humanity. A significant part of the credit for this has to go to Frederick Taylor, whose book The Principles of Scientific Management, was published in 1911.</p><p>Taylor laid down the basic principles of mass production. The ideas worked well for many years, but there were hidden problems.</p><p>One thing that happened, because the idea was that each worker and each machine should produce as much as possible as much of the time as possible, was that parts tended to pile up, everywhere. Different people, and different machines, doing different things, produce things at different rates. If you produce a lot of different parts that will eventually be fitted together, you will inevitably end up with too many parts of some things, and too few of other things.</p><p>Having big piles of unused parts laying around didn’t bother people much in the early 20th century. One reason was that the economy overall was expanding, except for the occasional depression, and most of the time, the parts in those big piles would eventually be used and sold. Another reason was that the prevalent accounting model, Cost Accounting[Cost Accounting is still the prevalent accounting model. It is still a model with problems, but today there are several alternatives, who have their own pros and cons.], regarded those big piles as assets. At the time, it was a reasonable assumption that whatever you produced would eventually be sold.</p><p>“Reasonable” does not always mean correct. Those piles of parts were actually a huge risk. Having capital tied up in parts meant a company had less cash on hand. If something happened, like a depression, or just a change in what the market wanted, the parts might become worthless, and the company stuck with them would suffer a huge loss.</p><p>Using an inherently wasteful production system also meant huge economic barriers to entry for new companies…unless someone could figure out how to make a small number of products with a much smaller investment.</p><p>Eventually, someone did.</p><p>The quality guru W. Edwards Deming is considered one of the greatest management experts of the 20th century. Deming traveled from the US to Japan in the early 1950’s. He taught both managers and engineers statistical methods to improve quality. However, there was something that Deming considered even more important.</p><p>Deming taught how to view a company, and the environment it operates in, as a system. He summarized what he taught in a simple sketch.</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihT8I2gaFgvvBpyCWc7lSb8ivSQdVi6dnurGDVKgNwmCwHwQExTGPjjQFeDGxwbTSb0q-Fihn0LwPBRcsp3BLAHGnPDQwgOWj3zbO9UsXg8RyAZai_UzAX7f3eDxcIwcsNlo_K/s1697/A-03+Deming%2527s+view+of+manufacturing+processes+as+systems.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="950" data-original-width="1697" height="224" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihT8I2gaFgvvBpyCWc7lSb8ivSQdVi6dnurGDVKgNwmCwHwQExTGPjjQFeDGxwbTSb0q-Fihn0LwPBRcsp3BLAHGnPDQwgOWj3zbO9UsXg8RyAZai_UzAX7f3eDxcIwcsNlo_K/w400-h224/A-03+Deming%2527s+view+of+manufacturing+processes+as+systems.jpg" width="400" /></a></div><br /><p></p><p>Figure: Deming’s view of manufacturing organizations as systems.</p><p>Deming’s simple sketch was the start of a revolution. Deming described a flow of materials, a value stream. He also described feedback. Information is retrieved from customers, and fed back into the process.</p><p>In 1950 Japan was a country in a deep economic crisis. The industry was obliterated during World War II. Nobody knew how to rebuild the country again.</p><p>Deming’s sketch held the key to the Japanese economic miracle. In the West, mass production based on Frederick Taylor’s Principles of Scientific Management reigned supreme. There was no way that a poor country like Japan could make the investments necessary to build an industry based on mass production.</p><p>The Japanese decided to change the rules, and play a different game. They would outmaneuver their stronger opponents. While Western companies were built around the functions needed for manufacturing, Japanese companies like Toyota and Honda decided to organize around the process flows companies need.</p><p>Value Stream became a central concept. The idea was to look at value streams from the perspective of the customer:</p><p>What does the customer want to get out of the process?</p><p>Looking at the process flow, the value stream, from the perspective of the customer made it possible to divide the flow into value adding time and non-value adding time. An astonishing discovery was that in most processes, only a small part of the time was value adding time. Most of the process time was non-value adding time, and the Japanese companies worked hard to get rid of it.</p><p>Getting rid of non-value adding time made it possible to produce things in much smaller volumes than mass production systems, with much smaller investments, and still make a profit. The feedback loop from customers meant that initially shoddy products would be improved over time. Eventually, they became good enough to turn quality into an additional competitive advantage.</p><p>Deming’s sketch represents the smartest business strategic move of the 20th century. To be clear, Deming did not, on his own, save Japan’s industry. Nor was he the only one who had bright ideas. The Japanese economic miracle was a lot more complex than that. Still, Deming’s sketch sums up the basic idea in a way that is easy to understand, even if it is a challenge to implement it.</p><p>In the West, we never really got it. For a long time, we continued to base our industry on the outdated mass production model. Scientific Management is so integral to how we think that most people who use it don’t even know its name. It’s the only way we know, so there is no need to distinguish it from anything else.</p><p>Our terminology has changed. Talking about value streams is popular today, but if you look closely at organizations and processes, they are often built around the old way of thinking. Many companies have redesigned their factories, but even then, the administrative processes, distribution networks, and management paradigms, are often based on Taylor’s ideas.</p><p>In the same manner, there is a lot of talk about the “customer”, but what is meant is often the next step in the value stream, not the customer who will use the product or service. This twists the whole idea of thinking in terms of value streams.</p><p>The tendency to adopt new terminology, without really changing anything, means a lot of good opportunities are lost. The purpose of this book is not to convince you that any particular idea is better than everything else. I do want you to appreciate the importance of new ideas, and I want to emphasize the importance of understanding ideas, rather than blindly following recipes. The reason is that implementing a good idea requires adapting it to your situation. To do that, you need to understand both the idea, and your situation. Blindly following a recipe for success, is actually a recipe for failure.</p><h2 style="text-align: left;">Takeaways</h2><p></p><ul style="text-align: left;"><li>Optimizing each part of a process often leads to sub-optimization of the whole.</li><li>If you do not know which management paradigm you are using, you are almost certainly using Scientific Management.</li><li>Scientific Management will get you, and your company into trouble, unless you have a deep understanding of its merits and limitations. It is safest to assume that you don’t.</li><li>Understanding value streams is a key to understanding production systems. Do not make the mistake of believing it is the only key!</li><li>Building organizations around value streams makes it easier to optimize processes than building organizations around functions.</li><li>Process flows can be divided into value added time and non-value added time. Non-value added time is bad, so try to get rid of it.</li><li>The customer is the user of the product, not someone in the production process.</li><li>Adopting value stream terminology does not make your organization focused on value streams. Building, or rebuilding, your organization around value streams does…but watch out for innovative ways of screwing things up.</li><li>Learn to appreciate the value of new ideas, but don’t be so open to new ideas that your brain falls out.</li><li>Implementing ideas requires adapting them to your situation, and that requires understanding both the ideas and your situation.</li><li>Following recipes for success, is a recipe for failure.</li></ul><p></p><div><br /></div>Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-17457161686373609262020-12-02T12:21:00.003+01:002020-12-04T15:24:24.544+01:00Tempo 2.0 - Chapter 3.2 Properties of Systems<p>This is a draft version of a section in Tempo 2.0. Please do comment.</p><p><br /></p><p>Even simple systems can be difficult to understand. It is not because systems are inherently difficult to wrap your head around. The problem is our brains are trained the wrong way. Fortunately, it is not all that difficult to re-learn. When we do that, many problems that have looked utterly incomprehensible before, are suddenly fairly easy to understand. Doing something about them may still be difficult, but at least we have got a start.</p><p>For starters, we will define what a system is:</p><p></p><ul style="text-align: left;"><li>A system is a set of connected parts, real or abstract, that form an integrated whole.</li><li>Systems have some interesting properties. For example:</li><li>Systems consists of parts, that are also systems.</li><li>Systems always belong to larger systems.</li><li>Systems have properties that do not exist when you examine the parts separately.</li><li>You cannot understand a system just by studying the parts.</li><li>When you do something with a part of a system, other parts will nearly always be affected.</li><li>When you improve part of a system, the system as a whole may get worse.</li><li>Systems with many connected parts usually have only a few degrees of freedom.</li><li>Cause and effect in a system can be separated in time. When we talk about organizations, time delays can be years, decades, or even centuries.</li><li>Cause and effects can be separated in space. It is common that a problem in one part of an organization is caused by a solution to a problem in a different part of an organization.</li><li>Systems that are not continuously improved, will degrade on their own. Organizations often find that the world around them changes faster than themselves. The organization therefore becomes less, and less, adapted to the world around it. When the gap between the organization and the world around it becomes too large, the organization dies.</li><li>Things can happen without having identifiable causes. Events can also have effects that are not predictable. Instead, the relationships between parts are statistical trends and dispositions. This is a biggie, because when you are dealing with this kind of a problem, almost everything you have learned in traditional management courses and training, will push you into doing the wrong thing. Though this sounds frightening at first, you are in no way helpless. There are things you can do, and those things can be highly effective.</li></ul><p></p><p>Leading or managing a system as if the parts are independent of each other does not work well! When we improve part of a system, the system as a whole can get worse!</p><p>For example, if your company increases its manufacturing capacity without selling more, you may suddenly find that you have tied up too much capital in stock. Sometimes that gets you into a lot of trouble. Goodbye company!</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibAUEXDMhm8Sc1fRjnvDCvgXFs0z-W8m1X4YH0xpxLDj8HlhOnu9hjsFYQsKbFhbRRUQDeL0cJ9dBQDhJgoJ5RRkuhnfafjhKlKXTibiEp0S0BSk_0l2fsEUH0sgsaDsFhVQJj/s1898/A-03+Adding+more+people+kills+productivity.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1242" data-original-width="1898" height="261" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibAUEXDMhm8Sc1fRjnvDCvgXFs0z-W8m1X4YH0xpxLDj8HlhOnu9hjsFYQsKbFhbRRUQDeL0cJ9dBQDhJgoJ5RRkuhnfafjhKlKXTibiEp0S0BSk_0l2fsEUH0sgsaDsFhVQJj/w400-h261/A-03+Adding+more+people+kills+productivity.png" width="400" /></a></div><p></p><p><i>Figure: Management thought they would increase capacity by increasing the number of people in the project team. Instead, capacity dropped like a rock.</i></p><p>Sometimes, it is less obvious what will happen. A mistake I see over and over again, is when management adds people to late software development projects. What often happens, is that the production capacity goes down instead of up.</p><p>The picture above is from production velocity measurements I made in a project several years ago. Both before and after, I have seen the same thing happen in many different projects. It is a problem that can be easily predicted, and prevented, or, if it has already happened, it can be fixed. Fixing it afterwards, is more difficult though.</p><p>Right now, you are probably thinking “That can’t be true! If it was, no project should have more than one person”. The answer is that it is not an either or situation. Adding more people has very different effects depending on the situation, and on how you add them. Sometimes velocity goes up. Sometimes velocity goes down. Sometimes, you will notice no difference.</p><p>If you know the basic principles involved, and if you know a little bit about the situation the team is in, and how the team is organized, figuring out what will happen is quite easy. It is also easy to measure the results of actions you take, to see if you found the right solution. Easy, that is, if you know how to do it. That, among many other things, you can learn from this book. We’ll take it one step at a time though, so back to basic properties of systems.</p><p>Because every part in a system is connected to one or more other parts, it follows that we cannot optimize one part without affecting other parts. As we saw in the graph above, the effects of optimizing a part can be a bit counter-intuitive.</p><p>Most of the time, cause and effect are easier to understand, but we keep shooting ourselves in our feet anyway. In software development, we often track how long it takes to finish each piece of work. We then push software developers to finish each piece of work faster. When we do that, quality goes down. The code gets more complicated, and there are a lot of bugs. Working with complicated code takes a lot of time, and fixing errors in complicated code also takes a long time. As a result the entire project slows down, because someone pushed the developers to speed up.</p><p>How much can you speed projects up by optimizing the whole? Back in 2010, when I wrote the original version of Tempo! I wrote that optimizing the whole instead of the parts could lead to delivering 500% faster than with waterfall methodologies. Since then, a lot has happened.</p><p>The original assessment by Jeff Sutherland was based on a single team producing software. Nowadays, I mostly work with programs where many teams collaborate. That makes the effects of sub-optimization much greater. I have seen multi-team programs where an estimated two weeks of work takes two years, or more.</p><p>You might think that is an extreme case, but no, it isn’t. What is even worse, when it happens, entire organizations go into denial. You hear people, otherwise very smart people, claim that a two year lead time is perfectly normal. They claim that even if it is a long lead time for a single piece of work, it does not matter, because they are going to deliver everything at once.</p><p>As a result, companies lose the revenues they would have had from early partial deliveries. Risk increases, because nobody knows if that big batch of software that will be delivered all at once, will work, or if it was what the customers wanted.</p><p>The more complicated our companies, their environments, and their products become, the worse traditional methods for managing them become. Traditional methods of leading companies, and planning what they do, are quickly becoming obsolete.</p><p>There are fields of science that helps us understand complicated and complex systems: Systems Thinking, and Complexity Thinking. You will encounter both of them in this book. I will do my best to present them in ways that are practically useful, and as easy to understand as possible, without being dumbed down.</p><p>One thing we have learned, often very painfully, is that there are no “best practices” that always work. Most of the problems you are facing today, are caused by the solutions of yesterday. You can be pretty sure that many of the problems you will be facing tomorrow, will be caused by the solutions you create and implement today.</p><p>Complexity Thinking and Systems Thinking help you to understand the causes of the problems you are facing, and make it easier to find solutions. They also give you a little bit of insight into what problems your solutions might cause in the future, and can help you reduce risks, and create opportunities.</p><p>Strategic Navigation, the business strategy framework this book is about, is based on a military strategic framework, Maneuver Conflict, created by Colonel John Boyd. It is an open system, based on systems and complexity thinking, that works well with several other frameworks and methods. You will encounter the ones I use in this book.</p><p>There is one thing I would like to encourage you to do:</p><p>I will introduce several frameworks and methods in this book. That means, I have picked and chosen parts I believe are useful to you, but by necessity, there is a lot I have left out. Do go look at the sources!</p><p>This book is a starting point. It is not the management book to end all management books. There is much more in-depth knowledge that you will almost certainly find useful, so embark on a journey of your own to find it. You will have to learn for the rest of your life, so make it interesting and fun.</p><p>It will be worth the effort.</p><h2 style="text-align: left;">Takeaways</h2><p></p><ul style="text-align: left;"><li>A system is a set of connected parts, real or abstract, that form an integrated whole.</li><li>Systems always belong to larger systems.</li><li>Systems have properties that do not exist when you examine the parts separately.</li><li>You cannot understand a system just by studying the parts.</li><li>When you do something with a part of a system, other parts will nearly always be affected.</li><li>When you improve part of a system, the system as a whole may get worse.</li><li>Systems with many connected parts usually have only a few degrees of freedom.</li><li>Cause and effect in a system can be separated in time.</li><li>Cause and effects can be separated in space.</li><li>Systems that are not continuously improved, will degrade on their own.</li><li>Things can happen without having identifiable causes.</li><li>Events can have effects that are not predictable.</li><li>You, your family, your team, your department, your company, the location where you live, your country, and the world, are all systems, and they are connected, and can and do affect each other. You cannot control or accurately predict how they interact, but you can influence, and make educated guesses.</li><li>This book is a starting point for learning.</li><li>You will have to learn for the rest of your life, so make it interesting and fun.</li></ul><p></p><p><br /></p><p><br /></p>Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-1637624869978330992020-08-15T16:45:00.002+02:002020-08-15T16:45:25.168+02:00Tempo 2.0 - Chapter 3: Your company is a system and section 3.1: The Monty Hall Problem<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhn_a6UwJfi-wWJ5nGxkA8IcXM3TKHLWVUm1JdMZ6OCgC9f7TXwvQdCShzseIGR5CK8TOVKx1xZ6h7JsgdNiJd88-22alTzMgE3zZNUGaY6GqsAOPcPTpIvRjC2wmFh_qVaq8s3/s1024/Monty+Hall+Render+All+v01+LoRes.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="683" data-original-width="1024" height="267" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhn_a6UwJfi-wWJ5nGxkA8IcXM3TKHLWVUm1JdMZ6OCgC9f7TXwvQdCShzseIGR5CK8TOVKx1xZ6h7JsgdNiJd88-22alTzMgE3zZNUGaY6GqsAOPcPTpIvRjC2wmFh_qVaq8s3/w400-h267/Monty+Hall+Render+All+v01+LoRes.png" width="400" /></a></div><p><span style="font-size: 12pt;">To manage a system effectively, you might focus on the
interactions of the parts rather than their behavior taken separately.</span></p><p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">
— Dr. Russel Ackoff<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Companies and other organizations are systems. All
systems have some properties in common. As you will soon see, these properties
can be counter-intuitive. If we rely only on intuition, we will make the wrong
decision, even when we have all the information we need to make better ones.<o:p></o:p></span></p><p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"></p><p class="MsoNormal" style="margin: 12pt 0cm 6pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-size: 18pt;">The Monty Hall problem</span></b><span style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">We are used to solve problems through <i style="mso-bidi-font-style: normal;">analysis. To analyze</i> means to split a problem
into parts, and trying to understand the whole by understanding each part
separately. The idea is that understanding the parts enables us to understand
the whole. This way of viewing the world is called <i style="mso-bidi-font-style: normal;">reductionism</i>, and it has been the dominating way of viewing the
world in Western culture for hundreds of years.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Analysis is indeed a powerful tool, but it has limits.
When we try to understand a system by examining its parts, we loose the full
picture. This can lead us to making bad decisions. Here is a classic example,
the Monty Hall problem:<a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-03.1%20Your%20company%20is%20a%20system%20-%20The%20Monty%20Hall%20Problem/Your%20company%20is%20a%20system/The%20Monty%20Hall%20problem.docx#_ftn1" name="_ftnref1" style="mso-footnote-id: ftn1;" title=""><sup>1</sup></a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 6pt 0cm 6pt 36pt;"><span style="font-size: 12pt;">You are a contestant in a
game show. The game show host, Monty, puts three cards on a table. All cards
are face down. Monty tells you that one of the cards is a winning card, the
other two are blanks.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 6pt 0cm 6pt 36pt;"><span style="font-size: 12pt;">Monty asks you to pick a
card, but keep it face down on the table. Then, Monty flips one of the two
remaining cards over. It’s a blank.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 6pt 0cm 6pt 36pt;"><span style="font-size: 12pt;">Now you get to choose: You
can either stick with the card you have, or you throw it away and pick the
remaining card on the table.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Think it over before you turn the page and read the
answer. What would you do, and why? Does it matter what you choose?<o:p></o:p></span></p>
<div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-TLbSBDZVj8A/Xzf00NP6dTI/AAAAAAAB0kI/XFBMbuGdS2k1wYqi3Xo5tjH1e-lotTzbwCLcBGAsYHQ/s1787/A-03%2BFRT%2Bwith%2Bsolution%2Bto%2Bthe%2BMonty%2BHall%2Bproblem.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1787" data-original-width="1330" height="640" src="https://1.bp.blogspot.com/-TLbSBDZVj8A/Xzf00NP6dTI/AAAAAAAB0kI/XFBMbuGdS2k1wYqi3Xo5tjH1e-lotTzbwCLcBGAsYHQ/s640/A-03%2BFRT%2Bwith%2Bsolution%2Bto%2Bthe%2BMonty%2BHall%2Bproblem.jpg" /></a></div><p class="MsoNormal" style="margin-bottom: 6pt; text-align: center;"><br /></p>
<p class="MsoNormal" style="margin-bottom: 12pt; tab-stops: 26.95pt;"><i style="mso-bidi-font-style: normal;"><span style="font-size: 12pt;">Figure: A Future Reality Tree with the solution to the Monty Hall problem.</span></i><span style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">The diagram above has the solution. Read the diagram
in the direction of the arrows, from the bottom, and up, to the top.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">The diagram is called a <i style="mso-bidi-font-style: normal;">Future Reality Tree</i> (FRT) and it is one of the tools you will learn
from this book. It is fairly easy to read the diagram even if you have never
seen a Future Reality Tree before.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Boxes with rounded corners contain text describing
reality as it is right now. Boxes with straight corners describe things we do
to change reality. The ellipses mean <b style="mso-bidi-font-weight: normal;">and</b>.
No ellipsis means the content of any one box can cause the effect on its own.
Note that in a complete tree, all the boxes must describe things that actually
do exist. Speculation and guesswork should not be present in the diagram
itself.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">The four boxes at the bottom of the diagram are read
like this:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-size: 12pt;">If</span></b><span style="font-size: 12pt;"> there are three cards on the table face down <b style="mso-bidi-font-weight: normal;">and</b> only one of the cards is a winning
card, <b style="mso-bidi-font-weight: normal;">and</b> I pick a card, but I do
not look at the face side, <b style="mso-bidi-font-weight: normal;">then</b>
there is a 1/3 chance I have picked a winning card.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Analysis can easily lead you astray when you are
dealing with anything even slightly complicated. If you break the problem down
in separate parts, you end up in a situation where you have two cards to pick
from, the one in your hand and the only remaining card on the table. It is easy
to conclude that there is a 50-50 chance of winning, regardless of whether you
switch cards or not. Because of this, most people choose to keep the card they
picked at the start.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">If you follow the diagram all the way to the top, you
will see that after Monty has flipped a blank card, <i style="mso-bidi-font-style: normal;">there is a 2/3 chance that the remaining card on the table is the
winning card!</i><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Really! Please do not take my word for it, after all,
I could be wrong, or even trying to trick you. Walk through the diagram
yourself. Even better, go get a deck of cards, and try it out a couple of
times.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">The Future Reality Tree helps us combine two different
ways of thinking, <i style="mso-bidi-font-style: normal;">analysis</i>, and <i style="mso-bidi-font-style: normal;">synthesis</i>:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><i style="mso-bidi-font-style: normal;"><span style="font-size: 12pt;">Analysis</span></i><span style="font-size: 12pt;"> is
breaking down the problem into parts. That is what I did when I split the
problem up in little boxes.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><i style="mso-bidi-font-style: normal;"><span style="font-size: 12pt;">Synthesis</span></i><span style="font-size: 12pt;">
means putting different ideas together to form a whole. I did that when I
organized the boxes, and drew arrows and ellipses.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">You can think of it as laying a puzzle. Analysis is
when you look at the shape and color of each piece. Synthesis is when you put
the pieces together, so we can see the entire picture.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">In this book, I use one of the best methods I know to
understand complicated problems, <i style="mso-bidi-font-style: normal;">The
Logical Thinking Process</i> (TLTP). I explain how you can use The Logical
Thinking Process to solve problems and develop both strategies and tactics in
Part C: Navigation.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">It is fairly easy to read TLTP diagrams even if you do
not yet know how to create them, so I’ll use them whenever I want to be extra careful to show cause and effect, and to build
logical arguments.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Like all other tools, TLTP diagrams are based on
certain assumptions of how things work, and that means they have certain limitations.
We will have a look at those limitations later on, when we get to complexity
theory and Cynefin. The reason I mention the limitations now, is I do not want
you to believe that just because I show you a really great hammer, all problems
are nails. We will deal with both nail-shaped, and not-nail-shaped problems and
solutions in this book.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 12pt 0cm 6pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-size: 18pt;">Takeaways</span></b><span style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l1 level1 lfo2; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><i style="mso-bidi-font-style: normal;"><span style="font-size: 12pt;">Analysis</span></i><span style="font-size: 12pt;"> is
when you break a problem into smaller pieces to try to understand each piece.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l1 level1 lfo2; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><i style="mso-bidi-font-style: normal;"><span style="font-size: 12pt;">Synthesis</span></i><span style="font-size: 12pt;"> is
when you organize and connect pieces of a problem, so you get an understanding
of the whole.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l1 level1 lfo2; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><span style="font-size: 12pt;">We need <i style="mso-bidi-font-style: normal;">analysis</i> and <i style="mso-bidi-font-style: normal;">synthesis</i> together to understand and solve complicated problems.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l1 level1 lfo2; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><span style="font-size: 12pt;">Visual methods,
like <i style="mso-bidi-font-style: normal;">The Logical Thinking Process</i> can
be a great help when analyzing and synthesizing problems and solutions.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l1 level1 lfo2; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><span style="font-size: 12pt;">Just because you
have a hammer, not every problem will be a nail. The tools in this book has
limitations, and to use them well, you must understand not just how and when
they work, but also when they do not work.<o:p></o:p></span></p>
<div style="mso-element: footnote-list;"><!--[if !supportFootnotes]--><br clear="all" />
<hr align="left" size="1" width="33%" />
<!--[endif]-->
<div id="ftn1" style="mso-element: footnote;">
<p class="MsoNormal"><a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-03.1%20Your%20company%20is%20a%20system%20-%20The%20Monty%20Hall%20Problem/Your%20company%20is%20a%20system/The%20Monty%20Hall%20problem.docx#_ftnref1" name="_ftn1" style="mso-footnote-id: ftn1;" title=""><sup><span style="font-size: 12pt;">1</span></sup></a><span style="font-size: 12pt;"> </span><span style="font-size: 11pt;">The Monty Hall
problem got its name from Maurice “Monty Hall” Halperin, who led the game show <i style="mso-bidi-font-style: normal;">Let’s Make a Deal</i> in the sixties and
seventies.</span><o:p></o:p></p>
</div>
</div><span style="font-size: 12pt;"></span><p></p>Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-71801294468944252312020-08-12T16:25:00.001+02:002020-08-12T16:27:13.883+02:00Tempo 2.0 - Chapter 2: Strategy, tactics, and maneuver<p> </p>This is the second draft chapter in <i>Tempo 2.0</i>.<br /><a href="http://kallokain.blogspot.com/2020/08/tempo-20-chapter-1-create-time-to-think.html">Link to the previous chapter</a>.<div><br /><br /><p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 6.0pt;"><span style="font-size: 12.0pt;">“We must be able to examine
the world from a number of perspectives so that we can generate mental images
or impressions that correspond to that world.”<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 6.0pt;"><i style="mso-bidi-font-style: normal;"><span style="font-size: 12.0pt;">— The Strategic Game of ? and ?</span></i><span style="font-size: 12.0pt;">, by Col. John Boyd<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">There are lots of books about business strategy. If
you look closely at them, you will find that they are about many different
things. <i>Tempo 2.0</i> isn’t just about strategy, but strategy is an important part.
Therefore, it is important to define what <i style="mso-bidi-font-style: normal;">strategy</i>
means in this book. Strategic Navigation defines <i style="mso-bidi-font-style: normal;">strategy</i> likes this:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 6.0pt;"><span style="font-size: 12.0pt;">A strategy is the answer to
the question: <i style="mso-bidi-font-style: normal;">What is my ultimate
objective, and what intermediate objectives do I need to achieve in order to
achieve my ultimate objective?<a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-02%20Strategy,%20tactics,%20and%20maneuver.docx#_ftn1" name="_ftnref1" style="mso-footnote-id: ftn1;" title=""><sup>1</sup></a></i><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">Thus, a strategy is a set of linked objectives, but
that alone won’t get us far. If we want things to happen, we also need to do
things in a purposeful manner. For that, we use <i style="mso-bidi-font-style: normal;">tactics</i>:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 6.0pt;"><span style="font-size: 12.0pt;">A tactic is the answer to
the question: <i style="mso-bidi-font-style: normal;">How do we achieve a
strategic objective?</i><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">Strategy and tactics together allows us to make plans
and execute them<a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-02%20Strategy,%20tactics,%20and%20maneuver.docx#_ftn2" name="_ftnref2" style="mso-footnote-id: ftn2;" title=""><sup>2</sup></a>.<o:p></o:p></span></p>
<p align="center" class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt; text-align: center;"><img height="250" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAABY0AAAN5CAYAAABE4hR1AAAgAElEQVR4AezdB7QURdrGcTOKOaCY14w5ZzFizgnXiGBYwLjmLOi65qy7YsSEigEwoZjDiiiKWUTBnHOOu/Wdp7+t3prqtyffuXPv/dc590zqrq7+dc/cmaerqydzFAQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEE/iswGRIIIIAAAggggAACCCCAAAIIIIAAAggggAACCHgBQmMvwS0CCCCAAAIIIIAAAggggAACCCCAAAIIIICAIzRmJ0AAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBIBQiNUwruIIAAAggggAACCCCAAAIIIIAAAggggAACCBAasw8ggAACCCCAAAIIIIAAAggggAACCCCAAAIIpAKExikFdxBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQIjdkHEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBFIBQuOUgjsIIIAAAggggAACCCCAAAIIIIAAAggggAAChMbsAwgggAACCCCAAAIIIIAAAggggAACCCCAAAKpAKFxSsEdBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAUJj9gEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQACBVIDQOKXgDgIIIIAAAggggAACCCCAAAIIIIAAAggggAChMfsAAggggAACCCCAAAIIIIAAAggggAACCCCAQCpAaJxScAcBBBBAAAEEEEAAAQQQQAABBBBAAAEEEECA0Jh9AAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQCAVIDROKbiDAAIIIIAAAggggAACCCCAAAIIIIAAAgggQGjMPoAAAggggAACCCCAAAIIIIAAAggggAACCCCQChAapxTcQQABBBBAAAEEEEAAAQQQQAABBBBAAAEEECA0Zh9AAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQSAUIjVMK7iCAAAIIIIAAAggggAACCCCAAAIIIIAAAggQGrMPIIAAAggggAACCCCAAAIIIIAAAggggAACCKQChMYpBXcQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEECI3ZBxBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQRSAULjlII7CCCAAAIIIIAAAggggAACCCCAAAIIIIAAAoTG7AMIIIAAAggggAACCCCAAAIIIIAAAggggAACqQChcUrBHQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAFCY/YBBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAgVSA0Dil4A4CCCCAAAIIIIAAAggggAACCCCAAAIIIIAAoTH7AAIIIIAAAggggAACCCCAAAIIIIAAAggggEAqQGicUnAHAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAgNCYfQABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAgFSA0Tim4gwACCCCAAAIIIIAAAggggAACCCCAAAIIIEBozD6AAAIIIIAAAggggAACCCCAAAIIIIAAAgggkAoQGqcU3EEAAQQQQAABBBBAAAEEEEAAAQQQQAABBBAgNGYfQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEgFCI1TCu4ggAACCCCAAAIIIIAAAggggAACCCCAAAIIEBqzDyCAAAIIIIAAAggggAACCCCAAAIIIIAAAgikAoTGKQV3EEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBAiN2QcQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEUgFC45SCOwgggAACCCCAAAIIIIAAAggggAACCCCAAAKExuwDCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAqkAoXFKwR0EEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABQmP2AQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAIFUgNA4peAOAggggAACCCCAAAIIIIAAAggggAACCCCAAKEx+wACCCCAAAIIIIAAAggggAACCCCAAAIIIIBAKkBonFJwBwEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQIDQmH0AAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAIBUgNE4puIMAAggggAACCCCAAAIIIIAAAggggAACCCBAaMw+gAACCCCAAAIIIIAAAggggAACCCCAAAIIIJAKEBqnFNxBAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQIDRmH0AAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBIBQiNUwruIIAAAggggAACCCCAAAIIIIAAAggggAACCBAasw8ggAACCCCAAAIIIIAAAggggAACCCCAAAIIpAKExikFdxBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQIjdkHEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBFIBQuOUgjsIIIAAAggggAACCCCAAAIIIIAAAggggAAChMbsAwgggAACCCCAAAIIIIAAAggggAACCCCAAAKpAKFxSsEdBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAUJj9gEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQACBVIDQOKXgDgIIIIAAAggggAACCCCAAAIIIIAAAggggAChMfsAAggggAACCCCAAAIIIIAAAggggAACCCCAQCpAaJxScAcBBBBAAAEEEEAAAQQQQAABBBBAAAEEEECA0Jh9AAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQCAVIDROKbiDAAIIIIAAAggggAACCCCAAAIIIIAAAgggQGjMPoAAAggggAACCCCAAAIIIIAAAggggAACCCCQChAapxTcQQABBBBAAAEEEEAAAQQQQAABBBBAAAEEECA0Zh9AAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQSAUIjVMK7iCAAAIIIIAAAggggAACCCCAAAIIIIAAAggQGrMPIIAAAggggAACCCCAAAIIIIAAAggggAACCKQChMYpBXcQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEECI3ZBxBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQRSAULjlII7CCCAAAIIIIAAAggggAACCCCAAAIIIIAAAoTG7AMIIIAAAggggAACCCCAAAIIIIAAAggggAACqQChcUrBHQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAFCY/YBBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAgVSA0Dil4A4CCCCAAAIIIIAAAggggAACCCCAAAIIIIAAoTH7AAIIIIAAAggggAACCCCAAAIIIIAAAggggEAqQGicUnAHAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAgNCYfQABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAgFSA0Tim4gwACCCCAAAIIIIAAAggggAACCCCAAAIIIEBozD6AAAIIIIAAAggggAACCCCAAAIIIIAAAgggkAoQGqcU3EEAAQQQQAABBBBAAAEEEEAAAQQQQAABBBAgNGYfQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEgFCI1TCu4ggAACCCCAAAIIIIAAAggggAACCCCAAAIIEBqzDyCAAAIIIIAAAggggAACCCCAAAIIIIAAAgikAoTGKQV3EEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBAiN2QcQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEUgFC45SCOwgggAACCCCAAAIIIIAAAggggAACCCCAAAKExuwDCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAqkAoXFKwR0EEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABQmP2AQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAIFUgNA4peAOAggggAACCCCAAAIIIIAAAggggAACCCCAAKEx+wACCCCAAAIIIIAAAggggAACCCCAAAIIIIBAKkBonFJwBwEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQIDQmH0AAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAIBUgNE4puIMAAggggAACCCCAAAIIIIAAAggggAACCCBAaMw+gAACCCCAAAIIIIAAAggggAACCCCAAAIIIJAKEBqnFNxBAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQIDRmH0AAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBIBQiNUwruIIAAAggggAACCCCAAAIIIIAAAggggAACCBAasw8ggAACCCCAAAIIIIAAAggggAACCCCAAAIIpAKExikFdxBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQIjdkHEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBFIBQuOUgjsIIIAAAggggAACCCCAAAIIIIAAAggggAAChMbsAwgggAACCCCAAAIIIIAAAggggAACCCCAAAKpAKFxSsEdBBBAAAEEEEAAAQQQQACBtiYwatQoN2TIkLr+jR07tq0xlN1erVvs9eyzz5Y9PxMiUI7A+++/n9nP7r777nJmres0N910U6Yd3377bV2XQWXNI/Dbb79ltrc+737++efmaWQbagmhcRvaWDQVAQQQQAABBBBAAAEEEECgUGCttdZyk002WV3/DjnkkMKFtJFH//nPf9xtt93mHn744dwWa91ir/79++dOzwttX2DSpEnunHPOaeiKDBs2LLOfLbXUUg1tgxY2xRRTZNrx+uuvN7wdzbbAn376yQ0cONB99913zda0ou357LPPknbnTaQDAvHnmx5/8sknebPwfBEBQuMiOLyEAAIIIIAAAggggAACCCDQ3AKExv+/fV566SW3wQYbJIHJjTfemLvRCI1zadrdCz/88IM7/vjjXadOnZJ9o5ErSGjcSO3yl6UDS0OHDnULLLBA8lnx9ddflz9zK06pHsTnnXeem3nmmd2CCy6Y2xJC41yaql4gNK6KjZkQQAABBBBAAAEEEEAAAQSaQaCjh8ZffPGFU0/hsEcloXEz7Jmt1wYFg9oH5p133rTXpQ4oNLIQGjdSu7xlvfjii2799ddP9wn1wG0LofF9993nunXrlrab0Li87V2PqQiN66FIHQgggAACCCCAAAIIIIAAAq0i0NFD49VWWy0NU/xp2YTGrbIrNs1Cr7jiisw+QWj8vyFsOuLwFJ9++mnBgSX/WdHsofGDDz6Y2ZcJjRv3UUNo3DhrloQAAggggAACCCCAAAIIIFBngTfeeMM9//zzuX9LLLFEJnTYdtttc6dXXbqIV1spyy+/fGb9ioXGTzzxhLv00ksL/h577LG2srq0swyBSy65JLNPNDo0njhxYsE+pn1OFyRrdPnHP/6RacdXX33V6Ga0+vI+/PDDzD7RFnoa33PPPZl2Exo3bnciNG6cNUtCAAEEEEAAAQQQQAABBBBosMCKK66YCR369OnT4Fa03OIqDY1briXU3CwCzRAaN4sF7fh/AUJjLoRXzXuB0LgaNeZBAAEEEEAAAQQQQAABBBBoEwL1Co11UbHx48e7hx56yF1//fVJr8mRI0e6MWPGuB9//LEmiy+//NI9/vjjSb06HfvNN990v/zyS1l1Njo01ni56omtdVfP0SeffNK999577o8//iirveFEurjVO++8k6z7DTfc4G699VanntBa/59//jmctGH3dRr/7bff7p566in3008/1bTc7777Llm3m2++2b388stO61uvomEFRowY4XQBRG2TsNQaGqu+jz/+2D333HPurrvuctdcc01i8vDDDyfvgXh54bJb6v6vv/7qRo8enVzETWcX/Pvf/26pReXWq/XWvnnLLbck7/ta9g/N+/TTTyfr8/bbb2e2YW4jqnyhnqHxRx99lLw/5HDnnXcm7+GW2idaqqexLpg3atSoZP/Wvl5LUV06W0Pv81deecX9/vvvtVTXVPMSGjfV5qAxCCCAAAIIIIAAAggggAAC9RSoNTQeO3as69Wrl+vUqVOmx7IfF3Taaad1m2++eRIMltt2Ba09e/Z088wzj1mv6jzggAPcpEmTMlUqmJhhhhmSv8knnzwzv9rqX19mmWUK5j/qqKPS1/w0f/3rXwumsR4oRNVFtGaZZZbM8uQw11xzudNPP91988031uwFzyl422uvvdyUU05p1qX6ZppppuQCf7p4Vz2KAn+/vv523333TapW6CMDWfltqtuppprKrbrqqkmQXW4bFBgNGDDALb744i7eNtNMM43T/njeeeeVDD3POeecTHvvvvvuJJzfbbfdCuzmm28+t99++7n11lsvmUfLCddD93WhRL/eun300Uczq6SgfvDgwW7llVfOzB/WN//88zvtRwpy84rC5nB5ur/KKquYk6v94bQy8kUHE7Reej+EbZhxxhmdHEoNNaH9KKxb9xU6x0XvtXi6V199NZlMtzvuuGOyj4dt0P6rddKBo3LLAw88kOwD8b4v03322cdpX1TZc889M+2x2l1qudrXtF6dO3cu8PPrMf3006fLOeyww3Kr+/77792gQYOcNYa66pp55pndOuusk4TguZVU8ELv3r2TdsXb3bc73FbaZ32Rn58mvP3kk0+SYF7rsNxyy2Xem9oHjz/++LIDXx0AOuGEE9yiiy6aWZ4+f/Ueuuiii1r8YIBf75a6JTRuKVnqRQABBBBAAAEEEEAAAQQQaHWBWkLjyy+/PBMIhEFEfF8BlXoKFyvqkXf11VcnoWg8v/VY4ZKmD4t6l1rTWs8ttNBC4azukEMOyczbv3//gmnCBwoSjzzySPMiWtbyZp111qSHalhHeP+0004rCDytOsLntP71GAv3tddey6z3Hnvs4T7//POSIanacNZZZ5UMgDSO7xprrJFZTrg+/v4mm2yS9OYNbcL7f//73zP1DB8+3B100EGZ51XnSiut5FZffXXzNb/M8FY95sOi3vLdu3cve37V1aNHj9yDBMOGDcvUtdRSS4WLTO/HByIUuKsn8XHHHZepI1wH3V9ggQWKhrYKy+N5rAvh6QBCPJ16h+v9rEA0fi18rIML559/fro+1h2FjFqf+EBCWI/u68wB9eTdeeedM8vUgY9Ky5lnnpmpJ16mf6zg3CovvPCCW2yxxcquR23/7LPPrKrKfm7XXXcte3m68KMveaHxu+++m4Tyfl3zbjfccMOSbddBLx1MyqsjfH7LLbcsWZ9vezPeEho341ahTQgggAACCCCAAAIIIIAAAnURqDY0vu2220oGPGE44O8rQCp2YTkFtH7acm8VfKk9vjQqNFZPUoWR5bbTTzfHHHM4K5hT6OmnqeRW66+eq7UUKzTeaKONnILMcttSrEe2ekSr92u5dWm6Oeec06ldVrFC40033TS3/nPPPbfq0FgBbbG6i63TCiusYDXf1RIa60Jnu+yyS+66xu1Zeumlc3tu1xIaH3744Ulv83h5eY91BkBe0dkKefPFz2v91YM5fr41QmP1bs/r7Ru3L3yszwANv1FtqXdoXMn7XL2884rOPFHv7HBdS93v2rWr2bs9bxnN9DyhcTNtDdqCAAIIIIAAAggggAACCCBQV4FqQmONz7vwwgtnggEFUOphpl6J6tU59dRTZ6ZRgHDqqaea66AhHqyAQb0Pu3Xr5jbeeOPc08inm266tMdao0Ljs88+22yvhj9QqKXT0a1QTuuosDkc51TBpIKkeP3XXHPNZBiOK6+8MunNu9VWWyWnpcfTLbvssgX1mcBFnrRC43gZSyyxhFNPw7yepepxbIXhWs911103s26qX+unoSPUs9ga4mT77bc3W22FxnF7/WPtPxqzttqexvfdd5/ZdvUA3nbbbZ0CPAWZfnnx7RdffJFZh1pC47h+vTf23ntvp+0Tv+Yf5x1UsPZPaxtaPY193bqdbbbZEgcNlaH9IHzN31cwbJVnnnnGnF7z6fNJw1Jsttlmufudr7/RobHGLtd6++XHtxqSRgc+4uf9Y22vascmr3do7NukbbfWWmsl+5M1tISm0+e6Nc6x3ud6P/u6wlvVuf/++yef4db/BR0EaYuF0LgtbjXajAACCCCAAAIIIIAAAgggUJZANaGx1SNWvUh1waqw6GJWCtXC8ED3rZ5qCqKtXrsKLp5//vm0Wg0TcOONN5q9nE8++eRkOl0kTwGS/qwgTWGvf11DJoSl3OEpFEJq3NB43RR+6mJxvuj+0UcfnZlO84VDdVihrYaHsIrG241P45999tkLnKz5ij1nLd+vm3ohhj1+FXArtI3boOm33nrrzGJ0QTBfl7/VUCW6iFdYFPZbByN0wbm4FAuNFQ5ffPHFyYUTdfq7AkcVXVRQ2/3EE0/MtEdj0fp9Qre6sKMvmt+3298q5Iovbqgxda3AVAdD4lKP0FjDVKitYbngggsybVWb83qB1xoaa3718g8vbqbQ2eptqqEy4qKg0Rr2Q+8tXXAxLBoqRQeO/DaIb2OLcN68+7rIpubT2Q9xfXqsQFuv60/j/oYlr/e5hp/QvqZ1058+F7fbbjuz/mOOOSassuz7+vxRmzQGcdxujQPv26xbXRTSl7zhKVSHDuzEY65r2Jm4fj3W0ERx0QVQ42l1YOX+++8vmHTcuHHmQRa9/9taITRua1uM9iKAAAIIIIAAAggggAACCJQtUE1orB52CgJ1YSSFhOplqfDCKlY4poAuLgqC48BBoaTV61Hz7r777pnp1dtWgWZYNAZqXK+WlVfKDY379euXqVcXi7IufqbxWuMwVOumnne+DB06NFOfQimrPs2jUFTjHyt4/eCDD2rqZaz68kJjjcGcdzE1XdAuttVjhUK+aHsoLIyn00WwrPLII49kplXwG5e80FjLintvxvvEJZdcklnGBhtsEC8ifazQ95///KfTNl977bXdIosskoz1nE4Q3LGCxGuuuSaY4v/vWu+Lcsc0lqWGRLAugqiQUm2MvfMOQNQaGms7WEUXmIvboLMB4vKvf/0rM53mu+yyy+JJk8d6P1j7k+ZRQFptUQgbt1ePw8A1rDvv/aLPD22DuOg56zNDBxms7RjPn/dY7/+43fo8zit5obGC5jgUVx1qtz5X42Xoop5h0QEU66Klef8XFCTHdeadVRAup9nuExo32xahPQgggAACCCCAAAIIIIAAAnUTqCY0rmTh6mUXhwPqfRYHK+oJGU+344475i5KvTp79+6dXGBLFy3Lu7BUS4XG1oWeil3sSyHhgQcemPTQ01im33//fcG65Q2poR7cO+20k7v22mtzg8qCiqp8kBeCxeFQWL0CNfUYjrfbddddl06mAwzx6xq+Q0F6XrH2SYVdYckLjeVUqlQaGpeqz7+ucFo9R+P1PfbYY/0k6W2toXF4wCGt9L93rKEkFGZbpZbQWMOpxIG8X0bekB5hD25Nq4u0xV7zzjuv09kCeUWBcjyPHjcyND7iiCMybejSpYuL99NwHXTwRQdh4rbrYnzVlnqFxv4sDasdOmgTt1kX/wyLztiIp1Fv87g3fjiPNY6yzk5pS4XQuC1tLdqKAAIIIIAAAggggAACCCBQkYAV0PXp06eiOsKJNX6rTitXQKoLcMVBgn8ch4ZWMKFTo2stLREaK/C2xvUdPXp01c1V+GbV6b10q4BPvUjPOOMMp4uKxcF71Qsv0tM4HJbCqt867f6kk05KJ1WgH66D7msM3mJF4/PG88TtyAuNNdxAqVKv0Fj+L7/8slOvafWSzBvfVmPyxqXW0HjgwIFxleljhdSxnw5yWKWW0Fg9UPOKhhSJ26DH7733XsEsVsiu4R2KlTfffNOsu5GhsfW5qSC5VDnggAMybc/rBV6qLr1er9B48ODBuYvba6+9Mm3WgYmwjBw5MjONPnuLld122y0zz1tvvVVslqZ7jdC46TYJDUIAAQQQQAABBBBAAAEEEKiXgBV+VBIaK+wcM2aMU1C48sorZ0IAKzjSc3EPxcUWWywz75AhQ2pezZYIjTVOsbVe6lVbS7HCTGs5/rk//elPTuFh3HuzmjZYPY01hEaxHp9azsEHH5yxUBjki9UrVBfC0qnseX+dO3fO1PnAAw/4KpPbvNC4WM9GX4HlXGx4Cj+fbjXm66233ppcKEwXOvPbotit1Su41tBYw2XkFWtoCF2Y0Sq1hMY9evSwqkyee/fdd00bPR+Wnj17ZqYrNc6v9knLu1GhsQ4W6AyAuA1XX311uGrmfWvM6VLhqlnRf5+sV2iscdLzinUWiC7EFxYdOIk9dEZB3ntcz1vvc40t3ZYKoXFb2lq0FQEEEEAAAQQQQAABBBBAoCKBWkJjnVo+55xzZsKCODywHoe9ZBX0WRcQ0ynutZaWCI2ffPJJc511kb5ai04Tt7yKPTf33HM7XZywlmKFxhpGpFTRqfVx29Zcc810tsMOOyzzejx9OY/jnpBWaKye2uWUakJjDTuwww47uKmmmqri9enbt2+mWbWGxnfccUemTv+EhuiITVsiNA4PDvhl+1sdyIjboMdxaKyLFsbTqSd9qWL1ym9UaKz3edxmPdZ43KWKdRFRhavxQbRS9fjX6xUaT5o0yVeZubU+k+LQWGeWWCaVPlePA4WZFWjBJwiNWxCXqhFAAAEEEEAAAQQQQAABBFpXoJrQWIGvFST4gEAB8BprrOF0mvydd96ZCRPUgzUsqk8BpZ/f395www3hZFXdb4nQWEMS+DaGt3EgVlWDnXPPPvus0ynhCpPC+ovd10XGXn311WoXmXshvPiicvECdDHEuF26OKIvGvs0fr2ax7roX1is0Fg9r8splYbGH330kbP2I78eGpZCgbIuTnjQQQdl1rd///6ZZtUaGj/++OOZOv0T1kUlWyI01kXf8kpeb+D4PbLZZptlvA499NC8apPn80LbRoXG+rzShQj99ve3d911V9F260Ur0NcYztWWeoXG1kXwfJusC17GobF1AVHvUsnt2Wef7RfbJm4JjdvEZqKRCCCAAAIIIIAAAggggAAC1QhUE1PgTtEAACAASURBVBqr16cVBCgs1GvhuLI6nT+eVr0147LaaqtlpqtHgGCFfQrV8ooVfsShny7WpOA7Xi9d4K6eRRf3U1s1Ju5CCy2UWV68/DCsrbQdVk9j1V8qiLPGH9bp7L5oGIW4nRrG5OGHH67oT+PYhsUKjVdYYYVwktz7lYbGVm9YDU2hcFOn04dDYujCgfH6KkiOS62hcbF9rVGhcXwxtHAdyw2N1Qs79tp2223DqjL3q91XMxUFT3z44YeZdqhdutijVRZddNHM9Oecc441acFz1sE2BefVlmYJjS+88MKMhw4cVvo+1wX12lIhNG5LW4u2IoAAAggggAACCCCAAAIIVCRQTWi80047ZQKCvFPKrYtWqQdtXHQxqDg86tWrVzxZ+li9/dT29ddf3+niUgon1fsyHiLCCo3joQ7SSp1z5YTGmn7BBRfMtPfKK68Mqyq4//bbb7sFFljAbbHFFk5hm3ocjh07tqLT0nUKuZax0UYbZZYtO40TWm3JC+KKWWlZujBfvN0UyvqiIUbi18vtEezrsG6t0LjccYmt0HidddaxFuOs8avVK17b0yqHH354Zn2tHrmExv+vZw1vMuuss7rvvvvO4k2eU6/zeJ/S41IHOHIrdM7lhcY6cGOVTTfdNNOGbbbZxpq04LmNN944M1+x8L1gZuOBFRoX+xzQMCuWXa09ja0zShZffHGjxe3rKULj9rU9WRsEEEAAAQQQQAABBBBAAIFAoNLQWL0qFerEwUPeReA0zmc8rXrpxmN4nnLKKZnpdAp4XmijwDWuV8NiaCiBsKi3WzxdsYuIlRsaW+GPeroqzLbK+eefn2nHEksskUwviwkTJiRDeah39b777uu6d+/uHnroIauq5DkN3RGvl1x/++233HmKvZAXGi+55JIFPWnDOp577rlMG9SmkSNHppMpXI3bqcd5AZ96pvfu3dspFB4xYoR76623MvuKKrdC4+222y5dbrE7V111VaZN6v1slZtuuikz7VZbbWVNmjy3yy67ZKbv169fZnpC4/8nUU9ta//IOwilz4OZZprJnCdvn8rgG0989dVXZp3xcBp+1kGDBpnTP/XUU36SzK31Wah1r2UcX6tOfT7nlZYKjfX5FW9HXWRR71+r6GwUnaWgnvkKnNXDOP6fYM3XbM8RGjfbFqE9CCCAAAIIIIAAAggggAACdROoNDTOCx10Uby4/Prrr05hXBwm6LHCwbC8/vrr5kXGevbs6TQcRFhU71prrZWpd8sttwwnS+736NEjM516N+aVckPjvCE6zjrrrExwrEB99tlnz7TDB2O///67m2+++TKvL7300rkhsNWzb7nllstbrZLP54XG2lYamzoOdNQTVL28422rXo5xb2/1ro6nU+geDuvgG2hdOE8XPVOP37BYobHGFS6n3HLLLZn2LLbYYpntprq0PeO2qz3ff/99ZlHq6a6gLJ4+Hv9VMxIa/z+fDrJYnxEawkZjRIcHYcaNG+esYSG8dy2hsT5TfD3hrcYvt4pC5k6dOmXm0X70yiuvZGZ58cUX3cILL5yZXmdCVHugRwvR+Odhe3VfZ3LoM8UqeZ/ftfY01rKsz1q99+PPDk1rXThPYXc4tJHV/mZ7jtC42bYI7UEAAQQQQAABBBBAAAEEEKibQKWhsRas4QXioEJhiXrZKeRRGKgecOr5GU/nH1un9+ddNE1hqELCW2+91e2///5OFx7z9YS3ej0uVhu6du3qNAbniSee6P785z8XzFJuaKwgZM011zTbsfnmmyeBl3oDb7/99ma4pHDxgw8+SJdtjQmqddMF8dTjWGPEqqgntXq/LrXUUpll/+Uvf0nrq/ROsdBY7VD4o/UZM2aM0wECa/maTr144/Lkk09m2qpp1113XafeygrN3nnnHXfuueeaBw60zeNSS2hsndKv9mjsagWV2ifUZhVreA1NqyFRfNCmoEsmuqCZXov/rDFrCY3/t0VvvvnmjJk3nHPOOZ2GgtDni38u77aW0FitsS48qeFX1KtYIWd8sOmoo44y26SLUmr/uO6665JhaLRfWRfO05kR2v9rKXnvWx1s0xkV6s07dOjQdBEtGRpr/GJr22y44YZOgb+CbH3u60CMdXDFGvs7bXiT3iE0btINQ7MQQAABBBBAAAEEEEAAAQRqF6gmNNbwCVY4oOc05MLcc8+d+7qf7/nnn880Xr1Xy5nX1xHe6uJZVs9VXZQtnC6+r+AmnK/c0FiNV+BjXRAvXob1WMFJWNQ7Vz2LrWn1XOfOnc2ein76Ll26uPfeey+ssqL7eeGTr7+c22WWWabAMmyAgtO8Oqywzk+roQisIQJqCY3Vq93Xn3frx6dWIDzjjDOa06s3rC7gqNu8evS8LqQXF0Lj/4koTLSG9cgztc4y0LS1hsbdunUruh3jMxl0sCOvLXltD58/5phj/odQ5T2FwMXeP1recccdl9bekqGxDhgqIA7XMbxfrJ0aJzweWihtdBPfITRu4o1D0xBAAAEEEEAAAQQQQAABBGoTqCY01qnZ1nAKYUDg7ysEVo9S/9jfXnDBBWbD//Wvf5kXmfPzWbdahx9++MGszzp9O64j7PFbSWisBSpcnH766TPrFy8jfKzQPTzt3jdc47Uuu+yyFdWlehV8q2d3LcUKjdUbUL2xw7bn3ddF/tSbMK9oOBJrGIK8+vS8giT1bLZKLaGx6tP408WWPWDAgHSx6jFabNrwNV0MLe5VqmEM4uFYCI1T3uSODtz07du3pLPGk9YBFutgjS66WUuxxlUPt601/MvHH39cNCgN5/f3dZBh4MCBNQ1LEa6nhmXxdVu3OlvBl5YMjbUM/W+wLj5qtcs/pzNHrIOIvs3NfEto3Mxbh7YhgAACCCCAAAIIIIAAAgjUJFBNaKwFqpdtqYBzt912S8aotE7xVw/NvKJgo1hvZh82KIw79NBD3eeff55XVRLO6rRnP491+/TTT6fzVxoaa0Zd7GmdddYpugwtV6fa64J4xcYw1broVHj1LLbaGj+n3o/1CFys0FhhtIoCzrzetmqPhuP44osvUsO8O9qu6vmteuP1iB/Ls1gIXWtorFPp55hjjtx2aP/zRQG/xp/WsANxO/1j9Yi+9tprk/1Nvd798/72mmuu8dUlt4TGBRzJAzlru1pj/ypY1HvTj9VrhcZ5B46yS7Kf0bjZxXoOqw1W0VA15513njluud/+/la98evxfg3b8dJLL7mFFloos8/5Zar3ry8tHRprOTpAos9cawgK3yZ/u9566zm1v60WQuO2uuVoNwIIIIAAAggggAACCCCAQEmByy67zKlXZfg3YsSIkvNpAgU4GjdTY8AqfJ5//vmdQsyTTjopGYfXV6KQVD3rwmXo/s8//+wnMW9Hjx6dhDG9e/d2q6yyitNF1jSOsMJozR/2EDYrCJ68++67XZ8+fZLergsuuKBTj9CTTz45CUQVpPgycuTITDs1Bm6pop6Sd911lzv11FOdxhNdcsklkx7TG2ywQbLciy66KLc3tFW3euwpiOrVq1fSk1Fjumr9FWpp/XXKuXpl16sUC421DPXi1JAa6tUoP/Ue15iuw4cPNy90Vaxd2m6aT9tQY05rjOzFF1/cbbLJJklv03LWSxedi/cnXeCukqJ2aBxtXZRPPec1fq0Ce/Ue1xAWcdG4y7pQn4baUEingyYaM1bjIOtih75obO+4bbfffrt/OblV/fE0l156acE0/oEC63jacHl+On+rEC6e/vLLL/cvF9xa70vrIIwuvBjXOWrUqIK6wgf6bIin1+O4x3U4T3j/ww8/TMbi/cc//uF0MbrwYmr63PCho7/VRdTqUfRZpbMgdtppp2QcZYW8e+yxRzLetsYWL1Z0MT19duo927179+R9ouF69Hlw2mmnJZ8PfmzyYvVU85pc9bmrz1+9P1dddVW33377OfmF4yZr+dZ2sS7s6NuhsxjieW677Tb/cu6t9lEdHNHnrA6k6H0uD41R3a9fPxcerMutpMlfIDRu8g1E8xBAAAEEEEAAAQQQQAABBBBAoDaBUqFxbbUzNwK2gALgN954o+QBpHDuSZMmZUJjBfgUBBotQGjcaHGWhwACCCCAAAIIIIAAAggggAACDRUgNG4oNwv7r4Aucuh7C88111zJhQXVM1fDVOQV9Xr28/hbDZFCQaDRAoTGjRZneQgggAACCCCAAAIIIIAAAggg0FABQuOGcrOw/wpoHOO8saUfe+yxAidNO2HChGSYFh8W+1sNK0JBoNEChMaNFmd5CCCAAAIIIIAAAggggAACCCDQUAFC44Zys7BAwLpwoA+DNQauxo1WT2JdSNI/H97qAoXqsUxBoNEChMaNFmd5CCCAAAIIIIAAAggggAACCCDQUAFC44Zys7BAYOLEiW622WYzA+EwHM67/7e//S2ojbsINE6A0Lhx1iwJAQQQQAABBBBAAAEEEEAAAQRaQYDQuBXQWWQq8OCDD1YcHE855ZSub9++7pdffknr4Q4CjRQgNG6kNstCAAEEEEAAAQQQQAABBBBAAIGGC/ixYueZZ55kzFjdzj///A1vBwvsuAI//PCDu+SSS9wiiyxStNfxLLPM4rbZZhv36quvdlws1rwpBAiNm2Iz0AgEEEAAAQQQQAABBBBAAAEEEEAAgY4g8P333ycXvdPF8G666SY3bNgwN27cOPf11193hNVnHduIAKFxG9lQNBMBBBBAAAEEEEAAAQQQQAABBBBAAAEEEGiEAKFxI5RZBgIIIIAAAggggAACCCCAAAIIIIAAAggg0EYECI3byIaimQgggAACCCCAAAIIIIAAAggg0NwCv//+u/v111+bu5G0DgEEEChDgNC4DCQmQQABBBBAAAEEEEAAAQQQQEAC//73v9s0RFtvfzPiP/LII+6II45w3bt3d507d3ZTTjmlW3TRRd2WW27pDj/8cDdp0qRmbHZd2lRsf7rwwgvd3nvvXfB377331mW5p512WkG9Ws7jjz9el7rrVckLL7yQaePRRx9dr+rbZD233HJLxuTqq69uk+vSERpNaNwRtjLriAACCCCAAAIIIIAAAgggUJPA559/7vr16+euv/76mupprZk/+ugj16tXLzdixIjWakK7XO7NN9/spphiCjfZZJPl/r3xxhvtbt3feecdt/POOztdyC2vbLPNNhmTs88+O2/yip5fe+21M3U3W/h49913Z9q42GKLVbSe7W3iI488MmOyzz77tLfVbDfrQ2jcbjYlK4IAAggggAACCCCAAAIIIFBvAQ03cNFFF7lZZ501CTsGDx5c70W0aH2//PKLO/PMM90MM8yQtH/48OEturyOVPkDDzyQ9CouFhjLvVhv3Lbm9eOPP7qTTz7ZTTvttMn+RGicvwUJjbM2hMZZk2Z+htC4mbcObUMAAQQQQAABBBBAAAEEEGg1AQ07sMwyyxT0jGtLofE999yTDJMQhpqExvXbnQ4++OCCfSN0nn322ZPX1llnnfotsJVruvXWW90CCyxQsM6ExvkbhdA4a0NonDVp5mcIjZt569A2BBBAAAEEEEAAAQQQQACBVhNYddVVCwIyhYJtKTTWuLphkKn7hMb125222GKLjO+GG26YjmH8888/u08//bR+C2zlmnwQHu5ThMb5G4XQOGtDaJw1aeZnCI2beevQNgQQQAABBBBAAAEEEEAAgVYTIDRuNfo2sWCNTxsGqLo/aNCgNtH2ahrZTKHx+++/7958882Cv2+//baa1WqxeQiNs7SExlmTZn6G0LiZtw5tQwABBBBAAAEEEEAAAQQQaDUBQuNWo28TC55uuukyofGzzz7bJtpeTSObKTSupv2NnofQOCtOaJw1aeZnCI2beevQNgQQQAABBBBAAAEEEEAAgYoFXn75ZTdkyBB3xhlnuP79+7s999zTHX744e7ss892N910k/vmm29y6/zpp5/cU089lfx169YtEwqecMIJ6etjx44tqEfL9fP6W38RtHfffTfphfqXv/zFXXfddUWHLfjhhx+cxo8999xzk3bvvvvubp999nFHHHFEclG70aNHuz/++KNg2f7Bd999l7Zh3nnnzbRfJr5tL7zwgp/NvNVFz7SsSy+91O2///5Ogc8NN9zgXnnlFacLBFZTPvzwQzdixAh30kknJXVeffXV7q233nL/+c9/0upUv2+jv/XLU29S/1x4W04v0wkTJmTmHT9+fLrccu7IzC936qmnzvhee+216euazm//vLq1/H/+85/u2GOPdXvttZc7+uij3Y033ui0L/322295sxU8/8knnxQsU8vVcyral+666y530EEHudNPP92p/aF1QUXGg6+++iqte6aZZsqsr/YN76E2h2WbbbbJTK/3oC96rz3xxBPJPt2nTx933nnnJY/V5lLFeq+VGgpEy7v33nvdZZdd5o477rjkc0HvR+2L//jHP5L1qMSmVBtLhca6SKXs9D7X+mv7jBo1yn355Zelqs59/cUXX0zer9qP9Ll3/PHHu1tuucW9/vrrVb9ntTC5PP3008lFQfU5pLp1QcTbb7896e1daj/3Da4kNP7ggw/SfcvvY7p97rnnfHXctrAAoXELA1M9AggggAACCCCAAAIIIIBAYwQUJmy11VaZoCoeQqBz586ud+/e7p133sk0TCFePH3e4/nmm69gfl30LJ5Wwd+DDz7opppqqoLXJp988iQ0DStQQHfYYYe5WWaZpWDauE49nmuuudyjjz4azp7cV7BjTW89p4v8WUUB0cUXX+w6deqUW9eMM86YhN/W/NZzCuz69u2bW58CeoW6Kuuvv35mOtmoKBTX9ovXR4FjsaJ1soaTCEPMYvP715ZddtnMsuO2hI8VDFpl2LBhztpfwnnVk/mss87KPUDg67388sszbbryyiudgnSrvTqY4D19HXm3ClnDNhW7371794JqioXGat+0005r1q19Sz7Fytprr52ZVwcgrKKxpS+88ELXtWvXzDzx+iy11FJJqFyP8LhYaPzQQw+5Ll26mO3RZ4UO7pQbxKqtOhC18sorm/X5dVTor32lknVTG3RgQC6+Hut2zjnndEOHDrX4C54rNzR+77333DzzzJNZ5pRTTsm47AWiLfuA0LhlfakdAQQQQAABBBBAAAEEEECgAQLqTWeFGcWeW2CBBdzEiRMLWlfv0Fg9/2aeeWazbQpjfFEYutpqq5nT5a3DNNNMk/RK9XXottbQ+LPPPnNbbrll2e1QL+hSvXxfe+01p4A6bz3883PMMYcbM2ZM0dBY66geuX4ef7vGGmuEDJn72g5+Wn87xRRTOPV8rqRYIayvz7qNQ2MFmOrdak2b95zWTT1F84oVGqs37WabbWYuZ/XVV8+rKvN8vUPj0047rejBg9BgwIABmfb4J8oNjX/99Ve35pprmg7hsuL7OjOhknDVtyu8tUJjXZzyzDPPdNr34mXGjzfeeOO0x3hYb3hf772ePXuWrCuse5NNNnE686FU0WeBpg3nLXV/5513dpovr5QTGn/99ddu6aWXNpercJzSOAFC48ZZsyQEEEAAAQQQQAABBBBAAIEWEHj11Vfd9NNPb4YMpUKORRZZpGAYgHqHxgsuuKDZLvUm/Pzzz1ONrbfe2pyuVPv1ejgsQC2hsYaAWH755StuxyqrrJLbK1KhnYKyctZD06gXsdUjNOwZqx7WVn1Wz3EPfOKJJ2bm2XTTTf3LZd/WEhqr16aCQKvtpZ5Tr9znn3/ebKcVGuftd1rORRddZNZjPVnv0NgaBzpv3dUbf9KkSVazXLmh8QEHHFCVt9qkIStqKVZonLeuec/rzIm8oveW3nt58xZ7Xr2O4wNm4XIURlfyvg2XNffccxd8toX1lgqNdZBlgw02MNdJZz9QGitAaNxYb5aGAAIIIIAAAggggAACCCBQZ4H99tsvEzLsuOOO7qqrrnLjxo1zGhtTYwTvu+++mekUdmgMWV80vq56IOvPGrN2ttlmS1+Pe2yWGm4gDFbUm9cXqxespt1oo42ScU41DrOGrdDywjr8ffWy9kXBom+/TuX20/hb9eb1ryvADItCMj9deKthBgYNGpSMZ6yxja1ekrfddltYVXr//PPPN+vUEAkaH1qntGsIBvWmDZcZ3w9DY/UAXXjhhTPTFxtqYskll8xMH273tMEl7my//fZJr+m8ntM6CKHX/J+CPV/UwzReLz2Wp8I/2W633XZmaK7pVlhhhYIDHL5eKzS2lqPntE+UGvvX16vbhx9+ON1fFOLG9WpYAr8/7bTTTuGszhqews8///zzJz2utQ1OPfXUZN38a+HtX//614I6/YNyQmONDRzWpfu6mN8pp5ziFOjqc0HjkmtoE2v4BQXvfixtv9xKbkuFxvJSj/Drr7/eKdzOGw5GQ1lYRb2h4/XTY31uqXe1hoPR54x1AUNNp8+XvN7UOoPAqlsHL9Zdd13Xr1+/pBeyNc615tttt92sJifjosf1arx2FbUlb7naRyiNFyA0brw5S0QAAQQQQAABBBBAAAEEEKijwHLLLVcQcCjYDcO6cFEKM3xooXGBdfq1QjerrLrqqum0fp7BgwdbkybP5YXGGqNVAbZ6FivEPuqoo5KLk/mKDjnkkMxyFLhZgY413q9CMKtYPQWHDx9uTZpcfEtufj39rULfuB0aozkOjnU6eXxxPgW9s846a6ZOhd/+Qm2+MQrnFIz75ca3YWisebTO8TTaXlZRT/R42hlmmMHpQn+1FGtM3ryLC2qM1nhca7VJ4fnjjz9e0AwNYaELOMZt1mMN7xCXYqGxgsOXXnop2fd0wT1dIK3aYoWPjz32WG51eaGxgnUNQRCW77//3hySQEO2WKWc0Pi+++7LGOaFj2+88YbzvaC1ndSjfI899nBvv/22tfiynssLjRW+KyiOyzPPPGOOc7ziiitmevJrP7P2D73n9RkTFg19s+uuu5rTX3HFFeGkyf3777/fnFYHLd58882C6fWZljcMii7AGJdiPY11MUhrneoxVEjcDh6XJ0BoXJ4TUyGAAAIIIIAAAggggAACCDSpgBVmXXDBBe6LL77ItFjho8Kkjz/+OPNa/ES9QuO///3vcdUFjxXKfvTRR0m71Ot2zz33zB1rVz0T42BF4ZZVKgmNFUbG9a611lqZwNgvRz0N4+lvvvlm/3Jyq4A9nkaP84JVhc66IJ41Txwaa0xWq+erNZyBxsaN69SFEGstlYTGAwcOzLRBvX6LjVVsjd2scazjnsJ5obGC/Fp6ysY+1vus0tBYvWDVs94q1npoH7ZKOaGxDtTE213Drzz11FOZAxxaxujRo5MhQOJxqK3ll/NcXmis3rR5Rb2e4zbrsYL/sFjDbmiIHn2OWEWfMZtvvnmmbvUU1kGKsOgsjbgN6lGu8NkqGnZlpZVWysyjntrxAae80FgHNOJl6rF6Icd1WG3guZYRIDRuGVdqRQABBBBAAAEEEEAAAQQQaJCAFYYocFBvWPX+1bAAuhhbpeFDPULjLl261NyjVYxqu3pDakiHOFzJ641ZSWgc9sD29SvAyiuPPPJIph0KksNitTUeEiOcXvevvvrqTL1qTxwaa9oePXpkptW2jos1lITaX2upJDReaKGFMm3VBfGKFfVOtpahgx5hscJWmd1xxx3hZDXfr0dorCA7r6i9ft/zt+r9bpVyQmMFrb6e+Fbvy7333tvdfvvtuWGotdxKnssLjeMAOKxTPa51ZkLc3mHDhqWT6SyKWWaZJTPNSSedlE5j3dFyrQMt4VjZOtBm9YgvNb6zhtCI26zHcYhthcZLLLFE5swFzauhYOKzF6z14rmWEyA0bjlbakYAAQQQQAABBBBAAAEEEGiAwBlnnGEGFnGIodPiNRTEAw88kDt8RdjceoTGCq2rLbqw25VXXpmM8znPPPPkrmNeEFdJaGxdUOvCCy90r7zyivmnHqaxr4YjCIt1SrxCo2JFAVZcrx5bobHGw42nXXnllQuqV0/eeBqNwavekbUWK9C1elEriIvboMca5qNUsYY8icduzguNrV7XpZZX7PV6hMbhWN7xsqx9Sgd+rG1VTmis+aw2x9tCvbc1TI0uEFjLcBTx+lihsXpalwpCrV6755xzTlq9DoDF66DH4QUx04mjO4svvnhm3muvvTadSmNYW3WHF+1MJw7u6KCWNb6xhroIixUaW8vTczvssEM4K/dbQYDQuBXQWSQCCCCAAAIIIIAAAggggED9BHR69YYbbmiGHXmBhHowarzevLGP1bp6hMZbb7112Sv622+/uUcffTS5WJR1Ya68ddH4q1YpNzTOC3zylpf3fBzYqgd0PG2pHot5AasVGv/0009u5plnziwjHHf1b3/7W+b1448/3uKq+LlyQ+Onn3460wa56EJspUqvXr0y82rYirDkhcaWWThfpfetALbS4SkOPPDA3MXqAEW8v+ixNcRGOaGxFqRgXqGwVW/ec7pAXDwucG6ji7xghcZ5w22E1egzI25b2Iv/zjvvzLyuHsTxMBNhnf6+Nf7wEUcc4V9OxnePl53X2zud6b93NOZxPG8YdmuySkJj1aUQm9J6AoTGrWfPkhFAAAEEEEAAAQQQQAABBOokoPE21VswDi1KPV5sscUyF2XzTapHaBwHfL7u+Fbj1Fq9feP2q6di/JzCGquUGxp/+eWXmTrjZZTzuGvXrgXN+NOf/pSpVwFnsaLgy1pWXgCqIR7i6cMxpDWGbfz6+PHjizWh7NfKDY0VXMZt0ONSPU7VEF24Lp533XXXLWijFRorRLR66BbMWOGDeoTGp59+eu5S1TM6Xlc9riU01sI07IV1kUdrWf45+eVdNC93BaIXrNB4ySWXjKbKPtQ4vr4d/naXXXZJJxwyZEjm9XKDXY3l7ev0tzvttFNatzWmsg5glVOsYYLigwSVhsa6yKm1/ctpD9PULkBoXLshNSCAAAIIIIAAAggggAACCDSJr3uzTAAAIABJREFUgHoIKnTRRaF8KFLqdtNNNzUDtnqExhoOo1R56623nBXwqt0aX1TjAOsCec8++6x74oknMuul09mtYtU5fPjwzKQKZXRRtthJQwPo+XL/FGirt7QvVm/QE0880b9s3irQjduhx3mh8ZgxYzLT+xB9woQJmddWX311c7nVPFluaPzqq69m2qF1KqensS6KGHto/w6LFRprzNt6l3qExvHQGmEbWyo01jLUK10XxrOGfoh9/WMFx6NGjQqbWNF9KzSeddZZS9ax7bbbZra5Dh74Yg0hUW5PY+vA2rHHHuurdrUE0gp4vZ2/1RA3YSkWGmvYGCvc10XyKK0jQGjcOu4sFQEEEEAAAQQQQAABBBBAoAUFNOzEk08+6U455RS3/vrrlzxFXeOExsUKja+55pp4svSxNf7sgAED0tfz7vTs2TMTtmjs0euvvz4TlirE8oGMv1UPZatYoXF4Qa1wHutCbbWeGr777rtn2qoL7hUrVtCm9cwLjTW0hjWUhy4aqF6t3sjfXnrppcUWX9Fr5YbG6gXvlx/eljOmsRW8X3DBBQXttEJjbc96Fys01nAqeUVjXIfrq/utFRqHbdTF2TQetsJ3a78P27zVVluFs1Z0P29f1sXuihUN8xK2QfcHDRqUzqLhV+LX9bicMY11ZkU8r4JiX6yDUpq+nDGNrQv4xZ8heaHx3HPP7bReCpnj9mm/y3v/+3Zz2zIChMYt40qtCCCAAAIIIIAAAggggAACrSCgU/J/+OGHzJLV01C9bBUCxaGEHofBiZ9ZvVLjacPwxk/nb63QOO5p56f1t9bFutRrUBfBs4rVE1BjB1vFuujVLbfcYk1qjgl98cUXm9OW+6TGDo79ZphhBqdxi/PKFltskZlHdRQLjRRExsvRWMZx+Kae0MWWndemvOfLDY01v3pRxm3U0BrFyrvvvus6deqUme+hhx4qmM0KjfN6nxfMWOGDLl26ZNpSrCdus4XG+lywhuyYOHFiMhTFvPPOm1m/+eabr0Kl/02eFxrrYFBe+eabb5zeI/G+Eh5g0AExK6A96aST8qpNntdFGvXZEtcdhs0Kh62zDkqNRa6Li8b16nEcNluhsUJh9cZX0bpZwXY5Z2wUXXlerEqA0LgqNmZCAAEEEEAAAQQQQAABBBBoBgH1ZDvhhBPczjvv7HR69HTTTZfc5o2DqZ6pGlc0Djh06npcrIvr6eJ5ecUKja+88sq8yZPnn3/++UxbNLRAXvuPOuqozPTLLLOMuYwVV1wxM21eT2lr7Fz1tLZCNi1s//33d0svvbRTL+mBAwe62267zSl8C0veBeAUAGk7xGXEiBGZ9vrtVCw0/vjjjzNBlxUAbr/99vEia3pcSWh8zDHHZNZN4ZzVw903SuNh+/X3txp2RWNQh8UKjbt37x5OUpf71hjV2mZ5pTVDYwXEOmDTv39/pwvbKfyVYbHA1tr/FGha+2reOofP54XGel/98ssv4aTpfY3H7bd1eKsDCGHp06dPZrrOnTu7Dz/8MJwsva91sC6CpwMB8cVArQM3c845p/v222/T+sI7+oywPmu6desWTpbct0LjeLgVnQ0Rrrvu673ig+VMpTzRYgKExi1GS8UIIIAAAggggAACCCCAAAItLaAQNA4Y9DivZ5x6vlnjHVvh3dZbb52pO+zxFoctVmhshdGhiRUaq/0KYeMyevToTDiqaRWQWkXBYWxz8sknp5OG7VfYNM0002SmV4gVh2Z5YXB4ATq/EKsNalOvXr2SEEgXg9Np6eolafWC9O0vFhprWda28vP627yhOXxbK72tJDTW/uXbEd7OM8887vHHHy9YtC4G2LdvX3N6q/e3FRrHF8srWECVD3SQIGy77oc96cP9SYtozdBYQaZ1cEjDIGi4EKtoKJt4/VpieAotY8stt3TazmEZOXKk2YM4vFCdn17DgsRt1eNFFlnE6TMlLFrfP//5z+b01pkHN998szmtLiqpccLDos9TjQlvtcUauqSc0FifN+utt16mTi0n/ixSW84880yncD/822+//cJmcr9KAULjKuGYDQEEEEAAAQQQQAABBBBAoPUFdOE169R/9brT+LnXXnut0wW27r//fqfhEhR8xAGHQlerR+2uu+6amVY93tQTb4011nDqfReWakJj9TjUxe7iNmmdLrroouT07scee8z169fPqQdyPJ0eKwS3yuabb56ZXsGwAlb1dtSYx2HRcAlW/Zr+hhtucDpF/rDDDnNdu3bNTKcei9ZYrXfddVdm2nAZ1rqHr/v7pULjO+64o+hydIGtONQM172a+5WExqpfBxz8+oS3uuCghtJQ0KWLoM0111zmdNq/rP20UaGxNVyLevarzbr4oPapsLRmaKx2XHfddaajeubrs0Bhvca+1tkA6tVtHUwqdmZBuK7W/byexn7bzz///K53795OB1vUC177gX/N3+r9EQe1WpbCU+vzSfNpHn0+6f2szyrr4nKabrvttjNDWB3IUe9s34bwVvu8DgTp80gX6JxpppnM6XTQwyrlhMaab+zYsWa9Mo2LDoSFbdR92VBqFyA0rt2QGhBAAAEEEEAAAQQQQAABBFpRQONpWgFeHCRYjxWw6OJPVjnvvPMyYURcRxiUVhMaa7kKt+N6K31sjeOs3rvF6tEYv2EI+d5775mBcLE69Jp6CCtUtorCLeuCdHl1WsNkaNpSobEC4TnmmCN3fQ844ACreTU9Z+1zGjc2r6iNGn86b92LPa8xbMePH29W3ajQ+MADDyza9vggSmuHxhriZYcddija5mLmGp4mb5gYc0NET1qhsS5aaY0ZnNcODa+RV9SDeIkllqhq/bStdEHAvPLJJ5849crOa1ex5xdeeOHcoSzKDY3Vrj333DOzfI13HB/8ITTO24q1P09oXLshNSCAAAIIIIAAAggggAACCLSyQDXBscKbyy67LLflGivX6v0XBiZhkFdtaKxA1I+5GtZt3Vdv1U022SQTpuiU8rioh6JVR/icwqGwvPLKK7k9XcP5/H0FxoMHDw6rMO8r2CxmqfBePUN1uruvO7zVhQxLlUMPPdScV/WMGTOm1OwVv15paKwF6EJn1ljF4brG99XrM+/CiKqzUaGxDOO2xY/DsXpbOzSWjc5E2HHHHUu2O14PhbGfffZZxftEOIMVGp966qnu3nvvNXs1x21Qz/N4CIuwft3/9NNPzWFA4rrCx+rVrPlKFe1z1jARYV3xffWc1j6eVyoJjXUQy3qPnXPOOQXVExoXcNT1AaFxXTmpDAEEEEAAAQQQQAABBBBAoLUE3nrrLXfwwQeXDGQUdO6+++7JWLql2nrPPfckY2XG4Yh/rKEjfKk2NNb8utBVsXBrwQUXdLron4o1jrOGkLDK0KFDc08hl4PVM1Yhtk4/zzv13K+7xhgN199afvjcqFGjnC56FfaO1DAc6lHo101Bna/f3+r0+nLKSy+9lJlXdSy++OLmafjl1FlsGivQsjytOjS+cqlAboYZZnCXXnppQW9wq65GhcbqNX711Vc7Df3it014q4MC4QXbmiE0lpeGW7j11lvdWmutZbY7XAcNVTNo0KAkbLasK3kuLzRWHc8995xTj9xw2f6+hvwo50CMb4u2iw64WMOH+Dp1q/eRzgjQ9OUWnYmg8eF1kdGwrvi+xubWUDSlSiWhserSRU7jZelzKTzYRWhcSr361wmNq7djTgQQQAABBBBAAAEEEEAAgSYU+Prrr93w4cOdLhp21FFHJT07Dz/88OSxgg2NcVxJUa88XTDquOOOS8adVb0a0uLbb78tqObll192Tz31VMFfOT36wkrUm1MhjXrNalzQK664IrmwVXhK9o8//liwDC3z2WefDaspuK+L3A0ZMiSx0Dinql/zWENahDMqXJKVxgvWUBd77713EuJoDFgFtLUUubz99tuZKnRRvDgkUmBVTlEPx06dOmXmV+/Olii6IGC8vUuZxu2QgUJfhWPyPeaYY9xNN92UXCSw3KERFKDF7VCP8ZYqCoavv/56p/eUDi4oZH3mmWdc3Bv89ddfz7RL+2JeUa/aeD302Ao5q32vjRs3Lmm7xhFW29UzduDAgcnY5zoAUqpnb17bred18CVen/fffz+dVOulA116j6tXsS7opovHhUPepBOXeUdnPuj9feyxxyYXm9R+pcBcYzcrPK+l6IDIJZdc4jSEjC5kOWDAAKeDH/qMsLaRtSz1Xo5NZJBXrM86zR9+rqpHclynNQ503jJ4Pl+A0DjfhlcQQAABBBBAAAEEEEAAAQQQQKBKAYU5CrDUW1shZjlhmIK7ODTecssty2qBwuF4Xj2u9CBBWQtjIgQQQKCdCxAat/MNzOohgAACCCCAAAIIIIAAAggg0BoCr732WibE1Sny2223XW7PRPWQjINf9Y4uVXRRMNUdz6shQygIIIAAApULEBpXbsYcCCCAAAIIIIAAAggggAACCCBQQkDjoeaNi3zBBRe4jz76KKlBF08bO3Zscnp+HPrqsU7fD4vq1fAEGoZEQ4Sod/JKK62UCYw1r4bWoCCAAAIIVC5AaFy5GXMggAACCCCAAAIIIIAAAggggEAZArvssosZ5vpweL755nNTTz117jQazzge21fjp04//fS58/i6l19++ZIXkStjFZgEAQQQ6JAChMYdcrOz0ggggAACCCCAAAIIIIAAAgi0vIAuBrbooouWDHh90Bvf6oKDVunWrVvROqecckp3//33W7PyHAIIIIBAGQKExmUgMQkCCCCAAAIIIIAAAggggAACCFQnMH78eNejR4+iIW8cFquHcbHQd+ONN86tb4oppnA33nhjdY1lLgQQQACBRIDQmB0BAQQQQAABBBBAAAEEEEAAAQRaXGDcuHGuT58+bo011nALLLBAwbAUXbt2TZ7fdddd3TXXXOP++OOPou057rjj3BxzzJEGx9NMM41bZJFF3CGHHOImTpxYdF5eRAABBBAoLUBoXNqIKRBAAAEEEEAAAQQQQAABBBBAoM4CuqDd559/7n766aeqa9ZF9D777DPGLq5akBkRQAABW4DQ2HbhWQQQQAABBBBAAAEEEEAAAQQQQAABBBBAoEMKEBp3yM3OSiOAAAIIIIAAAggggAACCCCAAAIIIIAAArYAobHtwrMIIIAAAggggAACCCCAAAIIIIAAAggggECHFCA07pCbnZVGAAEEEEAAAQQQQAABBBBAAAEEEEAAAQRsAUJj24VnEUAAAQQQQAABBBBAAAEEEEAAAQQQQACBDilAaNwhNzsrjQACCCCAAAIIIIAAAggggAACCCCAAAII2AKExrYLzyKAAAIIIIAAAggggAACCCCAAAIIIIAAAh1SgNC4Q252VhoBBBBAAAEEEEAAAQQQQAABBBBAAAEEELAFCI1tF55FAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQ6pAChcYfc7Kw0AggggAACCCCAAAIIIIAAAggggAACCCBgCxAa2y48iwACCCCAAAIIIIAAAggggAACCCCAAAIIdEgBQuMOudlZaQQQQAABBBBAAAEEEEAAAQQQQAABBBBAwBYgNLZdeBYBBBBAAAEEEEAAAQQQQAABBBBAAAEEEOiQAoTGHXKzs9IIIIAAAggggAACCCCAAAIIIIAAAggggIAtQGhsu/AsAggggAACCCCAAAIIIIAAAggggAACCCDQIQUIjTvkZmelEUAAAQQQQAABBBBAAAEEEEAAAQQQQAABW4DQ2HbhWQQQQAABBBBAAAEEEEAAAQQQQAABBBBAoEMKEBp3yM3OSiOAAAIIIIAAAggggAACCCCAAAIIIIAAArYAobHtwrMIIIAAAggggAACCCCAAAIIIIAAAggggECHFCA07pCbnZVGAAEEEEAAAQQQQAABBBBAAAEEEEAAAQRsAUJj24VnEUAAAQQQQAABBBBAAAEEEEAAAQQQQACBDilAaNwhNzsrjQACCCCAAAIIIIAAAggggAACCCCAAAII2AKExrYLzyKAAAIIIIAAAggggAACCCCAAAIIIIAAAh1SgNC4Q252VhoBBBBAAAEEEEAAAQQQQAABBBBAAAEEELAFCI1tF55FAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQ6pAChcYfc7Kw0AggggAACCCCAAAIIIIAAAggggAACCCBgCxAa2y48iwACCCCAAAIIIIAAAggggAACCCCAAAIIdEgBQuMOudlZaQQQQAABBBBAAAEEEEAAAQQQQAABBBBAwBYgNLZdeBYBBBBAAAEEEEAAAQQQQAABBBBAAAEEEOiQAoTGHXKzs9IIIIAAAggggAACCCCAAAIIIIAAAggggIAtQGhsu/AsAggggAACCCCAAAIIIIAAAggggAACCCDQIQUIjTvkZmelEUAAAQQQQAABBBBAAAEEEEAAAQQQQAABW4DQ2HbhWQQQQAABBBBAAAEEEEAAAQQQQAABBBBAoEMKEBp3yM3OSiOAAAIIIIAAAggggAACCCCAAAIIIIAAArYAobHtwrMIIIAAAggggAACCCCAAAIIIIAAAggggECHFCA07pCbnZVGAAEEEEAAAQQQQAABBBBAAAEEEEAAAQRsAUJj24VnEUAAAQQQQKCVBO655x7Xt29f17t3b/4wYB9gH2AfaMA+cPTRR7s333yzlT71WSwCCCCAAAIINKMAoXEzbhXahAACCCCAQAcVGDlypJtsssn4w4B9gH2AfaDB+0DXrl3djz/+2EH/+7DaCCCAAAIIIBALdLjQ+KeffnLHH398+jdgwAD373//O3ZpM4/V9t9++63NtPeXX35pM23Na+j999+f7j+DBg3Km4znGyQwbNiwdHtce+21LbbURx99NF2OPkP4UdVi1JmKb7jhhtT+jjvuyLzOE+1L4KCDDiIoanBQREjPQQr2AfYBvw888cQT7eufSrA2+h04ZMgQt88++7hNN93ULb300m6WWWZxs88+u1tyySXdhhtu6PTbcMyYMW3692GwytxtZQHtSz57OOOMM1q5NY1d/A8//OCGDh3q9L1uhRVWcDPPPLPr1q2b69Gjh3v99dcb2xiWhgACVQt0uNBY4YP/UuRv1aupLZbnnnvOrb322m0ivPrPf/7jbrvtNrfjjju2ReqCNm+77bbpPqQvnZTWFdB7wL+XDzvssBZrzGmnnZYuR8v74osvWmxZVFwosN1226X2ffr0KXyRR+1OYP/990+3t39vc0ugxT7APsA+0Jh94MEHH2x3/1fGjx/v9L9lpplmKvv/yzLLLOPuvvtup98wrVkUrh155JGt2YSSy5aROnFcffXVJad9//33Xf/+/UtO11Ym+PLLL12/fv1yf49fdtll6T43zzzztJXVqrmd6ti2zTbbpOsef35/8sknNS+DChBAoDECHS401hHk+ENLH2htqXz11VfJP9vJJ5/cLb/88k3f9AkTJrhNNtkkcT/ggAOavr2lGjj33HOn+xA9jUtptezrv//+u5tuuunS7XHzzTe32AIJjVuMtmTFhMYlidrVBHForN4pOiDEHwbsA+wD7AP13wc6d+6cfo/Sb6T2FhrfeOONLl7H+Ldgscd77rmn0/fNRhf10jzmmGPc1FNP7VZaaaVGL77s5b311ltu8803T/Yh9dLOK7/++qs766yz3PTTT++6dOmSN1mbeV6hqELyOeaYI1l3bS+rdNTQ+OSTTy74XAnfYzJr7YMx1rbiOQQQsAU6VGg8adKk9MNroYUWclNOOWXyeIoppnDvvvuuLdSEz2611Vbpeuy7775N2ML/NUn/UHXal/9H0ZLDB/xvqS1374MPPkjXRes0bty4llsYNZcUeOGFFwq2x8SJE0vOU+0EhMbVytU+H6Fx7YZtqYY4ND744IPbUvNpKwIIINCmBDSOsf+ertv2Ehr/8ccfSSebcN10X+vbs2dPd+qpp7rhw4c7hZ76PnnNNde4Qw45JAlo43l0pmSjQ67we2czh8arr756uv8UC42vu+66dLr2EBprGJdwPyE0LvzYCztZqYe1Dhi89tprTr+ldUtBAIG2I9ChQuOTTjop/XDXFYJ971d94J9wwgltYqvpC4s/oql2X3755U3dbp1SFf5DbevjF33zzTfu8ccfT/9ao+dBU2/wBjfuiiuuSPcvjUfXkl/owy/v2qcZnqJxG5vQuHHWzbAkQuNm2Aq0AQEEOopAew2Nzz333PQ7ov8tst9++7nvvvuu6KZVhxfNqx6+fj7dXn/99UXnq/eL4fdOQuN669ZeX7mh8Xvvved0PRz96fooHaHoGkbhe+e4447rCKvNOiLQbgU6TGiso83zzz9/+gH2yCOPuKuuuip9rC9MbeGCcmFvaX0Y68h4Mxf1LPb/NDSOmL6IURCol4C+/Pv9a7PNNqtXtWY94Zd3LZPQ2GRqkScJjVuEtWkrJTRu2k1DwxBAoB0KtMfQWJ1UOnXqlH5HVMeCe++9t6Kt9+yzzxZ01JlrrrmcLqTXqBJ+7yQ0bpR6+cspNzQuv8b2M6V67/vfZ7p96KGH2s/KsSYIdECBDhMa6+ie//CaYYYZnMZV0tjA4VHkW2+9tel3AY3Z6tdDY7k2e09XjWHs26vxpCkI1FNAY536/UtnErRkCb+8a5mExi2pXVg3oXGhR3t/RGjc3rcw64cAAs0k0N5CY511Fg6ZoO9s1f7GO+OMM9LvmapHF/VuVAm/dxIaN0q9/OUQGudbvfzyywXvG138kIIAAm1XoMOExrvsskv64bXtttumWywcH7gRoeY777yTXIn3ggsuSC5ucOmll7qRI0e6t99+O21TfOfnn39OxlzWuMt/+ctf0vVQYKbn9Bd/GH///ffpawrHfdHzN9xwg1PAduedd+Ze6VVh9OjRo92QIUPc3//+d6fTSjQUgI4UlrraqYZw8O1accUV0/YqCPDPf/bZZ75J5u1HH32UtO+8885Llq0ey88995yTRTVFPc01rIQuRnDiiSe6u+66yzw9TacQ+TZqnrCol7R/Tbfl9DbQemj7Xnzxxe7YY49Nlv/YY4+5b7/9Nqy6rvfffPPNZLvpAgTaZta+pSv9+nUppy3aH1555ZVk3zn++OOT9fjXv/7ltK2rKfpC/+KLL7rbb789OQVQF/q45JJLkl4g6k1fTvnxxx/Tccn1RV7btCVL+OU9LzTWPuNdNWZXWHSgasyYMU7vfdWl/eLTTz8NJ6n5/ocffpgu3x9Q0n6q97rex3oPlRrCQ+ugscZuuummZNgevWeefvrp3M+Kchqt/UTrrvexhgI6++yzk3EEX3311bLe04TG5Si3n2kIjdvPtmRNEECg+QXaW2is3y/6nub/9Luv1HefvK2k7y86U9LXtcMOO+RNmnlev5fUaenMM89Mvvfdc889Tt/TSrVF3x/1XfLII49Ml7vMMsuk3+/0mv+Ol1lohU/od9VLL73khg4dmozxfMoppyTf/8aOHVv0t4q+0/rvu2EHjkMPPTR9Xr+BVD7++OPkOf2m846zzTZbOp3q0XAGxYraqZ7fV155pdPvEA0VomCy3LOE9bvTtzf8/aZtod/m+r2r34f6jazvwPFvwLBtn3/+eVKXDiD49dGterf7ZYTjG2s4FP98/NsgrDe8r/XV2cRql36z67fDww8/7LTscoo8/TLj3+36/aTfojogcs455zidff3111+XU23RacLfQKNGjSqw0W8A357QIPw9qoxCRb+39bvjb3/7m7vvvvuSjn7FFiwr/abU7xb99tV+pnHZS2UNvs5wX46ttB31Hla98tI2D/cfX4dutS9NmDDBDRo0KJle2077KAWB9iDQIUJj9QicZppp0g8vBWm+6J9D+IE/fvx4/1Jdb/WPc5999nGTTz55wfLCZSvYVuAXF12ZNZzOur/88ssXzKZ/fH66iy66KHlNX1bCQen1+uKLL17w5UUf2PrHtOCCC6bz+3r8rXpn9+/fP/niU7DQ/z7o3bt37ry+jgMPPNCaNfkHufvuu7uppprKrGPWWWdNviiU+sLlK9c/nsGDB7slllgiU5+W0b179+QCGJpe+4lvn9WLW18i/Ou6LTY+s17r1atX7npoXGq1q9z18OtT7Pb5559322+/fUEbfXsXXXTRZHl+fg3l4F8r1vtCX6Q07bTTTptO7+fTrS4mqS9vpb7s+eXqS656y6vHRFhPfF9f8PUltlhRaB3OF/+jLzZvNa+VExrrC4pvk4bDUdGXRV1AJc9Q+2B80Kea9mkevZ/98rXt3njjjYILUeq1BRZYwBwLXV+aFN5r3/d1hLe6YKj2r3K/hKk9usCMLjoa1hPf1/tQB1T0pS+vEBrnybTP5wmN2+d2Za0QQKA5BdpbaKyLp/rvGvrdpbCqlqKD7nvuuWfy+0MBaKmiwGqRRRZJ2+Db4m//9Kc/uQceeCC3Gl00zE+bd1vrOilkU2/sYr9LteyddtopCX3jxipUzmubf15hskrc69u/Ht7qO71V9J1T36H9xevDeXRfQ5Dou6u+wxYrW2+9ddpehYAqCvfi38W+fv3ezOtV/uc//zmty08f34bjX6vzhX9d27ZY0XqoY8WMM86YzuPn9bfLLruse+aZZ4pV45588sl0/o022iiZVmHteuutl/vbdOedd666M5AWEP4G8m21bmXui/IAP43yGf2ejPcXHbTRcIRx0QEDZRazzDJLWoevy98uueSSLm/f8vWpQ42fft11102eVh6j32dWHqGhbnTRzLCoE+C8886b1uPr063ynZb+jRq2hfsItIRAhwiNFZr6N6+Cm/Bomo4gabgK//pf//rXujurp6eOqPplFLvVh1M8SH6/fv1Kzqsf2WEJQ0Edcdc/Dyu00j8mXxRs68O1WPvC1xQuqd646Gh4OJ11P/xn6uf/5z//mfulIK5jm222KRoyqU4dCdQXjXje+PHCCy/stO46mulfW2eddXyz0ttyx2fWP716ey1TAAAgAElEQVRSX8L8cvr06ZPWX8sdBdDWPza/HN0q9FNArKBa//D8a3lfPNXrYOaZZ06n89Nbt0svvbQrdcBFoeCWW25ZVn1ahgz1hS6v6IuCb4uC0JYu1YTG+gK1yiqrpO307Y1vtT3Ug6DWEobGOsihL5bxsvRYR7/Doh6/4VkB1jz+OY3pV2pcQJ3doB9Yfp5ybtX2sPdB2D5C41Cj/d8nNG7/25g1RACB5hFoT6Gxejvqe4r/3rHaaqs1DFrfc9XT1i+71O1hhx1m/pZpydBYnTfUgzMcnrFUOxWgxr9NGxEaq7NTuC2LtVOdUYp15glDY/3eO/XUU8vaToccckimg09LhcYKNxdbbLGy2uU77eSF5XForE4kxTqEeVv9JtZvgmpKPULjvn37muuvDmlhUa/zcjML/f5Vr/28zilxaKzewfFnovcJb31wHA9hE07j73fr1q3sXvHhenIfgWYR6BChcXjazK677pqxV3Dn39T6x5h32kFmxjKe0Ie5vrD4+vWhMXDgQKd/tgqvx40bl5wO07lz53QafVnQB68vCvp0Fd+DDjoonUb16VQJPa8/1eeLQkEfUitI1Okt/rEC8i222MKpHdNPP30aoOt0qTBwUmCnoEbhkkJnHdHUUALqPRse7Z1zzjkLTpXRshXmqU3h0B9avm+rbuMj9TpK7I10KwMdtdMHuU5d0WkqCvTDMFanUOUV9ZheY401CurcfPPNkzp1dF1DGYTBhMK1ww8/PJ3eOnhQzvjM559/flqH1kM+ChsVsmnsK61TeEFGTaPemLWU008/vWCZ+sKhIQA0HIe+gMjbh8Tqca9Q21urfVZv5/hLr/YN9ShWsKn9VttDXuH2kHfehQ71j3qTTTZJl6vlr7nmmslpZjpFSr2ktU2OOuqogqPr2n/zjqbvtttuaX06ONDSpdLQWEe+fQ93fWHRkWadBnbdddc5fSmKe+AutdRS5raoZL3C97CG2/HbWcv3p1eq94JOTfNl4sSJmd7F6u2vgyT+fX/00UennyG+Tp16llfWX3/9dNmaXgcLtN46BU6nqKn3hvbR+KCE9imrEBpbKu33ufCzWfuPeo1REEAAAQRaRiAOSNRTtq2WMADS/49ivxXquY76Lh13jND3Ov0u0NB++q6r74Brr712wfcj63epOkzou7t+t/jvXOrFGP6OKmdoOWv9NNygr1O3Clv120Tf6fRbUt/FtRyFh+F0a621VkF16jnp26OOG35afdf3z+t7n8qNN96YPKd19dPpN6ifTrf6HRoW/eb00+pWHZ+OOOKIpPOLAkN9R9V3hfA3qb7nxr8vfZ1haKzfH75unanrh7vQvqLvr/rO7F/X7VNPPeWrSW7vvvvupO3h70JNpx7pfp3UccOXcnoa6+xK/z3dL1uW2n+079xxxx3JWXnxe3Xvvff2iym4DUNjbcsuXbok6yRHnfmsYROvuuoqt9dee2WCeX3nrqbot4Vff20rvx661RAb/jV5+BL2NA5/t2geZTK+Dv1+8EUHB3yu4V/XvBqWQgc39Lta23S++eZL59d0+h1mlfAzQ/uyr1ud4/SelpXarPn98nSr39D6feSf23TTTZMhLLTfazjReFspH6Eg0FYF2n1oHH4Q6E3tT0kJN5jCNf+G160/chROU+39sG6dQqNTxq2iICXsKWpd1Esf7r6dCqSssE91KwTy0+kDU6dB6bE+2PwRSc3rx5rSPOFRUwXYxa5yGrZD9eYNbxAOU6F/1nlF/wh9e3WrYFqn9Ftl2LBh6bTy1NVZraJ/iGGdYY/qcHodxQ6/cPh5NC5SXMLwXyF3XPQPzc+vW53Kb435q3ULwz0F+NUWnd4WLlOnHVlfJPVlbLnlliuYVvMp2I+LfiyEdepUHatOzadxecPgWL3FrXLWWWcV1KkvqHlFB1LC5WvoAquER+M1XlxLl0pDY78O2tb6HIqLDk7FBzZq7W0c7ldavraNvnBq7GT1LtEXTw0PEpYwkNXBhbwwWGdMhL2R9WPIGksu3n55+4TaoANCYW9oBdp+TLO8Ntard35YP/ebS4DQuLm2B61BAIH2LRCHG205NFZg5L9/6balr3fh9wwtJ1yuDoJbQ7epJ3QYNGke/Va0Svi9sx4XwlOo5wMxLVe/t/J+S+r3Ytg5Q9Orw4hVwuEEBgwYYE2SPKcwzRspxMwr+n4c9opVsKueslZRSKjwztcb90j184ShsZ9WZyJbYxcrJPTT6FYdKaxS7oXwSoXGakPYa1YdfHSdF2vbKKzXcBNh+6z9JwyN/bQ6YGFdN0Z1+qxA0yo0zzsL1XKwnosvhJd3JmEYGvt2KghXb2etv8J3bSffKUm34W8RZScKoy0rjf8cHnhR/dZvnDgr0nTKT6whJXRgwLfT32p73XLLLRkGZRTh+02/dygItFWBdh8ah0cBdZTW+uegD5pw7Kl6nsqksNJ/qPTs2bPofhL+UNbRqriEF8HT0ce8osDTL9Pf+qO91jzqieyn060VmIbz6YtEeOqUejxbRUMW+Hp1GpBVdBp7+GV14403Lnlxh3DcXqtnonox+uXqNjyiabUh7lWreeIwWuscjoutI+Bh0X4V9mhfeeWVC3pzhtPqfvilVsFeeMGEeNq8xxqDOdwO2ieK9ZLXgYkw4NV6qtd7WBQChl9c9M+2WJ2aNzw4oPbERYFz+E9TR59LFa2L34bWAQftN/513dYatpZqj14Pv7xrmfKPi3VqljWEi59PYW44bIxOVaylxKFxKev4oEO8X8dtUS/zcFv68dLD6cL9oZyLi8Y/tKzTC8Ngm9A41G6f98P/hXqv0dO4fW5n1goBBJpDIPwers/cthwaK2zTOvg/9Upt6aLfCLp2iF+mzui0QqywHeH/OYVg1u/T8HtnPULjyy+/PG1jOWfWKnTz66RbXWPHKvUOjdXj1y9XHZni32RxGxRm++l1a52hGIfGeeGyr1u/2X2d6gFslXqFxhqy0S9Lt+qRXqzot1q4v2lYyLgTRxwaq9dsXsc1LSsebqTUb+di7dNr1YbG+v0cr0u4rPg3fl6+4OfR+yrMI9ThKD6YE4fG6pSW97mhAy/xGMpWRzK//PAMZPWuL/W54OfjFoFmE2jXobFOiQ/f2Hk9FrVR4rGNrJ6B1Ww8ffD7fwT6x6eQKK8oSNRYuhqvV0FmXPSFwdel0y7yioInP51uS4XV6n2oC+fpC4z+/NG8vPr1vD/tXvVbvUbVmzYMKDV+lFUU+vq26lR1hYGlisba9fPoi1lY9M8hPFqqo6qlinrh+vp0q1As/lDXP49wmvjCZeqdHr6u4RaKFR299NNrvUtd9M2qS/uzr0NHhUt9qVId8bAB8di0Olrr69T+agWjcVvigw7xNlTvAIXTOoCjfVG9S0uV8BQ29RqPi44U+3ZqP8vrCR3PV8vj8Mu7lm3ZxKGxDnCUKmFIb61rqfnD18PQWGF03vhdfp7wNEkdICinhA7hxSw0r943Gi5ljz32SIYf0Ze7UkVfYv221K0ObsSF0DgWad+Pwx/T2icIjdv39mbtEECgdQXaU2gcD3dXTo9JddzQhdH1pwDP/6nDjf/TcAj+Lx4CIbxgub6Txr8RrK2r3x7hMAjx93HNE37fqkdorE5B++67r9tggw2S331Wu+LnwgvF5Z1eX8/QWB1Vwgsya/zlcko4NIg1ZF0YGusMU6sXabic8PeQvodYv43rFRrrYoP+e7A6uJXqrKN26qxBP49ulSGEJQ6N1bu9WNHv53Cc61rP4Kw2NC52gUi1P7xeinqYW2cnxut55513FljFnePi0Ni66F5Yp4Zq8fYyK/YbdMSIEem0mqfUfhcuh/sINJNAuw6NNR6vf1PrttiFuvSlIgw5S31glLsR40BNpybowysOJUvVp/AnHL5CH0J5RcGzX28d1Srny0teXdbzakv4RUdDPMRFpwv5NujWCgp1JNGPsaRpNEh9OUWBrK9b4zSFRV+6/Gu6lXWpom0Rjq1q9fJWMO7r1ZfrePuFYayGiChVNL9CRw0ZUE1Rr4bwdKy8cZriuvv375+uh9ZHvQh80QGN8Gq9OmWonKKjrt5Gt6WuUltOneFQGtZRZH2J9MtU6NqIEn5517LLCY3L+bKrAx9+XfTFsZYShsY6sl6saB8MLwJqHfyx5tcY5769ug0vLGpNX+o5/VgL67O+MBIal1JsX68TGrev7cnaIIBAcwu0p9A4HvphwoQJJfHjg9fhdxLrfji+qirXxdL8dJWEuxrmy89n9S4Nv3dWUm/JFa5ggnAIsbzxoesZGqsTjTfRrX5Hl1PCkNf6XRCGxupcVKrEQydaww3WKzTWMIV+ncv53aC2K8RWwOznU4eNsMShsTpclSph72WNfV1LqTY0DofOtJYfDk1RrANdOK9+74TrFg8BGofGGlKxWAlDfvVcLlbiuotlUcXq4TUEWlugXYfGPXr0SD9MNXZoqRJOr16W1j+IUnXEr+tDPQxx/Ye7/sEWGzc4ricOavI+VBVCqu1+OaVOT4+X4x/rA1ZHztR7Vf94Bg8e7PQPRB+U4WkeWk442L+fPxyWQx/UVtGFBHw7dat11HqV+gs/gBVeq62+qJe2r1Nfxqwjw37a8Da84IMu0BUXjfvl69UywqJAPBwXWWM+t3TR2Em+Pbot1bPZt0c9yv18uhBbWMIvSHK1xr0Kpw/v+wvtqe5iQ6GE8yhs1hd1nUamo776MqoeqhoeJjwooZ4fcdl2223T9dBFHBpRwi/vWs9yQmP1VilVwoBss802KzV50dfD0FhBa7Gi95nfF3SrMdx0Smqpv/iIvXUaYN5y1ZNBnxe6KIo+mzQuWzjchdqhcbLjQmgci7Tvx+F7QvsEPY3b9/Zm7RBAoHUF2lNoHI9Ha433GmvXGhqH46aqx2up71H+dXUy8d/DdIHkuITfO1s6NNZvKXWgUo9VDTuo3zrxhcTisM23t56hcTj8gH5b6cxC71Xs9owzzkgtNZygvm+GJQyNy+nco++2ftvo1hqTtx6hsTpihb8hSw0TF65T2GEpviBeHBpbZ/GFdel+WF+t37uqCY1LDd+gbaqhI/x2sX4fxuvkH4cddOIzsMNcQXXnXavJ16Uxrn0big0Xqun1W9pPq1tCY6/IbVsTaLehsS7aFPYc1pjF+odR7C8cckFvbH3xqEdRT7p40Hr/AaJereUcRdXYoX4e/RPPKy+++GI6naYv58uS6tIHsUJs/dNR/eH4vX651q2mi8cGUn0777xz2g7rysCaJr5YnVV/qec0JldYwgCq1Kk4fr54fFyrd3LYGyDu+ap/WmE788ZB8surx+1BBx2ULrPY/hAvKzx9K+6dHI4hVs4XKl933FPU8tOXUV0gTUOn6CBCeGAjtLPuW4F4OJazxq9rRAm/vKud5YTGGvqlVAnHXbd6uZeaP3w9DI1LHTBS2yzvSp9TAJxX3nvvveQCFf/H3rmA/1dN+T8TRiOSogdTiqShUkpS5BpSSkV+pVLk6a6Sbj9FYVyTki6qn26oZmq6ueVOF1JGSLmEXHKLwRiaGf7P+T+vz1jn9/6s795n78/te/l813qez7PP55y919577X32Wfu9114b33EsBtS0e4DGOWkunvsBGi+eto6ahgRCAnMvgWkCjfXAbPSZGgtLFtEBZXM/1a3g6S2N1YpxUB3K4jNP9KR657hBYwyDzjnnnJ7rOMBCNf6wMvlwNkBjLGZ9vsP8ZyFASUFjXByUyB/qnNq1Ow7Q2O9IZh5fS3qGyNOe9rS+ZB409i5V+iL/7Q/nCpmsmWeOQsOAxhx42EW4O7TyEeYOZkzx0LmWz8eDxvzvIgWN/VzapwOP0jIHaOwlFP8XigSmFjTm9FZ9SYe5xqJWrVhHaVRWEk899dRmzTXXnFEuwG0sLP0HTvPjudVh55131kd91+eee24bD3/ONe4P+GCttdZabTrLx4e4LuCDola5/iNlhdFTb3ECnyJd0fR51f4H6DfCj7Km6wKzLA0h/pY1nf+wev/M1157rSZvvP80QNRJk1pUe7/Oubzpy6oU+q1weugDhy7Wkj88wX9s8fOrVggqa73GBy/A4lOe8pS2PVh19n2Y1X5NV7N6XluXrniqvJN/DWhcUzZVZMYJGmPt30Xqg0/lOei1X0QhT5QklCp1qZPiu8YaazTbb799X3sGaNzVaovjWYDGi6Odo5YhgZDA/JDANIHGXiftOqSqVvoegFPQGKMbtRRN6To19/zuP8qmeue4QGN8wOIOkMPdusplcz6McyzebIDG+Fy2/EYJ/QHZChrXuKCcLdDYL3IwZ6oldgCbjJh3K/k+W+NKbq5B45LVLvNvqy9hjb9yk4m6NcQ1ppIHjVNW5RpfQeMlS5booxnXARrPEEncWKASmErQGJcEClrqADPoda2lbm3748cXVw/4wPFlwWqXQT5FagXNFpwc6WS7tPoFj9tuu61ZffXV+8rCCtzuu+/eOxyQLRqsepqrDgA8BR6xHPWEb1ytW87HrYLPHFoAqD7oDzcNRn5Vkw9+DekCA6C+J5RDrY/3z4x7BHueUvo8v3H8V5+/JYtSy+/73/9+W07K6/u2WlN7QNl4pELcUVj9CfWwR4BVLSvPsfpn4QNfVFhpswUMJckWaJ7znOe0/FhY8KQKFgcQpCzdfZpx/FflnXrMd9C41IbqjoT6vO1tb+ud2Ey6QX433nhjn3hZdOE9gKf/sRDHGMVhMri+oc0ZWzRegMZ94lyUf/Q7Rt8YdZvkohRiVDokEBIICVRKYJpAY+YpLEibXsFcw/TLSnHMiOYBOAWN4a3AKu60BtGhLO4HPvCBGfmq3jkO0Jg5KMYJJhsNMR5iZyi795g/mXsHPax5NkBj5jRWLg7hM/kMGnpDrPkKGvu+NYglqu7Yxdevkue7EEDjkuGMnmlEH6md5yMX3aGrBmc886Axh1R2UYDGXdKJZ9MqgakEjTlIyT44hDjHZ+W55udPI825Vhi1Q3CQGRa4egAbZQVs8SeBMtBrfbp8IauDeCwJS6TgNeAxgFwX+QPu8D3lSX0Vs/qO79oU6Vb1lLKUStN1DwBc5cS2oRrCj6ylS1lxc4KsPU/5Z9aVWawmZ4MA9q1MKT9oqTLgX9fS4DNYLaJRDtUqFECxlnhHjO8GG2zQl4yFC3vGoghKX5efaVyFqMXGscce28ePP9wznpttttmM55O6oco7+S900Ni/L4MoXzkZM3nadNNN2/ZBTvQBDqikbVPkF3sYPzyFT2Mvken+H6DxdLdv1C4kEBKYXxKYJtAYyR5++OF9esgg29hTLeMBOAWNia+76WoPkU7l4++p3jkO0Fh3tqGfsbsP45uU6wXKgk6nB2TnDh7T+mOIkyM1MvHWnpbm7LPPbtuO3YYGXtvzYcP5Chozl7A5DWHqcPlcnfUsJg+4+j47DaCxd4eYwiBystL2f8YzntEXLUDjPnHEn5BAUgJTCRoriMX2mz//+c/Jyqdu8oHUg96wZFTLyVQaf48VKqyJsZo98cQTO/O/5557eofL6QfDgyY4/rfnuLIwq1+fL/VUwK20Wumds9eArF4RS63GcYCClXfjjTf2xWz/q6sODmirIVaOWWn85S9/OQN8pP6WL2HNgWycqqxgqT99ljLpKampRQTdXu8PIkjViUMdOMjtwAMPbMhvGIUIy2yrq1cUUnnSr7faaqs2jQd3KYP2nfPOOy/FZsY92oF3xMqirgoAh9X64pRTTpmR3t/w/qFT/pFVSTrggAM8i4n9V+Wd+i500BiXOer3vWaRqSTcb3/7221fQEZsgaTvdRH+Bq3/EKYOoAjQuEuC0/csQOPpa9OoUUggJDB/JTBtoLG3SMTtGVa2w5IH4DxojI9c02PQtcdFqneOChqj5+O20MqJLo0e2EWAyRafMLW7lPTjBI29cVJpLttVfn2moOF8ck9BGQHQTc41cyWrFzs3LR0Htiv5PjsNoDH1U3eaqTm7ykCvmfearDh3SSlAY5VGXIcE0hKYOtAYazY9WfNVr3pVuuYdd08++eR2YGGA6XIHkWKDOwYbmAixcO4igFcF7DiQTEkPBcAyOEdsE7d8sWDusuiEh/o/RmEsxQf8UZcSHDqXIj2htEv+W2yxRVtetnqUiC1namELsOBJT/rNrYhrGiyLTWaEKStu/UCl/DMfccQRLQ9cK3QRMsQPtOUJID0Mccif8cA6vdR23hVBql20bY866qiqYhHPykHIIQVGXmnnULQSKUAPP3xBKVFPVXprwW3lMey1Ku+UbaGDxshh7bXXbtsPYLaGGM9w/8NhiSipd9xxR5vsjDPOaPkho5o2Z2GNuPZLLfYEaNyKeFFcBGi8KJo5KhkSCAnMEwlMG2iMrq1zEfSL2sOxU02CsYfpKIQeNMZgwp5zPkfJJyp5UEZcsLE7C0OQZcuWzcgat2HG17sfmBG5cIPdZMaLsOaAQF/vnKGGzucwHMqR7nhkd2uKOJRQy1k6n8N4oH/idgC/uOgQ3mBsEqCxB2b9TmEr21lnndXWiYO8PWH5anWmnUtzOtL7w6z9OT6+bNMCGtO+Jitcp9QYXuEG0dIQcgCkUoDGKo24DgmkJTB1oDG+mHRg8I7w02Lov4t/VbWerAHllAMn0moZAGdLpCfvetAE/8LGL+U+wXizOmnxWEEukTqFX3/99Tujo9z4bU2s3KdILYgB4HOkDvxXXnnlnl/bXFzuA6Zb/QDZf/CDH8yIrla/8MRvao5wW2L8LPRW3FjS2jNCPsKecK1hcR7+8Id3+ti98sor27ik4UM1DF188cV9fFJgtvFl+7+uYpPvmWeeaY/bUH00sXpd8hXMgQRqqepBfHzTmlyIl1OmrAC6iEE63kGvDPiTc3GxMFs0jaCxB2w5FLKL/EQM/+aqmOs7zTuqz1J8OcRCF2Vod5RrTwEae4lM9/8Ajae7faN2IYGQwPySwLSBxkiXXaLq2xj9AgtTdc1WagV0GABh3CSYPkvoQWPmGrhgszgcLF2iyy+/vI1POvR6T4BbxpO56Ch0zTXXtLzgCejYRdRdzxghjbdmtfQKyB522GF2e0aoB4+j46NTeuKe+l1mLlcC4XGDiP9jk1VqDqxlHJelsZ+T5Nx8lEBjddtBHfS8Hi8f/iMjBZoxluPQdqVpBY3ZjWjtTMjO7hIp0MzchF3eSgEaqzTiOiSQlsDUgcZs37HBBPCyZrUuJRrd/g8/fHIOQnoQH6uKHEKWo5tuuqktM4OZP2gNFw9Wp65DzxT0A7wpEVv/jS+g3je/+c1kEj5OHERkcS1MHbTHR8ueE1511VVJntz0PlWxfk21F/krYAxfrHtThBWkApn4vPUKIuCl+sW18qaAc1WyaJuUf2bv4iIH4HKgIMqP5bftttumqlB1D6tr3WqD8uV9tiE3yu8POiT/FFiNlbWVjbBr2w99VvnSxz3gjgW98sPCIEdYDGu7kS5lVa/uK5ClB5WNP335fe97X/tTC2iLM2g4jaAxkwImItZOjFu33nprVjS60EQa73Pau5rwlg/KGGsSXSyzMqTenwCNVXLTfx2g8fS3cdQwJBASmD8SmEbQGOli3GC6hYXrrbdez6oXA58UoTuzyw3LXzWCsfS4PUwZLBx33HF9eWE0k5rTkCfGHOq+7VGPelTSfQZzT8sXYDBX5lQ9/D3vaqLL9zLn7nhLbcqRA8M5W8XK2TW38WdY4CYxRbikUOMtLLJzriJxO6KAMOVg7uNJ44wLNGY+afUmxJ1kikqgMX1uyy23bHkBgPtDpo0v8z8/h0215bSCxshKFzMwisotgPD+6WH3tFFqp22Axta7IgwJ5CUwVaCx33pzzDHH5GteeKIfagYZPjaDkLcExW0C93QVkg8dYBnWqfbR4VA2T7rCzdYbtgsB2nHgn5IeaodFa4mwqEb5sbwBcBh4GZChX/ziFz2/wDvssEMbx+ISplwYeJcEyO3LX/5y86Uvfam5+eabZxRp33337eONpTDxUFhYCaQeHNSg+eJXOKeIkQF+hTU+B+7hvwgFDsXGLA8AgdWVCT7JPHFSsPHCNUaO1E0D1gZYvJv/NHyGYQWuh0mgtCL/UchvG6Oc+BUD3KTvq48x7UPU2cqm+dPuaqkNP7aiWTl5jrsBlBUO0jO5UK+URT/xN9xwwzYeLlMAEa3tUH5p3/32228GYAzvlKWALl7gHiFHWFJb+Qg/8pGP5KJW359G0JjKs7CjsqL/YoHMe0jfZaGEBQnvOoRtYX6BCyBY+xrjC5Yy1t8IUYRZkNDxSvNHzp4CNPYSme7/ARpPd/tG7UICIYH5JYFpBY2RMnom7vRUz+AaNxIAnOi5uIFAj0fvTMUlPoYNr371q3tnqqRaD13J75zCwhHrWgBPjBwAo8lLAWP06dycjUV8LTfGIhjNHHLIIUXrW19GdHI9swe+GBiZwQfPAcNPP/30Zuutt+7L18rAHCFF3rBnu+22681D/Hk16IzGixC3eIceemiDdTKAspK64SMu4CD65O23396TJe4oOQPIzxEx+rJ5hvKbBGgMf51HM7/kvBraSK3RS6AxfAAu1XiG83Zw9cF8H12cna+A4c9+9rP7ZEibpnb1TStojKzop8zhrS9xjUtK8AZkwbyVAwXVwpi44BzeIttkb7wIU+c1Ec9IjfSWLFlit5Mh77zyHpeP7mRmcTMkMEEJTBVozEdUX0wOZRqW+Liz8mv8+KizlXoQwirY0mvIyjUWfXoAG8/xLwpQ6+kJT3hCko+u5uKrSPMAvKkhtnVoOq7xGestALEqveSSS3p+TC3+PvvsMyMLBmr96FlcQhQlTwze+G/SeFzrx0CfMTgDKHcRSokHP5UH1yh2HLagoPFpp502gy0gvqUF4M4Rq81eZiikAGO+LljlcqDfOAirTF2Nt7JaSN4AdPqBw/dYjpCdVyrhxbugixvGn36cs1AnD5Qg388B8QHNVRDZ3EsAACAASURBVC60A+XUdzgF0qs/aA5Zy1GAxis0J510Uk48ffeZKND3aRdrVwu1jeweIe+PLoApQxbCNC7X9AEsmn0eTM44gG+vvfZq06DwewrQ2Etkuv8HaDzd7Ru1CwmEBOaXBKYZNEbSGDzodn6vo5T+YwVaOp+GfNhRqGevKF+vC9uzrrM5AHQVYLY0hKmDoku9ChBa5z3GDx1fdw9yn7kFQBzzDIuHAVQKkAW8tTgawgPLWCP0TT1LQ+Pik1gJ8A8LWo1j1zlZAvrnXOtNCjT2IK6VUXcG14DG1J15dqq91VDH+BPiD9uf/WIynGbQmDpyVo/vs8gkJ6uNNtqoYWdwisLSOCWVuBcS6JfA1IDGrMLpQDvqgQGIiY+lDs5sPRqEAJ4BZbEOVj7+mgEOQDJ1sBb5YVGsK5mWXldwiWP3AaVriQ/4qaee2uc2wfhYiGWvWZvqFiSUqBS9853vTA7aWMamCMUAa9McQEU5ABlL/laVN/XCuleBf/iwCgzYDTh63XXXtTLjGY7yleCBz1aTw9lnn62PZ1wDgLPlyeL7EOUJUDS3xWoGw8obKLL4l1b5oRRiKcChjNRD3aWwqt9FWEuwUp5TyqgXVsOAttYvuvixMq4HFHq5AARjOQAhY3u+0kor9SmnWKkCxNvzrkM8AjSuB42t7fDJV5pU0a9Q4rtW4elv+Pn2frSt3SzEN571HyzB7T55+AM7AjS2VlocYYDGi6Odo5YhgZDA/JDAtIPGSJk5GUArC9Pqf9h0j1SIEQVu0dBragnDFnYpdunQ5LXVVltl3RloXuz00h1cVk7mWsMQruhSxiHGl/DpT396Y4ZXuJDQZ2pBq/nroX0a31tWAtyljFCYH6WInYw5oNnyATxEHikXgsZzUqAxeizuDa0sFmJtbVQLGhMfo6+S4RNzMCzjcwA5fKYdNKaOzKf9gfYmfwvZDXv44YcnrbGtfQI0NklEGBLIS2BqQGNAQJyj2w9XFaMSg5HxI+RDOwyhqLAKy7ZrtjZts802PXCRVVWUga6PnOUHoMxqL2AeAOu73vWuPj/JHApnZcWCdlDCapATavH1wwEEr3vd63quBLwvWMA9y4etHzm64447Gvyfwo9tR/iXTW0J0fQAUXz0AZNYLSbkP7IrWRcrH3/Nlh4Aa/xKq+KnB/ul/F+Tp9WVsBbsZSsRbQU4jSzJB3cVqYP7fFlH+Q/4ztYctv+rIsF/+3gS5nw/+bxRhLBAZUGDegDcARRjGVpqS8+L+PR3ZAEvFh/YZoY7E94PIyztVeba7vim1mdsTcsRAKjGHXSXQIqv9n14q4wtPvc0X8alEiEDS4Mbl1GIwweNl393a/hiQYLyxKEcKKQovShkWEywZbF0GInmgfsRFGXGkh133LH3Y+GNAz78aj9xrdyEvLNKLH7Y85SbG40b1wtfAgEaL/w2jBqEBEICC0cCiwE01tZgToWeg1sFjD3YVYjLM3z2Al6in2KdPAqhL2E0wS66PfbYo7dVnvkb8xrmaTofKeWDxTFzUNKihzOnGGWei/UvVq24p+B8GuqProbVM4Yo3pr4iiuuaHUwA5N9makPujYH/MEX1wr4hTbjAI2PPo/hDnMlXDlg5APImSPmyTxHp6R9cDvAIfHolBdccMGMs2tSfEhvemSN1TjGCxafsGuuju6P4RHzHOTITj/0cSOdo6f8LVs8C5ElVuucBYMujn/pnXbaqTef5l5XWYwHLh61/Dqfsjg+ZH5oaUbpX/ClzxovQuaoKRp1DoSscG2C+0NcMzJvYc6BgRT9uXQIO2ViPllTVis/83yL788TsjgW+rnroPNn4xNhSGCuJTA1oPFcCzLyX1gSwGpVLSG7XB0srJrNLK1u78ptLZuZKu6EBEICIYG5kUCAxnMj98g1JBASWJwSWGyg8eJs5ah1SCAkEBIICYQEhpNAgMbDyS1SzTMJsJLH9iX89WIRW7K2ZgVYrW9HXVGdTXFgvb3xxhv3LANSh4ZpWbAm0G1g6mNL48V1SCAkEBKYLxII0Hi+tESUIyQQElgMEgjQeDG0ctQxJBASCAmEBEICw0kgQOPh5Bap5pkE2Hajfp+PPfbYbAnZyoKfZgON8UXFvYVCuIuwsnMgWRf5wylwPRAUEggJhATmswQCNJ7PrRNlCwmEBKZNAgEaT1uLRn1CAiGBkEBIICQwPgkEaDw+WQanOZbAkiVLWjD1EY94RM8flC8SvrVe+tKXtvEAXzkIcCER/rAMNCbEJ5gHvfFHRr04TM7ibr755jPiLaR6R1lDAiGBxSGBAI0XRztHLUMCIYH5IYEAjedHO0QpQgIhgZBASCAkMB8lEKDxfGyVKNNQErjqqqtagNSA0nXWWafhxFwOEVh33XWbFVdcsS/Oy172sgUHpN577719/pip66qrrto84xnPaKjPJptsMuOkZVxUjHqox1CNEolCAiGBkMCAEgjQeECBRfSQQEggJDCCBAI0HkF4kTQkEBIICYQEQgJTLoEAjae8gRdb9T75yU82WBkbaJwL73Of+zRHH310w4m3C5Huvvvu5gUveEGxntR/q622au68886FWM0oc0ggJLAIJRCg8SJs9KhySCAkMGcSCNB4zkQfGYcEQgIhgZBASGDeSyBA43nfRFHAQSXwm9/8plm6dGmz4447Nvgrvt/97tcDV+973/s2j33sY5sjjjii+eY3vzko23kXH5cUy5Yta/bcc88G1xOrrLJKCyKvvvrqzc4779xcfvnlzV//+td5V/YoUEggJBASyEkgQOOcZOJ+SCAkEBIYvwQCNB6/TINjSCAkEBIICYQEpkUCARpPS0tGPbIS+Mtf/tLcc889DX5+p5kAkX/7298uWOvpaW6bqFtIICRQL4EAjetlFTFDAiGBkMCoEgjQeFQJRvqQQEggJBASCAlMrwQCNJ7eto2ahQRCAiGBkEBIYMFJIEDjBddkUeCQQEhgAUsgQOMF3HhR9JBASCAkEBIICUxYAgEaT1jAwT4kEBIICYQEQgIhgXoJBGhcL6uIGRIICYQERpVAgMajSjDShwRCAiGBkEBIYHolEKDxAG3705/+tLn55pubn//85+EndgC5RdSQQEhg8hL48Y9/HOPT5MUcOcyCBAI0ngUhRxYhgZBASOBvEgjQOLpCSCAkEBIICYQEQgI5CUwlaLz77rs3T3nKU3o/DgrzdMUVV7TPX/jCF/rHff+/8pWvNHvssUez9tprt4eMrbDCCs2KK67Y/OpXv+qLu1D+3Hvvvdmivve9721ls//++2fjDfLgqKOOanmeeOKJgySNuLMogfPOO69tp912220sOR999NEtz7e+9a0j8dxnn31aXmeccUaRV1c/LyaewwhnnnlmW8+99967syQ33HBD84pXvKJZa621+sYnDn38/e9/35lWH15//fVtnoyd0+7/W+se1/NPAgEaz782iRKFBEIC0yuBAI3nvm0Xqs6ak1xXfZYsWdLqnOeff36OxVjvH3TQQW2eJ5100lh5LxZmXW26WGQQ9Zx+CRiGSHjjjTdOf4UraziVoPFGG23UAigpoOrss89un6Mo5eiuu+5qVl999TYuYLH9VltttYaDxxYSUd5LL7202WSTTbLFft3rXtfW8VnPelY23iAPdt5555ZnCQQbhG/EHa8E3va2t7XttOGGG46F+S677NLy3HfffUfiucUWW7S8li5dmuX1i1/8otlzzz2b97///dk48/nBcccd19Zz8803zxb1zjvvbFZdddU2ro1NhI985COz6VIPPvaxj/XxCdA4JaW4N1sSCNB4tiQd+YQEQgIhgaYJ0HjuegEHWGOkk5qvzl2phs/5T3/6U4Me22V4tMEGG7Q659vf/vbhMxsg5fOe97w2z9e+9rUDpIyoP/rRj5qXvOQlzb/8y7+EMEICUy8BnU9/8pOfnPr61lYwQOMO0HjTTTdtPzDWgR772Mc2j3/845vtt9++VsbzIh5b1+2D+bCHPSxbpgCNs6KZ+gfTABqfddZZzYMf/ODeezvNoDELQKp02/i07rrrNuutt17DQs0gFKDxINKKuJOWQIDGk5Zw8A8JhARCAsslEKDxclnM5tWHPvShBiMkdLg3v/nNs5n1RPL61Kc+1Tz60Y/u1YfdgTlS/TVA45yU5sd92mellVbqtWmAxvOjTaIUk5WAzakJAzReLusAjTOg8R/+8IfeAGkdZ7vttmu+973vLZfcAru68MIL2/oEaLzAGm+WijsNoDGLOvbOTjNofM8997T1pL5YAGB5PCwFaDys5CLdJCQQoPEkpBo8QwIhgZBAWgIBGqflMum7bH82nXUaQONdd921rU+AxpPuPbPD/0EPelDbpgEaz47MI5e5lYCNyYQBGi9vi0UJGi+vfv7qW9/6VjtI0mkuu+yyfOQF8GQuQeMFIJ4oYtM08x00rmmkxQIa33LLLX3j0zXXXFMjnmycAI2zookHcyCBAI3nQOiRZUggJLBoJRCg8dw0/WIFjedC2rbbljl9uKeob4EAjetlFTGnQwIBGqfbMUDjtFx6KwvaaX7zm99kYi6M2wEaL4x2mstSBmg8l9JfnneNT+OrrrqqBY3vc5/7NOyMGIUCNB5FepF23BII0HjcEg1+IYGQQEggL4EAjfOymeSTAI0nKd1+3gEa98uj9l+AxrWSinjTIgHF/8LSeHmrBmi8XBZ9Vx/96EdbUGbFFVfse7YQ/wRovBBbbXbLHKDx7Mo7l1sNaHz55Ze349M//MM/5FhV3w/QuFpUEXEWJBCg8SwIObIICYQEQgJ/k0CAxnPTFQI0nj25B2g8nKwDNB5ObpFq4UogQON02y1K0PiOO+5ozjnnnN6PQwiMfv3rX7f3DznkkBaUwZLP4hNi5ZcjfI1eeeWVzQknnNDstNNOzVOf+tTmVa96VfO+972vue6665r/9//+Xy7pRO5TFspMGewlWHnllfvq88tf/rLNO3cQ3m233daceeaZPT7U6ZWvfGVz9tlnN9wv1enTn/50m98XvvCFNq/Uxfe///3eCcLwf/rTn9484xnPaPbbb7/m1FNPbeBz7733ppJV3/va177WlkXbPsfg0ksvbeN//vOfz0Xr3f/973/fxkXm//M//5OMzyFmn/3sZ5t3vOMdPTkiT3xmH3vssc3FF1/c/OQnP0mm05s//OEP27w++MEP6qPstdYF9yueBgWN//jHPzannXZas+eeezZbbrll86IXvajhwAT6+V/+8pce+1122aXtd/vuu6/PcqD/vHf2Ht58881t2p/+9Kft/dVXX73Nb7fddmvvA4qm6D//8z+bD3zgA81BBx3UvOAFL2g222yzZvfdd+/1wX/7t39rfv7zn6eSZe9R7y9+8Yu99513jrbF3zDjAe/if/zHf2TT2oMcaPyLX/yirc8BBxzQ1vN+97tfex/5sOA1KOVAY/oJYxeyfNrTntaQ7/nnnz+Uf3feXd7hk046qdljjz0aJkv4v6PfffzjH2/+67/+a9BiV8dnpwirxaecckqvDs9+9rN79dlrr72at7zlLc0ll1zSMP53Ee+l9T/qYUQ6+uYxxxzTPOtZz2q23Xbb5g1veEMDsE//ChpcAgEaDy6zSBESCAmEBIaVwDSBxugS9q3+8Ic/3IoEvfmCCy5o+L5svvnmPb370EMPbW688cY2Tu3FX//61+bqq6/u6Q/oR+gzzPne9KY3NeiOXfqEzjXt0DjmZzvssENbbnh0EfNY6nL44Yc3z3nOcxp0Gq65V3P+Dvq7yUj91KKzoN+ceOKJzQtf+MIe3yOOOKJBjjpX1LKh2xkvdGibazIvsPuUSwmXj/bs1ltv1UfJ69tvv71hDoPfZ3R05P385z+/p7szP+QAvtJcdJKg8Q9+8IOenv/yl7+8p/czd8WnM/pt15xO9Xrk8d///d/J+utN+p3J7qabbtJHM67vuuuu3lyT+cjWW2/dbLXVVs1rXvOa5r3vfW9z7bXXZvVu+pDl8fd///dtmzIft/uf+9znZuRnN5jn0o+Y56JnMxfafvvtm6VLl/b0beZtJdK5nercv/3tb3vvGC5GeI+32WabXj9gfu+JPkH/or68X9T/1a9+dcOZN4PiCcyHmG+T7zOf+cyG/vT617++AUv40Y9+5LOe8f9Xv/pVKzubpzFWwZOyvexlL+u9Z2AJnpAnc5ijjz66eelLX9qbq4IbHHnkkc15553XfP3rX/dJZv0/81veQ+aMBx54YG9c2mKLLXrzPcYT8I3cGGKFvfvuu1sZfeITn7DbDXM43DDSfxjrmK9zzTgy6E5bcCbSMl4zjtA/wbN03LQxjDAsjdtmaBYlaEznsA6BomQEEGX3u0JeghQBPDzkIQ/p5EFHHxSISuVVe4+BuqsuPLvhhhtadh40RjFSECvFa8MNN2xQYHK08847t2XYe++9k9EYbBgIAehTedi9Jz7xib0PQJJJxU3AKeNFyACVo9/97nfN3/3d37Xxn/SkJ+Wi9u5/5CMfaeOuv/76ybjf/OY3ewOelsFfP+ABD2je8573NMg+R//6r//a5kX8GlJ/v3xAPdWCxny8+CisuuqqbRl8HVDmGMjHCRrz3lk+DPhGDOh2PxfycVeiDgDcpfeVBRY+6MQvEUojSnKuDNxnvNEPYYqnvm8oREbXX399J2/LF+ByUPKgMX0PcLfrfQQY7eqjWoZ///d/b57whCd0ln/ddddtSgqw8qy5pt0uuuiiYjsju4c+9KENOzJyba1jB8oGdMUVVzSqUFsbWPi4xz1upPGqpo7TGCdA42ls1ahTSCAkMF8lME2g8c9+9rNW13jEIx7REzl6ALtG7dvsQwA1QOUa+tKXvtRsvPHGWV7wRj8GTErpE1/96lc705J+k002SRYFoOuwww7rTM+85Y1vfGPzv//7v0ke3Pzxj3/c8lhvvfV68ZgDq+GFl9Fqq63WW+D3TAF0fFz/H11baYMNNmjToIvnCAANkM/zS/0HqP3Od76TY9UD+SzduHwaA2xiKGB8UyE6Im2WAgO9Xl9jWIJBleVz1FFHJevLogDGGV19Hh7o3V/+8pdn8NDdyZaXDwHvUwRIC6jq4+v/lVZaqWfE0QX069yOuSSEkY/Oy5Un1xgA2bwEGQAw+jj2//GPf3yy7r5O8AFot3SpEOOdd73rXZ0LF8jZ0jJPY2xQfMSewQuswAhDLHAWe54LMbYbFEC1PEYNwb8YH3Jls/uMA8uWLUuOi5SBhQiLy6IVBMBOf7H7PnzMYx7TqCFZri4siNFnu/oPbUi7aB4BGi+XaIDGYwCNeUlf8YpX9HUyOhyASwqU4sXqslZe3jyjX40CGgOS6sqsvkT+mjrlVpB0UEyBxqysorB5ng984AOTCoxZVg4jHRQu+FpeWE3miJV+i2dhl/UAg5HFw+rQ0zvf+c7kYJUbDFEMWCVO0VyBxnzgdWHB6kvo68FHDutUizOqpfE4QWPawspl4X3ve99mjTXWaAjtnoUoLF3KDSu9AMwW38JVVlklCbyykyFniT4fQGOUD6sDIe8cixN6j+vnPve5nRY1fHyxNCC9T5tadEDBxZIkNdFKvQdd95jI7LjjjjPyZVwGIM4B4sg/RR40Pvfcc5Pvs68nEwa1kkjxjnv9EgjQuF8e8S8kEBIICUxSAtMMGmOJqt9lvv8YoHgdAIA5tQvP5I5eggWd8rJrnVfYPUIWmD0QOCxo/I1vfKNXbuXPNbqZ17+5z/wvB4R70Jjdjykd1ufFf3adKk0KNGZ355prrjlD3ve///0bdOtU2dC3cm2o89lxgMYAvg9/+MNnlIPypWRJ/h7InwRozI5Hdn56+dBHHvawh824j9598skna5P2DCh8ev8/BRr/8z//c1Ivxo2eT89/wOWc1bEHjTFkSfHw9ygDAH3JiId0j3rUo7LW1ggEQxaAdZ8HskwZjAAG54zRPGiMcZjny/+11167nW8CHj/4wQ+eEQ/MJdXH2LmAVf5sEcZ1WEin6sEcLwfQYqGdIg8alxb7LF/mmGa9neKLlfeTn/zkGeXkXfULK/vvv39fvACNl0s0QGMBjf/85z/3PjZ8cNi6YJ2RTs89+915553LJdg0va1OFpeQ1U5WhlidQsng48zWHF2F4SNfs52hL6Mh/lBWys0gamXkRba6EP7pT39qOecAQYBftqRQF1bxAb3/6Z/+qeUJb7aup6gEGrPdwsrGC4zLA1WyKB9bo/7xH/+xjcdqeA50S5VB76n1K9vKcuQHDsqo27g0HR9pBcG+8pWv6OPe9hGrIyEfHKx9sdAGjOQDh9KGha7GAzhOAWhzBRqzQqjlW2uttXrWliiNrO7Sn3CzoXHselKgMauH1p+1j2CNbPdVcdYPN2UDIP3ud7/bfqSpB4oCW/6s7IQ59yRYnWg83nOsk1EcaDvKR1rPDwUoRTnQmG1MVh/6juXJWGL3CbWuKf6pe97S2HgzllE/Flt435CLt6rAxUSOeG+NFyH9he1EtvjCNjMsr1mg0ni59yyXT+o+SonyZLKHOx1T2qkP7c6WTsYdi4uCllqtV9BY33UmZriiYMuTjfWA6caPcBjr71SdFsu9AI0XS0tHPUMCIYH5IIFpBY0VGMaQgS3sZgCA3s3cSOOss8462W3rxx9/fN93nXkIBgPoXOh66DXoUlgJ6/cfHVOJOY3pbIDXFhcrSbuPPqHE/BT9yeJSZqxXAYiYf/DDwlPnU8TFcCM1h1DQGEDPdCB2JGJMg66E6wT0NTWIgSfguulRlJG8rdzsprUy4prN7n/729/W6jQlS2P0M/IxXlwDViNjqw+AFfMm9FSLR+jlbRmPEzRmzuMB2IMPPrjnJoCyU0a2uzPH1LKhhypNAjTWXaPgF1hPqtzQ52lXLDStbCx6gFkYIVtrOwV8mbfYfe92Q3dxwxee7ErF+pt3Dp6f+cxnZsyFsAa2NrX8CRU0VuCUeTJ9gfeO9wTMQI1a8MFsACHzsTPOOKNnucsubyxiPZiMS5kUUV61vAdcZF5JuzJPpJ0ZT1iAMDkSAtinSOeejLcGVlJ2DFyYS/Bes0sAQibaRowVyIR87Tl1Ys6tYxhW0bNFOl+l7uTN4paND5QVeeFGQ0F2+hTvkCcFjdXoctNNN+3hL/Ci3wEm61hD3jkvAOTh5624A6E9MFpkbo3r1JxVeoDGy1spQGMBjZeL5f/M4W0Q4MXOEduu9WVlq4gpJD4NVqMbbbRRO7iwOjNbpFtN+NDlKAUav/Wtb01G58OjLg9yL2wJNNZtF7nVJwqAEqOr6WwNH4YA8K1t+SDk2kvrZvEBklOkwCHKjfIEGNMPHh8BProp4kPEB8zyI0xZQ88FaIyCravq+C5j9S5FtI0poVaXSYHGmr+2GQs/KeKDbGVie5J93HxcPia4h7C4+D3yRHvpBIG+nJMJirVuK6RPpKzz9SOs7ik070kfhEed2RVgyonmTZ29kpTySceHmFV8kx+gOQB6iphE4QvO4jI5YpI0LJG3KhymhOX4oUha3oRsgfOkoLHFRVnTd93SpHZP5N55SxPhcgkEaLxcFnEVEggJhAQmLYFpBY3tW81CbmoxGLly3oTFI0zNeQBn1WoOX5g5C0nmRvizVZ6cdZEi+Fg8dlnlCJ+gFg+rupwRA+nx/alAn/p1Nv4KGhtfXARSdk+AV95FRG5hHyMC44cMclQCjdXdH+AjQFSOKB9b2S1f5JPSNccJGqMfW35gBDkf1F52xDWjCeozCdBY3Vd0zbtwqacW26m5JmWsOQiPOqm1Pa7Zcm4rmUN446JUH1XQ2GRNH0Wmnii7xbGQMqTmWBil4ZLF4rGwkiKdr/E+sUMgR/jr1R2VLB55UtDY8mYngoL1lBfMAEJ+Fo/QG6Mpf909y9xSjQE13jivGSt04STnKsXy9OMsO0A8KWhsdQeXos94Yu6u7zTxb7nlFh+tZ4FsvAgBsFPzNvj5uQfxAzReLtIAjUcAjRm4dHAG4AEY6iLAFQWZuz78XXwGfTYsaMyqUWqAtvyVLx+fVNwu0JiVPH2ZS9sq+GBg5QdgyQrmMMRhhar8pQYZPqZWLlux5L/5/vL5MlhafA8sK0hJnJJPW2So/qAAtu0jYvnOBWis1vfUo+sDRjn1sDbidykvVq+uMOeeQtPUgMZqBYqVSRehyLA6ilU9oKb/0OjKOm4tSocRkF5BZg6n8DQfQGPA3tTkwcoKKKpW3aySe8Lnsb0TjA25CZalQ8l55CMf2aZhkjQsYVlgebMVlfJ2Ee+cWrVwcKEnDxqz4JAC1S0dVsxWBkJ/EIzFi3CmBLziNo6tpDNziTshgZBASCAkgASmGTRGNyvt7AS8se81OoMHKdQFIfOH0lwF3cBbCaYMFGpAYwBeNZjh8N4SAUBbfVJb8D1oDNCEZXGOKLuWIQcQjQs0VteK3jo3VUYO4LL6EqbaWwGmUXQKLCR1Dlma26DbKvCqBi3jBo1pJzXYKR3yyGIA+jnz3JxvaS17brHAg8BYgHcROrda/OIaEMMkJQ8acy6KAqwal/dNy0kf6HJXQF2tv5C3J95vdVWobebj2n92LRpPsAI/P/CgMfmCR+QIF3jGDyvjLsJQBmCbeRn4AQaNkyZ2WVj5kD1lKBE7OSxNyo2nB427dn6Qlx/HzjrrrBlFYKen5Ynrj9Q4bImYK6qxE+kCNDbpNHEQHopSihhsrJPlLI1Z+bQ4hLV+K9WkvmslNlWuYe8puDuIpXFp4GHLkcogpXR0gcYoZihoxoNB1wNzWueul13jla7VhzJbeTwx8FiZuFYL2xT4pYd8+QFGtzyQbwpY9/n7jwsgsdJcgMbqIwvgtUQobbw7JseSYlXiNy7QGKDWysRhJuoKxZeB/tnVH9Wtwp577umTJ/+rywaUOz85mQ+gsfdZl6oIW8JMjoRqxUMfV0tf6lRDuq2OCdewhFserLHZllcL1uoWR1a2PXnQmAWD5C3uYgAAIABJREFULmKs0onFsItcXXlM67MAjae1ZaNeIYGQwHyUwDSDxjXbtVnwV30GME9JXUPUzttU14N3aj5VAxqrlTEAX808CEtb1b/9OToebMGqskTqktAbx1jacYDG6Ny4eMR6FJcg3rWF5aUhrgq0/VKWyeMCjXU+XbMgQTmpB7IhVGOxcYPG6N4AYyYLQGE/x1C50ZdKc1IFY3OgsRrQIeca0h26lBdLVCUPGqfm6hpfrdfx7dtVLw6pNBkRestctTLGr3bXPNDKgKsI5el3F/h5femdA1NSfn5MsnwtrBkXLO44Qt45LOzf/e53NwDcNbTNNtu0dUotBnnQuDRvol3U7QVzPiUWIhT8r5nbnnLKKW0Zkb/HdJT/YrsOS+MRQGMF7gB//KCT60xqecpAOxukH7lBQOPSyhHPdVDTj6HVqws0Jo5uS4cXq0IM6F0rcMZ72FAd6rMq50nLjM8kfHNZPZGlkiorrNb71UXdvpHa9q689FqtFLxlgfY9/CHVkFrh4hPXkwJ2uFlQwoJefUal0mt8u1Zwfr6Axt4VAauK9Ae2AnUpGVYnC/lY6RZAVl1rCEDT+hIh/UdpPoDG7AAokZ904NvLiK1qWkcUgRrCOsHSAbj6d6mGx6BxaEfecXYvWN6Alp48aIwPrBKhuBrP1JbXUvrF+jxA48Xa8lHvkEBIYC4kMM2gMeBUDWH5Z99rwD0jFsTtPiF+WWsIvVmBW1wueKoBjdXK+cUvfrFnkf2v7hD9GRpef2N3VonUcCR3Hsw4QONSOfxzXJlde+21fW10ww03+Gh9W9lHsTTeY4892ryw0B2Fxg0aUxavP+F+AQA+5aqhpuwl0Jh5kxqJ1M6FyFsPOuTQbCUPGjN36yLdRYo7vC5Cf9d32u/m1b6eck2Y46318UCqB41PP/30HJvefXZ7qnU/Ywl+z5knzcbcqLNwAz6kj7CDW63LU4ZWHjSuAWzZ9WltyQ5XJe8SI2X0p/G59vPXmjJ4HtP6P0DjEUBjBdlwmcB2nZrfdttt13bw1LaISXS2YUBjtjmUCMDFXlbClB8fBWDxA+UJoFkHRuOHGw+sS9lGkvON5HnV/seZuuXDKpT6v0LRsw+grVaykmbx/SELanG5ZMmSviLg39bSEdaCZzDRDyBKitJsg8Z+BbXWn7QqV/MFNAYQVYsJbR9W6FEmaaeSqxk+PpqWuta8//hT0nQou0pzDRrjDqWGkI9a0uLTywiFXevIinKNbPzhkxygMU5C0eI0YqyPDz300IZFDRZ6tKxcp/qqB41T2x99WXWLpVdmfNz4v1wCftIzygRvOdf+q0EWiPpTxr+QQEggJDBdEphm0Bj9tYYUwFU9ny3+qiMAuNaSWn2mDtzSPHM+jTUObhBrdCniqN/W/fbbr6/IHjROzd36EjRNn59mDGlSNGnQmJ2BAH4nn3xyA+iEdakC89ZOWCp7GpelsboPzMnB5537PwnQGN+7CvSaTAgxjqCfccZGrQ6kvFKWxj/72c/63o+U7HP1V8Mib8HvQWMO4u4iPUg+5fpP0yIjlYsHjfGHbM8pY+07pzsSOJRSyYPGuFQp0RFHHNGWw8pDuPLKKzdgK2A7vuwlnpN+jsUz/YuysXscQ0B2SGj5uWYxzJMHjWuwH30f/S5RLJUtX3xOg1mViPdCjeQCNF4usQCNRwCNGeCsM44S6rbu5U0z3qthQOMaK+hxgMbUFP+4apGbkuf666/f4AMH0GccpMDh1Vdf3bLUgd0+PLp1jZVE/diquxG/EqqWk9RpEGUT4MrkwIdeabZBY60/ZUpts9Py2TXtZXVIAXEWryYcl3sK8kLxVD9HVkYNcZvCxIFtfdreVlb/cdO0g1x7X1lzDRoDdNaS+n5SH8SpQykGkYnF5UCXUYn3mckF77tuU7I8UmGqr3rQuGalX/tsgMb1LTlu0JjTlrH6QAHnAFrc0tDuTKqZaABK487k7rvvri9kxByrBNBRWIDlV7MduZQ5Y7zxIyztmirxi+chgWmWwLSCxuwGS+lvqbbcZZddWn2Vg9WM9OyKlEsxi5cK1T0duyo9KSCcAo0puxmxpHSV2nve8tKDxqXzOCi3unbLgaXjBo2xtjznnHMatrXruROleqeAy3GBxjp3HHVBexKgMW2Few49dyQlL3afohOlzvXRfloCjT24W7tIQx7Msaxs/kA6z1cPENTy2bWCxgcffLDdToZdoDEGMbVzBSt7KgTUVVJsgfh+l6nGtWvefz3kLpUPiya83+g5cwUg33zzzb3D0/G9XCu7GtC4Bh/TubwHjfVsnUFcHq677rptvwzQ2Hpj+DTuHf6wXBzLr2p8GusAlXqRa+/VrKQsL9lwV8OAxryIJRoXaEw+WG5yMJluE0/JkAEJoK1WEczVgVVA48+WDyM9QMJOdKWeWGBafLazQzjlt0MHWMXyAxyrspaG0Dv6tzxTIYOfpWX7hdJsg8YoYFYWQlws1BCno1q6FBBXw8PiKAC3dOlSu90XqgsOD8b2RWya3vaeD37wgw3b/dQnkpVXQw5g9AcwXHTRRW3dNO6g174ucw0aM8mpJfXlTbmNeI8HlUMqfupQA8ujFAIAqp+1FH8mY2xDo7y6lTPVVz1o3OUnzsqmfTZAY5NKORwHaMz3AUsO3e2Q6gP+HhYlgMxzSZSd/lY6TGYuyzjuvFXx10XcYfOhDbVtObwoKCQQEkhLYFpBY4w8aonFZRszdP6jh2atttpqtex68Tgk2Hiia3gqgca4PbT0o4QY3Sh50LjGGGe2QWPmT+oyJFV/LELZweqBtUmCxuqCAHeTo9CkQGPKhDsKfLwCxqZkZ/fY1Usfz82pS6Cx992Nu5BaOuSQQ9qyYTWu5EHjks9exWRGAY2ZO5hsRgnR/5U8aDyITkJ/ZsemHhaeKhu7o9VVoOY/iWt2U6vulioTVsYswuFmc9NNN21lWwMa1yz2a/4eNGZHqZUJY5Fa0jNuAjReLrWwNB7B0hgH89YZGZT56A7z47TGSdNCAI1VBkz42FYAgKVb4E3ehK9//es1ycDXuoWeVSUjBZrUB5T6XjYwCzcNVia1TDBebKex54SDWFABVFpaBjAlBY0Bq2sIFyrGL+WTWN2teJ/GuAmwtIS1PuLwC2fpUkBcTbktjgJwHmi1OIOAxpaGEED4sssu622XSbkroA6soGL1YOR9YuFmZZj33x8eOdegMeBpLamssC420vEGQP7WW28dSjbDrpqzOKMgsPVB+sdee+3V4Fv8tttu69uqpFucUn01QGNr3cmHo4LGTLR1l4O1f21Ivx7EldA4JcKCpPmw5JCRxUKq+AdovFhaPeo5XyQwraAx+kfNlmTaQccgdTWHL2L9dgwCim2yySZt2pR7vhJoTLn0sHAWn4fRM7/73e/2dbX5Dhrjts1bLGKgw1ybuR9zLwAro7vuuquVM201SdBY54g1hyxaGVOhB41rzvJRYw0WuWsI618OAQNY9XK1vp3Se+FdAo19HcyoqqZcuqjireHnCjTG0ph5tckFX8vDvHPeuGoU0NhkyVjGzmz0W3U/Y2UlxLVCzZkrxnPYkHmzgsBWBix6MdagvyE3HX91Z/ZsgMacJWPlevjDH15dVd1NEKDxcrEFaDwCaKwrm2ybmc+kIE7tQXgoUCViMLAXkjDlF6vk07iUB1tSAHnYWqQAMhP70spjF28sBRlErPxsFWEQtA+qX/Vki5TFZQsWpAsHBiRrnoBXloZwkMmwKpNsm1NS0Bi+CmZqPLsGfNNyDAoa+3ooQGh5pELdepRTSFLpUvcmCRprfizisNOAsisoivzUB5X388xJt+OguQaNa/2s4xta+xSKoxFKjT7Dh/hsEpMzzZ//ugCUKou62qDtPQVo7CUyuf+jgMb411OLE+sH+HREieUQIw7kwIKByc0nPvGJhvFQLQtIA9gwF5a+euZBgMbD97GwNB5edpFy8UlgWkFjxvJat0N6+PRhhx3WdgLcsdl3hHAQ4w8FfFMAn+r5KfcUFEJ13wMOOKAt1ygX8xk0Zh6Gz1aTOS5GOBy9a57Dd93iE6YWfcflnkL1y5SxUKpdACIVPLM4HnAtuSyAh+6MTPUp450LmQ+yy3Lbbbft8wcNKJ+y7CyBxljMquzRqWrJXIWRXhdqSD9XoDF5Y5lvdTr22GNrq9MZbxygsWaAZThuSJgzegA5tUClacdx7c+g4XDMkmsSNewyHEXL4t0+pvqjxudaF/u8pTFu6awdCRlbSoRcH/jAB7bpAjReLrEAjUcAjdXKlM7oLQaXi7n/igGWiW3qA9Ifc3z/5jNozAuK7PyqXKr2fOh0AEitJqfS5e7pdisABT2BV5VG0nPwleUN8A7orIp2brBUP1xsg68h/KWqZTB+p5T8x1RX3DWeXXuL50FBY9pIt2TVKip6yMF8Ao05+BDr1xLRJ7Ud9IOETFSxZRGphnjvsfrIKcBzDRqzVa0EsFJPrwBpGr9I4X195+SETAD0avwF53jQLvpe7rTTTtltd8bDn46O31tPARp7iUzu/7CgMYuItLeN04S4O2IRo0Qop/rukRa3QIO4FCrlUfN8sYLGvPfsaOHHgtSoFKDxqBKM9ItJAvrNZOwDhFuo5A/mYhdYiRj/1boQ92NGPNNvSq0+4w/CPuOMM4xlG9aAxuyOsvwHOXMC61t8u6MTeZrPoLGf39QcvI0/V5MRIYYfnsYFGqv1oncd6PO0/xwUDdgLuId+aW0C6KflLvmW9t+11FwM3vQ9b11uZdGQsxw0/5TcSqAx/NR9IwfH1xAGOmqYg/Wsku8HJSMxNRYYxT0FZdhhhx1audQuDJAO0D+nM/o5U417ChYbaMfSrkviqe4I7mB9TGU6zms95BMZlfJjfqeGf7iG9DRu0NhjH/iyLhGGivpOBGi8XGIBGo8AGvMia8c64YQTlku248rcDrCqxzaX0ovWwar6ER8sKysr3zlSP7qzYWmMjxs7VZNtXCViYDQfwtSHVaRR6Morr2zlAtigW5pTh3DpKtmyZcvatN53kZZJt2MwkNdsbQPAtvYi9O4g/EDIRLuLLrjggj5+g4LG8AZEtzLRh7z/Zp8/vrr1AzEboLGuDuNP2RMfbT0cgoWAEunhKHyUlTjJ2mRC3jVgJwfrWRomarSlkgJX8E+RKnpYYYxK7BCwMhGigJdIDzzBStePYzoJxc2Mf57ib4o/wDXthJ/zQcm7UmHBrETqqob6b7/99jOSBGg8QyQTuzEsaKxjMu3IYhsLRLVEH9VvAjxqJ0C1eZTiqeK/mCyNS3IZ9LmfXNdM0AbNI+KHBKZFAvq9ZtybJtA4dQCdbzfGeerNj92GgK1KejASC5E1+gxuFIwnYUqf2XLLLds4b3rTmzTL9prt8cYHnbrGZynAlVk5A8wx11KaFGhsrpUoL2B3jtjJaXXCn64Slp32jK32OQMLTeN1BnZjehoXaIwrOysf4Re/+EWf1Yz/6i9bLSz9d6q0wMFuR83bg8annHJKa+iyzjrrFPsp/dj6CXxPOumkGWXX52AJKcK1hJULA6Mat5u4oLQ0hMzPlOYSNFYsAMyhZrckxm/Mx6gL56X4OeggoDHtwgKRLWThPrJE2i+ZQ41j8T2Xp3cHw2GhJWLc0vZ+7nOfOyPJuEFj5KgGb7vvvvuMPP0N9WFPeQM0Xi6hAI1HAI0RowHAdCxWEUvWsh6cqAWalzfZcFd8iOxlZTABfE3RbIPGALNWLkJWXbvIKzp8cEchfF+ilJA3ipX55+E00hQoyhZnK69aEKPU5QhraEtDWLJIBVTWrfLk463S6WfKs2tVFRkpP9INAxp7lwNeCfX1Z6uKlnE2QGPdpgL46gnZ6qp5zfv35Cc/ua0HSo6SAsDU1Su/Gpdr8sdftMmFiYhv2/kAGrNNUy2HfT3wU8U4YvU477zzfJQe8GzPCfEL2EWAOjpxHeRAPuXrF/NKygz1xFpEy5pSZgI0VilP9tpPAGtOKMfCwxR22hJ3EzULdL4mKJm6IMI7WrMY5PkM+z9A42El15/OT8YDNO6XT/wLCagE9NvL+DlNoDG6SpdLCSyJ1VVdygLOG14A0HQRLjFsboE8AYdTpO77OOgqRQDYasmJMYHXG306Peib/P3OOj+XQqcrke7MfMlLXpKMrkA57g9y1AUac2YJZebHXIx5WhexuEo8S0OYMhYYF2iMxasaqMC3i9BJVTdR4JW+p7q0d0WofLE2VV+r1NODxhgYqRy8wZHy45q+pfl/61vf8lEa9aGcMyhRjIH8U3NMZUy99ZBDgD10L6W5BI15f3Un6TbbbDOjfFpWrlVvRabsnlIaBDQmnS408L6U9FAAf2v7LkM2LdOw13788HNjzxf9S995ypkaE8cNGlOOI488spUL7cJ5NjkC99FFEsoZoPFyaQVoPCJozIuz0kortR2SCaa3HDRxMxhz8q691IDMOWCG7StYu/GrmTBbHrmQVTLLl1B9s2qa2QaN+fiqTLDkzfkfY8BkC4TVAzBvHISCaDwtTA1m5OV9CVv8kqUvTuEtLsoNVg3+Awl/Vu/UepU0KeWHtE960pNangyEKeWAbRYc4GZ5W5j6oHcdhGdyZpXOeFAPPhS+HrjtUKXP4s8GaKxWDoBGqcUR9UdGHVJ+uK2+73//+9v6Ug/aR4m6cyK21ZFVYT7cKYUeawnf11If2vkAGlMfPvApoIXtPXqCLzsEUvVF9noYHWA9Ey/fX5AnK+K+3wPID0OURZU9QPrcpAMlXEF8a0cOW/EUoLGXyOT+q/JNm9R8A9VSjDQ333zz0AX0Ey8We2uIbxR+klEyGTs4/Z3tprntisaTsQGQk59a7ODL3+6XXBAZLx/Sx40HEzUj8mSRFl+RbJtmAbfGmsbSa8iYz3ebhcVLL720Z2FDiNwYM0uTHXiR3spZ43eOBQEWZFmMYiILyIWMbHyBl73PhKmxTOsw6DUW7LfffnuvrTnPgMUp2p0JSW5LeC4P9CD6CVuDaQt2UDF5YtJZY7GV41tz3+qBay76G79R6gE4xTeV3VKcA4FfcBa5J1UP2pt2oPzIDflRfnY6aX+vkQVx4IfFGHo8fZi+xbtBHrnvSIk33yT6I+8D7xtjA2VkrKiVC3MFez/0feLdY8GM8zKML/2mtJXbl3maQWPefxbCU8AobuX43ttYgVVhSp+nDdUqGJ+XH/7wh70Ye/95l9UyGevglH5O5EMOOaTNG50+Z1XrfXMCNqcOTaP/+p2KqV2jHvRJycZXrgY0Pvnkk9v6YPCSKiN8FUDyxhZ+noU7iByhl5k1prUhYeqMmXGBxpTF64P4d029y7y3ZoxEudZaa60Zu58A17XsKStpvol6AJ/F96Ax/fTRj350yw+DoZyfZHR0sAbjxTti30+VN4Cpxely96aL7VjrM89M8aM8KhN4K5BueTNGWr6EpTFtnO4pKIOCsOSP5XxKl6OO3jo1tagyKGis7jLJn0MXczJgYULBTv9OUR/mWYYrEabimOxLIXXW/FhEyeltyMy3N/VJ7S6fBGiMPuYXKFK7Nfjup94x+mHQ/0kgQOMRQWPEqGAbLwJAFAcpnX766b2JDEoiH1s7YI04KBGpD4N1TLWGxFH8qITyTL72A2RkxZIVRD3Aa7ZBY+qFYm7lIgSEByQALGX1kq34DG58bDVeSikYRk56wJ3xP/7445OsmHgiO4tHyGBZIhRT9d1EOkBNlCGUD8C0gw46qN1WZPwBm3PE5M7iWQjwxmEa/Bj86Is8Y6uMuskYFjRmUu4nFwD5bMPhA/eud72r2WqrrdpyqXXEbIDGuqJIvfFHzOKCWo6wRdDXAes+82lNe9C3sHQ1uRIivxQBtKhFCXGZhGCJDQgA+Ek7K9BKHCwKmPB5mmvQGHcx5lYEFxEow4xV+PjD0l4P4aB/dZ3Sy0TJvy8odljb8yHm3WaBgf6psj700EOTyqaXVe4/44fyY+GEcZiJET8m1yjL2j/VGh8g2ZOfJKTazqfRA2w49TyoTgKDgsZMfnQS2rXzoqYEtC3tRZ8B2GEi1kWAOIBLfozXPsh7lJtAe7+Gms6uhx0/GZONBwfUUBfG/1xZ99lnn05LDJUD9Wbc1IVfy0tDLPl531MTSOOnu0S6Doxl0sTZBt7iyvJjLMen6aRAY0Bh/ZZavj7kWwRg30XUBeApNaEyfoy3ADEpQKKLd+kZIKgueFp+Pjz88MOz/dby4P3Dz6tf+FNe1IO+mAPFjFdtSF/C+KFUB9xqMWmsIRY4OGhMy+2vcSGQmxyn8qC/6I5Ezw8LRIBuBYJTfAAsLC2gC/XHHY/6lbTnhLwffrt3iq/d8zrRNFkam1wAevk2sNCEn1zeUd0xSLwuIIUD8UynNp6ALyxYov+ycMTh2KojES/ndgLZk5/xImRcRmdlfqDEuM12dY1Lm2HZy3eKeRx6q+rfxEWHAyD2NCnQODWfAxziG6CAl36vvcwBmXS+hw7JXIg6sgBF32SOxpkpNq/mPVI9MuVmYZygMfL0Yw9GErQ13y90W8qoZaJf3HLLLb4peotS2q5cwwsdhF2s7Hwzt4zMNdTfrgeNYc533nR4eJEW/YMDzAHl6Pv0WXW3SLzcLlg90Jx4nOlDH/UHRvPNVYMN4vJd5ywfykT+WNOrTIiDzpGiuQaN6a/e6ApAHit+vne888wl/PebBaOUQeCgoDFjPK51kJH9APbpE/Qv2pJ5GTLVMYcxJLVQwPzd+BDyXRqF6HvKDywELAN9lu8e3zXKr7s4dJ71uMc9bkb2kwCNyYSdIToX5T3inWDsxCUd7khsjs6YYm5TqV+AxsubKUDjMYDGvNhMYnKTMH2puGYwL22ZHjdoTJP7D5yVi4+H0VyAxuR94okn9g0+VrZcyKCN3MdBDO46mJBnFxCGPzMtl3fenysT4ENqFUt56TV1ZDKWIyyt1IJZ0+o1iiWDuIKRw4LGlIWPkd/Or/nZNQMySoj9Hxb0sPorAAfQmCJOIjblyvIlZLKgwA8WcR7o1fj+mslwaoXZysDWRz3QxKf3/wEdciCAthP5pgiFwXiiLI9K6tMYaxq2+6XkaHkS8vGvOYgS6yp/sq/y8ddYgmtbDVM3gAm1cvZ56H+2xaE03Hjjja1MGQ8AnpQCNFZpTPZ6UNAY63dt067dA+MuOeOhTuK0HP6acTPl/3C2QGMms0xkfbn8fyZ1Xd9AZIhlS06n8PzsPwBe7rtdAxpj6Ym1jfHLhQBm3vXVqJbGjNcsDOTyTN1n3Mtti0cOb3zjG6v5YY2WmggO2p8BJ5nM6SQzVXa9x0SVPpoi6qEHQ2m61DWLhuhCo5IHp1J52T2+BV2HYVIHjDx0C7mlTYWAd6WdDPSXQdqXxY4uS38FjZGf6lapMtq90lzD2mGaQWPmFzqnMtloyDc/ZxlpMiKk3XW7vvLw11jApnbjKT8s8z3QBh/K4y3b2RVQWtTQMgDWsDiUokmBxuhNHoi3MmlZukBjyotu6QF64+NDgHsWfNR9IOOMp3GDxrQPixC+PKn/jC05y3QWqTGUSKXTe2AM6A+MVXY/BRpTbwx5LE5NCPCY+zajNygIbfxYsPKEXqCW+xY3FwKM5+a5cw0aUzcWHHXszdXD7jOfyJ2VMyhoTP7M8weZWzLO5fxijxs0RpfweIjJwYeMCRgfsfCmz7wLj0mBxsiSnX8lvYfn9HddoAvQePlbHqDxGEBjEycWjEwec52SQZfBp0sxNF6q4IzD0hi+fODY0gSApi+trvLNFWhM+VAS1P2ElpFrVn746Kcm3Sa3YUMFJPm45wA9+KuDfMrVNRnx5UE5wGqIlVpfP/6jJNGHGDhriI881iYpflhss0Jtg7KCkaOAxpQLCyoOq0gtlNBOgLqUTbeMzwZoTNkAAHVroMnZu5bgfUVRy4HHKPxYSKB85ZQabSPiYDGRagsrA+8yq/xdoKi201yBxtSLPpiyYgJMZusVrk9qCcWHscVbGJhcCJ/5zGdmlZ3afDQe1mAAZOo+SPOj72JFZ1ZjtJ+uLntLlQCNVbqTvR4UNPZgXs6id9ylZjubgi18+xnzWChh8gwggFWbbmumD7JAocR4iiUOP1XC6b92P+f2SvmkrtXSWK1zmWyiwPNu4hoCRVkXd6hLDihkAU2tR7DGAZxiWzZgBJMmJkgcyuOtkFOWVpS7BBrzPfGACfoUCwR849huyOI9AKe+53Y9Kmjst6oCFgCsM0lGfuxgYGeJ32oMkJEiAAQrGzoH1kO0B9Za7Eyi7wAM6jcWH4ejEiCW5UuITJlkWj1wo4ZMAWI0Hot5KWIiaPHoM1iV0Rb0A94P+hDvhI79ehBUimfpHsCd5UnIYgTvFKA6RgAA9b4vsGCTsualX/nxg7ikR7dDb6CdaX8PKue29KPnqW9XyojlKGMBbUw5sZL2CziMJcgsRQpc6JZydqhhRUVZAdLV3YHJKHUAm89DxzHSTZOlMTKnT2AdaTLRkEX8QeYVLEozfqq+oPx4DzDoYDysIXStlCEG5U4RbcOY641drAyMueyA7ToEdlKgMeXFyhBd14O+6ge6BBrDh7Goa1cHlooYUPAOQ2pMwXzbv0vjBo17mTZNz+JUv53WDhZyvkvNO4ixhh7UbenRubEgt/5UAxpTNsbJHXfcMdnn4Q3OgN5dA4pxbom6vbCypVwAMf6hd+hOPotPSL9gDlF65+YDaGxt7PUjrQ/XjJ/M7f1Cj6UnHAY0Jh3fLXZE53Qb8meuxi4HdIccjRs0Jh/an0U5/200+dDH0JXM6Iq5r+qO/mykSYLGlJd3CBwsNXYiQ/vuBWic7kVTCRoDAuDMml8K/OMFtOe5jyrbEiwO4SDEgIkCzgeMgZPtA0wiBwFZyJM0vHhMQsZJlA8Fiq0VrPzqoI8yZPXW+7n8+VhbfELdfmRpGEQtDhPUEjFp4mOC3Jg0oWgwKTTFoJR+mOeUy8poIFImGAIWAAAgAElEQVSOj/Yf0gxbLiY3TBz40LDFF1Cqa8DPlYf7lIHJDRM4QE4mEH6CpG2bei+4VysDKwvxGWQpPz8mUQqIKs+atje+qZD+aOWjLiVihRh/inyomdRruTQtfp6wVKSfvec97+n5RURZ9/LTNKVrPs7kTVuYj0UWi2r6irZT7h0cZXxKlV35+TwBv5iMMrEGuEr1nRTP1D3qDz+UQWQN0ET/8YB+Ku2w9wDksEBnaxzgBRaI5JdqC/12+P4KqGz9jzCV3pdx0D7r0y/W/4OCxrqQh1XhbJFuz2OBSS2ptAwozCyamSKN3+LUt5I04z4IT0Fjyx9ALNV/mdiqT2UWMNEXPPFtNl6AF4yvOeJ7rhNhJhApKoHGLCpbnoTUK7WYBxii4IClGQU0ZlzQOuAaKkfIiy3Kli9hykJY29kvUClvxkflVQM+aHq9RhfTiSdjeo6oh7cgThk8qOsFv81ceQO8aj1y1liaJnfNAbbGC3Au1ZdJS3ltyynxUxZYfOuNF+GSJUuSW4vhh36jizq0YaoPAjAoTxYnc3MNyqSLs7hWStVHQWN4A1IAlKfieitsFm9KNO2gsdWfBUVchvHOMUcbxeod2TO+sViEbgGwgwuFWncoViYL+U7wnjD34z1Pjb0WlxD9AmAQQM/qw2KT1100jV2jD6s+U8qLdDpP6gLHLA/iUBfmc7zv+s1TXaukU9JGzI8Yr9Cn0ecMhLK8CKmD1sm/m5PWx5hL8J3CZQGuQqj3IPN+qwvfU4xfMO7BxZtvT52D1syF4Ee52IrPnJrxgbExNyeycqRC5jb0ceZMzGFT44+l4xnAPVgD81xkwiK4B/Mtvg8H1bm1fb3MPG/fV7rqoWkZx5lf42OcOQxGQHwXSn0YHr4+g8qf9GA3yBAdhPzRD0pusKz89s6b/sYC47iIvs+7jnsKxkLGWN75lFy1nfw44mWUSu/LrPxq3gfSUzbeMWSIBbLXYZUnZQr6PwlMJWg8LY1rvnZZxQkKCYQEQgIhgZDAYpDAoKCxHoAJ0DkbhMWCAkNMJLqISYVu28TqMEUKJmJ5NCp50Lh0qKC34vRAGwq0+q5F8S6RWnICDqeoBBqr5StWSl2TCUBabRuuRwGNFYTDYrQ02WMSp/n7Q7AAPPR5yTLegFmseZjgDEv0J8uXNiwBRQAwFp/Q74BiYoVVpcUpgQH2nlIPAIxhiHZXy/3Se6dnjgA2e9IT6tmhlAN3LR3Wj1ZfQnxbKgGMqZUS2+RLcgYEUJ5Mvj150JhF0BwhI/Xrz0FWJVosoHFJDvE8JBASCAlMswRwfcn3JucuZZrrHnUbTQIBGo8mv4mlRunjoCxebFbpgkICIYGQQEggJLAYJDAoaKxgLD5va4gDddiGzw9LMfthiW4/LAb5Yc3hSU+SZ3t8DWGVYuAQriJSwOekQWN2QXURZWI7rZUTdzlKAJ4AfrghwHq6BLKRVl27YJmcoi7QGDDSykPogewUP6w7Nc0ooDGgL8D3EUcc0bMsSuWn95Chbjf323+RmYKtKZBQ+bE7g11Io1q8kA9WcLhOYFdSDWFBb3LkvVDCSkjdZ2Al2UVY8/AbpR7IVg+pxWq+i2h3rM9TlmAeFMcCq4bU/6h3H/ed73ynlRdyK8mE/ACV1T+4P2CKOAoa8w6VdkJhCWft5suYqmOAximpxL2QQEggJDA9EuC7YQf3mevK6ald1GTSEgjQeNISHoI/lgqmIKIc1kzKhsgmkoQEQgIhgZBASGDeSWBQ0FgtD9muXkMAnwaqlEJ/kj3AlfoHZiteDXkL2NQW20mCxlh61pD6hsT6smQpWeIJ6GoyxrdtirpAY+Rr6QG3asrjD0ccBTROlbfrHv1D64M8PZnVLfXCByn9sWRx7HlM+j/1UJ+iWFx74kwMaxvalu2pw2zJ9ny7/rMV3/IkxJoeNwGUdxDyVsNYTtcQfrk1f9XR1WoYwL22TFjsG0/0fp/O5gTE4bpEulBD//L8fPoAjb1E4n9IICQQEpgeCaBvcs4R3xDckJW+CdNT86jJuCQQoPG4JDlGPlhhcGADh8JhCREUEggJhARCAiGBxSKBQUFj3WK+9dZbV4lpFNAYkMgAHsKLL7645zsd/+ldPwVPSZfygTxJ0BgftTWERarWr9ZnHryRDX41caOAb18sKNWqFr4pUpAV624lPQm+9owHrHO1DpMCjQGw8ZGONTpWvFhf+0ORUi4lFJjXcuJ6A3+FWKzO5qSOegC84oufg5Y4wE+tpSljajur999rdcFNDD4s6eMldx7a1jXXHK6XOniHdx8fhYC66j81x1MXI7C+qiVv+X7HHXe0SfWgQT1kuo2QufBAtNf9FTR+4xvfmOGy/LZ3M1Oy7g7QeLns4iokEBIICUybBPA7jI9/Dswr7VSZtrpHfcYjgbT2Ph7ewWUECXAIQknJG4F9JA0JhARCAiGBkMC8lMCgoPHSpUtbgJCTmWvANsAxXFnkfuqX1FsaAxIZODZKyEGoniYJGtduv8d1h9Yrt40ROXOQGIegsmUfOWm63LWvM/+7QGNcZBiv2sNbOAjH0hCOCzTmkCtcO7z5zW9udt11196BZJpP6joFGiM79ZWcSoffYaxqv/a1r1WBoCm55u5hdQRwzenlL3/5y/sOjEuVhXsp0Bj++Er2CwPKA0AWa2CAzBowN1dmvY8vYz2cUPPjGgt5wFUOo8odisSBPZZu7733Vvad1+jmWl99j/fff/+WJy5caskvcvgFJQWNAeNL5A/4K80nAjQuSTSehwRCAiGBhS2B3CHgC7tWUfrZkkCAxrMl6cgnJBASCAmEBEICIYGiBAYFjbGMNPCHEMV4VNIt8B405kAwzW/Ya0699zRJ0Nj71vV5239OSNc6cTq4J0C7nXbaqS+epuEadwW4YTjwwAP74nle/O8CjTU9YG0tqaXsqKAxFtTveMc7GhYlfD31P/61AbkBLe1+CjS2Otx0000NQDiysvipkO2knPg9Kv3xj3/snW7uQUKfJ4smb3jDG/rcsORAY8oEIMzCAa4QPC/9jzVwbhFi0LqxuIGsH/OYx3TmieV36sA89U18zDHHDJT9Rhtt1ObJTgMjDp2z+mIxXku4xrB0hNdff31fUgWNS36cSRig8QqtPJFFUEggJBASCAmEBEICw0sgQOPhZRcpQwIhgZBASCAkEBIYswQGBY3Zrq6Ay7Jly0YuURdo7LeSY2mJD9FBf9///vdnlHOSoHHKt+6MAjRNzzWCypODxJQA4FLuAfDzzKGAgIv4i7XDx7D2VH7Ky667QGPAS0tfe+gglrwK8I4CGlMPfGVbGSzE2nTnnXduTj755N7hfIDtZuWuVtddoLHVH9CQA/6o69prrz0jL/LEshb3J8MSW1LVB7HWA7cY9Hks8LUeCoJ2gcZWJg7H4/C3448/PgvmskUWVy3jIqyXAa3f+c53Nnpwn9XPQgV3yRtLYHvGlt1aIj9LR8h7b4TFsj1jkaGWcA1i6Qj9Qk2AxrWSbHpu/eh/9uMQyaCQQEggJBASCAmEBIaXQIDGw8suUoYEQgIhgZBASCAkMGYJDAoa4zNVD8N73vOeN7If1S7Q2Ps0/e53vzs2CUwSNMY3cA1538t60Bfb6AH9DODi+rLLLmsAlg0w9Xl4NwwpH7ddoPEwPo3x32dlJBwFNMbNgfJ67Wtf27PkBCBNEa4AHvzgB7dpPFiZSqP3AHcBh0844YQZwCvW3cMSPq21Hlhw4/oidwAc7aQWyRdeeOFAWQOussCAdbj381zrm3qgDJum996zYPHe97632WyzzfrqyyKCLWTA95JLLmmfYyFeS/79VyAfoNhkjOubWvILUYDISgEaqzTiOiQQEggJhARCAiGB2ZRAgMazKe3IKyQQEggJhARCAiGBTgkMChrDjK3gBtYQ1lhFdhWiCzTm0DDdhv/Rj360i9VAzyYJGr/uda+rKouCvFhuKhisz5BzDWCuFp2kuffee2eUows0vuKKK9q2Re7Iv0Tf+9732jTkOSxoDPCpwCmWwCnQW8vjrUZTbkgsvsrW7mlI/h7sxa/yoITM1lprrVYmRx11VFGOHhw9++yzs9nW1ANLYNrCflg0j0KlPGknrLwtP0Isko0Ae/VZql9aXA2//vWv96XTdwB/18YTILpURuN7zTXXtOlIrws1xAnQ2CQVYUggJBASCAmEBEICsy2BAI1nW+KRX0ggJBASCAmEBEICWQkMAxoDCj7xiU9sgRcsPTmwbhgC6FHrUu/TGJ4K7h500EFV4BDuKDbYYIPewWP4UE35Xt5hhx3aOtS6k+iqIweQGYiFewMOQOsigDatG0Cf0uGHH97ye+lLX6qPstfetcMf/vCHGXG7QGPvYxkXCiU699xz23JS/2FB49tuu62PT41/1BtuuKEvjT+47Oqrr24OPvjg3sGB+OQtkbeahv+g9J3vfKevTF/96leLLPC3bH2H8LTTTutLg1sG/DHjpxgQukQAocoPNxaDEqDv61//+uYFL3hB86IXvaj43vEuc6Cg5av+gP3hcyxO1JC6S9l44437wHfkankRKkid400ZX/ayl7XpeF88BWjsJRL/QwIhgZBASCAkEBKYLQlMJWjMQR8o2fxy2wdnS8CRz/yUANY71kcIU8TE1uLUWqCk+MS9sgQAKkzWhDWWZCWuvo1rLX5KfOfjc4Agk59uv52PZY0yhQRKEhgGNIanB+uwrPzEJz5RBJa0PBw2tv/++7cADsBPCjTGj7GCQ/7gKuXJNeOPHrzFQVq4IfC03377tXy7LFR9utx/BY0prwcwfTrvf5ht80pLlixpy4ecSoSrC+//+J577pmRrAs0JvLLX/7yNl/87HZ9I/h2e7/Aw4LG3lVHyg+1VgZXD7vuumtbVmR+yimnaJSeOw/rOxyY9+c//7nvuf/zy1/+so9fSn4+jf/vrWpLCyqUiUMMrZyE9CWlq666qn3OgkRJ36YNlB/1GpTw9as8SocD8t7ha9vSAIQb8eyAAw5on2FVX2qLH/7wh238lEzQO57//Oe3cVhYKeke1113XRsfnikf2AEaW6uNN+R9Nd2p1H/Hm3NwCwmEBGZbAszl7X33uzlmuyyD5KfjVM6d1CD8Im5IYBgJTCVorAobVhCzTQA4KQui2S5H5JeXgE527n//+ycjYhFmE423v/3tyTiTvMmEaphJ1STLNCneTPxM1oRYd41Kn/rUp/p4pgCaUfOYrfQAJN/+9rez2em24/e///3ZePEgJLAQJDAsaEzd3v3ud/e994wngLWARTmgEbAAP6iAYhxupmMR1ym3DvDacccd27j4T7399tuz4j3//PPbuPDEEjZF+LG1/I899thUlIHuedAYH8Tqg1WZAYg+9alPbfPfd999ZwBe6mIAoBAXBjnCn+1DHvKQlp/V6+67756RpAQa43vX0hPyTQag8wTop9bQlmZY0JiyGg/C008/3WfZ/idvBfcsnT8Q7be//W1fP8NyNQcscp+6Gi9A+2HIW2vj8zdHLDxyMJzlaSG+iZXQddV385FHHpmtB+ne8573tDyH9c2MPNR/OXy6FkpV1+M76fUAXIloHeg7GJ6k6Kc//WmfFT5uS/whkaTDuthkRsg7mOqrxOW7rr6XN9100+RuAO1Xai2dKif3sIjXMuBnu4vUBQvpPvOZz3RFX1DP/KGCWngdwwc5DFF5xHVIICSwMCSg+tWTn/zkhVHopunbibLnnnsumHJHQadLAgEaj7E9UWYvuuiiZo011mjwaxY0fyWgE4n5BhoDRgD8rbLKKj3LufkrxfGVLEDjvCxvvPHG3onwHL6UowCNc5KJ+wtRAqOAxoyfALIp8BfrXkAh/BVjxYsLCl1kVpCF66222qrB8jYH6HmrR/Jk7P7GN77RA56weOXag5gAXTlrEe+bGdcXWKouW7ZsqKb0oLHVkXICWAF0AhZ/5CMf6fPdy6FhgGSeAIKNByFuAgDJDJDH3y4yAyCEB3G8pTHWmp5KoDHxdcIHX4A0LLzJ89e//nUvX1wW8My3/7CgMW2v7jrgTRuZmw/AOBYLkB9WpTznp3Wmn3miTS0u4W677dYw1rNQDMAIsHzrrbc2jPsaL2WF6nmn/lMP+p3yAgBHdjyjHlgfc2ifWkprPVKLGPBQnqSlTawe8OcdYOFF443ic/zaa6/t40Xf+eQnP9ngbgJQmPcOP8OA7Vr+N73pTSnR9BYCtGzGD+MP3g/kwqF53nodPTJHRxxxRF8ZkcvnP//5hkUIFqkYO/ARrYA1ZfCW/cY/QGOTRH2IXgkovMUWW2QTBWicFU08CAlMnQRUhwjQeOqaNyo0YQkEaDxGAbNl0hTPAI3HKNgJsJqvoDEWM2yRtH40jO/CCYhr4iwDNE6LWBWcAI3TMoq70yeBUUBjkwZAlfoytTG1JsTqDlC5y4LR8gEIUl/KJf7Pe97zekCdpfehd7Fh/NZbb70seO156H8FjQE1VU8x3j5kOz+W1znyB9uRHnAOK0nPa++99+7tvOJQMHv2sY99bAbrGtAYQPDoo49u+Rg/HwLE0S6Pecxj2rjDgsYUFJDbAHDNCzlhba33yBPXJZdddll7nzb3Cw+A7AceeGAbR3nkrmsO4ZshWLmBVSyW5p7/4x//+L5D8njOQiR6rOpKuGlJ1cMD256//19zCJ8UO3nJoofn2/Wfvp9zP8B7/r73va+aH/0LENnLQgvK1mf1fdxVNp4h78997nPKou86QOM+cRT/8A4+4AEP6LVpgMZFcUWEkMCikIDOqQI0XhRNHpUcowSmEjRmUoGSzg/FcrZo5ZVXbpXOAI1nS+rD5aMToZylMVtzrR9hfTMb5A+KCdB4eKlzIA2WgvbLbQ8dPofJp9x2223bMaULNN59993bvnrllVdOvmCRQ0hgghIYB2hM8bASxCoxtdU+BeIAzJ544okNW/kHIawpOZwrxdPuYaWIhSpWkCX60Ic+lOSF9emgpKAxYB1b77FetnL5EFceKQtjzReQjS3yKQDS+AGoqj/pt73tbW2er3rVq5Rd77oGNCYi/u+Rj/qptTwJAXex2IXGBRrDC5dJeliZ5mnX6J7mbxgZ2n1CDqLzRP+kLuoKS9PYNc+vueaaXt09j0H/YxWt/qEtDw2xksVyG8JiWJ+lXEfhJxJLayz5Na6/ps34PplV+qBl1/j0A/rXc57znM48WQDCorfmXAqsf5/97Gd38qPvdrmK0jICKmN139W+LLawE6H0zgVorJItX2NVbv0vQOOyvCJGSGAxSODCCy9s50r4s18ohGsowyO8u6uFUoco58KXwFSCxnPVLAEaz5XkB8+3BjQenOvoKQI0/r+tvamJ6ejSXXgcakHjhVezKHFIIC+BcYHGmgO+d/HTybZ4XCcAjGEJiJsAAC+AoFHALAAi8sB9A/wALd761rc2TFLItwYs1vISHz++8Lr88st7rooAGQclDxqTnrJidfrRj360B5IzCcFyMuWftSs/ANKPf/zjPTAcWZ588sk9ngCTvqwA8fhZtZ+30mTMt2cGvHblDX9cEuAeYenSpT3LcOSlbj9w72A8x7FoCFBJ+7KIjMyOP/74nksyQGrv25n6Wd6EXQsR1OULX/hCjy9985hjjukBnRzC9/Of/7zTorVLRrlnlI1FVeqBj+rjjjuu109ZpE7lp3LsOmeBxQRAUvoSfYF6sFDCPdwy+DbPlW+Q+7yztAmW3aeddlqDCw2shj/96U837GAa9J2mn+CuhTMR6FvUAf/PuAXB//EwBGCNiwss7OFFGSkrAHpNXydP3G1Yf6KNSoQuafEJS7KfNp/GARqXekg8DwmEBEICIYGQQL0EAjSul1UxZoDGRRHNmwgBGs+bpugVZBLuKeZXDYcrTYDGw8ktUi1sCUwCNF7YEhm+9CnQeHhukTIkEBKYRgkEaLxCb0fKNLZt1CkkEBIICYQEQgKjSiBA44wE2cI5qIXCOEBj8h2HRYxVCwsHrGMGJcowiGUUcUuWDDVlgIcdMFMTvxSHw11S9ZgN0Ph3v/td73CZUhn1+bgsjanzoP1XyzHKNZZeNb5ANY8a0DjVjspj3NfUIecDcZi86NtsY/ent3fxWmigMeMGY1hQSGAUCQRoPIr0+tMGaNwvj/gXEggJzJRAgMZp0Bi9Db18PhI6Pi6LxjH3GqZ+5DtOvRyd2+9QGaZc8z0NcwA7gHTUsjLHH+c8xcoDz9q2oB8wbx9XP2TePgg/+uAwOIfVtSa0A1Zr4pbiMEeqcZdU4lP7nHYZV3/zeTI2jtrupB8GL/FlmfT/cfaBcfKadL2V/1SCxmwJxfccP/zuecLHoT0///zze4/5+F5wwQXNa17zmt6hNve5z32aBz7wgc3Tn/703unVbFdLEVsKjdeKK67Y50PL7rNVLke8KBwqs8suuzSPfexje+k59ZsDZfDDiG/k0gt50003tWVgqy3EaeYveclLmpVWWql3Ivp+++3X8/9GR4XYcmfl48RpiO1vbLnkNHTqjj8wDvzYeeedWx+BvYh/297Kltn999+/4RAV4pIGx/Lvfve7BwJLr7vuugY/is985jObhzzkIT1ea6yxRq8c+AhMnbRu5UiF1OfII49s1l133ea+971vj98TnvCEBhmw5RCqAY057dtkdMUVV6Syau/xgT311FN7bYYP3dVXX72XL/njJ5PT1/F5yRbNFMGfvGgz88NGiH89K8NFF12UStq7x9ZYTmjfYYcdmkc/+tE9HvjKw5cbbUSfnxQBEtOHATgtb+qNH79XvOIVvS2epYWQHGjMVnLqb4cN4UOTE+DZUltaXOAgLJMdIYpIF/H8rLPOavbcc8+eb0bq8Hd/93fN+uuv3yxZsqS35bVUD8+fLcmUdeONN25sUQme66yzTvOiF72o1x/9+00aKzfvgfUH+rPd9764+G/P8PNoxPZzu48fy1olkK20lo4wtx2WstMv8fPImMXYRXkZyxjTqLtuF7dyRRgS6JJAgMZd0hnsWYDGg8krYocEFqMEpgU0RhdBZ0HnN93poQ99aJ8+w7zLaMcdd2zjMeeCAHWYR6K3P+xhD+s9R2dDnz3jjDOy+pDxZB5p+hNuUkqE2xKLf/DBB3dGx4UM+ijzLs5joY6rrrpq7+wO8kVn9jplJ8OOh/jAt3KZz210deaJzDVMNmuuuWaDHHGtM4iOTFxcwOyxxx69+YLp3LQd53TwLKe347rHyrbrrrsWQTid8+JKqYsAIY03Ya0LmRxPAE3mYBzG+ahHPaoBX6DdmO+iN1Me7ZM5PtxHZri2Qf7MCZhP8KM/UNZanRuZEZ8+bfTlL3+5V5Ytt9yynTvTxsydPQbCXGLZsmW9tqNO1If3jLS48unqg7iOMfn+4Ac/6GVPiK7CvOhBD3pQjx/hi1/84p57IysjIbyvvvrq3tkM9p6DdTDP4r01nEPT2DVls7zp3zkCEwLjYF7LeRTImDoyB8W3MGfMcNhuDTGegM2ADdicDn60H+1I3zQ55Pjh7snKTfuXCHdfjAccQLzKKqu0/W3rrbduDjnkkAbcpUQqKw4WhVjY4YwADjgG20Am8OdMCly+5TAOnxdzSupN/zfch/Fsww037J25AKZQmuN7nuP+zxhDH6GNqKthfOA7yPWVr3xlFUZHuehP4HkvfOELezhJqj/hxmu+01SCxs9//vN7HZnOzMvhiY8+z/hxAAUrPgCjdi8VMnjxAnkCaE7F13s6KGt6TkrmY6txU9cM7l0H4PAyW7rddtutd3DJIx7xiPaePbvf/e7X8tlss83a5wBEgN8Gall8DengBsDzASyd+r3JJps0pdPKGXwAd+0DqvnpNbJHzl0fIZMr/vOop6b31yg8+JKz+7mD8PTwkre//e2WxYwQJe5xj3tcy8/4pkJAeMro6wL/VHy9h6xSRPuvttpqxfSAx+NckaYO+Ns0QFfL6q9ZTPjWt76VKn7vngeNv/71r/fAbs9H//PBxddijlgg0PhdigQKEQC7xk9d896kDjTyZUA2jDOm1Kd42T0+tuoPk0USe5YLOWldif8WVw//9LxSY5jysWv6mvFDKfP9lXh89PkAWrxcyMeWRaygkECtBAI0rpVUOV6AxmUZRYyQwGKXwLSAxmawkdNHuK9+uT1ojG97DAW60pOHGaCk+o3KEoClRABKlh+Hd6YI/RXwwuJ1hdtvv31fHVP8au4xj7N88FOPb2wOGrV7qRDQsMb3N/NOAKMUD7331Kc+dQZgSdn9QaNd7QFop/NCAEbmnzkC3LEyMM9I6b+5tP7+XXfd1eh82/j6EODM5tieh/3Hh3+pb8IXo43rr7/ekiVDA62QBcS8tGsuDjBoQCPyLB0YCqaSs/7FQMzqf8sttzSA1QYc2n0NKZfNa2iL0qHDzN11TqUCOOGEE9q8mZemiLRPfOIT23haFn992GGHdS5YADyyqOPT+f/gL4Dwub4GYGxpMGzKERbF4F4GcFoaHyJTyt5lSKSy4iBjrIpLB8+yyFAyUsM4q2ZuzLwWbGq2CUMnFu+8zHL/Wdgw48tUWZkr5w5u9jwxVpxNK/RUebvuLXrQmJVlHfwYSAE5zGLSNygWqkqAMAC0HqRlALT7nFTuiZU2P0DzccKK8rnPfW67MmT5s5LHyc4pUtAYgFnrY+kJGcSN9CPG6vADHvCA9gXBQpUVO7M2Nh58dL/3ve81++yzTxvXVoZSg2LXijkv2JOe9KSWD3mYZSwWkaw22UfN8gd8zw2o1CsFvDLooBRyqrfKW/MeBTRmQu7LiexQ2hjkN9988561ttXBQixAlVg5pL/YKqTFAwy2fvSWt7xFk/Rk4cEVysLgxIo2K4rI1HgR0rcHPeyoL9O//aEdUgsHKNMAifRBWy22/JEzH8UUedDYrNdJSzoUUaywVRnnGf2WA3BSVAsaoyD6vs5qMivMKOk+T2TKCnQXpWTDAhH86Bue50l11F8AACAASURBVFOe8pQW0Kd9rM2pu8mPfO0+769SDjQmjo4H5F8iVkSpv+XLzgFPLHj5hQqUBVbgGWf8+IkFCYpCUEigRgJ+XMOqI2g4CQRoPJzcIlVIYDFJwOskHN65EAmwBz1JjWDQP0x3Ivz1r3/dVk1BYwA5rwsyF2Fu5vV8DEByurTKchygMfr2Xnvt1epk6GYYa6BrAyBhnak6G8/Rx0qGO60QMhcKGp955pl9cxn0e557eVnZuow0sIYGrDQdk5A5LvUAgPHzIPLAstSTgs5YOeYIS27Ni+suqz4sCC0+AOWwxMGsfhGDOQtAONbi6P06L+XaYwyWN8ZOViYLAXLBC9gdjJWv3SeEF1a3ObL+TDug42tadHuAVwXaeU6fY8EFi1mLT9sw51UMwZ7lQHAFjdFPtA/BB376/sKP8mJ4pHMrykc5/VyE+OAUKVIgNAUaA4hrv4IXc2r6Je9aCp+hPVPYBAstCobTJsRlFyYGfsxrPbjL7uoU1YDGgJNYRZv8CcmT8oMtIStrd4sDJsDCRopUVhhYqlwYUzEo8uOO5YkxXYow2NMy0P/oD7wP4BaKzRivWmOnVH6D3gOLsF3/JiPGI+bRYFPbbLPNjOfEA29JEUA7/dl4ESI37U98S/Q5/SLVn1L8Z/veogeNraH4AHKqsSL8WOkB+FocQgaMHOkgBxCVI1brlCeAJh8XJVbo2PatH1YG6lRHUtDYQCZeaMApVg+xGqST6sdIQWMrC50eoM1kAHikJxATz8BhOvk555zTbkUiLoOErkIzGOaUKgYIy5dBjRUvv42dFTPvrgHL1hRhmQof48lAxuqlEluM+LhaHAuRWYoYYC1OytIYhUw/lFiMAqp7ol58vPXjwCCZIgYYy5MwN/CSloFU4+JKBRcjSrQLVgyaNwPzqKSWEZQBhQ8lTPsnfRjlUBUC+nPqA+VBY6sXCwXaL+APSKw8UcqQm6ca0JjJg23dIU/6rweEyfPGG2/ss6hGSaF/pkjfR3hiOeItbbFyePOb39zXfmwl8lTr07gLNL7wwgvbfBgXSlvtVG70G79iz8q0gsKMBeeee25f21MPtkepVQTvCu0cFBIoSSBA45KE6p8HaFwvq4gZElisElCgE71loYLG1n46d2EXWY4UNDa9E3CM+ZdaJKMH+fkI26tTpLIcB2jMNngrGyH6N7q9Em4LvF7e5RpR0+auFTS2/Jk7og+brg84zJzW77a85JJLkmwBtnSuDIjvAWF4M59QOQLceP/JJ554YisXwP0c4f7Qym8h7vxShFwB3C1eyWI3xYN7yMVbqx577LEzXCdgaatGMhiH+HkzcxIrDyFAJC4N1ZIXmWGJrGVnTvzVr341WUQF7ow3oOhXvvKVtm8BoAKU2XNCwwCYA2BRamUAN2BOyhzD4tN+1k+0EAoaW1zAVFzrmeUrfD1Qbnkz/8Py2BYmiEs9zU0GPKl7aleoAqEp0Fj1Jery2c9+dkYdcJvgdVSPN1BfFkGsfgCRKRcU3MPVgcVjPmoyUJmVQGPef/++Ak77hSPKzrza8iPMGROprCw+c1/meyZ72hfcwfME4/FEXMWImN+mdtEzvigYDbYxW4SVttUVbIjvALL1hAW5B7hxFesJC23jxyJHynIa1zQYsFo8Qo8ZeL5z9T9A47+tYAE6pojBSF9WGvPOO+9MRe37EOZAYz5I+mKzcmMvX4op5VKADBDOkwepKGNqhU8Hbw8a468r9fKSFy+sduauD5EHxK+55hpf3IaXTfl1WSAif8z1LT4fBQURjTmArcXhQ4VikiL8Y+Ery+ISDgsaq2UzoF3JJxUr4ZqvWjtYWWtBY9xMKFDI4IuscoRlqCoJ/B+WAEsVaAVc7wIi2YZmH3vqj5LuKQUas8KvfVbT8F6ocoL/I08KfpJv6j3TDz9l7Npigq9h3WKSsn7kY48SbO2MItvll4nFEouLsoiSpjQO0Ji+olbfuM3oIhRHKxOroZ5UUceHcZfbEfqzjh8oMUEhgZIE9L2kL6betRKPeP5/EmDCyeI3PzvDIWQTEggJhARUAgrQMeYuVtAYQI4F7xQBHmCZZ/oRIHKKVJbjAI09AJ7TiymLgh7MNUchnatSZ8AtD1Ybf1y8qbUr29hTpBbTGHx4owRNwzwOK2+Tt/dBi3s6e0aY86dqersaFuWAKMA/4wnAlauvljN1jW9h40OYmrtbOoyN1NoQoMmIPofhifFiftFlfIEMND4YQ6oOOh+ENxaUqXjMabwlL+2cm/Nxto+VlTDVJh40Zl6vCzRWd0J1N2p8c1biGN9ZHMLUwoUCoSnQWIHert3SyAqLUMsPnVUJrEHnXbkdsaQBC9C4KeM4xaGYo3kCyLWyEOInOzdOcF/xC+KrUaHxVlkRB8Of3BlT9FOMKq0MzM89poTrH3sOgOr9ZFu+hB5LShnkafxxXDNX1wUtjC67iPdQDQdTuxK0/zLfzxH9SV1kYlE/HylA4xVW6E2muhqHVQ/r6ISsPKVIO1sONNYXG7Ayp5wof1ZELX8GV7MEtjgeNGbLUm6wsDQeNM6B5sRntdryJ8QBeo7IV0FuPiBKAJuqiGD5WyorHy1dQWQgU/J+W1Pb6TU+vrB0280woDH10NXhFGipeXLNirXKMTVg1oLGaqWKkpv6MPv899133zZ/rNtLcvfp7T/uTLQeH//4x+1RNtTVW9J6n0ceNMaqILU4oBlw4ImVAxl4K4QSaIzCqUrkhz70IWWfvKaulidWuH4lG4sJe07IVpwu4qNK/7M0rGoqjQM0hh9WzJYHik6OAK31/fVW17w7uvsBxbhEjC2WN2FO4SvxieeLRwIBGi+eto6ahgRCAnMvAQU6+U4vVtBYDxJOtQqHs5k+wxwgRSrLcYDGbC23PEtgAgdAozcCeLF7NmUskSpz6p7O1dCV/Y5Yn0ZdF6Z8M2OJZ/UgzM2Tla/Ob5m3KWjFHEaNZ1KLour7GLlgnEHegFqpOQZgm5WROdOwpFbGOfcFypuFccuXtDY/A2y0+4RdRlbG79JLL+1Lw65gTwoaA957i1SNz5xfy9BlwY7VqcYF/PPkQeOuHbW4NFR+gKddpJasCr5bGgVCU6CxntFz3nnnWbJkCCjNwhEGYX7uhnGhlrsL6Ic5Vui4rDjuuOOSc6QSaMxucssPK/Aun93kB0jp0/hFA5UVvD324oUC8GxlIPQuVS+++OL2eWlBhv7Prmj6Hq45MT6bNPGeWPmx2K8ZO3XhILVbWL8F7PrtIhYLGOsBn7sWmbp4TPpZgMYrrJDdvmHCZyXUOhIh20JSVAMaY7lnvPiA1ZAH1PzhX/pRhbc5jO/iraAxq4hdRH2tzITk10UKpvqVF7bdKC/v2zfHFz6Wzq8QU197xmptylWB56sA6jCgMfwY1FgJ56PoV9R8fvzHitXKScihEp5qQWP1LWQnPnte/j8fZs0/Zens06T+6zaUnMsUn85b4C5durQviu/jnBRbIkB3rY+3ni6BxrgMsfS8A12W2lYW2lz9rfmVSO1XtcA8uwL4mLC9yvfdcYHGaj1BnVPbpKijurJAkfQfTZQokxmguS+vycmHKGeWLrct0KeJ/4tXAgEaL962j5qHBEICsy8BndzyrV6MoDFAWgls+fSnP93qMgCPqa3LKstxgMZqFcguvxKwPa7eo6AxW7FLpMYs6I+eAMRMD8Ri1oBRH0//EwejEEvHoehKemAVoJsn9GtLi/sO3ZWKOwdPuuW8dn7qeXjAsIYPBiiA/LQt8yGTDXMlKz87glP9zefvjbOYs3lS0Bgr4y46/vjj2zJQlpSLQUvPzkYrL2HKalZBY4xQrK7GQ0M/jysZ9+hc44ADDlBWvWsFQlOgMWeyWPnBMmoM+2Zk0jS9+STvgPHCBUQNTpDixb0u0BiZqwFU7uwgz9tjR35eqLKiHiXgG5DY6kvoXbvAX5+zc6CmP/tyT/I/smT3bGmBzMqgO9dTLjlod6sz7hrxc72QKUDjFVZo2HbeRQxoaoKeWs0kfQ1orIAq/npqiPx1249fnfUvfupD6PNR0Bhn/F2EZaB1esIuq2T46MFbOE9XQhE1XgxyXVv3NZ2uUAHaKXH4n/HssqLUNHzILM2woLHy67oGWEZpYCXR8iRMrcDWgMb0B93KUlq9srKxqq6KQtfqrqVJhapUDQIAqrWEHspIHh409gsjqXJwT98LvwLvlQ0PgOo2OcpWSwrk+kUR9eFbC+Z35at5dW3RV2uL1KIRfUbL5g9VtDKgPFofxQ+cJ+3DHPJYSwqmpxT7Wj4Rb3FIIEDjxdHOUcuQQEhgfkhAgU50gMUIGuN3tERM+k1HIky5K1RZjgM0xsBE8+Qa8JNdlWz5Rr+bBClonPN7qvmq0QFWwZ7UP24KYPHx7T+uLqz+AM9KCuID0nnjD/RNSwsAqCCsd3fxk5/8pI3Ljju/q1fz7boG2LY8CXOuHLp42DMFnTigr5bU9R1GRp50Lrjffvv5x33/AbOtPiyUeIvUvshN0+e+0FvgEldBY6xduwifz5Y3YWneyllOFt+7jCAfBUJToDGGQJaeEBd8zA95j7FaH4S078GL/sm8kB2cfmdsiW8XaOxl5H1i53jjalLryoGRSior+ksJ4PX4hecHb3U3Q96Mubgg5Xvj5+halvl0zbiAz2H6hO4oSLlz1J0p1p/AP7Bq7nKHOZ/qq2VZ9KBxaZXLhKXWhamtHsQrgcb4uFG3CAA9nKpY81PQ2m+58KCxXy2yOmiooDGgaxd5H8Rd21jgoz5cPGjMCbw2SAEa19SdOH6g0QGXA/yMZy0gpXUaF2jMgMcKFVtWUExwE6L9xspo4bCgMb6fjAchg26tHLEOtbS5xY+uvkAfVncKftW/K636pmagVfKgsfftq3H1WgFs+CuVQGM9fABL41oZKlDt/TOrRQS+f0elcYHGlEN9rLF45ScauDhRRTIF3LNdyPoPVv21MtNJFGNPUEigSwIBGndJJ56FBEICIYHxSkC/0XzjFyNojD/TEuFb03QgQu+ijPQqy3GAxgChqcPcrBy4gkD/ZU5RAvRK9dPnChrjK7lE3j2bj69WoGz/rtUf9UwUgGcl5l3qDxgAzQi5mbUnbYLOiyWvyc3rojo/HeXAcNW1mbt7XdvKVxOqf+KcsUeKj/oWBpvwZVBdv2TApgcsgluUyGSOnEug8XbbbdfJzvspBtjvIjVOGgY0BvhU4xnrKxYCwNMOzPW9TH25cKmw9tprt/3NeBCCBeGekz5X416yCzRmLm+8mZ8PMgbo+UR+h6+CxmuuuaavXvK/9quUe0beP3WBaOUmxBiO9xsMRTGeZEazcJP2xdMA30LeARZt2EHMwomW265ToDH1UF/PFtdCxiB2PbOgVepPs1DlYhaLHjTGV24NKfg3LGjsTfOt0wwa4jdKSUFjgNj/z955QNtTFFvfBCgoSnQhiKCgEiUKwh8EBZEMCiJR4iNHQYKACIKAIJKzEiRJkviIEkQEyTlnBAQRE4LP5zff+o2vhn3q9oQTbjjnVK11V889013dvbtnpnt3dTXEXp0oaexXW31aJVgpa511cBVprMRhu/XW+Lp1QK23d999d1/85P9KUnZLGuNWgBd62YtEy63XnZLGpFM9nV7ju6tdaeKvqkzn0UcfXZQbzNUiQNuDAUdT0VVlbwlRRxrrwKZTDHWVnMGr6kkdRtm0Xhavl6QxFu+6aOBPZ8VqxcrPZCElStJb3HZDBin98HFM1T9+GxsEgjQeG5wjl8FFgB1nTMj584v31JrJkN0n7MYazlC87bbbCp0bbLCB/RxhHyCgRCff9GEkjTkno07GgzS2MkFcKCmTGntBxrKzqwkRZXrLQiWNIZDqpIo0ZsynOyRTZW/yW8o6FKtlS6vnyyjhyDZyhB2XZrwFllhbmvAeND11bhAsTSrUQ885OLFTwa2flYewnTL5tvD9QftR6sA4LbOSxilf1RqXa51b1ZHGHNBbJdqGYMA8pkq6JY3RjUUtFsGKfeoaYzYMxGinMsHIi93cqfT6G4egwS2VzY2qSGM4HNPVbn9j4cbSeotzJY3L5oS+3tqvUqQx8dk5oQfGW/4a8oxieMc8fqwFjov5sO7g1bKVXadIY8oON+D9gqd0zDnnnPkBhlX9aayx8PkNPWmM0/Mm0gvS2B8IhXUjA7V2/6pIYx60JqKkcZ2LgV6SxrpNnbK2W3eLT5lMeNDsAeQF3kTeeOONIk2npDEvdw6lsLx9yMuTFzIfRdxhMKHSOJ2Sxmz5UD04lDdc2gn32GOPJlC1xNHTTykDh0Q2FV359qvvShrX+djW/HTrlj9Rtoo0pu1od8MRS4V2sLO4kKgmbFlRv1LtWGGbDh/2kjRGt5Ls3v0EK6iGR9lBF/hUszisFhsO7YZlAyNf//h/OBEI0ng42z1q3TsEfvGLXxTvasgQL3pAFO/0stPrfbqq/zlXwL4Pc801V1XUuDfBEOAbbm1HOIykcROXYqNBGmPhZ9jXkXIs9rCFHkLFyE9LqyHt6X2KttvllDRusnPOE5WaH8ZMSih1OuZOuUVTd4O4PjDBgtYwUSMOdY9gxBa+TG1HLwZASiabvqahGkd18x5kx6WVnxA3jU2Femla74ZT28IwKNM9mqQxBHuVjAdpbOXBSIo+BKGrWPprnpMqP88YSOFWA3eG7Az26fV/Flvpi16qSONu+pvO+zyBr6RxarHGl5H/m/Yr5su47eSdy0KXYqDXzKnZXT9Wc0YIbd0xrGXhmrJy+CGkMvyHukctI40NJ3al4J+egzG9Xv0fa/Y6i3rTOdZhkMZjSBp7fy9XXnllT9pbLY0nOmmsH/G6wVFTcJZaaqniAUw5/E/pYSuAPaSdksYMokwHIafyLrfcctn3vve9fHXMb6/wVrpKfFsZfR9J+W/yelJuBExfr0NPjKYOOSjLUz9sfquLksZNreXJRy1fvSVEFWlMWj05ljbrhVAv6xNq8dCp7l6TxvquYCHMdiXQh6zcPA9lLmh02xYLQCGBwGggEKTxaKAaOocJgSCNh6m1u69rkMbvygmMOiTbJY1TZ0z4PPSg73bmRcwxIBJxpcD8w8ZwFjIfbOKu0JfH/u8laYxOJcwgT3olGAHZTk9C5lGI+kJWP6+4FzCMzO3GZZddVvzGPK4bOe644wpdWFd3I2qR2Q5mSvQyp/IuC5qSe5RddTXpn+1YGk9k0ljbDUtt2hVXA4qd9aOPfexjIzDW9HYN+YlrCw6NVMLW9BCm/H1XkcbqVqWpy1Urj7qn8HPo0SSNLX9C+iZ8CH64dQ6tmBx++OGaZFSun3766REuRTkLiLkuh8Dz7vfkNS4qrZwYZTUV/Bnj75h3VKo/gYPuxm6qd7TjBWk8hqQxjakfgF6QSuhUImiik8ZaVh40Pvbdiq70sCLYRNRatxPSmC0y9qIgnG+++WpPFr3kkkta0nCAg5cmpDFbZ9TNAC+zsRQGDVZ3PnxN5etf/3qRzh/MoKQxuuu2IFme6uvMb92qI41ZLbR6eNcWpr/dUA+B3GqrrRol50OFRQiDEv+R6DVpzDYZHdBdf/31eRl1e1OVLzdWog0z34aNKhuRAoEGCARp3ACkiBIIVCDAWItvNX/eDyjJwtK4ArwhvBWkce9IY9we2jjJn0GT6lo6Fm1CyqV04HaBQ9K9/8wmpHVKH7/1mjTW8SwkWC9F681cCwMXsxxmN6rKb3/726J97HwVtuZbm3WDGfn4uUedS0crG3NCdnOqpanOKZpYwpsuXBJZfRjze1GiKiyNPTrV/7/66qu5tb8aHoH17bffXp0wcRcjMHzaqnUrCw3+0Lkq0viGG24o2ppyeFckiWzzn3THNekgxVXGijTWPJkD83xCIGsf5eyq0RZ2K9szA8eCS01PEvsyqHtUjKo6EXYBnHDCCS2H1VMOdcPaid7RSBOk8RiTxrotxh+iVdbAdFq2I3HiJp3If4CUiJ3opLFa+PJQ8HFtIpxYjL8fPqqs9uiqKVvp7UHnZWurzFV61X9rJ6Qxq/uWZ9OHW62sScNWLi9NSGPSqEuOrbfe2qtJ/s9HiJcgAyosSxlkdiIcFmJ1x5F/EyFv9Q/kTwH2pDFWUnXiLa5x/6HiB24QpipKlLJK7AlbjavXPG+0P1tT/JbeLbbYosBmySWX1GSl19ttt12Rxh/EooPsHXbYoVSHYls34NVTlcmb94se1sCWoTJRFyM8N019L1199dX5gRi4ZOnHE2PL8IjfRweBII1HB9fQGggYAkEaGxIRgkCQxr0jjZVManLOyrzzzluMAT1pzG4wxroQe8wh3n777coOy1hbD5yr2zJdpazXpLEe5seYs46QsbJBhjPmhkyCsEuJjk1xG3jTTTcVmHoDDjDVw/Nw+YGrSpvXdLs1HEMQ00WYckXo6+Dfx7aDlPmd6aJfNZmngKu6VFhmmWV8di2EXJDG/4GH+Qy44+MZ69064RwADhm09lEjKtybMEfELQpW7HXCGQSmh9DvRK4ijem/mrbJ/Jny6KGQqTx7TRpjDIYLK8hpPbCyDBvdEcAOAr97uyxdJ7/zzKiVc2qh3euFU1ADvkmTJrVEsf7EuwtSuE54t+mOkV4Zltbl2879II17SBrjW9YeXG/1aI3CAMLisIrS5MHBjYWlIfRO6/uJNGbAg89aqw/EWpOPoB5QgLW2EoCQUKaPkFW7KqEMOkDohDSGwLM8+WjU1YEXkhKApD3vvPNGFJMBn/rF5QWbEl0RYzsKpGudnHLKKUWZyd9/lOrS231eZFZ3wpQLDYtrIYsemsYTk540brKggu8n08mER1fnybeONNbnBj2UsU7oa1NMMUWRrz9giIUNKxMhg9wqod8oYct2FRW1zvaHFGi8dkjj+++/vygjFjEc5Ghl5tkylxWq3669X+46f+ikYyFErZvZGRASCFQhEKRxFTpxLxDoHgFPUvgF0E5yCJ/GnaA2MdIMGml8yCGHFOMayM8y0e3FTSw5m7inWGKJJYq86w6EhHgyi1jGYZ40xmDGxmeELMDXiVrNcjB5p9Jr0tgb25x22mm1RWNugDGUYVB2FovOITigTN0HQjp70XZXAxLO++lWGEMrH9BkPqMuLSCvjFCHS7C6E/r5f6qsnoD08wrSqBVnkMb/QZFzaAxr5uFNDofVBRo9XJ6zp0wXbijqxBuM+Z3IVaQxfUVdv2A9r4Z1qbxJg39wKyNzP89j9Jo01sWxJu9adsJa+eivZW4TU/Vr9zfPI6WeGa9TxzuU0+++PfXUU1vK//rrr3sVI/5XlyVN5tcjFIzyD0Ea95A01g9smf8VVp+UQOFUzaqVY7YP4EjfHhxIHohFFSW/JrqlMeX2BOJJJ52k1RlxrfUDB1afvHAohGHENo8qa0baxuISdkIa41tKdVS5U+DlrCvslq7MrYQeusggKyU43deBJqR61UcCPLCmtbzpqzYoSemv+g1yVklKiH+2gpUJq2dK0rNo4Pu8DvisjFUDyjvuuKNl0AMh7qWONKb+rAxafri6qGpH8FUSl0GF9xfHs4kPJNPJgL2qXQ477LAiLml8v9XFCbYwlom2R52lMTr4uFkZdfsbg+c6UXcwPDtspysTMFZLavJssshQpi9+Hw4EgjQejnaOWo4fAkEajx/2EzHnQSONlWxj7FsmSh42ITKakMb4JLXxFZZoZduMGUv7Q5E8aUy59ewOtkBXjSkhLJWc8VvOy3BI/a5z2m4PwkM/pBRzXsOGubA/oE3LQV308Gaw5L1VJkq4GInGOD1FNrHr0srBONau64yOyvL2v3sDkirXBcyR9PkzP8voBDM9uJ5dplVuHTk8T9uNuqXmNUEavyu3yNd2w5JV59V1uwQgldWIiHmpiZ9/YtVbJepTGz/DnuepIo3R691f1j33Z511VtHn6fvsQPXSa9JYDc6w9PfzZ58/pKk9lylreR+/m//hJMwvehkeqh/jq2mnnbYoH2n8oZc8p/pu2WuvvVTFiGvehbpAxqF8E02CNO4haazWsPi4pcH5WLF1QMVbfDIgwG2DlyeffDLTFWs6JQ7pvSip2g+kMQMeXZ3jo85BEJ5I5GPJwE8fOoi91PakJ554ouVlz6qZt/JEHwee2UvIQvSnRAde/gAC/0Fg4JkiTvmA6yq25UlY9lLXDz7uTOgbfJx8vdkKo/rw+ZM6wfW+++5rOfSNNE23r6Rw4TdW7jXvBRZYIKMNvOCrV/27kYb+6iVFGjOoof09uU36qaaaqsif5yc1iPZtpNbplv8999zTQj5D2OPv2gsrhLjU0Dqvu+66Plr+v98ZwKEavu3oiwwqtW/7k2tRpi5N+Miim3eKHupBvHZJY1ZRtS52/cgjjyTrpD+ydU+30FCuM888c0Q74f5ED3ghD/qzb090M6gFC/treqClliuuBweBII1715a8G/kGMCnBlROLOOx6Ycsubpp4l3M/9VymSsF7FEumQw89NNeBLnQyCef9xNbcXgk7G3DLxZ+No3ivsPDE95MdN/hg33PPPfNvmt9t0qQcjLOw3oIs4J3OohiTG/Lk29sUF/Iif6y28GMKAQU27EZhayLfo6a+BtHFBALLJyZOlIsxxt57753/xi6huq2afI8Nu+uuu24EFGWkMd+WCy64IGOCg69/8uR/LB7rsFDLGz+BGlGA//uBiSN9k/7Eex/CDStRJsG97Etl+cfv/0FASSu+1ak+009YaV+kPmw3x5qe/q2EzGiQxlgD25iKkDEqY017fhj/MT/0uw+JmyKN9SAy4my66aZZymqNdwLvHc3bGyK004Y6F+kFaUzekKdaPgh93o1emPPw3tO4WG9WCe8qjc81c82UMNb1cfk/NRdPpa/7je8u8yLLgx2pqd2lfH/UeAUiivmQit/hN/vssyd3KWPAoUZm5H3EEUeoquI6SON03+AbZG1GyHfJcxOAyDxoqaWWKuIyz7Xnm/u0jrPw+wAAIABJREFUv87LMGZjh63GscagfdVYbL311rNbRVhHGqNXjecoO4cM6rvOysWYAt7F6sluV+/2lLi9Jo3hJ5QUxSI6RYxSFwzmlMRN9WPaxeaMhN69YwFewwt9Xlk8oF28UDZ25+pOAsXRx8fNhd0nxGgxxUXwXVK+j76T6ite/1j/H6RxD0ljP9G1jgJRosKAwQ8WeJDYKoAOJhncV18p6GKSl+pE/UYagwUPnTp+p348hDz0u+22Wz4o8h8/iMLUQ2zYQsLpixD8WNXGWpPBxyc+8Yni4dWPNC+blFSRxnwQ1EKT8rOliLIzmYUoxoJA25DVYvVFzAs5Jbqybn2IkDqoQFLrqj1xeNFh+QsByWq1nh5sutTvkupr55p+qB8xdIMjfZi8GbiycKIDE+KUnZSrpDGEpFoM8DHlQ86WOz4yVg9CVmTLLFebkMbUeZ999mnRiV7yYVsh7Qgpof7PuA/GVQSFH+wyYKS/7LLLLhkDX/V5hz4+FqkPCWQs9/0f7wt1I6GDkyaWxux40BVy9Dc9RBLM6OO+benbfCBZnWfiP8MMM7SUm+e5bLsXpLHWsYk/qXb6a8TtLwT8t7TKn3d/1WxsSwsxqG589Bnz13y7UkSElpgtk0okeB32PwRy6n2muppc64Ir/gEhUtm9Yfn48NOf/nR28cUXN1Gd8Q6EKPY6/P+UITWh8plACLAt2qfX/xnzYOHDGLBMwA2CRhfmVIdd0w5V4yEWhi0uBg1eUqQxpL8fl5kOQr6VVX7slairI42Z8OnZEpqPXveqL/n6x/+tCAwaaezPvNA+pW4BR4M05vnmXaR5cs2OOxZidGzEuBlC2+KmSGPmG2qURFzGpJQdC0HG1YzH9WBo4nhfvq0tXv+fvut7RRqTq77Xrd7MF1gE5DvEjj71FUscLA1ThjlaCyw9TZ+F6EsJcxhv0ML7OzXHTqVv8htzEzVwoUzsRKSetBnzXR2HM38tcz9CfKsTIXNLSK7NN988w+8x80sl2YhDnyirj47fwz3FO63JGMh/x3luWUym37JAzhyd51bbA1cEXuA51HKZ+CwgbbTRRvlCN2fgKBfBfc5lYoHJi8636T8pYReEks/o411DP8OAh3ePf8/zHvEGdqa716QxevHxrLhxjcEbWLD4j3GWn+czt0ztFmAMobo6PYjO6ovBmOrjeaTdWcRm4Q4uQMliXIPqIaa0nc7L0Uu5bdeD6YYr0v7Eu13JdOKV7US3so5XGKRxD0ljBik6GLAOQifzwqCCwXDdxAAdfBx4UTFwSEk/ksbUA6sbPxAyzHzIS7uJ5QMWMf4l7XXxsLL6br93QhpTfnT4l4Hp1JAXCRZetB/WO3aPQVJKmAj6gQZpGCB4YRUREtgPFiwPDRmcYGldNojwuuv+Rw+uRfzgTvO0a16uVe4mlDRm4Mu2DohZS58KcbFQtb2lKWlMPdk65AeQqTz5jcP/IByqBGwgVql3mR77nQFIavsY+rFU1wMtLA0h7xuTdklj0vkV0CY+nS0/QgYaenKsls1fs4BSta0wSGNFNq6DNO6+DzAR9BMExhs8i7rdVZ9VFuvKSEEmwDrBJR0EBzsp1ELD9DFBaUK2VtVUyQXI1i984QvF+5QxAQtw6pfP8uZdVvWdw7qFslt8C7G4Sb3TwKWKoNUxmOlCD5MYv/jN/Y033niEBRA4MC7EZ6fpsBDyBl3U2X6zkO9MStoljZmwmU5CLADVjZHdYwJadlBUU9IY6zq+o6bTQiaLumBsv0OOleWZqnv81j4C/l3RZLzdfi5jl4Ln31vdWn9iMd5kNEhjdGNVVzZ2s3IwdsZvJ4th9luKNEYfVsR6kLrFT4WQHRhvlM0Zre514WiRxuTLQeC+z6Xqwm+Mket2VqCT96e64SNtGQlLfL97EGKt15LaMZyqJ6462FlZJXxnlLRK6eE3OAOILvAokyCN05bG4PXoo482mtuDNWOqKkMdOAmMm8raSn+HTOQAx5Q0IY1JB0mp7nFUv7/m+aZ/lslokMbkxQKUJ0l92ex/xqplO456TRpTtpQRmZVFQ6y64R9YZFBjxZQbEnZppcabqs+u6U9NDmEsa7PR/n0gSWOskpgY8YfPUC88xHa/6cmyWP5amqpVObZ5smLCJAoiD6sNBsFsqUwJDywrhUx8PFEIicWkqOqhRucNN9xQlA2irYkwabH61PkUZtXL4hJCZFWJ4p9yp6FpGdidccYZ+WoNBKw+fJC/EKs8QLwcmgpkLhaduuqOLraSYFnEQArSz+rESl9K2CJicdgmmhLKxXYDtgvpR5gHnzblFF8ly5h4mk5Cvaf6cetgK27oxQ8w1qhlE2FOfGX1kq1YSpqTFgtr2qSdrbFalrprBseQPFg9e5KUFVu2+paRoqab+4aLrRZiyYuVAB8Ns9hGP+3FR6euT7RDGlMOiGpICiwa9LBGXuYM6Jgsl1k1Wz18CLFLO/I+0JVpVnepB5ZddcJHid0H9F/eEWAAIaFlYeJj+KUO/UjlceONNxZpIGM6IXggmFi0gDjyEwDefVhXs5W9rN9aubBApvzmD5pBT8jwIhCkcXdtjysHJXixTIEoVRKB9ycWdyyi2oCVkPGRFybs+nzzPvIkHu9PFkdVV2o7rtdd9b+SxqYXUgCixSw6eLfwDfI7dMomXyxQ+gE8YwzqwyQbfXwrIZZ0hwkLc97NEGUnb8WaMYaPx7Z49c9HXVIH0UKkWD0JaQsl8SkbW5B1UshYI2Uh3i5pbPmim0kz+JIfhJZvVyxuuOelCWlMv9NtvWCMlRaTXXRanvQdxZ88q0gQX5b4vz0E9PmmL/Q7aUzted8x/mSCz5iOORkLQ7pAzhjTxk7ErRPeExafkOe/TDDq4H3AWI/nFFwZk0PWsBPQLAp5fk3n1772tTJ1+bPBM8ZuCz9GZbzFzkIsUrFw7IUwp7Bypc4N8XnwTrP4hHVCvSFqsTTU+Ro4YYDF/LzKF3BKP+NRKwOkfdWOQFzgWFzCdvNK5Z/6jX744x//OF/4U0tQ+gJzJL6nfD+bCN8WzshhPohBkr23CVlUZPGvjjMgH8b8Vveyb6WVB/dNFreqf1p8FgQtfopEwzLa7h955JGWLBniRsTiEpbtVrTE7HS0+N6tJHHYkWz36d9lwvcPEp/5pzeMYgzCeINvuncVmNLH3Ip3CxazOg+E72AuxzcX9wtlPBE6MTizcpftUta8GTusueaaOfmtvApkLe3Dfe+6QtNz3RQrTde0X4EbC1v0WZ4D68eUj/cjC36MwXTMqvlwza4sMLFd4d0c+qm68UGPLv98wfNgDMHYRMc/7Oaztkn1OXTTn6gP/SnF9fGuoz/5cbWWayJcDyRpPBGApQxVnT1VRgbErKiwKlG3DSeVfhB+46UJAcqkrdsJAg81H1gclvdiq2wdvuQBScgHu9uya17t9iPiUw62qoxFvX1ZyZdJp052NU4n1yxUMFk2oqCJDn+CcDtY0HcgXlgEamLh0KQ8fKCpA31bPzhN0loc+lWnaU3HaIYM6Hh+6yyxy8rAIIXBQ5NBUZmO+L3/EQjSuLs2ZBeTDcLZzVM1cea9pFafxPfCApXpY9t11TuRybHFRVc37ytPGjPB5vuSEuoIOW55s4DuFxYpC4v0FofJXxXBgn9LtRSmPF7wG2z6WHAsm4iRt24xTrlcUR/wTCDKhJPWdScOk3ovnZDGTLg9ZqaXBU6rJyEL216akMZ6Qj1Wc4wVysTj32SRtUxX/F6NwCCSxlpjnr92x9Kavttrxq7M7TpZnC/Lm3ExOpk3dvOeLdM/lr9TfoxHmK/xfhtkYRHxgQce6HqeD2YsgvKerDPmGmQ8R7tu4MychvkgbdeNMIejn7NgNFb9nL7BvAyDul5yE93goGkZM7H41ilXY2Ow1JhK82n3mnZn0RzsetlWvexP7dap2/hBGneLYKQPBAKBCYmA+k5idZcXdcjERsAIHQj/kOFFIEjjztuexTr1yYdVbp1gOWGEIFYbXvTgzLoToFkUw5IXy1CsnrohSTxpXLbjx8oLgWL1IPTWkiza6X21ODQdPrQJiaXzJLO6nCpzFWE6mXxAQmNZhKsovwiqrhnqrN7weYd1C4di6XZ7y6td0pg2q5sY6XZ/LK38BLSONGYRX7ePN7FEV/zZsVNljWV1j7B9BAadNG4fkUgRCAQCgUAgMNERsHHi2WefPdGL2vflC9K475swKhAIBAIpBNQ35EwzzZSKEr9NIATwD2WEQqeWyhOoOlGULhAI0rhz8LDawBoX9zNsryyzHNUc1JKYbc5+gY1Tv400xdK4bkumT695tXNtkwHyZhtnE8KQw5+srHvvvXdLdkqOU486kpTE4Mn2adN50EEHtejEvZfdw9K4avtsHS5qKY2Lraq2q9PVLmnc5OAVrKOsroTe12AdaYxfaksP/k0sP8FfCc1f//rXLfjHP71BQDGmjfyCS29yCS2BQCAQCAQCgUBvEMBq24wk/HikNzmEFkUgSGNFI64DgUBgYBDA95ZNUMsOHRyYyvZ5RSCh7ICPJn4F+7y6UfwaBII0rgGoR7chHvElC7ls70pCiDoVtmTqfQgmXGBgOevjarpur5U0xjK3iSgxiVWvCv4urR51FtOaDr+Lls77QWRLpd0jhAzF/ydWz01IUc2Hw2JVF2dpYGnLttI6klj1cN0uacw25zqhDOpL1RO4daQx/l2tfrjqaCrrr79+kS6siZqi1l68II3bwytiBwKBQCAQCIwfAoxd7RB4XHu1O0Yav5L3b85BGvdv20XJA4FAwCHA9mUOXuCgCD2Uj0NHQiYuApArHJoH0RESCARp3Ps+wDOG6wgOK8J3OO9EDhwxEk/DlP/3slOlOViKXR24wei1X0UljZtYwoIa5dC66PkQuMywe3UHAGsLqIuEeeaZp2VygosJddtg+gmJy6Gt+P/VcqhuvcaPPgfJqA675pAriHp8YTYho9sljausmrWMvKetTBD0KnWkMYS7pWVRF//XTf44lMbSlR00o+WI6/YRCNK4fcwiRSAQCAQCgcD4IABJzAFyTQ7pHJ8SDl6uQRoPXptGjQKBoUSAw5n0lFibZBJ6P5RDCdAEr7T3jznBixvFG0UEgjTuDbi4eYEghiz1pJC+H/11ijRmgI7PXh9X/5966qkzTkbnVPomJGldLZU0vvbaa+ui5/c5FEjLBBGLQLTabgbup051L8vg1ltvbdHp/TRjbc3BdZqvvwZ/rGuvvvrqEb6MNV+sZ3SXjNfD//g+xk3G3XffrUlbrtshjTnRu6koQX7AAQe0JKsjjdVnc6peTX7Dh3NI7xHw74dwT9F7jENjIBAIBAKBQO8QiHlj77BsoilI4yYoRZxAIBCY8AhAKvhJ52STTZY8JGjCVyYKGAgMMQJBGnfX+BC8kMXqSsC/G/EfzsGTWGkQV++nSGMrEe4YjjjiiFKLWNOz+uqr56eEW7pOQiWNb7vttkYqHn300Za6vPDCC3k6Dgi0shHedNNNjfQRCXJW03Kithcw5/A6yNw6chTi9Y033vAqiv8pK+QyJLMn87QcXNMW/kA9FLVDGuOLuansvPPOBRa4m1CpIo0poy97J/8vv/zymmVc9wgB38+CNO4RsKEmEAgEAoFAIBAYAASCNB6ARowqBAKBQJY99thj2WGHHZZbum2xxRa5VdxDDz0U0AQCgUCfIRCkcXcN5n0UQ85hTbrnnnvmPnJ5VyrRqAfhEbeJqwJIUvRAOK+wwgpJQpDD6/DH26koaXzFFVc0UoP7DSUj9fA8JXPPP//8RvqIdNVVV7XorMMHq2bcSOBOYskll2xJa2XDDUWTg/ggkHFvsd9++xUHvpgOC3fYYYcRdWmHNP7kJz85In3ZD2uuuWZRnzPPPLMlWhVpTMTFFlusSIu7Ecj3dv+wxA7pPQJBGvce09AYCAQCgUAgEAgMCgJBGg9KS0Y9AoFAIBAIBAKBAUAgSOPOGxEi18hEQiwzn3rqqRY/vF77ueee25LmzTff9FEq/4dAfvbZZzOIQPLT/Ls5uExJ46Y+iC+44IIif9xRUDaTTTbZpLjHAmNToV5Wp3YIVvQbuY5rD++v+IYbbmhahDwebjCwZsYthB0AY+XyZGo7pDE66ohwKygH/Vmevvx1pDGW7ZY2fBMbohMjDNJ4YrRDlCIQCAQCgUAgEJiICARpPBFbJcoUCAQCgUAgEAgMKQJBGnfe8GplPOWUU2b4Na4T3AwYmUeYcp2AxS6uH+rIRe5/85vfLPRBFHYqShrvvvvujdQccsghRd7e/+2hhx5a3PvWt77VSB+RyNvwwd+wCqQwPo7xpawEtcaxa/zuL7300oUu7xOY9FjePvnkk5akNGRxYIoppih04c5CpV3S+JFHHtHkyevXX3+9yA88Hn/88ZZ4daSx4r/22mu3pK36B2v11157rdEBgFV64l45AkEal2MTdwKBQCAQCAQCgWFHIEjjYe8BUf9AIBAIBAKBQGACIRCkceeNsc022xTE3oYbblirCKKSg/KMFCVUn71/+9vfctcWdh9XCXWCdbHFxz1Dp6Kk8Uc+8pGWcqV0QpDjq9nyvvDCC1uiXXrppcU94jRxX/T888+3kLOnn356oZN788wzT6HziSeeKO6VXfzoRz8q4mP5bALpO8sss+T3sObFxUWdrLjiioWun/70py3R2yWNjzrqqJb0qX+OOeaYIj8srnGdoVJHGv/yl78s0oP/ww8/rMmT1yxWGMYctBgnpSdh6vrHII27hjAUBAKBQCAQCAQCA4vAQJLG119/fXbeeeflf/fee+/ANl5ULBDoBQJYLNnzcvnll3elEkLBdP3ud7/rSlckDgQmEgIQada3CdkqHjI6CARp3DmuO+20U0HMrbLKKpWKIIxxm2Akq4WQoSpY5do99NdZ1B544IFFfKxLOxUljcm/TpeSmhwCiHWqClbQaukLaVtVF+7hB9rqTvjcc88VKrm/1FJLFfebuLzYcssti/hnnXVWoevll18ufiefuoP6OKxQCXJPwLZLGkNUP/PMM0V5/AXuL5RYTLkdqSON33rrrWyJJZYo6rnGGmvUkuPHH398ER9cqsroyxz/N0dA2xac4yC85tiNZUx8sds4xA75HMv8I69AIIUAu2isXxKm/PVzLoHFYd7ZrTAGN32Er776arcqI30gEAhUIDCQpPGkSZOKQSaTjpBAIBAoR+AnP/lJ8by066/Ra2USyISDP7812MeN/wOBfkIA/53WtwmxwAwZHQSCNO4cVyxOtZ9yyF2ZnHbaaS1xLZ23mL3sssta4uHjt8wS9o477shwi2G6+L9T8aQxOk899dTs3//+d4tKyFv1O0w8/k+JP/QPEjw1wYXg5PA5qwchri+84GtZ41x55ZVJIpoyMmnWuEpAoxfLcLs/xxxzZL4dLG+wx7WFxV1wwQVHYNIuaYwu9KSIKMr5pS99qcgP4h3S2ksdaUx8f1Dhtttum3l/zMQDLyzFrY6EW221lc8y/58FPQ6/tT9vYZ5MFD+2IBCkcQscE/afySabrHgmLrrooglbzijYcCGA6yp9V3vXRaDBN83i/PjHP+4aIIhq00dYt9DadYahIBAYcgSCNB7yDhDVDwSCNI4+EAjUIxCkcT1GvYoRpHHnSP7+979vOSQNtw5M0O68887cShNiD/LzK1/5SjHhWnbZZVuI3vvuu6+lAP/617+yzTbbrIjPBG3llVfO8J/Mc3HrrbdmuB7YZZddWuKstNJKXVnkp0hj8oZcPfPMMzMI4DPOOCPbaKONWvLF73DZTgDIyB122KElPgfUHX744RkuItiphquG5ZZbriUOVtspf84cGggWOnndYIMNcgsoCFLKCInp8cPXM2VRefrpp1vaDp177bVXdvHFF2e33XZbjjWYK4FLHMh/L+2Qxlgs2wF3TOyxrmbX0TXXXJMdfPDBGYvJVj/8KJe5KGlCGlNniGLTRzjXXHNluO0gT/oShxmus846LXHoo/hUTgmW8aqvF4REKp9B/i1I4/5o3SCN+6Odhq2UQRoPW4tHfYcRgSCNh7HVo86BgCAQpLGAEZeBQAkCQRqXADMKPwdp3B2okH1KopVdQyjjIxYyVInXE044YUQBsOpRorlMp/1O3G63iypp/N3vfjfbeeeda+sFIQmRWyUQyieffHILUW7lToW77bZbhm/dMsG1xAILLFBbNtO9/vrrl+qDZMZ3r8WtC3HZ4clnytkOabzYYotlENYLL7xwZb7U8e677y6DIWtCGpMY/Ol3apFeVU/8Yr/00kul+QZpXApN4xtBGjeGalwjBmk8rvBH5iUIBGlcAkz8HAgMEAJBGg9QY0ZVAoFOEOglaYxFFJNY/v77v/+7k+JEmkBgQiLAFm3r24Sp7dkTsuB9WKggjbtvNCZxSgQrKceBa9ttt12Lf151VYHlrXcBQYno8xwmp358VS/E07rrrpvhq7fM0redmilpjHU0ZcL9RoqgXWGFFXL3D2VuM1L54lcRjGacccYkWYq7gxtvvDFJynp9ENX4+Z1//vmTumabbbZs4403zvFLYav6XnnlldzyFr/Miq9d40YCa+kqArdd0pj8IWbxX+1Ja/rLt7/97VJLXyt7U9LY4uN+A0w8YWn1hMzGgr3uXRuksSHaeejbIHwad47laKYM0ng00Q3dnSLALhAdH3MorZdwT+ERif8Dgf5CIEjj/mqvKG0g0HMEekka97xwoTAQCASGDoEgjXvT5FigYu2LuwkW8bBihRhMkZbE9X9lpYCYhdh84IEH8gOzrr322uzZZ58t9XNcpqfud08aW3zK+eKLL+buE37961/nVrKpOln8upD6QDziE/Gqq67KOEDZH6JXp8PuQ5aDMTpwd8EOBcraSfn+8Y9/5LjiFxp/yLfffntO3FL/Oqlry6r7WJ7TZyg/FshNifgqnVXlBRvcqtA/8Ql9zz33ZFhvd5pvE3yqyjOM94I07o9WD9K4P9opSjkSgSCNR2ISvwQC/YRAkMb91FpR1kBgFBAI0ngUQA2VgUAg0DECQRp3DN1AJSwjjQeqklGZQGACIBCk8QRohAZFCNK4AUgRZUIiEKTxhGyWKFQg0BiBoSONsbrhsA0sSqp81DVFEH34D2TLJtuXu7VwQN9vf/vb/BAVLC44gbRua15ZWbF4eeSRR/LtfZx+znbVTnWV5dHN72+88UZ+OM/555+fYamEpUm3+LFFhi2SuEnAQqZbfe3WD4uZ+++/Pzv33HPzPpY6FVx1ggH9kfpj6dRpeWnXhx9+OK83+th223R78EQijbEuuuSSS/IT1lMn2it2VddYwWG1dN555+VWSxzkNB5Cn+ZQH6zXnnzyycoi0F6Umb5LW3b6rFJXnnX00K84Wb5Xgl9TdGK12K1erMh4P4EP9f7b3/7Wq2JOCD28C1544YV8ezvvg9/97ncDV8fRAjpI49FCtr/0BmncX+0Vpe1fBIaBNGZ8/cwzz+RjTNxvdLqbQFuZcRvjbcatzAMZ03Q6djO97DBgjMX8z0s/kcZvvfVWvhuFMR71YQzc6Vj8z3/+c3bXXXdlzBeZc7N7o9P5kse0yf+0Mzs+cPvDjg/mbt0IfY+DUtHHjp2m8zWfJxgwz6RMzHfY2cLYvBNs/JgVnd3Mw3xZq0hjdufgioiDUOk3TYT5iLkyIoTXaSrMN8iL/sR8q+mulqb6I14gMIgIDA1pfOqpp2b6wuIF8573vCf3P8epzbwsmwpEwDe+8Y1spplmanlhoXOaaabJVlxxxZy0aaqPl/tFF12UHzLz7ne/e4ROTqvecccdG5E0fCw22WST7DOf+Uz2vve9b4Qu6sxJ2PgHrPp4//CHP8w+/OEP539f/OIXa6vCdkaLT8iHKyXgDJm1xBJLjCgb+OFLj3sQU02FOnOaOn730KF/lOXLX/5yThw21VcXjwN5rK74V0T4+HBiu/dBOPnkk+c++3SAAQYHHXRQfugM7aHlnXPOOXPSu64M3IdgxR8jp56/973vbdGDTn771Kc+lZ8KX/VBbEoaM5D96le/WtQdDI455piWoq633nrFfQ4k8oKvS8OOPo2wUIIfxdlnn72lDjwL1I1nt+kAiAWD1GFNU001VbbccsvlA3ry5CAiKweEXqcC2Wl61l577VwNA7gtt9wyoy21bbnGFygDTxUWh/DHSRk1PocEHX744ZXPqeqhLBwYpJMK0/fRj340759sIa8SfExafXgOEQaze+65Z/6u9P31Yx/7WMYhUe1Mkhikff7zn88+8IEPtNSX9uYdzfNVpo8Jn5WP8KSTTqqqTnEPfZ/4xCeKtLxv2xW2wWveZSQ3C1c/+MEPMjA3/DWcddZZ8/7HwkZIGoEgjdO4DNuvQRoPW4tHfccLgUEmjSG/vvSlL2Uc/KnfYq5nnnnmfM7Ed7upMMbbfPPNs89+9rOl8yzGswcccEAlGXj88ccXY4p99903z37//fdvOSBynnnmycdEzLEQHd/pOIY5l45Pmvqkhqxj3mppcQ3TjTz11FPZWmutlc8zU/NZyg9uTcb1zJUg4idNmjSi3Wg75ov438cooxfy85//vMBh6623zlXSd5gD+/Eq86sNNtgge/DBBxtnDQG7xx57ZDPMMMOI+oDL5z73ufyA1ibzHcblZ555Zp7G92n+Zy667LLL5sYKdQXE/zBzUv8OML0f//jH87MKmHOWCQsc1ocIU0YyysH8+Mc/zud18C+MiS0vQrgLDmXlsNQqLNoljTl3YJdddsnnGb5v0r740GdxIyQQCATSCAw8acwLAnJKX0ip61VXXTVLOW73sJ1zzjnJgYfXyQuIAUHVCw/dWDuvs846teVDP6RS1UAAMmb66advpAt9HKaSerFTru9973uFHl7edcKARjFIkb5gwYdY41Vd024QlVWCBXXZITaqG/K23cWBsnw5EMZ0c8o8AxY/oLD7Fs4333wW8CMdAAAgAElEQVQZHzjIW0h9+70sZEBVJuDIgTvTTjttrR7Tv+iii+YWFimdTUhj2mH55Zdvye+www4boW6NNdYo4my66aYj7uthSxBDWOezwGHlLAtZFKjaGQAmDLrL0tvvDGYYFKy55ppFXAZenQqWAqZ7pZVWyq3l55577uI3u6chzzGLDAiEdWpxR+ODaZWwaAIJrmnKrj/0oQ9VDkqxmLG09FkGWSuvvHLxm93zIYMt2rJK6P8sDvi0qf95N7H6nxKIcUvDdRPBgsHSMNGoe6+kdDIpMx2EKdIYItgvfmgavWbigHVSyEgEgjQeickw/hKk8TC2etR5PBDwhFHVXGM8ytdJnhjG7LfffkmjCv0Wcw153KTOjCXKFoS9Tv5nHMXOr5QceeSRxZiCdx0GNSkdjCltLllGGjO3oA6WnrFWE2Ecb2nmmmuuIp8maTUOBO+xxx47wvjBdKdCDHrKrL2pL4d9ptKlfuNgV8ar3QhGQKabAzrpD96Yw+5bSHsw964T5mwpQzPToyGGZ1hSlwltrXMYTeuvIbdZiCgzEsNoB+Miny71P0S0LlRo+ejjmiZlJa+kMSQ1pLumSV3Tj8vatR3S+M4778wXK1J5+N+23377juYIikdcBwKDiMDAk8ZY6doLgck81o8nn3xytuuuu+Yfc7tHyIszRQRYw++9996FLuLzMYHM4qPLxxIykBU51clHr0xYKYRs0fhY7vGxOvroo3MrTsggte6D9EqRKfrhRx8rx9tss01uqQgBieUbL2jIU82Pk85TMhqkMaSt5o21ISvxrCbyt9dee42wFt5pp51Sxct/83WmrakPVtSQuZx8jlW15kl7dStKGq+yyirFyj8rl7QnfYt286Qu1pqUz8rDCjltBEHiiSbIf7VO1jLzsTUdhHzI6ddYpdLWYIrFrw4uiUe/SkkdacxWISyMNU/6Z0raIY1ZBTfrcLBbeuml83pstdVWSSIZ6/cywTpVywcx+M1vfjM74ogjcjwgdBk8EYfnSVf6e0UaYyWg/W222WbLqAt/DMa1fJCiDFDt2SYdzyd9i+fCfrc0ZavfbNmbf/75W3TzDqGf064HHnhgtvrqq48Y+DIoSomSxvRJJWipH+84FuJSZVxttdVSKvPfKKdiQ73mnXfejOeb9/H3v//9nJzWPvv+979/hFU2ynhXGC6EWLbUCbsALA3PWydSRxrznCyyyCJFPrxreQ/wXJ5xxhkZE0QGwFpHynT33Xd3UpyBThOk8UA3b+PKBWncGKqIGAh0hcCgkcaQjt7QgfEm47HjjjsuNyJhdxhzKhsbEGJtWibsrNO4WC6jj7kIY2/GW+z+Y+yi8SD4UqKk8de//vXcclbT2TVzGhMdP3gCjzmGpfngBz9YSraZLkIdP2o+GqfJNWNKy5uQcejOO++cj0MZs0HeU0c/tqXMKdF5CfoYW0F+6nzRW6imdjemdJf9pqQxuxxtvkwfwYgJvHEnQV3ZCWj1Zf5y4YUXlqnNd8RZXELiY/mO1THGZRhTeWMT5vBlOwPBVfUxl2JeSPlPPPHEfA7qDcgOPfTQEeXD2Es5CPoWc0f6s41ZmTdqnyNfXK15aZc0Vm6G+ZHNBeBM/C5N2j5FejcljbFWV+Mc8MdQkHkH/Yk8md8ophhapfL09Y7/A4FhQmDgSWN7CeBOwq9W8ULgRWVxCHnxpgSiVl86vPDZKu2F7Sd8GE0nL6cyUoAPtMUjJF2KKGQ7OxaCFheyUYWt1zrgYxu+r6vFxxoQwsd0QaSl6tFr0pgBnBJ1bN9PCR8xSC4rHx++1FZ16qHWvYsvvnhyNR+LQj56po+wzHVGqjyp35Q0Nr3LLLPMiBVzyphawaWtcEngxQ8EGDR5gZhSHFmRLrOapF0hJ62MfPhTq9c6OIPYU6E9IFxNB/2ZQUmZtEMam86FFloo923tdWLBbUQvcRkgpj7i+JDWeFh2pCzob7zxxqRVeq9IY6sPEwlWtc0yhHrRh3XBwOIygE5tYcRSX+vE+yYlEOOmi5BJEAMpLwzoIGktLu2I73QvShpbXPorPum0PqTDZ7ha3KAz9S4hrj4z9EPefam2xMWGWmPwrvP58o7VATv4VQnbTnXQSx6dSB1pDLFvmBHecsstyWzweagLSlULi0kFQ/BjkMZD0MgNqhikcQOQIkog0AMEdA7B96uJ1W0Psh01FYzr9HsMuZvyz8o4ZoEFFijiMqZJjaEYr+DiynRi5FBmZMQ4WxfcGRsxtvKipLHpxR0FC+mcccJOSuZKnI1homMZTxr78Rs7Y6vk3nvvLerDWFTzqUrn72EtrEQ5i+NlPnpx56AGBIyXPY6M+SCdDRN2LfpxIGVgXK3zbYhW5iydipLGljdzOMZsXnDjoUZilNfXgzTM/5UoZ06bcqeB9TDEOn3F8k7tMmRur30A4jMllEXdQKq1usVnnmF5ETJHSgn9SklojJ28tEsaW77o8n2FeS6GLxaH8Gc/+5nPMn9ONU7KpzHzY31uaU9czXnBUp65hOKPMWBIIBAIvIPAUJDGWIOmPjgGAx8ke/Hw0cEqToW06ieV7fRlRB3piA95YzrxY+rzxxWGkp74NPVxtAxsYzd9hPgeNWFl3O5BLqeIZ4tLqAMF0rFy6qXXpPFDDz1UlJF6V/nzpPy2wkv52LLlRckyPty+zTQ+uCoJwco6H+hORQkwykf+bPFJCT5XrW0sTBHGpKVMapGaWjXXQQ2DrdTgVsuBPy7LlzC1Hb6MNGZAxmqspWfgg3uJKmmXNMYaomqgiqWw5U+IOwgvPDsWB0K9ChMGNkrGkq6XpDEDjjKrYHyh68ITeTORKRMs1q1e9DEvDFrtPiGkdNU7hMGmDtZZUPDErZ90oPfqq6/2WRf/+/6VslQBc6132cKcKWWxRUlh/GB7wZrH6s77uKreWBVZXCwYquL6fPT/OtIYqxHLp8yyyPSx8GJx2SmQWhizuMMY6vsanIJYH8Ze8J+zAhif8MchSCGBQCAwOggMEmkMYaakIy4Aq4SxEZal9k3mnAYvWJLafQjSsjG/pfMkGpabXjxpzO7Vup1TShh60hj9SlbjWqxK2DVmdWI3YaeChbXpYYxZN55Rd2Gk85aruDYwfVikVs0RWAjQuXRqPtu0Xjq/In/aOWVoY/r8GBxLaC/q3o1xcGrxQNOwi9PqTsjCgQqLOXafBY4yAzHS0JcsLiHjdRXdPc1cr0qwpDddzD0hdlV8f69zT4Eu/IKXCeN0NVhi56PvV8z1rEyEKdIYItji0E/q8NdnEuOOdnydl9Ulfg8EBgWBoSCN77vvvsr24sWqRJLfxuFX48osyDQTdOrqoieSIELsRUboP5qqi2sIRRsEQQzzcTPhg832DQhvXDLUCS9jJWX4GHjpNWnMAWVWX3CpcqhPWSAnIcOxhvQkOJbXpovQf1R9XfgfkloHFviX6lQ8aZwiYk03Fq9aViySq0S30acGcawq42Oaj3aKVPa66Tc6yEwRpCnSmJVfJYB5PuqsFshb09T5NAaXOgLRk5h+kMzAXZ8zSOY68YRUCpM6HXZffRpTn80228xuJUPdgsZguGriof6fIaO9BYUO+GljLGbqhH6v/dG3qce7biBJfpCepjM12VJLEBZsPFGdKjOuakwnVgJePIHrDxfU+OxCMF28KzsVn6e3KlFf5ewAqBIO0uEgEN4dWN40waRK36Dd889okMaD1sJRn0AgEJhICAwSaaxEEa4F+N7WCWSjjRMYT3FWhApb9tmlCZGEK7EmwpzMdPpDo0mvBBXxmoxPdDzvx8PoVPddjNvLxpiMOXSnWDcHQuO6AWtt5qZN6gC2hguht2rHEtTuM/atIm6pM4Q843jOCvHzxSbtZHE8aczuzzrRnbHsclSh31k9CFMWuhqfa+Ze6p7B61TuALyrDNjQh7Us43w4Bj9mhS+w8rFDuUowdMPVGoT/Aw88MGLM2i5pzPwHQ5oq8UYpfuGljjQGf+U6Dj744Krs8nvgr8Y1uD4MCQQCgf8gMPCkMStVTUTJLr8qzeqhvVghbptaqvGyt3SeHNPD75oe5sRLmZNuq/JvakGrL0XICy+9Jo1ZlVTSlgFGp6f06koslqpNCRdOwLX2SJFbHoOy/z1pXEXW8UG3PAmxRqwSPbQRS9AqadrWejhGauDqSWM+mkr0MUit8telZdTnqAlpnHKRoPogSnW7kLd0ZsuS4csgxK9+qy679kR+L0ljsKwSBmZWXgjkKrn++uuLuKTxAyzd/dD00BO2YKnLFN8fPWmcejf4Mqsf35TbGVvsog5lW+m8Tgb/hhOhP6SUeqgfcJ6blGh96Eds+exU6khj3fFBmVnUqbJ677Qcw5AuSONhaOWoYyAQCEwUBAaJNFYLRQwxmgiEmo41MXQpk6ZjbzUSSJGpnjS+5ppryrIsfq8jjb37rrLzR9jxaGMsiPUmY+eiECUXzE2bYEM8Nfbw8wssSpnbWfmYS4/FThMljekLdcZNwOCNytQPMe4erA6EVRbTCqla9UL8q4UtZVKduEnRnceqp+7a72Bm52PVrt0qfe2SxnUGNpaXGn34cX4daazGamBWNVe3/Agh9w3jphySpo/rQGBQERh40rjpKpFuLfZknfrWwfKOldsmf+qiAis0FR1MNH15avp2rvlAQ5RxwisWfFiw6sAjtfrWa9KY8uImxF7EFrK1nNVcVpohK5sIVmeWHtcfTdqCOLqqCrnZqShpzAe9jrTWgWiVP2DKw4GFVjffD5uUFzKNAQRWE/RpXDdQRtOZIgGVNMZvMP6/LT5hndWklqtd0rjJoExJx6OOOkqzyzgx2cpaR8JaQjCCYLZ0vSSNq6zOyV+tEuq2DuKr2cpI6EljxYXJR1PRNvJuFJRkJc+UJYvPRxcYcJGh8ve//72lDryDmjyvDLz1ufHb6sgDAtrwmXHGGZPPoW6/q7Ok0HKnrutIY6xn9FmjbLxn8UeNlRLYhjRDIEjjZjhFrEAgEAgEeoHAIJHGaqmJn9gmYw7iqDFN3VjdY848C1IKApR5J2STutljTuXFk8ZlZ0JoOp27lY3P1H0XB52lRF38VblJS6Vt9zeIZM4FwkoWt2uMiWzsRuh3vKGfsanG4RoXIpxDBLmuRGq75SmLr6RxyiVcKh1jVS2nzgH04ESsupuK303rfSpzDozmyTUHuXGoIDuhmxD3lAVLXHUdhx7+52A9Dq6HCG4q7ZLGKQOmVF4YxFhd/Vy0jjRWN3DMERijN3kXYFFtefIuCQkEAoH/IDDwpHHKeXqq8dnCYS8J/EoxADDRlS6L0244adIkU5eHuqW7qfVdi4KSfyg31pucyAqhhnWtPx3Yl32sSGNe1hxs5fO3/3G5wLYvDt2CbCoTPhyWptOQwyY6FSWNsXasEyW/2NpTJVikW53qSGPITw71wmcrVo2sOLNdydKnwjrSOJWG38oGp74uSkjWWRpD3FKHOtGBvLfkXWuttYr6rrbaanWqivvqv66XpDHbtqpESeMUPpoWtwXaHkoa42dL711++eWatPJaD1z0RLsnjZtYd6y//vpFWfwuDe8/XcvcznXqRHNPLHsXQPQtPQAjpaMSKHezjjQmOv6fq55BfJazcMdWQf3GuKyG/t8gjYe+CwQAgUAgMIYIDAppjBGHJ8LaGWtYXMjNMuHbzUI2pNT222+f4XaO+YulTYV1pDEEcxOyrwlp7Mcq3r8s1qR6cF3djr8yHFK/gz/5Y+DBzjPmfOoiIIVNijSG0GTenIrPb8xrGXtiiODdLqTK1eQ3JY2ZOzcR6qtW05xjYwIZb+XnULqm4t1a+HN9GPuq4ZnlYSEEKf6Cr7jiiloLciylp5566qKcpsPCz372s7kBEv29ar7WLmmcOgwwhY8afrBLUqWONNZzYaw+7Ya8S+oMw7RMcR0IDDICA08aN9nuQwOzOqgvE90OrQSvxmnnmgGZCS8gTYsPqm4FnWzdn3feeVt0az52jYWiWlqOFWlMHXHXgGW1uqqwcmnIgAYi1PtxRcccc8xRW0fVlbpGf6ekjZLGfjEg1Y5KGusqdCpuE9IYi2z6jB6al6ojv+GaQgeZTUlj+gdWx6aXQQgnJNdJO6QxvuGaSBVprC5H6khYzUvT9ZI01veG5mfXShrX7TCoIo1vu+22om1oI6ySm4oeLshgXsWTxk2sY6tIYwb01oe6CbEWSsmXv/zlQj/lUOFQDMsTIrfqwBBNV3btJ2JlExV86KvLDiuDD2eZZZbkIZ9l+Q/T70EaD1NrR10DgUBgvBEYFNKYnXb+W9vJ/4xlvUDqMl7EqrNOJ3gqMVtHGqfObvD587+O58uMOSD31H2Xz1vdH9QdJJwqQ+o35nZYTs8222y12GjZwDFFGpMHLjMYC9SRzsxXIKi7dbGhpDHW2k1Fnx11Q6LjUyy7mwpzU50jp85qwXczRjPaH1J9EjcfEK9VCxIYu+CvO5Vef4M7wKgrJe2SxnUGNpbHCSecUJSLhRWdt9eRxjrf0nq0e81O7ZBAIBDIsoEnjessO60TMBCwFwkfKH0x6WEBbAvhY9Lu39Zbb21Z5brVX1M7W8sLJXJBWVlVtPJrCGGJPyjyx9KO7U/E1w97HWlMnesEAkXzZfWySiBwWD0FRz0sQnVwjZW3PwSBlU+LB0nebltY/KryVd1T0rjJanQvSWPajvJb/TUkHwaz+GNiGxir0cSfaaaZivhNSGP6P+5C8CurZW8y6Blr0lhdadS5e9A21VX6XpLGDGKqRAcx3ZDGDLi07SGRm8q+++5bpPVb5npNGvOMazlxX2HPXzth2YnY6keYfqtELvha3nVYN8GuKWlsup577rnc2oatft5thZWLkAF9lQWH6RumMEjjYWrtqGsgEAiMNwJKfPFd8oeTjXf5mubPHEe/r7hoa2esYXFxKaXCWFrdoWkeXDMXgbjksC4OQie+zlU8cYtudU/RZNciaZQkLCONiafuu7DQpDwmajTxwx/+0H7uOMSQpWwHKJaaiy66aO5WAiMCzuVBFL8y0tgKBCGNwc3GG2+cH0SoafWafLo5t0JJ4/XWW8+yrwzBVY2w1O0Cux+tfO3shIT8tnSEVYZlzDnAj7mQ8gqanmvcUtYZtYAdPrBxH1I1ZsUNhieh2yWNUy7nUkDjJsPq4p+ROtJYXedhpGHPdruh5yBS5YzfAoFhQGDgSeOmfqnUl6w/rRS/ufbS6pXvJw6CM51V26CadEI9qA+d+GLaZ599MrZ/pE6ShaDABYfl7w/pI08GOHYfi9Y68f5X60hj1ceAgwEq2GLRavlayEBBRT/Efju8xhut6/EkjfGVZrgQQv5DArItPkVYYoGuftX8QBiM1KcxlhGcXGyi/qPJzx9YYfEsHGvSWPFo6nKEQZ4OrvqRNGZQqVviWCRoKuojzL/rek0aP/TQQy39FXcVvRQWn3RrneHADgX9Xft0p/m3SxprPmw3ZELCxCq1dbbq0B3VMyzXQRoPS0tHPQOBQGAiIDAopDFklpJ4/vDkTrE+9NBDW8YyWF0y/uRAuRQZxziT3XQ2XmdO5mU0SWPvvstIOohBKxNjyF4QYuzyM52EzBmZUzNmSrkaxFWhxrdxm8cn9T9zGsZLGMeoQZfp8zvOUjrKflPSuKk7CfzkWt6Eaon7ne98p7jXdH5C2fw4/NJLLy0rcsvvzAsuu+yynFxPuUvBNVpTYcyKe098c+tChdXV7+JulzRuWiddqFl++eVbil9HGkNuW3lZ1AkJBAKB7hAYeNIYQq2J6CFp/nAotVgrO1SgSR4aR32xNrHgJO3NN9+ck8G8yM0HFQSwDkwWXnjh3Nm75uWvGUzYi5QwhRFbbCwOg6M6gUy0+ITtkMaqmwHf9ddf3+KLFEtZXSVXP0X4ph1rGS/SmMGS+kulL9a5jMCXmbYLAzkvShrjCkIFy031CzvDDDPkBwloHL0ea9KYCYHVD0tTMKoTMLM0hP1IGlNHrEesHiwcNRX871k6ts+p+MEq/9dJlXsKyFu1Vm/qY74uT72vBCOHjyIsmFkdvZWNpm3nuhvSWPNhgsnijeKy++67a5Shv9Y2pR1ZvAoJBAKBQCAQGB0EBoU0Bh0IOvv+77jjjl0DxvxDd+yx2G4Ws2XKPZm42267jYg6mqQxmal7BAg0RA9n+8pXvjKiTO3+wHhGxzJYtOqOr5S+G2+8sWgf2gl3GZ0I80XGZerCjjlKpzu3lDSmvZuIP7SO/01UH+4mmpYLQtb6L2E7Owktbw4KhJhV95pNdg1beg0xPmOXqrbzLrvsolHyQ/O0zN6PNpHVtSTnLjWRVVddtcBCd2yTto40Zr5hZcJyGov1kEAgEOgcgYEnjSFR6wRiQ/23esvfQw45pHjxYInJClwTYZURqz6sdln9U9ljjz0KnVgGNzkJFotbewEasY3/TPuN8Oyzz9ZsktccGKVpfH1JxOFqFger5DpRjEjnSWM7UfhrX/tadvLJJ9epyx34W/6E+Hc14aABu8dHTA8IszipEGJtww03zIl3tkl1KuNFGnN4ltWbsM7ql/p5X92pleYq0hgdWDFrvmyDKpOxJo2931+2BtaJ+o2mXv1KGq+yyipFuzAY1IWVMgx+//vft/jZ876Ce00aUw71X8fz10SwfmGwiJUBBCvbPcuEBTTrn1iQY22BFYr9dsABB5Qlbev3KtKYbwKTMcq73HLLZeBcJ+ySsDJ2Opivy6Nf7wdp3K8tF+UOBAKBfkRgkEhj5kf2bcVlWxOyjh2PjG359jBGZLxt4sdFkIF14olRxgZeRps0VvddtmMUotiwaTJf9GX2//s5Bm7t6gTC0MpAqC4dSItbM6y4cS+AT9s68STrPffcU5ckeV9JXsrFTrk6UXdvPEPa18BC6+kPay7TDTlq6TAUYkxrwhwHIwN23Fa5J7H4zLdNF6HxFxymfeyxx+YHOTJmxZ1anaiBiN+l2K6lMfOXOoGs5sBDK7/fKVtHGnNQvKUl9NbRZfljjIQxHzwNu9W1TcvSxO+BwDAgMPCkMS+KukOilCBlu4530M7/6t8Hq+Q6YRu2vqy8Cwi2S+v9upVWVm6nn376Io2RY3z0VU/d9m9efkpWkJYD57x4vVUWh5DunJCr5fCkMRaAdn/JJZf02Y34Xw/6Yju3utnAZ5luP8Nqu04gnXRbeGrVv06H3R8v0lhXTcHykUcesSIlQ1bhIekNd8Kdd955RNw60pgE6tIAPWWk+1iTxpRNJwhzzjlnpbUxp0Z7H9r9Shr7AW5Zm2iD86xrf/CDYj85qnruTa8OJFPuYrD0sTxZ5NHJmOnwoZK+bI17+eWXfZTif8hy9R14+eWXZ/gvszzZWdELqSKNeT/pO6nJREfryHMa8g4CQRq/g0VcBQKBQCAw2ggMEmnsx8p18yuwVWMUxg7qMgpyzsYThHWWn4xJ/Jg5dVDzaJPG3n0XYy9zNYD7rl5YXnojDMbYVQIBqi4fwRPXHyr4Eza8OaCtTu66664iPnP4uh2YZfr8mLpuF7AnNb37Suqq5wdhHFBHQD799NNFG4GB963M/NmwaTL31b7L3Md2Y0K46kGNnrhPYaTuCjHqUGmXNGY+XmdcoYQ8ltrelUodaUz/17kARDeLQ1VCGnV7gnuOkEAgEPgPAkNBGrO9vsw5/sMPP5zpYInJakr0ZckLu+qAPbbrzD///MWLvcw6WV1U8GGpIjf0oDt81JoPLU9Op05ZtfowkOGjZh8cC1ODGe+LdOmll05+7PgA8mE1XRZ60hi87B5hnQ8rXWn1W+ipj/pcRl+V3zJ8aimpzaCiCmvDqywcL9IYn2SKIYsdZUK7eD9jpPWDGtI3IY1ZlVZ/0yxgsP3Oy3iQxizq6LYpDpvTRQYrIxbpOuAyLPuVNKaN9cRjLHo5ObxMsHKwCQN1T/lsGw3SmLZgy6DhjeVPqu9YubFc0UW6JtbJutOBw1AsLw706JVUkcbkoQs0uPSpIrp5nnQwe/rpp/eqmAOhJ0jjgWjGqEQgEAj0CQI6D+L72a8H4QE3YyPct9k4gC36foFcm4UxpBoTMH/TnVueEKs6PI50O+20U5G3lYFDgL2MNmlMfvot1bFR2VzXl7Hufz+3w0q4TNhRqzvkDBsO7VO54oorWvCrmt+RTufnzFU7FU8aM6/A1VlKIB919y/z8pQhj5K21BcXgdq3VDeEu1qCE59xp4o3cvNzbY1LPjon82NpPUic57+KxIVzUFeFfiHGPyN17imoGySuWT5rublmYUbdMaYOkqwjjdHDIdrWzwix0ub9kBJ+32CDDVris9M2JZSP3QT8NbGuT+mI3wKBfkNgKEhjXhT40oE0YRUJITz33HNbXkpsbX7llVeSbeiJD3RiKQYRZR8AQrY/QIroS8p/EC0DVhTVOg3fxDjRtzISj5e4rrqiVw/348Olgx1W4/hoW5nQwWonLzb9wGn5ylZT+fhqPF6mYIg+cGLrkx5Kp9tI/IcMa2T8D5s+iHS2xvPSV4Fo2X777Yt4xOc0Vy+skOsKLvE4ERUrZK07Ft06eCQeA7puZLxIY3DXw73or7g90fqCC4MM/+Ez3MHISxPSmDT+45ta5dYBSmoxQn0Q09+biPoro6wp4dRqqyMhfQMfbgzYeM7xv6WW+hq3X0ljcPALCQyy2IWg1h68Q9jqp8Q68VIuH0aDNKacfjAOiUx/0kNS2E2B1Yq+EznMg8FoneBfUIlma1/bkVGXvsn9OtKY+4ox1s9MqPT5JB/eSYssskjRXyl32cC5SbkGMY5OdGnL8Gk8iK0cdQoEAoGJgsAgkcZgim9Z/R4z58CoxgxuiIPVJVbJalmIUQmH26lAJmkcxijnnXdey7edOQ7nzvhvl41FGBt7GQvSWN13WVkIe0V0MfZSYwRwuummm1qqytgO8i1FGFMW3ACoMK/FnYaVF7w5SNAbg2B8wO5Ji0eI791OxY9T0Ud/YJSKJVQAACAASURBVJHA8mY8BzmsZ4MQL3U2EOUgPge4aRnpC4xrjbyk7zB+VJ+/xE/tDMXgQJ9V5t2HH374CKtx5sJ+HuhdGjIWpX5WNubozJmsXIYjbh7UQIU03vCjE9KYfHEhilU/GCB//etfc6t/nQfgX1rnClauJqQx+GM8YnUkXHbZZfMd6FpPDAgxONJ4EPh+/G5567x05plntp8jDAQGGoGBJ43Zjg2Rai8CVgM5JEFdFXCPFy8WblUCEarWlqYTAmSBBRbIUqeVYtlZ9tIhLwYsWj50QiJQRrVEs7wg4rw+fwgdcTn8iW0VX/ziF1tIGO5hEadbo8v8PrPNO0XE6JYW9DEwY/VT3QR40pi6Qkh5jEiLT2fKwItXB3noxteSfUx82zDoIS3x9A8ycsEFF2w5INDus9qvHwqvs8n/40UaU7Zzzjmnpa7Ui4HGyiuvnG/5on9bXQnNR5v9hsW1l6akMf3Of1QZOKuMF2lMm+pWJquvD+m7p5xySgtGfiCl9am7ZpKgefhFEJ9e8eOAzSrx/prLfHczEdJBu5WHASDPlP1vIe86PymycowWaUz7eNcYlIfBJ+QqbkX8O5n3IoPVpsIzYHUkZFElNdBsqs/HqyONiY/PNS0D19SDCRDWS/79x/0mPt59WQb9fz/xDtJ40Fs86hcIBALjiYASUXyX+tnS2HDE4ETJJ/s2YzE577zzjph7cZ85WUq89Stx2d214oor5iSUnxexfV9dczGn8zIWpDHjdnXfRbkZb/l5pC9bO/9D1Bq2Fs4999y5URFGO34eyfddXRbiu9jLk08+OWIOx/yQebHNF5XwJF+IXIxrOhUljRm3+Tn4Zz7zmZaD5ayuGF6VzVMpCwZizEktvoWMxbG2TY3fwaRMJ1auvl+DMcYyYOOfZfIrm/vq/M/KRV+uGrOmDrFrlzTGeEv7BXjTZ3ybsgjBPCslTUhj0mEgk8Kf85rgblJ4Lb744pUHOgZpnGqR+G3QERh40hhLzFtuuSU5WbcXJC/ZlNVdqvGxCOPla2nLQrZDsTqJX9k64WWr24ZSOrEwZTWxzB8PH21egKm09huH/XGaKuItFClDSliJTBFPppOPHZacSB1pTByI3rq6opsPB0RB3Sm8WFSq6w4rlw/BD1KxyYGDKRz0t/EkjSkHW/GnnHLKyrZmMGuHLnhikwGMig4a+BBWCT6l1NqZfq7W+eNFGluZsdT3FujWFxg4c0AG/s7sN8JuJkce2/Egjak7fttTgyKtJ9eTJk2qfNeNFmls7XP99de3bHHz5bP/cZ3RDmGMftre0hNusskmlm1PwiakMROxH/3oR8mJhZaNa6wn7N3ZkwIOkJIgjQeoMaMqgUAgMOER8MRJN+OiiVRZLAjVStJ/h+1/iFR2P1UJfl91/GtpNWS+hLUmYwF/UDn/q4wFaUx+6r6Lsh544IFajK6vMQrg4PcU+anYQNQzH0cwOLF7EKC6O84KxDzV7xS1NBoyX8QooW78bXrLQiWNMQZj5ytjUc1LryFX2THbxBCJuTsuFrxxhOrjmv511FFH1ZL6zO8gWX16/z/YYqVdNveln8IflO3EVH28I8oOT2yXNGYnAPyMX2zR/LAIrnLz1pQ0pr3Bn13fdfjThzH2w6K7SoI0rkIn7g0qAgNJGmO5xUuSPyNDIYUhx9hSj3Uqq0iQkvjWLVvNq2p03D1ACnMIFO4osEBmYAKhDLnLFot2hBcaBAL+dli5ZoWTlT5WG/nQKDFXppeXK+mxuGNFFFKCbTFszWf1XAlYyGz0Gk5VBztAsrGyiGUk1nK8LHFzwMERrAab8DExffq73beQjxRuPDhQcIUVVshXwVlNZAvJrrvumreJJzYtbVkIGc1hCpSLwwZoD7aAY2lLO+mWtDIdTX/nY2319H6dUjogqy1+yueVpmFbl8Wt8lmMywEO88OaHItSfKiylQZCG/+o6uKEvmU6CflYq4Cd3W+ytUvrTzqdXGgfSPk2u/vuu4u8/OGQWia9pkxWPsraROiz+CKDwMOSWA9Q4F2gAxOPRxP9Fgff2FY2wjorB943Fj+Fj+klZPuXxSVMDao1Pu3MQBy3HGwDZJEIixp2G+DypcmJ0uCmefJ/nXAAn6XxlueptLwb6aP0X951vI95p7CrALKQXQq8I9oVXLOo5QLv6F4K7ySrJ2HVd4N3LRbguBaCqLc68v2h39M39X3cy3IOgq4gjQehFaMOgUAg0C8IDCppDP64oWAcyFgc4xYIYshdXPDhtg9Xe3ZAWF17vfrqq9lee+2Vj7EwRGCexbkrWE4yH1DiknEMRJWNG4wwtTxwHWH3moy9SQdJaWmq/DRbHoQQ5zbmxVq37IwfTdPJNfM+5tXMRdjtyriHOQrzUnZJMkY1YU5m9SC0ubrdtxAMmWPYfJF5MfM7CEXmO7RdU6Mv01kWetKYeIzzyAMiEdKbcTXtTTt4Fw1levV3dhAyNsSogTmq7VTG4IZ5eju74yCr6dfsQGb8TL+mPzKvZh7AIojOfbQc/pp8WcSwMSv1xPgIDoJFBuZ9VbyGnzukXK5Rb2tzKxd9mLk7ri55JjkkER4AI5A6ozvmW6aPEJccdcKzAClPf2LnLX0JXgP8ea6fe+65OhX5fZ2XMs8MCQSGAYGBJI2HoeGijoFAINAZAhDXNoAmrFrg6CyHSDUeCDCotXZlYtEJ8Twe5Y48RyIQpPFITOKXQCAQCARGC4FBJo1HC7N+0YubDhsbYVAQkkYgRRqnY8avgUAgEAgMHwJBGg9fm0eNA4GBQYDVbdydYPGPRYcdVlFVQT2Mjy1ZTbaWVemLexMDAT2Uk22kIf2LQJDG/dt2UfJAIBDoPwSCNO6/NmtSYhbP1Y0Bi+shaQSCNE7jEr8GAoFAIAACQRpHPwgEAoG+RYABsfriOvPMMyvrgl8v3MmY1cU666xTGT9u9gcCbEuzAzQ4AE+3iPZHDaKUikCQxopGXAcCgUAgMLoIBGk8uviOl/Zf/epXxXiXQ7PDSKK8JYI0Lscm7gQCgUAgEKRx9IFAIBDoawTwi2skMD6xytxN4ENWT2wmzZVXXtnXdR/WwpvvaBYN8BGHX2/rAxyIEtLfCARp3N/tF6UPBAKB/kIgSOP+aq9UaSGE7cAzrjnIHJ+5NjZq6jc5pXsYfgvSeBhaOeoYCAQCnSIQpHGnyEW6QCAQmBAIcCL1lFNOWQyMOQwNC2JOjMbymMMXttlmm+wjH/lIEYdBNMRUSH8iwAF//E033XQtbcr/HE4Y0t8IBGnc3+0XpQ8EAoH+QiBI4/5qr1RpObRtsskmyw+h+9CHPtQyNuKQtLrDlFM6h+m3II2HqbWjroFAINAuAkEat4tYxA8EAoEJh8D555+fve9972sZJJt1RSrkpGuzyJhwlYkC1SIwadKkEW3NZOnmm2+uTRsRJj4CQRpP/DaKEgYCgcDgIBCk8WC05UwzzTRibDTNNNNkjz322GBUcBRrEaTxKIIbqgOBQKDvEQjSuO+bMCoQCAQCIICF6fbbb5994AMfGDFohjiefPLJs7XWWiu77rrrArA+R2C99dZraWOsaM4+++w+r1UU3xAI0tiQiDAQCAQCgdFHIEjj0cd4LHJYbLHFWsZGnOFxww03jEXWfZ/H6aefns8fmEPMOuusfV+fqEAgEAgEAr1EIEjjXqIZugKBQGDcEWCL3hNPPJFde+212WmnnZZdeuml2Z133hlb88a9ZXpXAHwa06bnnHNO9tRTT/VOcWiaEAgEaTwhmiEKEQgEAkOCQJDGg9HQnN3xm9/8JjvvvPOyl156aTAqFbUIBAKBQCAQGHcEgjQe9yaIAgQCgUAgEAgEAoGAIRCksSERYSAQCAQCo49AkMajj3HkEAgEAoFAIBAI9CsCQRr3a8tFuQOBQCAQCAQCgQFEIEjjAWzUqFIgEAhMWASCNJ6wTRMFCwQCgUAgEAgExh2BII3HvQmiAIFAIBAIBALDgABuNULqEQjSuB6jiBEIBAKBQK8QCNK4V0iGnkAgEAgEAoFAYPAQCNJ48Nq0qNGrr76abbbZZsXfiy++WNyLi0CgDoG77rqr6Dtbb711XfS4X4LAtttuW+B42223lcSq//lPf/pToYfn+rnnnqtPNIYxLrnkkqJ8+++/f23O/+///b/aOBMxwuOPP17Uk3Z48803S4v5j3/8IzvppJOyDTfcMJttttnyA2o+9KEPZXPNNVd2zTXXlKYb9htBGg97D4j6BwKBwFgiEKTxWKIdeQUCgUAgEAgEAv2FQJDG/dVebZX26aefbjlF98EHH2wrfUQebgQuuuiiov9wmnBIZwhAEr7rXe/K/84666zOlGRZxqKP6SG8++67O9Y1Ggm/973vFeVbeOGFK7O48sors5133rkyzkS9+etf/7qoJ+3wxhtvJIsKKb7eeuu1xNX2u+OOO5Lp4scsC9I4ekEgEAgEAmOHQJDGY4d15BQIBAKBQCAQCPQbAkEa91uLtVHeII3bACuijkAgSOMRkHT0Q5DG78D27LPPZmussUZOpK666qrv3Oijq6ak8RFHHJEkjN/97ndn/P3973/vo1qPbVGDNB5bvCO3QCAQGG4EgjQe7vaP2gcCgUAgEAgEAlUIBGlchU6f3wvSuM8bcJyLH6RxbxogSON3cNxmm20KInXQSePFFlusqOt0002XnXDCCbm1+L/+9a/slVdeeQeUuBqBQJDGIyCJHwKBQCAQGDUEgjQeNWhDcSAQCAQCgUAg0PcIBGnc901YXoEgjcuxiTv1CARpXI9Rkxi9Io3/53/+J7v33nuLP/zlTiR5+eWXi7I99thjyaINE2msk/BvfetbSTzixzQCQRqncYlfA4FAIBAYDQT0e4Ubpeuuu240sgmdgUAgEAgEAoFAINCHCARp3IeN1rTIQRo3RSripRAI0jiFSvu/9Yo0bj/niZdiWEjjf/7zn4WVMRPwM844Y+I1xgQuUZDGE7hxomiBQCAwcAgEaTxwTRoVCgQCgUAgEAgEeoZAkMY9g3LiKQrSeOK1ST+VKEjj3rRWkMbv4DgspDH+ivXQO/wghzRHIEjj5lhFzEAgEAgEukUgSONuEYz0gUAgEAgEAoHA4CIwkKTxQw89lN1+++35nx029Nprr2WnnXZatv3222eXXHJJVrW1m1Pvn3/++eyaa67Jjj766GzbbbfNtttuu+zII4/MrrzyyuyJJ57IiFMlbNW2MqALYXv5tddem+28887Zsccem/u3rNJB/Pvvvz8788wzs29/+9t52U899dTsrrvuyt5+++2qpPm9KtL4ueeeK8pHOevqY5lhQWf1InzzzTftVschOh9++OEMkvKHP/xhttlmm2W77757dsopp2Q33XRT9oc//KFWN9vhrVx//vOfi/jovu222zIOpYKIOOyww7Jf/epX2RtvvFHEGY0Lykz/OfTQQ7PNN988O+igg/K+89JLLzXCmgPDrD5a///93//NXQAcd9xxeX3Qe9VVV2Wvvvpq29WgX+Jndbfddsu22mqr/Pl48skni/KNJmlMvzn33HOz/fffP2/vH/zgB9n111+f/e1vfyvqQf81DHie6gRfsTwbPC977bVXtsUWW+TtTnvz/HcilPOee+7JzjnnnGy//fbLNt1002yfffbJLUfpV9rXyvT3ijT2z5692zTfBx98sMBMn03edxCX9EeeA95l/P/Xv/5Vk3d1/eKLLxZ5P/DAAy26rB2//vWvF2TqpEmTivjcL3sH0SdpU8Wf9rjvvvuyt956qyWfJv+Qhn7y05/+NNthhx2yXXbZJW9P3rW8c+uk6iC8O+64I6/TjTfeWNQT8vjEE09sqeu///3vumyG+n6QxkPd/FH5QCAQGGMEgjQeY8Aju0AgEAgEAoFAoI8QGEjSePHFFy8m7BA+jz76aPbBD36w+I1J/JRTTpmTEL6t8OP1iU98oiWuWozZ9TLLLJOTxz69/f+Tn/yk0AEBCqG17LLLFr+ZHg5LShHA5513XjbNNNOMiG/pIKJOP/30UqKFclSRxhdccEGLbgiwJvKLX/yiSEf5UmVvooc4EKCHHHJINsUUUxQ6rX4avuc978mJ9hRJZnmtssoqhQ6IeQio73//+9n73//+4nfVOfnkk2cQr2VEleltN4TgXX311ZN5Wv4rr7xy7UFYLG5YfAgnhAUD348tzrvf/e6czATTOoGA3WijjbL3ve99RR6mh3DBBRfMXnjhhZzEt98/8IEP1KltdJ/n4IADDsg4GMx0a0iZIDRpF8h2uwfpXyUQw/POO28R39JpiF/ZposFkNcsFoGr6vDXvEcOP/zwvC+Xla9XpDGkrOZ/9913j8hy0UUXLeJAgtIfIEYnm2yy4nfVQX+CvO+FfO973yvyWHjhhVtUap5l177vspD0ta99rbINwJ/no8lzTJzjjz8+f/eXlWHGGWfMLrvsspay+3+qSOOpppqqwKAsD37v5r3pyzOI/wdpPIitGnUKBAKBiYpAkMYTtWWiXIFAIBAIBAKBwPgjMPCk8S233JLNM888yYk8JJwJJNHWW2+djFc2+YeQvOKKK0xFS+hJYywfU3qWX375lnRYLm6wwQbJuKn03/jGN7LXX3+9RYf9U0UaY7WoxB2W1E1EyVm2mncqEPlK7qfq5n+bbbbZSi1qtVxY3uo2eK9H/1933XUbEU5N6nn55ZdnkE6qv+x6hhlmyC699NJStZ40hlwv06W/szChFqY+A6zkZ5999lpdH/vYx7J99923iNcL0hhr19VWW63QqeX21xDGENv2exlpjE6eAYtXF84yyyzZ1Vdf7WFp+f/mm2/OPvnJTzbWSZ5LLLFEKXE8XqTxnXfema2zzjqN6rHTTju1YNDJP70kjZ955pnMT2Kr2nbVVVfN/vSnP5UWm4USFmuqdOg9vgVlz1GQxqUw9+xGkMY9gzIUBQKBQCBQi4D/3sZBeLWQRYRAIBAIBAKBQGBoEBh40niRRRYpiAKIrznnnDP/n+u//OUvRUNjVaikwUorrZRbWmKth9Xl7373u3yLNBZ0Gm+hhRZKko5KGhNH08w111yF5d/Pf/7zogxYwnlr5C984QsZcdju/fjjj2dnn312plu80fvlL385WYYq0phMsUC0ck0//fS1W7Oxon3ve99bpAGTTgSLQghgyxtrQUhSrEWpI64Z2N7NVnrIVYtHCDGVEiWNwdfSQMofc8wx+UnQJ510Uk6iYWVs9wnJt1vBtYLqpH9BuvI7/Yf6HHzwwRk4a7xbb701mbWSxlof+vOPf/zj3CUFh2ttvPHG2dRTT92iUxdDVDkk2KyzztoSd+21187OP//8DBcAkKl77LFH0Te1nL0gjddbb72WvOebb76MNsHNAO4CcNny6U9/uoijVr4p0ph+tMYaaxTxKe/HP/7x3AUJbk2oExb1W265ZYu1Kpbr5JcS+rj2D/ofbhFYfOJ5gnTH7Qg40W8VI3BMyXiRxtpvwAlXJPRHXO7wv+JLPXDr041UkcZnnXVWxt9yyy1XYIZFu/1OaC4bCOeee+4i3swzz5xbn7NrBPcutCvWwP5dyfOVElxOqD7q+tWvfjVj1wSLV9Qb10VaNuKwaJGSKtKYHSLUhWdQ+wbvAq2rt6pO5TPMvwVpPMytH3UPBAKBsUYgSOOxRjzyCwQCgUAgEAgE+geBgSeNmbhDjuAf19wbQP7gm9iELeu6rRgfr2UCsestkiERvChpbOQBpBmEKIIvUQgttWbzLiMOPPDApPUiZYAIVfcCF198sS9CpXsKIkPCWNkIsZStEq0TJAzl6EQoq+VLHSCyygScPvOZzxTxsY7GxYEXJY3RDbkNiZcqI+SN5U/IFvhuhPKoawSwgVxMCb6kdSGDayPLNL6SxlZW3Dak4kKQqvuBBRZYIFlvtRzmmTA3EJov17/5zW+yj370oy0YdUsa33DDDS36vvnNb7b0fSsDCzlrrrlmS1zqnyKNTz755JZ4WJKWWd1jfa6W9Z///OeTzxauMwzvaaedNl/EsLL5EGtYJezx0ZuS8SKNqQfvNdy1pARMra6E3ewcQH8VaWz56w4ArINTwiKClov+nRKebbUy/+xnP5vs9/Rz1ce3IPVe4NnSOpAm5banijS2cvKt0TxT3wiLG+FIBII0HolJ/BIIBAKBwGghEKTxaCEbegOBQCAQCAQCgf5HYChIYw6RqxJ8ktoEf6aZZkqSkpoektniE2Kl5kUJVuJg4awEsY/PNnv1pbzWWmsliQ1Nt+eeexblYDu9PxSqztIYXRCMVheIvCpRi2ncJXQq+IO2PDn0rk44BMviE6aIQU8a1223x7+t6YT460Yg8E0X5C3W6VWCNav6JuZALi+eNMZPcpVgDWtlIPzjH//YEh0SC+LX4uC2oEr0EDzSdEsaL7XUUkXeWJnjHqVM8PfqLaI9aYz1qMbhus5P7IUXXliUgTpheatCmXj+DSOfp8a1a/yVW3zSpmQ8SeMy61vKCXGKxa2Vn3dUN6KEq/dpbHqbkMZHHXVUUSZ2WlTJU089VcTFih/LYRUOiPzIRz5SxNlxxx31dvJa3aLgc94v1ARpnIStpz8GadxTOENZIBAIBAKVCARpXAlP3AwEAoFAIBAIBIYagaEgjfFXXCVY2H73u9/NIE2xSmsiSi5BcnjxpHGZywBLh/WbkTdYgeKDs04gr/UQObZbqzQhjdUKDx/N6rJDdT344INF+dje//vf/15vN77GKheSdeedd8792zZxcYFvVsOGEAtPL0oa414A39BVgosH0wnenhiqSuvvaV/A5UcTwZrd8sdNgxdPGnMoWJWo9TZ6IdNU8J9s+RFizVkl4KG+wLshjV955ZUWVwipRRZfFoh0La8ncL01aop49zohSSEBTS8W4SoQ7fQLXNWsuOKK2Wuvvaa3k9fUxfRh1ZuS8SKNca1RR6Qr6Y0/7m6kV6SxvgvBzi+A+DKySFP23uIwTGufD3/4w5ULd6ZXiWjSYnmvEqSxojE610Eajw6uoTUQCAQCgRQCQRqnUInfAoFAIBAIBAKBQAAEBp40xsdprwXiU32v/uAHPxiRhSeNPfHgE0CiGrmBRW9TWXTRRYt0bK1XaUIaQ4ypa4MyQk/JJQi1sRR8jho2hCnCU0njOeaYo7Z4nmQtI53qFHH4lpZN3Z5Upb3kkkuKdJD1nrRW0pj28fe97nvvvbfQR3lwPaKiLlVSJLXGtWvtw92Qxj/72c+KsrHgUEdkkj+WxOp+xZPG6mIEq+2UyxKrh4ann356URZwbZpOdeg1Pmy1/VO+aseLNC5zl6Hlx9rayk8/7EZ6RRrjA9zKRMiiDO1WRx6nyq7uK8rcYaTScRCklcEvSARpnEKst78FadxbPENbIBAIBAJVCARpXIVO3AsEAoFAIBAIBIYbgYEnjb/0pS911cK4jbj99tvzrexMZCFpIVeMUCDEms2LEm7EYZt0lSjpufTSS+eH33EAXt0fxJCVxR/c1IQ0pkx6sB6HQXmBCOMwKsvn3HPP9VF69j8kNgeN4f4CFwqQ81gCW96Ed99994j8FD8OBqwTLJxVZ6eW0/QN1cMhY3Vtxv3DDjusJR2+jlWUNMb1SJ1AqGk5vA9VDgS0+6uttlqduvy+Wid3QxqrG5XZZ5+9Ud5EIq6V2ZPGqhMXK02FxRvTSVjme9rrw0oZMhNMcAWCuxB1j2E6Ibu9jBdpvP766/uijPifA+Ws7IQp0ntEopIfekUao/6LX/xiS7koGwsOSyyxRHbQQQdlWN6n/BL7onHYntWPw/+aPJvEUSt7+ppKkMaKxuhcB2k8OriG1kAgEAgEUggEaZxCJX4LBAKBQCAQCAQCARAYeNJ4yy23bKuln3/++Wz//ffPD0fjADYOVDPSoSysI43ZFl1HcOhhb2X51P2++OKLt9S1KWmMew7TDUHrCVQO0rL71MX7Tm7JtM1/brnlltxVBaSmWvdZfqmwjjTeeOONa0tx1113FXUiD1/nWgX/FwGCKVXGdn+77rrrWrJU0hgCrU68n21PGs8///xFOdHdRMDZ6tENaUx7mJ4mhL6Vbdllly3SedIYq1HTyaJHU3nppZeKdKSHNE0Jlt1Yg2OhzSKOHqJn+abCiUQa77HHHqmqtfyGZbzWY6KQxvjg1jbWMto1C0rf+c53st/+9rdJS3zeueo73NK1G/r+FaRxSxcalX+CNB4VWENpIBAIBAJJBII0TsISPwYCgUAgEAgEAoHAMJDGe+21V6OGxsJ1gw02aNkSnyIXPvWpT2VY9CqJVEca11mKQm6ob+JUvk1+8wdxNSWN2aKvA0asYFU23HDDgljaaqut9FbH17feemvGIVdV9YKwx7KbdtF4daQxhEOd9Io0xiWIlq3Ta+/zWkljCPU6qSONcdNiZWNRpIlgHW9puiGN1ZJ95ZVXbpJ1HmfNNdcs8veksVqQcrhaU4HUtToRetzRw4F5dYs44AGZ74nNiUQa77vvvrWwTFTSmIJDYONj+vOf/3xLm2n72fVKK62U8QyoeOt7i9tuuMgii6jaLEjjFjhG5Z8gjUcF1lAaCAQCgUASAZ0D8I30hgzJRPFjIBAIBAKBQCAQCAwFAgNvacwBd3WCVVuKmMCnKr/jb/iCCy5oOZxuzjnnLIiMOtIYorlOZplllkIfB/I13Uat8SijSlPSmDR6MJtu9+cQwSmnnLIo22233aZZdHSNv13dsm8kDlbMK6ywQgYR+6tf/SqjXZBHH320yJ+4E4k09j5hzzzzzI7azrtJ6DVp/LnPfa7AsKmlsfafbkjjb3/720XelKOpqL9uTxpDElq/WWuttZqqzHADYukIsSZWwdc1bhA0Dtcf/ehH890Hhx9+eMYz8M9//jNPxjOncYM0fleOx8ILL6ywFtcQ/IZXOz6GcQ1y7LHHZrjPUV/XposQX+b0WRMWwzQueev7sum191MepLEhPHqhJ42/Az37iQAAIABJREFU9a1v5W1L+8ZfYBB9IPpA9IHe9oHpp5+++DbzPQ3SePS+b6E5EAgEAoFAIBDoNwSCNM6ybL311msZLGENedNNN2X4M04JFnBqGbzPPvuMiKY+jZuQxvheNgJk0003HaGvkx8YVJtOwgcffLBUDT5CNe5jjz2Wxz3nnHOK37G+rHOzUZrB/92AhFaLBtxh7L333tkDDzyQ3GJOsquuuqooA2XEH7EX9Wk8lpbGkNuKW6duLnx9ek0aQ8ZbOZta+95www1Fmm5I4xNPPLHQM/XUUzfuQxC1VmZPGu+yyy7FPayOm8rNN99cpEM3rg1MWJxQf+UslhxzzDHZU089VVpm75s69c7QBRIO8OtUXnzxxZaypxZPlGjvd0vjMpxef/313EL8q1/9agspTHviV1lFLcZT72mN2/Q6SOOmSHUez5PG9h6I8D+LMoFD4BB9IPrAaPaBII07/35FykAgEAgEAoFAYNAQGHrSGMtAtaRlK32dX88nn3yyhbzZddddR/SLdklj3D7YAFAtfUcodj9UkbjtkMaoXWyxxYoycBAdsu666xa//fCHP3S5t//v1VdfXeijvj/96U9rlUAYGjaEEPpexos09kQe/qGbCO1W1Xa9Jo232267AkN8wTaR0047rUjTDWnsifVnn322NnvcxWibe9L4pJNOKu5DytY9s5bhz372syId+vUAQqyINU8OOayTzTbbrCUNhKaXII3fQaQdS2PaFGvhKsFHNf3Z2s37dVf3IU0XS8iv6tkM0riqRXpzL0jjIMTsmY4w+kL0gbHvA0Ea9+ZbFloCgUAgEAgEAoFBQGDoSWN86+qAtAnpx+FZmmbbbbcd0RfaJY3x3Wk68eWL5W+dcFgXB5xxgNwSSyyReV/E7ZLG6moBf8MQ6riMoFxs2Ycg7Vb23HPPop4QkSnLTJ+HJxCwPPYyXqQx5NJUU01V1Ilt1E3k7LPPztPNM888Ga4WPLa9Jo2ZAFj/IsTitk6UcOuGNP7rX/+aTTvttEX+qefFl4UDzrS8njT2xN0ZZ5zhVYz4n7ZSNzRgr6L1nW+++fRW6TXPnZbTtyMJgzR+Bz5dvOCZ9YLbj2984xsZ+LObo4ll9tFHH120Ae4olGhW1yi0w8svv+yzHPE/7yTcBc0666zZUkstlbHQoOL7nvelTFxc62i/IE1IcwR+9KMfteCnWMb12BNIgXlgHn1guPqALqg3f3NHzEAgEAgEAoFAIBAYRASGnjT2BPCNN95Y2c5/+tOfMiyBdQC9ySabjEjTLmn8yiuvFAQtupdddtlKazcyhFDRcnTj0xh9f/7zn4vt+biNwD+v6f/KV74yoo6d/KAEMK4KIL6rBFJfSVnKc9FFF41IMl6kMQVRf9CUr44gghjTbfP4+fWWjb0mjSHS1Gcd/atKcAFibU/YDWlMPlium77JJ588d/lQlj+TFfKz+ISeNMYKFb+5Fmf22Wcv/AyX6cV/scUn3G+//VqiKgHMokmd4BOX50R1Pv744yOSBWn8DiR6cCR4p2TJJZcsMF1jjTVSUVp+O+igg4r4kyZNarmHy5HJJpusuM+hmnVy6KGHFvFpW3VhQtogjesQ7P4+C01YhrOAqs9XXA8XcRXtHe0dfWBs+wCGIgcffHD3L/HQEAgEAoFAIBAIBAIDg8DQk8bevUCKALbWZiKrLhxsMMvBdV7aJY1Jf+SRR7ZMkDmA7+233/aq8/85jEvJVKzi1MKOSO1aGpNG/TurT1ksY3shxx9/fEsdUwSw5XPXXXe1EOmGd8r6cDxJY/rFTDPNVNQLAvPOO++0arSEkJ1rr712EZc6pVx09Jo0phBqSU6+u+++e9KtA/1m3nnnbSljt6QxlpfanyCwr7322hZs+AdXFhrP2tyTxsSFzLP7hGuuuWa+8DFCaZZlLAapL+3pppsu8/6nsYA2fRCN+NkuE/ptitC67777RiQJ0vgdSE499dQC4xlnnDHDx7mX4447rohDe3hLX42P5fDMM89cxMdC1Yu3WsfNTpk7kyuuuKLFTzKW6V56TRrjO3yvvfYq/lILD74Mw/I/C2xYfsdfYNAvfcAWSNn1wI6xfil3lDOeMfpA2bdxWL45Uc9AIBAIBAKBQCAQGInA0JPGWHjq4VGQFFtssUX2xBNP5IMnyC7ILQ5rYzu7kkp2vdpqq41AthPSGNLXk3VYoUIq3nPPPdmrr76a4WcVMlkP7MJyM+V/rBPSmLpavSzEIpjBZC+EQ8XUihTdYPXHP/4xt7aFBDr33HOzrbfeOptmmmmKsjABs/KcfPLJI4oynqQxhfFW35QXC2RcaeB3FSKIQwW9lTrWdLgB8TIapDFW3Wy3NxwJsSD/xS9+kT3//PM50U1bmCsJtdDsljSmfr/85S9b+i1WuvRvnjcs0DnQzix36d/a5pQrJbgD0fpw6CSk4x133JHjfuWVV2Ycmod7FY136aWXjlDn+/7HP/7xvM1YFOA9Qd+F9Nxoo40K61XFCP3eKpVMgjR+B2p/qOUcc8yR47nWWmtl4IwQ6rsWXLl/zTXX5G2Av2vehyyy4ZrH2rXMgt0v6hCf5wBL8Yceeihjl8ctt9ySbb755i19jndT6rDBXpPGBx54YFEHypZyv/MOgnEVCAQCExWBN998s2XRk3dKSCAQCAQCgUAgEAgEAoFAINDPCAw9aUzjQeip1a6REBBCSlzxO0TCsccem+lBXFgweivfTkhjygJ5t/zyy7eQCFaeVAgZduGFFyb7YCekMcQiVsuaF4ReL0Wx03xSbTD33HPn28FXX331okybbrrpiOKMN2kMqXjiiSdmH/zgB4tyat1S12ylZ5KZktEgjckH9yqeOE6V7SMf+Uh28cUXF3XpBWlM/pC5ahmayhtLbUhBXVyArE0Jlqp6iGRKn/5GH4MsLBPF3afT/7leZpllMtwfQFTbPXyTewnS+B1E2NlB3zK8NMQligkEPdbger/quuo9iE4s/tSfdZUu7rFoUeb3O0hja6UIA4FAQBHQsyl4jzB+ZBwWEggEAoFAIBAIBAKBQCAQCPQrAkEa/1/L4Qph6aWXriQpcCtgW9ohd5V4uPrqq1v6QKekMUqaEpD4+0xZwllBOiGNSbvPPvu01O03v/mNqexJSP04uIzDphRDvYa0wQKP7cmIblmHuH/rrbdayjLepLEV5plnnsm+9KUvldaLOuLKAivJKuttJS9ZRKgTDuNS/CC2ygTs2LJfRnDjNuDee+/NLXVNZ69IY8qE5TWuICDxsA61PD796U/nVsevv/56bn1tvxOWLYxYHbFCrepPuJLgeak7YJL+hk9b+pjmr9eQmaeffnrhh3qbbbYp4i600EJWpCIM0riAIr/gfZLqe6eddlpLRIhjLPW8Nbe2BZbpvLdZZKgTFvZwTaF9TnVxDfmMJfljjz1Wqi5I41Jo4kYgMLQIeCtje7eEtfHQdomoeCAQCAQCgUAgEAgEAgOBwECSxhBeTOz5e/bZZxs3FGQmPlUh9CDt2PqOfzq2uL/wwgsj9HBIm+XjTxrGos7uYV3ZieAag7SQKbvuumu24YYb5oQuPj4ffPDBWpWQg1YGQvQ1EQ7UswkPRB64jIYwycI1AgdZbbbZZhnkGz6P2Sr+l7/8pSVLDunTunhfqGwzt/u4FqkT0lt8wjLf0XV6UvfBi/6Af1T6D/1ou+22yw9zwy2CJ7xTOp588smifFW+dS0thJjWB7zqBKvjU045JSeQIcrwG4y1p7nLgEA1nb1eOLCykcf999+fW0Dbb4S4K7E+SJhyv6LxuTZduArBX/P666+fh/hyhqhuR3AFw0GQHJYHNri44LnDV7Un+9FtOBH6wx31PfGHP/yhnWK0xKWPaj7+GSAy5KnFafLug6C3+ITdPOv0edNVR+LSx4jDrgPet1i1p96x1IkFOtoUwhercvzOH3XUUfl7IoVBC2iJf3i34EYENzc77rhj/nx+//vfz9ub565O/LvI7zIhPX4hDQvCqueR+mlcnsuQQCAQ6C8EvJWxfb/C2ri/2jFKGwgEAoFAIBAIBAKBQCDQisBAksatVYz/2kWAA8VswlPmS7ZdnRF/eBGARIUEbkewMrU+SNiEOG9Hf8QNBAKBQCAQCAR6gUCZlbF9w8LauBcoh45AIBAIBAKBQCAQCAQCgfFAIEjj8UB9AueJtR9b+ZnsTDnllBluD0ICgW4QwBJziimmyA/YW3zxxbP77ruvVp26I5l++ulHWO/WKogIgUAgEAgEAoHAGCBQZmVspHFYG49BI0QWgUAgEAgEAoFAIBAIBAKjgkCQxqMCa38qZWs6bhRsorPlllv2Z0Wi1BMOgUUXXbToV7h6qJLXXnst4zA864frrLNOVfS4FwgEAoFAIBAIjAsCdVbG9h0La+NxaZ7INBAIBAKBQCAQCAQCgUCgSwSCNO4SwH5ODjl3/fXXZxzeRvhf//VfBVHHRAdfsyGBQC8Q2G233Yq+xeFlWGZ538Dkg6/ZBRdcsIiLhVanPsF7Ue7QEQgEAoFAIBAIlCFQZ2VspHFYG5chGL8HAoFAIBAIBAKBQCAQCExkBII0nsitM8pl49Anm9D48Dvf+c4o5x7qhwkBrLEWWmihlv423XTTZcsuu2y2wQYbZCuvvHI211xztdynTx566KHDBFPUNRAIBAKBQKBPEGhqZWzjq7A27pOGjWIGAoFAIBAIBAKBQCAQCBQIBGlcQDF8F2+//fYIku7/s3cmYPdd490219DEzGdITTW15rGmRAgqMaalqClCxUwNEWoKaQg1BaGkFYq0ojFLUxSlEmKsSqullBraIkSpod3fdZ/22Z6z/mufvc95z3nPdK/req993nP2XsO91t57rd961rMY3Nz1rnfVh+z2NYeFl/grX/lKk91UxEC6dtxrr72aE088ceF5MgEJSEACEpDALASGWhnHO05r41koe40EJCABCUhAAhKQwDIJKBovk/4KpH3b2952tEnZuc51roZNyp7xjGc0Z5999grkzCxsIgH8Zr/3ve9t7nKXuzRXucpVmvOe97ztxMWFL3zh5qY3vWnz0pe+tMF1ikECEpCABCSwigSmtTIO4Vhr41WsTfMkAQlIQAISkIAEJNBFQNG4i8wWff+Tn/ykOeuss7aoxBZ1VQj87Gc/a77+9a83P/jBD1YlS+ZDAhKQgAQkMJHAtFbGIRprbTwRqz9KQAISkIAEJCABCawYAUXjFasQsyMBCUhAAhKQgAQksJoEZrUyDuFYa+PVrFdzJQEJSEACEpCABCSwJwFF4z2Z+I0EJCABCUhAAhKQgAT2IDCrlXGIxlob74HULyQgAQlIQAISkIAEVpSAovGKVozZkoAEJCABCUhAAhJYHQI7tTIO4Vhr49WpU3MiAQlIQAISkIAEJNBNQNG4m42/SEACEpCABCQgAQlIYERgp1bGIRprbWyDkoAEJCABCUhAAhJYBwKKxutQS+ZRAhKQgAQkIAEJSGBpBOZlZRzCsdbGS6tKE5aABCQgAQlIQAISGEhA0XggKE+TgAQkIAEJSEACEthOAvOyMg7RWGvj7WxHlloCEpCABCQgAQmsEwFF43WqLfMqAQlIQAISkIAEJLCrBOZtZRzCsdbGu1qNJiYBCUhAAhKQgAQkMCUBReMpgXm6BCQgAQlIQAISkMD2EJi3lXGIxlobb08bsqQSkIAEJCABCUhgHQkoGq9jrZlnCUhAAhKQgAQkIIGFE1iUlXEIx1obL7wKTUACEpCABCQgAQlIYEYCisYzgvMyCUhAAhKQgAQkIIHNJrAoK+MQjbU23uz2Y+kkIAEJSEACEpDAOhNQNF7n2jPvEpCABCQgAQlIQAILIbBoK+MQjrU2Xkj1GakEJCABCUhAAhKQwA4JKBrvEKCXS0ACEpCABCQgAQlsHoFFWxmHaKy18ea1HUskAQlIQAISkIAENoGAovEm1KJlkIAEJCABCUhAAhKYG4HdsjIO4Vhr47lVnRFJQAISkIAEJCABCcyJgKLxnEAajQQkIAEJSEACEpDAZhDYLSvjEI21Nt6MdmMpJCABCUhAAhKQwCYRUDTepNq0LBKQgAQkIAEJSEACOyKw21bGIRxrbbyjavNiCUhAAhKQgAQkIIE5E1A0njNQo5OABCQgAQlIQAISWF8Cu21lHKKx1sbr22bMuQQkIAEJSEACEthEAorGm1irlkkCEpCABCQgAQlIYGoCy7IyDuFYa+Opq8wLJCABCUhAAhKQgAQWREDReEFgjVYCEpCABCQgAQlIYL0ILMvKOERjrY3Xq72YWwlIQAISkIAEJLDJBBSNN7l2LZsEJCABCUhAAhKQwCACy7YyDuFYa+NB1eVJEpCABCQgAQlIQAILJqBovGDARi8BCUhAAhKQgAQksPoElm1lHKKx1sar31bMoQQkIAEJSEACEtgGAorG21DLllECEpCABCQgAQlIoJPAqlgZh3CstXFnVfmDBCQgAQlIQAISkMAuEVA03iXQJiMBCUhAAhKQgAQksJoEVsXKOERjrY1Xs52YKwlIQAISkIAEJLBNBBSNt6m2LasEJCABCUhAAhKQwB4ETjjhhOb5z3/+zH+HHXZYE4Ivxwtd6EIzxxX5OO200/bIp19IQAISkIAEJCABCUhgtwgoGu8WadORgAQkIAEJSEACEthIAn/1V381Jhpf8pKX3MhyWigJSEACEpCABCQgge0hoGi8PXVtSSUgAQlIQAISkIAEFkBA0XgBUI1SAhKQgAQkIAEJSGCpBBSNl4rfxCUgAQlIQAISkIAE1p2AovG616D5l4AEJCABCUhAAhIoCSgal0T8XwISkIAEJCABCUhAAlMQUDSeApanSkACEpCABCQgAQmsBQFF47WoJjMpAQlIQAISkIAEJLCqBBSNV7VmzJcEJCABCUhAAhKQwKwEFI1nJed1EpCABCQgAQlIQAISaJpG0dhmIAEJSEACEpCABCSwaQQUjTetRi2PBCQgAQlIQAISkMCuElA03lXcJiYBCUhAAhKQgAQksAsEFI13AbJJSEACEpCABCQgAQlsLgFF482tW0smAQlIQAISkIAEtpWAovG21rzlloAEJCABCUhAAhKYCwFF47lgNBIJSEACEpCABCQggRUioGi8QpVhViQgAQlIQAISkIAE1o+AovH61Zk5loAEJCABCUhAAhKYTEDReDIff5WABCQgAQlIQAISkMBEAorGE/H4owQkIAEJSEACEpDAGhJQNF7DSjPLEpCABCQgAQlIQAKrQ0DReHXqwpxIQAISkIAEJCABCcyHgKLxfDgaiwQkIAEJSEACEpDAlhJQNN7SirfYEpCABCQgAQlIYIMJKBpvcOVaNAlIQAISkIAEJCCBxRNQNF48Y1OQgAQkIAEJSEACEthdAorGu8vb1CQgAQlIQAISkIAENoyAovGGVajFkYAEJCABCUhAAhJoFI1tBBKQgAQkIAEJSEACEtgBAUXjHcDzUglIQAISkIAEJCCBlSSgaLyS1WKmJCABCUhAAhKQgATWhYCi8brUlPmUgAQkIAEJSEACEhhKQNF4KCnPk4AEJCABCUhAAhKQQIWAonEFil9JQAISkIAEJCABCaw1AUXjta4+My8BCUhAAhKQgAQksGwCisbLrgHTl4AEJCABCUhAAhKYNwFF43kTNT4JSEACEpCABCQgga0ioGi8VdVtYSUgAQlIQAISkMBWEFA03opqtpASkIAEJCABCUhAAosioGi8KLLGKwEJSEACEpCABCSwLAKKxssib7oSkIAEJCABCUhAAhtBQNF4I6rRQkhAAhKQgAQkIAEJJAKKxgmGHyUgAQlIQAISkIAEJDAtAUXjaYl5vgQkIAEJSEACEpDAqhNQNF71GjJ/EpCABCQgAQlIQAIrTUDReKWrx8xJQAISkIAEJCABCcxAQNF4BmheIgEJSEACEpCABCQggSCgaBwkPEpAAhKQgAQkIAEJbAoBReNNqUnLIQEJSEACEpCABCSwFAKKxkvBbqISkIAEJCABCUhAAgskoGi8QLhGLQEJSEACEpCABCSw+QQUjTe/ji2hBCQgAQlIQAIS2DYCisbbVuOWVwISkIAEJCABCUhgrgQUjeeK08gkIAEJSEACEpCABFaAgKLxClSCWZCABCQgAQlIQAISWF8CisbrW3fmXAISkIAEJCABCUigTkDRuM7FbyUgAQlIQAISkIAEJDCIgKLxIEyeJAEJSEACEpCABCSwRgQUjdeossyqBCQgAQlIQAISkMDqEVA0Xr06MUcSkIAEJCABCUhAAjsjoGi8M35eLQEJSEACEpCABCSw5QQUjbe8AVh8CUhAAhKQgAQksIEEFI03sFItkgQkIAEJSEACEpDA7hFQNN491qYkAQlIQAISkIAEJLA7BBSNd4ezqUhAAhKQgAQkIAEJbCgBReMNrViLJQEJSEACEpCABLaYgKLxFle+RZeABCQgAQlIQAIS2DkBReOdMzQGCUhAAhKQgAQkIIHVIqBovFr1YW4kIAEJSEACEpCABNaMgKLxmlWY2ZWABCQgAQlIQAIS6CWgaNyLyBMkIAEJSEACEpCABCTQTUDRuJuNv0hAAhKQgAQkIAEJrCcBReP1rDdzLQEJSEACEpCABCSwIgQUjVekIsyGBCQgAQlIQAISkMDcCCgazw2lEUlAAhKQgAQkIAEJbCMBReNtrHXLLAEJSEACEpCABDabgKLxZtevpZOABCQgAQlIQAISWDABReMFAzZ6CUhAAhKQgAQkIIFdJ6BovOvITVACEpCABCQgAQlIYJMIKBpvUm1aFglIQAISkIAEJCABCCga2w4kIAEJSEACEpCABCSwAwKKxjuA56USkIAEJCABCUhAAitJQNF4JavFTElAAhKQgAQkIAEJrAsBReN1qSnzKQEJSEACEpCABCQwlICi8VBSnicBCUhAAhKQgAQkIIEKAUXjChS/koAEJCABCUhAAhJYawKKxmtdfWZeAhKQgAQkIAEJSGDZBBSNl10Dpi8BCUhAAhKQgAQkMG8CisbzJmp8EpCABCQgAQlIQAJbRUDReKuq28JKQAISkIAEJCCBrSCgaLwV1WwhJSABCUhAAhKQgAQWRUDReFFkjVcCEpCABCQgAQlIYFkEFI2XRd50JSABCUhAAhKQgAQ2goCi8UZUo4WQgAQkIAEJSEACEkgEFI0TDD9KQAISkIAEJCABCUhgWgKKxtMS83wJSEACEpCABCQggVUnoGi86jVk/iQgAQlIQAISkIAEVpqAovFKV4+Zk4AEJCABCUhAAhKYgYCi8QzQvEQCEpCABCQgAQlIQAJBQNE4SHiUgAQkIAEJSEACEtgUAorGm1KTlkMCEpCABCQgAQlIYCkEFI2Xgt1EJSABCUhAAhKQgAQWSEDReIFwjVoCEpCABCQgAQlIYPMJKBpvfh1bQglIQAISkIAEJLBtBBSNt63GLa8EJCABCUhAAhKQwFwJKBrPFaeRSUACEpCABCQgAQmsAAFF4xWoBLMgAQlIQAISkIAEJLC+BBSN17fuzLkEJCABCUhAAhKQQJ2AonGdi99KQAISkIAEJCABCUhgEAFF40GYPEkCEpCABCQgAQlIYI0IKBqvUWWZVQlIQAISkIAEJCCB1SOgaLx6dWKOJCABCUhAAhKQgAR2RkDReGf8vFoCEpCABCQgAQlIYMsJKBpveQOw+BKQgAQkIAEJSGADCSgab2ClWiQJSEACEpCABCQggd0joGi8e6xNSQISkIAEJCABCUhgdwgoGu8OZ1ORgAQkIAEJSEACEthQAorGG1qxFksCEpCABCQgAQlsMQFF4y2ufIsuAQlIQAISkIAEJLBzAorGO2doDBKQgAQkIAEJSEACq0VA0Xi16sPcSEACEpCABCQgAQmsGQFF4zWrMLMrAQlIQAISkIAEJNBLQNG4F5EnSEACEpCABCQgAQlIoJuAonE3G3+RgAQkIAEJSEACElhPAorG61lv5loCEpCABCQgAQlIYEUIKBqvSEWYDQlIQAISkIAEJCCBuRFQNJ4bSiOSgAQkIAEJSEACEthGAorG21jrllkCEpCABCQgAQlsNgFF482uX0snAQlIQAISkIAEJLBgAorGCwZs9BKQgAQkIAEJSEACu05A0XjXkZugBCQgAQlIQAISkMAmEVA03qTatCwSkIAEJCABCUhAAhBQNLYdSEACEpCABCQgAQlIYAcEFI13AM9LJSABCUhAAhKQgARWkoCi8UpWi5mSgAQkIAEJSEACElgXAorG61JT5lMCEpCABCQgAQlIYCgBReOhpDxPAhKQgAQkIAEJSEACFQKKxhUofiUBCUhAAhKQgAQksNYEFI3XuvrMvAQkIAEJSEACEpDAsgkoGi+7BkxfAhKQgAQkIAEJSGDeBBSN503U+CQgAQlIQAISkIAEtoqAovFWVbeFlYAEJCABCUhAAltBQNF4K6rZQkpAAhKQgAQkIAEJLIqAovGiyBqvBCQgAQlIQAISkMCyCCgaL4u86UpAAhKQgAQkIAEJbAQBReONqEYLIQEJSEACEpCABCSQCCgaJxh+lIAEJCABCUhAAhKQwLQEFI2nJeb5EpCABCQgAQlIQAKrTkDReNVryPxJQAISkIAEJCABCaw0AUXjla4eMycBCUhAAhKQgAQkMAMBReMZoHmJBCQgAQlIQAISkIAEgoCicZDwKAEJSEACEpCABCSwKQQUjTelJi2HBCQgAQlIQAISkMBSCCgaLwW7iUpAAhKQgAQkIAEJLJCAovEC4Rq1BCQgAQlIQAISkMDmE1A03vw6toQSkIAEJCABCUhg2wgoGm9bjVteCUhAAhKQgAQkIIG5ElA0nitOI5OABCQgAQlIQAISWAECisYrUAlmQQISkIAEJCABCUhgfQkoGq9v3ZlzCUhAAhKQgAQkIIE6AUXjOhe/lYAEJCABCUhAAhKQwCACisaDMHmSBCTEodsbAAAgAElEQVQgAQlIQAISkMAaEVA0XqPKMqsSkIAEJCABCUhAAqtHQNF49erEHElAAhKQgAQkIAEJ7IyAovHO+Hm1BCQgAQlIQAISkMCWE1A03vIGYPElIAEJSEACEpDABhJQNN7ASrVIEpCABCQgAQlIQAK7R0DRePdYm5IEJCABCUhAAhKQwO4QUDTeHc6mIgEJSEACEpCABCSwoQQUjTe0Yi2WBCQgAQlIQAIS2GICisZbXPkWXQISkIAEJCABCUhg5wQUjXfO0BgkIAEJSEACEpCABFaLgKLxatWHuZGABCQgAQlIQAISWDMCisZrVmFmVwISkIAEJCABCUigl4CicS8iT5CABCQgAQlIQAISkEA3AUXjbjb+IgEJSEACEpCABCSwngQUjdez3sy1BCQgAQlIQAISkMCKEFA0XpGKMBsSkIAEJCABCUhAAnMjoGg8N5RGJAEJSEACEpCABCSwjQQUjbex1i2zBCQgAQlIQAIS2GwCisabXb+WTgISkIAEJCABCUhgwQQUjRcM2OglIAEJSEACEpCABHadgKLxriM3QQlIQAISkIAEJCCBTSKgaLxJtWlZJCABCUhAAhKQgAQgoGhsO5CABCQgAQlIQAISkMAOCCga7wCel0pAAhKQgAQkIAEJrCQBReOVrBYzJQEJSEACEpCABCSwLgQUjdelpsynBCQgAQlIQAISkMBQAorGQ0l5ngQkIAEJSEACEpCABCoEFI0rUPxKAhKQgAQkIAEJSGCtCSgar3X1mXkJSEACEpCABCQggWUTUDRedg2YvgQkIAEJSEACEpDAvAkoGs+bqPFJQAISkIAEJCABCWwVAUXjrapuCysBCUhAAhKQgAS2goCi8VZUs4WUgAQkIAEJSEACElgUAUXjRZE1XglIQAISkIAEJCCBZRFQNF4WedOVgAQkIAEJSEACEtgIAorGG1GNFkICEpCABCQgAQlIIBFQNE4w/CgBCUhAAhKQgAQkIIFpCSgaT0vM8yUgAQlIQAISkIAEVp2AovGq15D5k4AEJCABCUhAAhJYaQKKxitdPWZOAhKQgAQkIAEJSGAGAorGM0DzEglIQAISkIAEJCABCQQBReMg4VECEpCABCQgAQlIYFMIKBpvSk1aDglIQAISkIAEJCCBpRBQNF4KdhOVgAQkIAEJSEACElggAUXjBcI1aglIQAISkIAEJCCBzSegaLz5dWwJJSABCUhAAhKQwLYRUDTethq3vBKQgAQkIAEJSEACcyWgaDxXnEYmAQlIQAISkIAEJLACBBSNV6ASzIIEJCABCUhAAhKQwPoSUDRe37oz5xKQgAQkIAEJSEACdQKKxnUufisBCUhAAhKQgAQkIIFBBBSNB2HyJAlIQAISkIAEJCCBNSKgaLxGlWVWJSABCUhAAhKQgARWj4Ci8erViTmSgAQkIAEJSEACEtgZAUXjnfHzaglIQAISkIAEJCCBLSegaLzlDcDiS0ACEpCABCQggQ0koGi8gZVqkSQgAQlIQAISkIAEdo+AovHusTYlCUhAAhKQgAQkIIHdIaBovDucTUUCEpCABCQgAQlIYEMJKBpvaMVaLAlIQAISkIAEJLDFBBSNt7jyLboEJCABCUhAAhKQwM4JKBrvnKExSEACEpCABCQgAQmsFgFF49WqD3MjAQlIQAISkIAEJLBmBBSN16zCzK4EJCABCUhAAhKQQC8BReNeRJ4gAQlIQAISkIAEJCCBbgKKxt1s/EUCEpCABCQgAQlIYD0JKBqvZ72ZawlIQAISkIAEJCCBFSGgaLwiFWE2JCABCUhAAhKQgATmRkDReG4ojUgCEpCABCQgAQlIYBsJKBpvY61bZglIQAISkIAEJLDZBBSNN7t+LZ0EJCABCUhAAhKQwIIJKBovGLDRS0ACEpCABCQgAQnsOgFF411HboISkIAEJCABCUhAAptEQNF4k2rTskhAAhKQgAQkIAEJQEDR2HYgAQlIQAISkIAEJCCBHRBQNN4BPC+VgAQkIAEJSEACElhJAorGK1ktZkoCEpCABCQgAQlIYF0IKBqvS02ZTwlIQAISkIAEJCCBoQQUjYeS8jwJSEACEpCABCQgAQlUCCgaV6D4lQQkIAEJSEACEpDAWhNQNF7r6jPzEpCABCQgAQlIQALLJqBovOwaMH0JSEACEpCABCQggXkTUDSeN1Hjk4AEJCABCUhAAhLYKgKKxltV3RZWAhKQgAQkIAEJbAUBReOtqGYLKQEJSEACEpCABCSwKAKKxosia7wSkIAEJCABCUhAAssioGi8LPKmKwEJSEACEpCABCSwEQQUjTeiGi2EBCQgAQlIQAISkEAioGicYPhRAhKQgAQkIAEJSEAC0xJQNJ6WmOdLQAISkIAEJCABCaw6AUXjVa8h8ycBCUhAAhKQgAQksNIEFI1XunrMnAQkIAEJSEACEpDADAQUjWeA5iUSkIAEJCABCUhAAhIIAorGQcKjBCQgAQlIQAISkMCmEFA03pSatBwSkIAEJCABCUhAAkshoGi8FOwmKgEJSEACEpCABCSwQAKKxguEa9QSkIAEJCABCUhAAptPQNF48+vYEkpAAhKQgAQkIIFtI6BovG01bnklIAEJSEACEpCABOZKQNF4rjiNTAISkIAEJCABCUhgBQgoGq9AJZgFCUhAAhKQgAQkIIH1JaBovL51Z84lIAEJSEACEpCABOoEFI3rXPxWAhKQgAQkIAEJSEACgwgoGg/C5EkSkIAEJCABCUhAAmtEQNF4jSrLrEpAAhKQgAQkIAEJrB4BRePVqxNzJAEJSEACEpCABCSwMwKKxjvj59USkIAEJCABCUhAAltOQNF4yxuAxZeABCQgAQlIQAIbSEDReAMr1SJJQAISkIAEJCABCeweAUXj3WNtShKQgAQkIAEJSEACu0NA0Xh3OJuKBCQgAQlIQAISkMCGElA03tCKtVgSkIAEJCABCUhgiwkoGm9x5Vt0CUhAAhKQgAQkIIGdE1A03jlDY5CABCQgAQlIQAISWC0CisarVR/mRgISkIAEJCABCUhgzQgoGq9ZhZldCUhAAhKQgAQkIIFeAorGvYg8QQISkIAEJCABCUhAAt0EFI272fiLBCQgAQlIQAISkMB6ElA0Xs96M9cSkIAEJCABCUhAAitCQNF4RSrCbEhAAhKQgAQkIAEJzI2AovHcUBqRBCQgAQlIQAISkMA2ElA03sZat8wSkIAEJCABCUhgswkoGm92/Vo6CUhAAhKQgAQkIIEFE1A0XjBgo5eABCQgAQlIQAIS2HUCisa7jtwEJSABCUhAAhKQgAQ2iYCi8SbVpmWRgAQkIAEJSEACEoCAorHtQAISkIAEJCABCUhAAjsgoGi8A3heKgEJSEACEpCABCSwkgQUjVeyWsyUBCQgAQlIQAISkMC6EFA0XpeaMp8SkIAEJCABCUhAAkMJKBoPJeV5EpCABCQgAQlIQAISqBBQNK5A8SsJSEACEpCABCQggbUmoGi81tVn5iUgAQlIQAISkIAElk1A0XjZNWD6EpCABCQgAQlIQALzJqBoPG+ixicBCUhAAhKQgAQksFUEFI23qrotrAQkIAEJSEACEtgKAorGW1HNFlICEpCABCQgAQlIYFEEFI0XRdZ4JSABCUhAAhKQgASWRUDReFnkTVcCEpCABCQgAQlIYCMIKBpvRDVaCAlIQAISkIAEJCCBREDROMHwowQkIAEJSEACyyXwP//zP81zn/vc5uY3v3lzwxve0D8ZrEUbuNrVrtac4xznaP/Oc57zrEW+vcd8xkQbuOMd79i8733vW+4LwNQlIIG1JvDf//3fzc9+9rO1LoOZl0AXgZ/+9KddP23091snGp999tnNYYcd1v496lGPara18je6Zc+xcC996Uvb9nLiiSfOMeb5RfXjH/+4zSPt+8wzz5xf5ANj+v73vz/wTE9bFoE3vOENbTt5+ctfvkc2/u3f/q39nXb09a9/fY9zFv2F7WjRhFc//hNOOKEV3rII5+efC5KykIVtwDawiDbwC7/wC813vvOd1X9RTMjhcccdN9aXyeO+/PnhD394c8QRRzTPe97zmle96lXN29/+9uaHP/zhhJgX99Pf//3fj+X5v/7rv3ac2KmnntrG+YxnPGOP+H7yk5+0v8Pl85///B7nzPOLRz7ykW16n/jEJ+YZ9UbFhS6R2yltY9XDP/zDPzRHH310c+CBBzYXvvCFGyZN99lnn2a//fZrMAQw7B6B7373u2Pt5ytf+cruJb6BKfEsfu1rX9sceuihzdWvfvXR+ORiF7tYc+1rX7t597vfvYElrhdp60Tj448/fo/B6Mknn1yns2LfIng/6UlPaj784Q+vWM7q2eEhdfe7333tZxvvcIc7tG2GDs8qho9//ONtHhlE7KbYRwf7aU97WvOYxzxmFdGYp0Tglre8ZdtOeJaU4W1ve1v7+/nOd76GyYjdCmeddVbDJN5RRx21W0mazooSYLC0CDHEOBXZbAO2AdtAfxt4//vfv6Jvh2HZutvd7jbzO+QiF7nISHChX72bAea5bf7gBz/YcfLPf/7z2zgRO8rwox/9qP2dtP/yL/+yPGWu/zMhEWV885vfPNe4Nyky+t7BieOq34//8i//0lzqUpcay3Pk/zrXuc5Y1XzjG99o7nvf+zYYqRgWQ+Bf//Vfx+rCCZrZOTPh8ZCHPGSMZ7Rtjn/91389e+RrduXWica3uMUt9qj429/+9itdbTRYXq6Xv/zlR3nHb94qB2Zkfv/3f7+5wAUuMMrvui9RWQfRGKvReIgxs7tbAauMK17xiqO0/+iP/mi3kjWdGQhguRD3JG3lpJNO2iOWpz71qW07uulNb7rH74v4gufb6173uubSl770KO1TTjllEckY5xoR+J3f+Z22HcZzzWO/0CMjGdkGbAPzaAPvfe971+iNsWdWdyIaZ361ftKeqc3nG0Xj+XDchFjWSTQmrze60Y06+2z3uc99RlXCGOQlL3lJs/fee4/OVTReXEtVNJ4fW1ag5HdC+XndV+VMQ2qrRGOWd0RlM+N63vOet/3/H//xH6fhtqvnIsJGvjmuumjMTHXOr6Lx4pvLAx/4wJb5b/zGbyw+waZpvvCFL7RpUt+f+9zndiVdE5mNwKc//emx+qotV2ICLe5drH53I3zgAx9o0yTtb3/727uRrGmsMIFSND7ggANGS8NYHuafDGwDtgHbwHzbQAg58f7fJNF4r732ah7xiEdU/3BPcb/73a856KCDml/7tV9rsiUsLJho3y0rPUXjFe6U7HLW1kk0ZuwXzw2Ot73tbRtWLWIpj5uE//iP/xjR4z7K5ykaL65RKRrPjy3uVaLdsgqFiY8vfvGLDdocFvbbFLZKNGY5dlT87/3e7zV3utOd2v+f+MQnrmy9Kxovt2rw08QyNf5qQttyc/e/qf/zP/9z83d/93ejP5b+7Eb4kz/5k/b+udCFLrT2bkh2g9ky0/jDP/zDtr6w6q35GGPyLNpRdPQWnedjjjmmzddVrnKVRSdn/GtAoBSNH/3oR69Brs2iBCQggfUk8P/+3/9r38OMkzZJNL7Sla40uFL+9m//tmE5fYwVOV7ucpfbFVddyxCN2bAsxjccv/e97w1mNcuJWZTXPUU3wXUSjd/1rneN3S8f+tCHqgVTNK5iWciXtJ98X8/D1c1CMroGkcZqat4F97rXvdYgx4vL4taIxjj7j+XPVDx+gbPodfGLX7zBt9MqBkXjVawV84QP4+hYMxNnWG0CD37wg9v6YsJsVcI97nGPNl/3vve9VyVb5mOJBBSNlwjfpCUgga0joGj88ypnzLX//vu3/RL6uaeffvrPT1jQp2WIxgsqSme0isadaMZ+WCfR+JWvfGV7r1zwghfsnGBRNB6rYv9ZAwJMqrGhY2gdGF9tc9ga0Rjfq1Hp7OqJb53vf//7zfnPf/72+9e//vUr2RYUjVeyWrY+Uze72c3ae2eVLfW3vqL+D8B1r3vdtr6OPPLIlcFyhStcoc3Xi170opXJlxlZHgFF4+WxN2UJSGD7CCgaj9f5a17zmrZfwtjxxS9+8fgJC/hP0XgBUNc0ynUSjbk3Ql+52tWu1klc0bgTjT+sKAG0wmjbHBe9UeiKYmiztTWi8V3vete24n/zN3+zBYD/12gQN7/5zdvv5/kBC+b3vOc9zUtf+tIG68zf/d3fbeiQ/M3f/M3I309XWt/61reaT37yk81pp53W5pG8MtPB9/x99atfbS9HBI/vw0czS9A/9alPNc985jMbdtGN79uLig8I1Pgnestb3tIcddRRzUMf+tAGgelNb3pTc8YZZ4yE9uKS9l98vJD+cccdN5ZflkhEvvochrMk/n3ve1/zwhe+sHnYwx7WvOAFLxgtk/v3f//3Np1pPpDeG97whlEZDjvssFEdkB8szyPgfiLyV1uaBbP4faj/GlhQT2wshgACwze+8Y3NP/3TP0Wyczt+7Wtfa/NHWcpAWSP/n/3sZ8d+pn3gm5g6w7fb8573vOaDH/zg2Dn5n6hj2kKecKGtRBpf//rX8yVjn0kPiw0cy+Mu5pGPfOQobXYfPfvss8fOnfQP/nlJj7Ydgbjf+c53juJ9xjOe0XzsYx9rmCUkkKfI3+c///m4ZHSEH20EH75Pe9rTmlNPPbXquoGTWeLDvYxI/oQnPKF5xSte0UzrDoRy/vmf/3mDWwbaOGn+6Z/+aUO+KMMsgbK97GUvG/FEeMXFRI6LfJ/73Odu70vKUAZcnASjL33pS+XPe/zPs+fP/uzPRs8V/AU+7nGPa4499tiGpWp9ri3wL09apT/j/GybdM9TryyBgz/PU56rr371q5uPfvSjK7tiZA+AftFJQNG4E40/SEACEpg7AUXjcaT0GWNsyPG3fuu3xk744Q9/2PaX6MswduoL9P+jj1VzddclGhM3fRvGRfSZ6et85jOfGeQSjnFflIO9fMpAXyryxLE2BsrX0O+jv8pm54wPGVvSD2TciNDZF7osjfFvS9+R+B7/+MePNmqeNJboS2fI7+SXvjL98SjPs571rNFYjXEiY+pFBXSBGGczNqXvzLgm9gAaIhrThqLuYi8Q2uU73vGOUX+ccXtffTJGRov44z/+4+bwww8f+f1mDMFYivEkolktcF2kzVgo2hhGIPE9R8YVX/7yl0ffMc6K8zgy1o9zJ/X3a+nT/uParIPUzs3f5fEydT8p/Od//mc7XmV8SNvAVzPc8/iqKw7KVOaR+mW8++QnP3k09sX3cFeAPyviSZd7jTb61re+dTRmj3bSdW0e95MHytIXaDuMz9kvgPH5Yx/72IYN7hnv89uQkOslxt9cR/qM944++ugGd3PHH3/8aPw+5JkxJN3aOcGAdodLWp6dWMXT3vvu7SgHOkJus2glUacc++qhlq91/m4rRGNEnSyYnHDCCW2d4VMpNwgayrwCDRYxLbvFyGnFZ3YWxVl8GeggxDldx+zrkQ3y4rw73OEOo+gQVOK7OF7rWtfaQ7zkgYDokznF+fmI71qcgNdulLvf/e57pJWv5XOXDys6DH27HSP294lRwRBhjrL/4i/+YjVPWJvzUiTc6la3as+piWmwjHLw0JkUeBjd7na3a8+P6+J4rnOdq2HTOl6k8woHH3xwm95v//Zv7xEtnc1I/yY3ucnod154CG6/9Eu/1P4W53C8y13u0tQE/tLXW74mPtP5KAPpnXjiiRN32OU+4YXYF5hMibRiVpvvmPSJ7+P47ne/exTdIYcc0v525zvfefQdEwDwiHPzkTrPL0niv+Md7zi2eWacTxvjxdoXvvnNb446ZTjSj2vLI24jJnUiyjTo2P76r/96Nb7LX/7yo84J19BJyWnVOmhsAhPnTLIcZ+Lhvve979iSnbgujjBBDD/rrLPKLI86W5e4xCXatOKa8vgXf/EXe1xLB5YB0zWvec3O6/FfuOqbhe5RML8YI6BoPIbDfyQgAQkslICi8Z54L3nJS7b9DNxV5IDglPssQyba6XvGNQ95yENydKPPNdEYoaWrv8Q4BmFwUugTjREvI08cuyzpKB8bBual2vk6PuOagHHFJEGtFI0Rk+5///uP5SHHiz9RROp5BsqMKDapLOSBTRAxXOoSTmfJE2NnDEa6dAHqGjF1iGhMGwpW6BoIxFe96lXb7/jtvOc976i/XuYVw428WjTiKY/oBRiulYF2V55b+5+xwoMe9KDec6dd9p/3pLrFLW5RZq/zf86NfJKvWoA9ou4kPeR617te7+bvlCnSQnRGRM3PgPiNsVc2msIim4054/fakWcTAnZXmGYjPO5XxOnLXvaynWme73zna5773OdWtZ+chzy+5T7jD7eDXfca/uJxFzvvgJbDJFmNHd+d85znHGleeZyf83Cxi12s89ocZ5/4nOPchM9bIRrnlyaiZ745adC5kWP5N4/ATZiFqtzIap/32WefVuCJ9HcqGjOLWUuLl1V+CSJ0Ir7Vzu36bt99993j4TGraIx42/UCLdPnoYYl6KSAINYlBub4eGhgWXvLW96yLfusojH1jaVn14Mxp8vni170og0v7XkE2k7Ej6BfBizc43dEb9o8wnV813UsBWg6d5NeohFPacnLC5jOZvyej4jo+X8+c99M6nTSXuIa8ogVba2+adMx00nHJ6559rOfPZopnPSC5NwHPOABI5TUE0JkXF878kIty53rAYvoWnq0wTI+nkddHfccJ502OoTl9fl/Xnzk/w/+4A/a86585SvnaEafmeAqO/N7nNQ0I4uMvjRz+gjXpbUIEyb5nK7P5aQFL+cDDzywem2N41Oe8pRaEfxuDQgoGq9BJZlFCUhgYwgoGo9XJQYquW9SGozshmiMxeeQMQV567LYy+PfmqUx44FczlrfE4OHvj5wjoN+WpeBT+5nYlSV++Y5jvLzvNyDYDk4yeigTJf/EfXoI+80YDGe9/CopcV31HkWHPmOCYUyZNEY69C8cjrHnY3LEK0ZD+SVovnc2mf614wjc1i2aFzqG6yC7QtY+ufyYUxTBu7r61//+mPn5WvyZ9oyY+4YZ5Zx5TpENEZ0zdfHZ8T7CGzEuffee1fPi/Pzkb1qaqschorGWF5nIT3HXfvMvTBJu8h6GsZWt771rXvLgq7w8pe/PBDs6MjECUZvtbzXvuOZWJsUUTSuV8PGi8aIT9e4xjXaBoRYVgaE4mhMWMjNY+agFHwRwtiNmOUGLG3gYYXpf36Bks8slvHw4kWAZV3kjyNLSPiev7w5Q7Y0Jq784EFYZNaU61n6EwGBNb88uFEQW4iLvCKEsWSIa/J5xMNDOwdeauQJK8WcX6wwI7+lhS0CcD6XNFhGgJUhM9scWZrBjHqcxwuMmbha4OF905vetD2Xa7AkZikEFpLM2rPEg40PI74sXM4qGuMPO+LjSDngiMBJmT/ykY+MltDnDuBVrnKVzo5VrWy177Ciz+kyAVAGZnrjnOc85znNDW94w9H/iJgIqNQv9cyyjdKSOLvTwBo+6jFbpd7oRjdqv+f3/AJFaC5fGtQHFsB0ROnoYt1fikS48ugKT3/609vy0PmJmVuE29vc5jYNlvu8uOIlxCRRrmM6UEwewQSxGSYsv8FCGkE1WFFXLFuLlwe/4QaBTjUuPA499ND2XK5hWV0tcF9ki3fySdugDdNhp3NNO8kTN4iteXKrjJfOSBZKaUt0SLAqJ14mMKKN09k/4IAD2ryWyyyJm2ui3BxZTlYG7vc8aXCpS11q1H54lvFM43nFsrjsCoi4qP8c6MxEO8ozweQxvscqPQcYMbOf84ilARYZ/AZHrK5ZjZDP0eI4U1yfz+XzIA961qcU5lQCEpDAehBQNB6vp7JPT/84h90QjaMvg1ENFq+M9xjHkJdS+MTFQS3MQzTO/X0sHFlijtBCP5FxIhaPt73tbcf6XvTTayGPeaN89LUxREJEZpxMP7AUfriOfuZOAmOY6PuTNuMExtP00RHCzjzzzNHYhO9ivBx5ZIn7TkM5ZviVX/mV0TiF/jdjRCyQ6ftHmvnYJxrncS9jA8YEcT3xR8hCJr8jkOIuk/pkzE0/mv737W9/+/Z6zsPQKY9JODf664y5Ii2eI/E9R9zIYUnKZ8ZIcR5HhOg4l3Y0TWDsmC3wGcv2hZw+FtlZb+FaxtNZNyGPaEaMA3FTyfiayYusKXEO461ayKwZd+dxKOPJ0APi2QLfXP/UIZb7jE9xwYELGMbG5Vio1jaHiMbcD+WkzQ1ucIORqxTGkrhLoW2Uq1l5HtVWkcIgi8YRN+0RAy/cUqKxcJ/vt99+Y22BVQq1Ffc1rl3f0SbyWJe6gSHPTrQfntk817F85rf4Q68pJx2YFKFtoh3FeRzRt6LNcpzHZFJXeVbx+40XjbnJc4XTcMrAizifg8+SnYYb3/jGbZyIdl2Bl20Wf7hRy8AsUs5flxCSReM4H1GMBw4PR8zwEQh52EdAQI1zudl5aXYFBMS99tqrPR8L3VpAVIs4OdZcWXAdN1vu+Pzqr/7qyFdPLU4e2PEAIk7SLh/4XFcK7PhaylbVETedHcTOnE8+zyIaI7znlxcvo9J3cKRL/Lm+EcR3EvIGj7yAakstsjAXLylEmdpDn45DZnLyySdXs5fF5S6xlAvLCYRJS9eYsY206XjU8kecuImI80IAp8PEjGkEXh78ERB44/w4wuGkk06K09sjL4E4Jx/pRJbtjXad3XvUxFisZfNgDGG4y684FtO5M9DlIgKBH+E58kenjxndMmDhmzeZi/MR2stApyV+Rwwuy8rsbYjnnMdzZdILvrQsL62GSZ808n1DB6sr0OGI/FF3XW5uiJO6inN5vkQ76Irb71ePgKLx6tWJOZKABDaXQO6n8P5EvFvnkN3dMXE+TcB1We7vMFleWtftlmjMOKXms5U+WV6iT78oj+2ivDsVjcuVYYw5aoG+V+730ffMBiRxTcZYoboAACAASURBVCkak++adTPxlZaZXf2+iLvvmI25GMt2jdOIB4E6C2CM6XcSSt+oGFfUDNQQLmuu9vpE4+jzMm4gDgLCISIjLAkc8zgaYbg2Ph6d3DQjK9qIlyPjt1rIG+HVrNnjmtI4BbeUOwkY3kX+SqO7Ml7KnoV0hMsyZDcaiMe1dsk11Fu26kZQr1nWZ9E48km9x7OEMS7+wGMsdcopp7TlQWDmGVMLaEJ5hTRCaRmGiMbZYJL8YQ1ds1qGHfcO92qUo1x5Eenne4ZzMU6j7ZeBOMt+/k5XE+RnHWlTR106AvdFnkBidQR5KgP3R5SZ47q/F8vyTfv/xovGmO5HhdNxqL3EaCjM+MV5173udauNZyhcHijZIm/SsnXiZIaVtLkh2cCrDLOKxszcdAlUpIFoiz+ZKDezMX0hCzJ0MmthqGicXzSIYCzLmBToOGVrZ2aCckDEu8xlLtOWBwvH2kMgrkFkLDsws4jGefYSltn6O9LKRx62wRwRcVIe83W1z1hlR1yIh2XgZRS/xxGH+l2BvOSZVvwclQFxM8+YMhFRC8xY5/O6LA/iWuqPey/yWfMTTP7CgjbOo+Nce9FFvOWLhPustJKPc9kUMOKNI5sZdtVRtqqt+ajLlgW8TPtm07PAzf1bPq/4P3cWmKDoeilSJoTxKEccmfkvQ+4s4UurDLmN0z5qPpHzNViPR3oca5NhDHDyOXlTwxxXdkfC+TErn8/Jn7Fuz7P1dMQM60Wg7Exqabxe9WduJSCB9SKw7aIx4yGszVgFlo1j6HPUJvB3QzRmvFO698qtirFmFrdrK2lz/7cm6PW5p2AFXvTTEBy7+sLki7yGUQyr6zBYKkM55qqNMeIa6iT76B1iTRrXlkfGF9nFBisM+0Je1YgwuJOQBX6MJRhHdQX61/T/gzvHIaIxKy3LMUNOg5V5ESdjs9pkRD6fuLJhDPsE1UIey9faWFwzb9G4HGfU2luknQ0IaaNl2RmvRtuFUW1vnoiLI+0pC/BsBl6GUjRmXBICcXku/+NHOeoHwXNSyGNF2lMpWveJxkyKZFeDGGP1BfyAR/5oPzXepWg8yR95eX8j3M4asNLO2gCaHnU0KWAgGuXhWDOSUzQeJ7jRojGNKC8Ln2QRybKQ3Hhqy/zH0XX/h2iRX4xYv04KiCf8dc34zSoad80ERV54MeHTlwE6M1U1a8U4N47ZEpOXWi0MEY3peGQrw66XURl/FlyZgc+B5T25Dvm/L+B2I18zi2ic/R/RMegLLPnA3QbWmszM16ww++KI3/MmfTUxmFmxXL5f/uVfHltiFPHEsRSZa75+yk3VumaLs7jJ8rZJnZlIn83TIr+8oMpQCo3c39nCuDyf/+95z3u2cRL3pM4AbjMifY4sY5nUSc6W8txLOSCC5rhe97rX5Z87P+dBQLkcr/TjVVuWlCPmpZmtknnR1zqr1772tdu81qzfEZ+x+uA+HVIOJqty2WvuLuhMxDksBaQDUQbaTLYOwG/6kJDF+p3OXg9Jz3PmS0DReL48jU0CEpDAJAKbLBpjKIDAU/tjhSNlz4JR9Es4IprV+ky7IRpnV4JddYeQGvmlf1caEexUNMYiL+JHxMat3KRAv5cxQVe/OY+NWVnXF7LhF24QZg2MsxjnM05ivFuKhrV4cdMQZccQrKtMtWvzd2gC2eBpiGBNXzvS5jhENO7TLfidMRYc+/SByH92U0Fd1MKyRGPyEqtNYYTlcVfAfUvwpExlyHsyMTYfUtd5DFMbW5WicekXuswDRoORRyY4aDddgbEdom2XCN0nGpduFz75yU92JdV+zz2UReHaJFX+HW2kj+PBBx/clhnNYNbA/RHsOOJSpC+UojUuM8qgaDxOZKNF4zxDSiNCcOoKLOfI1sGIeTsJ2a8KDxNmqrEy7LuBamnOKhqHT9danLN+V1ou1oTuIaIxHY98g/dtbhf5ZSlHXIc1QOaZZ+kQmoYE3HFEfBynFY2ZWc/Xk78hIed7yPm1c4gjC4z4HipDdj9CPvERPSmUS6jK2UuuzZuqdS37K0XDocvKECSDJz7NypA7cZw3xDqe3ZcjTnhNcleA8BvncpzEi3jyTG35kspLp7Dor4miZfn4P/smK9PPHRuWY/XNpBJfXkWBOFyG0nIc4Xyn4a1vfWvLkQFb7TmRJ2y6dj/GKjrXx5CJIPKelzV2+frbaRm9fnEEFI0Xx9aYJSABCZQENlk0zn2IaT7f//7377T03Q3ReNJK0ag/XGnkMmExmcNORWOMi7Kgjj/TE044YWZjlywa3+te98pZrX7OonhtNWX1ojl9Wa5yq00eDEmqNEYpjUFqcZSrHoeIxjsxQKrlgTFmdsOAAU4tLFM0xp9wtH/aZm2sgYaCpXicV65SpkzZor1vVWwwKMf/WD7nUIrGXe4u4ppsDU1eGeMxlpql3fWJxo973ONaHtOItVhUB0eMwcqQRePYTL48J/+fx4G18Wk+d9JnBPnIF+PtoRoLGkJcR/spg6LxOJGNFo3ZcCsaQ20GYRxFM+YfihdbTTArr+n6vxSsIx+ImfiNYZnIUBFpVtG4FJy68tr1PZbHLO1GeGTH12zxF+WpCXBDROPSWhVrbGbt+v7yDU4e8qx3FtSwwB0SyqVZ04rGOPgPFhxrvnuG5GOWc8qdYGv+uTITNrDoExkRnqM8CKy1By8dvTinqxORZ0yxqsb6APcjfX/4zIq4a1YI+QXDy6nW/jJLLB4iPo6IUZNC3kiNpS6T7lE65znuvMkjLxpeQPE7riv6yh6/5+dWXqVAhzBbDdNxHxKwpIl84IaiDKUw2+d6guuxAP72t7898s3FvYyYf+SRR44s5xG9s4uTromFcMtD3rosBPLu0MRDGw9Ok47ZncZOljyVrPx/dwgoGu8OZ1ORgAQkAAFF43OM3KlhWcz4obbKLreURYvG9PX6+uvkh3OYmI8+Xrn6bKeiMWmUG2GRFsZQiE1sijdpL5zMjM9ZNK65YyzPz2IQBiCLCowVGDNjcMC4JouIwRY/0rOELKpiaDKkXhl7ZLG+TzRmvLKTQJ8eX7tYlmPkxsaG2SgJBl0uE3L5dtM9BeVlHJLHRTV3dBj0RB0ybmTcnwPjtXwPMc7s0yLi9+xGpNwnpxSN8xgxpx+fyQergSOvceSe4ZmEQD7EQp74+kTj293udm06XRbkka98fNGLXtRehxBfagRZNB5yf+f4usaKOf2uz3nMQNsdGrKBE7xLy21F43GSGysaY9UbNxxHZh5wLj/pL/vu4ZohVozjOMf/Q/DJ1ss5P3zmhsOimSXnk2aSZhWNJ1lWj+f0fx3kMxuK70huuLIDWeY9/q+JdkNEY/zVRhw7OSJYRcibBzz84Q+Pr3uP2Q/ytKJx6S4gi9i9Ce/whLxsjBcXD7cyZJ/VQ14M+cFbW8JD/Oz6GnXWdY9klx1x7rTH/fffvyxOkwXVIVYK+FvO6dY2wsyJ5GdAHy8s+SNuBPn88ixdpcR50x5zJyRb2RNPn1sOykVHMHfSa/6A80TMpJc2bZsXPMvBJj3XyjLe+c53zohHn+k0500IaMu1kIX3Mt6h/7OJnmG9COTnEPWsT+P1qj9zKwEJrBeBss+/7hv+5I3w6J9hXdj1xybijJcmGQmUtblo0Rgrw6Eh91tLoWYeojEbbOdl5LW+F/lltSdiO/3OrpD7o69//eu7Tmu/X4RoTF+d1a0YKyCesVlXrUzld7OKxvjJjrgYPw0NeWzaJxrXrD4npUNZGMNgDYqrx9wfj7yWx1UUjSkjm5BHXmurxPOzgM3fylCujI24pj0ygZJDFo2HTgJhrJdXm9byQH3h4uRzn/vc2Lgzp90nGue2VeY7x1N+ftvb3tayJm+lW9MsGmejpzKe+D/f35PGn3F+1zHrP4wfhgYMkTLjcrJQ0Xic5MaKxtlVQW4Q03xmxmfSy28cZf0/OiM8sPDZOSltOmxYrdbCrKJxbWfWWvw8BLI1Yi2fPPC4KbHay7/PKhpn37U5vmk/505HdkrPTOHQkJfvTysa81DMed5pexmaZ87L7g8QU8tQvjS6NqzL12Wxl032yoD1fS4vzvhrIb848vnTfC5FYR7eeVZ3iG/dbPGMgD6pfkqXKX2W+vhzivKU1qxs7hG/7eSYJ0Vy578UqWt1wHf4Es7psxFFGbLPZzpftUDafUIxnU7uQTplWKFEuqxUKANWwvE7x9oyTPx55XNm/TzUX3qZR/9fHgFF4+WxN2UJSGD7CGyyaLwTMaKrJSxaNGa8NTQgIkX/qJxgzf3GmhVoudqyawk9E/0YDdz4xjdu04o0yyMGJ1iA1kIWjYe4rcui0jwsjTGOyhtul3nnf6yBEWExeMi/zyoaZ3+6CIJDQ67XPtF4yH46pMvEyBFHHDHaVyeXrfyM5TIuAmkz8duqisZYF0ceGYdkIzzGrNmNYG01MGO9uH4nx3JfoSwa11wfdLUDxj6Mv5mI6csPq0dLy2niLcf/eexXCqGT9vkp88im5jlP5QrnPPYfMkbP9/dOntP77LNPm6+h7kUoWznuRw/LoWS17pOpuWyzfN5I0ZhKzrMouYFP+3mor90++DwE2JkRH1nZt07ODw82Nporw6yiMRsB9oV3vOMdVTGIFwYvIZbqIFzFQykv8yDvs4rGL3nJS9obnM3MeGjN8oeLhggHHXRQG2eX+BXn5mNeSj+taFxasnZtCpfTm9dn/MBG+6kJY3nZBW0La4FJgd+zMFg+PLkWPpEmwmCtjdGxinM48vJDRJ32r5zxyzOCLNsawjpPctRcM2Qe3AuRbzhM2oSA6/JES7nJZvYlzY6505Y9zs9LZR7zmMe0+euyAs/l4XO2+qezXrOk4UUd5a5Zjr/whS9sf+c83I0wEUbHExcZdMIYIISldd7Vl/Nr1t15E4baEifyXvobx5d2cJnmWHZqSkb+v3oEFI1Xr07MkQQksLkEFI2nq9tSNM5jka6YWD0XfS1cb5UBYTB+Z5PloSELJrgKyGFeonGOEz/Kxx577GhVah4zRN450q/EL28ZlikaIw5mNwSRX/qgjB/pt9N/jbFS6Yt4VtE4WxoP3W8HbtmgqU80rq3oK9nTR0eDiHLn49WudrXmkEMOaeib46Yi+vPZZd+qisZMaDDOivJkFy3Z5SFjtihXZoOgGtdypB3MokeUe65k0Zjn6yyBcRCWwGzOl/OYPzORU07STBKNycclLnGJNj42iBwaytXV+HXOYVmicZ7MqlmT5zzmz2wAmFmWdahonGk1zUaKxqXzelwh4EtmyF8WWWhI+ISdd0C44eXF8nfE2dxgWWZUPtQWJRrzQs8W0OzuikCUXxhl2UsBqSaslQxr/puy+Ej5d+I/OvKYHbsPnc1lp+HMf1rRuHSDMmQH0sjvTo48yHLd4VO2DE996lPbsuFSoC+ULhXKlwHX47c2eGFVWgvlUh9mJucRsr9lZuD7AvdRfjHWXDPkOLL1O5YIkwJiebamLa24sxX4DW5wg0lRDf5tiEVwGdnhhx/e1ldt+RrCe9QnR/wb58Dyp/w7rmv6fGrlXZ8ZUORZ/4g7W150CeCl+Dxk85CI3+N6E1A0Xu/6M/cSkMB6EVA0nq6+StH405/+dG8E2Y1En2g81Ect48ncF2X8m8MiROMcP2M3+ub4XC0FWXzjlmFZojGr7jBQiv4sq2dh8/nPf75zBWIWHLmuFObKsnX9n60pYcT4rS8wfskuI+YhGue2QHkQUTEOmrSPSbZ2vutd71rN9jJ9GkeG8ng3r/y82c1u1tZ5zSiG61mVHe2CIwZX8wjzEI1zPpiswdo/u2KIfHMP5tAnGuOPPK6dxp1DqQGVhkjLEo1xSxLlweXM0IAxZ1zHsZzoUjQeJ7mRonHe/AtH7jVr2HEM4/8hsEUjQvQY4jt0PIaf/9f3cuCGyxaEpMtLLIdFicbZATnpdrnHyHnJG1NxTU3sHSIaf/GLX2wZEw/XDAmloJ6vyS94Hlxw6wvlbqXTisa0rdxhq1nn1vLA7O0d73jHBt/L5GHaQAcVbvEHzzJkR/eIdH0hv/ixXKgFrM8jzS7L3VKIxxfvkIC4jFUqD+3aZARLfyJtNpPsC0wSxfkc+wT9vNlHrUOf0ysFzdLq+aijjmrTxpXEkEB7pbOC5S4v/HKyJQutNQG4TAPRP7vzqDHLlhS041LgzW2CcpR5KtPk/swbZnYJ5nwfdVNzg0K8PAfjHI5Dnk9ch0sgxG8sf2KFRJlP/19tAorGq10/5k4CEtgsAorG09Vn2b8sJ9zL2OiL5I3Nan3MbGlMn4fNj/tCOZbC6CeHLBTuxD0Ffbu+/t83vvGNkYuy6Ldd+9rXzlkZfV6WaHzccceN9SfZjL4v0GeOsnCcVQvI/WziGWKVjkCd056HaJytMTH66bOcps6z0N5l4JHHCbU2FpxLi95y3BTnzXLMxkpMCFA2DE2CIVrOpD2H8ur00i/4pPxM0iRmFY25zya5UiQ/TFrlPV/QFHLoE40xWgw2t771rfOlEz8/4hGPaK+rjW2XJRrnMXfN+LKrUKxgDQ48n0u3rorG4+Q2TjTGKXee7Rwilo0jaUbO4aMRcSyXnpfnl//zoGAZEg+hITMeNNIsPJb+ZRCWc35qLw/ygFiSz6u5Dsh5ZdYwzmcZzJCQZ6e4tmZ1yMs44uVYE855KPJgj/NKX0BdecGHMUuJrne9642WyOeXAJ2lzBEn/30hTzCQl2lFY+LPy/uHbLpFG82dx1lE4/wywiKhfHHxf354Y23fF+5zn/u09cGmF7WQX1IsT6uFsqNR82lbXkc7yp2TctaU87O/5ezLuowr/md322hfWNGXM6JxHkfynHcK7nPgnzviNT9ruJmJtDkipPeF7NKCOi3vX5YQRZxDljoxIRHnc6wx49kW59Q6+Pg0i9/7NgakfNmFCNfVNqVg8JSf0Sx3qoXSzUnNdU95Henn5ZJ01g3rR0DReP3qzBxLQALrS0DReLq6w3VY9I044t5sUigtk4eIxrV+cJkGbsIiHwiypbFM7qvWBD36Y3E9x2zAQ784Nkqjf97XLyZvjF9zfGU/dlmicd4sDcMGytYXDjjggLGy1Pbe6IuD32Gcxze4q+gL5X45tXF/NuLqc09BfzqPj9lIrS9g2ZrrsrZ3DnEMFY0/9alPjcVXbqLWl5++3/fdd982fja9zIIgY5lJYb/99muvvc51rlPVLcrrEf/32muvBlcyGIGVE0d5nN43ZsPam9WkpM14tYyrTJv/895duOfIoU80zmxoF6WxYo4rPjOOze5VeTaUIesOu+nTuHSdip/rvoAOlf1G037KoGg8TmTjRON8I/CwK/2TjBe//h+dAW7aeFiygVZN+Kxf3YyW6sS1+JLtm03jwRnncyxnikkn34gnnXRSNelpRePsE5clHH0BES6/dMhracpPHOUmV10vhkc+8pFtuRFRaw7qc57oDLE5YbDCIrx88Wd/TdRbOWuU48NnbsQVx1lE4yz2wafGJKebZ8SYWOibUczXxufcWcBCtgzkIcrEkTrpC5ktvqzLULoyqPmqjWvwfRXps1vwJGt/fuOFG+czS1iej4+xLDTiFqQvPOEJT2jj7GvfpbVG31LD7CqCz2XghZ0nBmo88zV0pvIzp9ahK31JTfLVSwcg84Jt7bmS/YDXLMdzJ6zcYCXnn89YmeQXMGnWJtw+85nPtPXCOZPul7y0DJcz5f2e88DgJFtSsKxu0vn5Wj+vFgFF49WqD3MjAQlsNgFF4+nql357Hg8deuihnRFwLhs7Rx+X4xDRGEOJ8K9bi5w+eXZhgIBchp2IxsSFdWnkGxcUfX2ql73sZe35CGBlWJZofJvb3KbNV9cKuJxXVv1lAwQYTOpz52trn7NRDnU2ySUE458rXOEKbX5Je6eicba6Jb4uo5/IO4JaHudwTZdbwKGicSlk1sYkkf4sxzxhQd5ZkUm++UNUnBRw8RjncmTfpb6Q6xR3kaX7kmlEY+4rDJAiD33jLfKWLeHvcY97jGW3ZJ03wuNEDO7YnybS6/JXnSPNRkZcV5soy1rVborGTMygNUR5uMf7tBX25InzOeJGpgyKxuNENko05qbLjuOHziaOI/nf//LDgMbU98DJcSA65xcjs5WTROds7l+bCSbuvOlW19KJaUXjnC5Wv8yEd4W3v/3te4hQcKmJayypyjdi126TnJd9zuKIv+ulzAssO+Qn/prlJOJfFssQsWrlQgDPM7+R31lEYx5W+WHPi4oHdi2cfvrpYzu5ImzOEvLuv/jiLQMbAUSZ6KDAb1IYshSqdMnA8ryuUM768bKpdTYR+rJgjNBau9eyGxFeSn0vA/I1jeDJrHTw4uU/6X4l7mxdTqe8FnInlTx3iaPMKOeXN7PWtWVjTL7kNotlMG2vDLjhuNSlLtWWh3IRf8mM+mB5UZSb5XtlyJ0S2njXJAwdEPIdccWxdo9m1pxXK0PkIw9AOJdOWC3QAUdUjnR5nrGBp2E9CSgar2e9mWsJSGA9CSgaT19vpSVql8uDxz/+8W3fJPooQ0RjzsUopLQeJqf0eVhWHvHR56v1G3cqGpfCyqS9QRjTXfWqV23zVBub5LHxm9/85l7o2R9wbVVfbwT/d0KuA8aItbFrxIWVYl4JG4zLzbnj/CFHDF1y2Rkf1Nw7UtcYcESacdypaEx/P1uJ4he3a5zDWAEr0kg7jl0rkoeKxoxD80TLkPofwjbOYTwZY6S85w86Q2mIFNfEET75fiKeSb6NSwNF+qxlmEY05tq8YSKcstV/GTdW77k+2Rw8hz7RmHNzvVHHjNO7tAIE4GzYxGrvGtNlicaUB50q2ipHVsd2jS/ZVyzvKYaRYSn6E6eicW5VG7YRXmk52iWujiOo/1e6WOjy5VO/umnyplo0XgQVBBQsABFeENxotFkwi5u2Fmf2T8vsJ75luSEQVSJMKxqTfr7BmNnEijlmtlmaQp5JJ152WZDl2pprBR6++YHNg41Z9gc+8IFNKSCz/CrngRc17HhB8kKFEz5xsw9UzmcpTtcLL3eSOJc4cavBRnlYAyC2RZrxgon/a0samF2P37GOrgVefnEOR9w44B7jjDPOGPkl+/jHPz56IWB5Hucxa9v1QKulEd/h7zfPgNdm+/JGbLUlFxFXHHNbQLitdT7zLC5lwKqb66ifUuyn01F2qJmIQcijY4m1KfWURUvirAmX5JFZ3+A2xOULL75sgVG+UKPcccybt9FWJgU665EXjojptUCnNNf33nvv3eB3G/EYAZhnTDmTj5V1zeVLxJ83IiRt6pZOPRNVMH3e8543Wi7Fb3nTFTawKwMbg+RylDPRnH/qqaeOnUN6lIv6xd0Hgjc+iUNEL58PNWv0bGlP+vh0p3OEmFz6eqNTkidIOJ/JLp71tCPy/PSnP72BbZSFzlZt4qEsv/+vLgFF49WtG3MmAQlsHgFF4+nrtDSOoB9y3/vet8EohfEYm3PljcSyi7U+0Tj38emTItZiFIN15vHHH9/2uaLf86pXvapagDweqhklMQaJODiWQhXjDQSifA5WiYzlsF5lrIBhDu4Uoh/IueS/HBeQwRhLcs4Q0XBeojF90VwGlvPT54z9U/BXjLENfY8Yv+Y64NqacFuF3vElKwhzHuBFXVKnjLdpN9n4Ifena2nnFad97inIEmPwnD46AnXEeIk/xquIodngJeehS7TP4mOtjWUcl73sZds84NoBC9lDDjlktCFfPm/WzzXBnfHwkMCK3LLOGeciRjIuYzUl47a73e1ubRngiYEiv5VhWtEYoTf7VoY9rjvZz4U9amLszDgvG9zBkd9yGCIaM4bLBomUhbp/4xvf2CBKEwfCed5kjnPYK+fMM8/MybWflykaoz2VmhrPLrQLNnVn3I1hIGPOvBKYzzyva0HReJzKRlkalwPNLsu+cQT1/xBF8guQG2Uaf0ZcX/rLJY5Jf5OEUATw2rXZx9C0ojElz9bGOf5848f3uLPgxssbXbGTZi0gUsV1+Vj6coITL5x4Sedzuz5T5hC2a2nzHUv5s2hYiwshurSerbkzGSIa87Cic5Nn4mppxnd00BHtZgm8QCIejtmvc8SXd1cdYs387Gc/u42TCY5aQPDN6ebPNbGdl2y2Osjnl5/pSNIOugK+ouOaro3T8rWli5Q+dxbZVzeTC5NC3tQCgZLZ7a5Ap6HshEQ5yiOz+H3LtdioDov88tr8Py9AhNnsnqO2bBGxP66Df5fPZyaN4rw4cr+WEy50Nhg85JcxS77KQMc44imPtUEGz5zckSqvyf/TeeqbICjz4/+rR6B8lw9Zqrd6pTBHEpCABNaDgKLx9PWEoHDggQd29mdy3wShBzEmvusTjRGYcWsW53cdEZYQ+hiD1MJORWPiRNDM+5l05SV/37WPyrJEY8qRrY1zXmvjXcRbDCSyqDZkf5ZaHcR3jHef+MQn9tYpeaO95EmGeYjGGJfkVbHBAOOWcrzMuAVe2YCOvj1CYhmmEY3LFcORh4c97GFltDP9XxunYlAzNDCWxeo08tV3ZGzypS99qRr9tKIxkeCmc6iOQN64n2ptY4hoTHoY5mUL677yIvpPWsWZ76XddE8RFYCxYWmMNalMrMLt2leHOBWNg+z/HjdGNEZMQTCIxoGLgJ2G0qpviPiW00TYRFTtEzwwkUdw7LKcJU5eNsxgR/niyOZd0VmYRTRmKQwCUykARfwceQgwi0weCDzc43f8CtcCs16lhSDXMENXC4h6WeiM+PORTu2LXvSiXsE44udFwQwZImgIWRwR53gZUj+IVDkNBKoyDBGN4xosyWGS48yf6eAx68nLe9YAg4gTa9IyIP5lER6Rri/kDc9qzu25nnaGoBosIw8cu/xz4TifOpgknLIhIxYUk0IWSpn17Qt0WCN/tN9ou7XruO+YOY3zsT6YFJ71rGe157IDcV/AwiHnP9KJI9Yp1GmX2IT/ZQAAIABJREFUaFvGj2VH6R8v4sKq/21ve9voktwRqFne5s7rpOcl98mTnvSkzjok/3SO4jmU/UrVfBpj0ZAnASLvtNmuZyATI7mNxjX5SLutzfaX/Px/9QkoGq9+HZlDCUhgcwgoGs9Wl/QtEfi6+rj0a2JDu2lFY3JE3yov6c99Hvr/H/3oRydmfB6iMQkgjGFAkFfP5bzEZ8Y/GLZ0hWWKxqxcY0PpvDIt8h1HRCRWBNJPJTDmid8QkKOf21W+Id9j+ZhXAkb8cYwVxPMWjckb9Zj3nIk085G9QXBzR4BD3iScCYoyTCMaY2RTG+uzEd08AvWTjZWG+K8u02V8jvVzZlJ+5r6mbUwac8wiGpMX9rjpMzpkHM4K+C6L36GiMenxDEODyrpBrbww6duja9micdQlukd2P1GWBy3m4IMP3mN1a1wfR0XjIPG/x40RjRGnmG2Jv2msgseR/Pw/HhwRH0dcDMwSWP5z8sknj2aDMYtnFgTLP5bmIJZN8xJiiQLuCI4++uiG5UiY2ocghlCb89slwNTKwIOPFxnLqe5973s3uGEgfjokCPI5sIwnpxPp53P4zPfUAyIcwvRrX/vaBp++XSHOhxWWr+TjsMMOG7kxQPTqsy7uipfvcQlC/dFOciitdmuuAZhtjvL2WawSNy9ZLC4pN7ubIvBhYY2rjz5xNOet6zMW9JGfeLHnc5kIiN851lxN5PP5TL3ENV2zpnENVrx0EnDpgCVETZCMc+PICwwXE7Qr2j9c4FGzLI1r4sj9wYRI5G+SZW9cA+c4f8gGi3Euxz5eTAzE+UNnsCkD4jGuFBA3+aPz+q53vavq1yzK0XUkPqzimZRi+RRCNq5i8j3P/5HPmi9i6jF+r02WlGlTbjbPYNKIZW58Jo1Y3hfn4zIi4p1kOU2be8ELXjBqRxxr1uoRZxxpmwyCyAO7YePKhvtsyH0ZcXhcfQKKxqtfR+ZQAhLYHAKbJhrTt4x+SM2N3rxrDjGF/hx9MSbF6acwfsp+P5n8jjzVxJ48hsv9VnxtMu6j30zfEVGR33PcXeXBhUSkWfPJy3glfudY8+uZ48bqGJdojNGwlqas9GVxV9F3LfHQD470ujZJz+kxJovz51WP1BXjXVYt4jaPFbe4/6BPXfaVGXNH+hxzHzvnc9rPGImgAcSYG02AOs5+jqnjSLt0P0B6tKH4fehYJPJJ/xuhEE2CvjQsENro54dgHufmPj3jhjLQJiIftTZWns/4hb48qx3RBjDymWS9Wl7f93/mspMV54xbccGIUI5gyrgHY0LcmEwSiyN/XB9cJk2kxPnlER0B9yWsNCdt/qgz4uobB5c6QNmuy7T4n7EvcTNpwhgLDYZnDvUz1NANl4VR5iGMFnF/R9kYm3IPMWkX7RzjT9xgDskb8aBLRXk4DnnGRfqbeNwY0XgTK8cyTUeAh2QpYPXFQCcvZqCYzZ/2+r74/V0CEpCABKYjoGg8HS/PloAEJLATApsmGu+EhddKQAISkIAEJDBOQNF4nIf/rTEBZhQRgPfZZ58Gn8pDZoTy0qNJS/TXGItZl4AEJLBWBBSN16q6zKwEJLDmBBSN17wCzb4EJCABCUhggQQUjRcI16h3lwDLCLJf6/Aj1pULXGfk83EdYJCABCQggeUSUDReLn9Tl4AEtouAovF21bellYAEJCABCUxDQNF4Glqeu/IEDjrooNbdBJv7nXTSSa3P58g8/pROPfXUsY0IcN5e82cc13iUgAQkIIHdIaBovDucTUUCEpAABBSNbQcSkIAEJCABCXQRUDTuIuP3a0mATfrKzu8Vr3jF5k53ulPzoAc9aHTMO6vizoJdSNmQwCABCUhAAssnoGi8/DowBxKQwPYQKPvNbGxmkIAEJCABCUhAAhBQNLYdbBwBdiy+0pWu1Focx0Z3tSMdZXbENEhAAhKQwGoQUDRejXowFxKQwHYQUDTejnq2lBKQgAQkIIFZCCgaz0LNa1aewE9/+tPmDW94Q7Pvvvs2l7nMZcYE5L333nv0PT6Pv/e97618WcygBCQggW0ioGi8TbVtWSUggWUTUDRedg2YvgQkIAEJSGB1CSgar27dmLM5EvjRj37UfPnLX27OPvvsOcZqVBKQgAQkMG8CisbzJmp8EpCABLoJKBp3s/EXCUhAAhKQwLYTUDTe9hZg+SUgAQlIQAIrREDReIUqw6xIQAIbT0DReOOr2AJKQAISkIAEZiagaDwzOi+UgAQkIAEJSGDeBBSN503U+CQgAQl0E1A07mbjLxKQgAQkIIFtJ6BovO0twPJLQAISkIAEVoiAovEKVYZZkYAENp6AovHGV7EFlIAEJCABCcxMQNF4RnRHHHFEc+UrX3n0d8ghh8wYy/hl+++/fxvn6173uvEf1+i/n/3sZ80ZZ5zRmeMXv/jFbTnvete7dp7nDxKQgAQksH0EFI23r84tsQQksDwCisbLYz+PlB/72Me246pHP/rR84hyKXE86UlPasvxsIc9bCl5WIVEzzrrrFXIhnlYMQLHHntse38cdNBBc8ndQx/60DbOww8/fC5xGslmElA0nrFeb3CDGzTnOMc5Rn9PecpTZozl55d997vfbeMj3o985CM//3GNPp1++unNDW94w+bII4/szPWd7nSntqwPechDOs/zBwlIQAIS2D4CisbbV+eWWAISWB4BRePlsZ9Hyve5z33acdW97nWveUS5lDgwwoqx9cEHH7yUPCwz0R//+MfNMccc09zkJjdZZjZMe0UJPPvZz27vj+te97pzyeXd7na3Ns4HPehBc4nTSDaTgKLxDPX6ox/9qDnPec7T3mQnn3zyDLGMX/Le9763je/c5z5388Mf/nD8hBX/DyYM9M95znOOynHKKadUc/w///M/zaUvfem2rK9+9aur5/mlBCQgAQlsJwFF4+2sd0stAQksh4Ci8XK4zytVReN5kVxePJ/61Keaa17zmqPx8a/8yq8sLyOmvLIEFI1Xtmq2ImOKxjNU82mnndaKnsyIfu1rX5shlvFLXvGKVzSXu9zlRn8HHHDA+I9r8N8HP/jBMSb/8R//Uc31N77xjbaclPezn/1s9Ty/lIAEJCCB7SSgaLyd9W6pJSCB5RBQNF4O93mlqmg8L5LLi+cP/uAP2nG0ovHy6mGVU1Y0XuXa2fy8KRrPUMcvfelL2wf7ZS5zmRli2LxLnv/857dMrnKVq2xeAS2RBCQgAQnsCgFF413BbCISkIAERgQUjde7ISgar3f9kXtF4/Wvw0WXQNF40YSNfxIBReNJdDp+u9/97tcKpG7k9r+Q7nGPe7RM7n3ve3eQ82sJSEACEpDAZAKKxpP5+KsEJCCBeRJQNJ4nzd2PS9F495nPO0VF43kT3bz4FI03r07XqUSKxjPU1tWvfvVWIH3Oc54zQwybd8kVrnCFlsmLXvSizSugJZKABCQggV0hoGi8K5hNRAISkMCIgKLxejcEReP1rj9yr2i8/nW46BIoGi+asPFPIrA1ojEbsH3yk59s2HjtEY94RHPzm9+8udrVrtawa+Tv/d7vNX/1V381iVP721lnndWKo/gz/ou/+IvRbziwf+Yzn9nc4Q53GMX7m7/5m83znve85nvf+157bdcH8vXc5z539Ifri77wL//yL83Tn/705u53v3tznetcp7nGNa7RkB7pf/zjH++7vPr7Zz7zmeYJT3hCg+X0r/7qrzb4U2Ln2qc+9akN6dXCn/zJn4zyfOSRR44xYffNKE/Oz89+9rP2e37/x3/8xzbaP/qjP2p/g8fQ8Dd/8zftdbjI+MlPflK99N/+7d+ao48+usEi+vrXv35z1atedVRWyveBD3ygeo1fSkACEpDA7hNQNN595qYoAQlsL4FNFo0Z//3lX/7laKxwr3vdazS+ufGNb9w85CEPaV7+8pc3n//856eu+H/4h39oXve61zVPecpTRmMlxkyMnRhTPvGJT2z+8A//sPnWt741Vbzf//73R9cxniN/V7ziFZtb3vKWzQMe8IDmla98ZfNf//VfnfHVRGPKfeqpp47GhgcddNBo3PMbv/EbI3Hyox/9aPPjH/+4M76d/PCDH/ygOf7440fjrZvc5CajctziFrdo7n//+zfs38PG6V3hkEMOaceTjEEJlIPN4p/1rGc1d7rTnUbl4LcXvOAFDWPAacoBw3e9610jBvQz9t133+ZKV7rS6HjooYeO2sj73ve+ruy13x977LHt2PPss88eff/P//zPo/p74AMfOBqX3+AGNxgxeM1rXjOx7qhbxsQHHnhgW/ZLXepSbfz89u1vf7tNu/zwla98pWEM/ZjHPKa59a1v3fzyL//yaHz7jGc8ozn55JM7x8U5njwGjz2J3vGOdzT3ve99m2tf+9rN4x//+Oav//qvG8bxOw0f+tCHRm3ynve85yhudAzSOeaYY0ZaDPU9Kfz3f/93ywahPQL5przcf9w33JO//du/Parrz33uc3HaXI+0vXe/+93NC1/4wob2tN9++43a061udasGLQTdgWdPX5mGZqomGsODcqPhcJ9d61rXariPaFc8p/oCzyz0LP7Ic1/44Q9/2NCmaW+3u93tmitf+cqjdvfoRz96dN/THqcNH/vYx5qHPvShzf777z+K77a3ve1If+JepXwE9LbQlk4//fRpk/D8ORDYCtH4u9/9bsPDKW6KriMv5u985zsTsfLiytf/+7//e4O18bnPfe6x7+McHt59Iig3XpzPC6wrsIkcrh+60iKOc53rXKMH5qSXco6fjeh4CUf6teOFLnShBkE2blyu5wF4yUtecuJ1xHXKKae0yfHQzvF/4QtfaH+7y13u0v52xBFHtN9P+sDLn4dVxMkDpwyI/Hz/C7/wC+15cX4+0lngXIMEJCABCSyXgKLxcvmbugQksF0ENlU0/td//deRMU/u75efz3Oe84zGcUMEMUSipz3taRPHYRH/xS52sZGw3CcY8TtiyC/+4i9OHKf80i/9UvOmN72p2jBL0RghE4E88lI7IgbOIphXM/B/40KE3L322mtiupe//OWb17/+9dVoStEYARpBsZb/+A5xcIgoeMYZZ4wEtbhu0hFR+utf/3o1j3x56Utfus0T5yHOM1buivOyl71s8853vrMaXx7Hdl2fx8sRCe0GQ7hJ6RLfjW50o+bv//7v47Lq8brXvW6bd879sz/7s/b/nCeM7mYNiOpwzfHVPiNifvOb3+xM5qc//WkbB2UnYLiX66SM97znPW+DUV7fvdiZaOUH0kTwLtOq/Y/G8bWvfa0Sy3RflaIx9zkGhLU0+Y5nG6u/J5V7qGhMHLQLnkNd6fE9dXLcccdNTDNKTT0fcMABE+PDmJEJtYc97GHteWhSht0nsPGi8Yc//OEmu06Ihs4DkhmNi1zkIm0j5Dce7JMeVswaRRwXvehFR7OT8f+FL3zh0UwzN2l8x/H85z9/8+Uvf7mzdrF6jvOZzasFXohlOc53vvONrGYpx8UvfvE2DuLiJdFldRvxM9tXvtzPec5zjtKpdV5e/OIXx6Wj8kSeJx2zCM9MZpwL9/wQe/KTn9z+xgNwSGBmL+Lbe++995jVZ7aLGbc4hyN1w3fMYrGJYf6N2WYeTAYJSEACElgeAUXj5bE3ZQlIYPsIbKJo/La3va1BuM39fD7vs88+1e+x0psk7GC1l8W1iJfxFwZCXeLdJIEDAx+sfyOuOGIc1BUnwk0Zsmh805vedGTpGnFx7DI2Yhw0yYq1TKfrf4x4fuu3fmuPcmDIRDlqY0pWq5Yhi8aMY7HeHlIOLHNZUdoVWIlbMmAMzbj6cpe7XMPYN6fDZ+4JrCprIQuUiJGIknE9eWFcXrY90sc6vQyziMaMrbOxVaR9gQtcoGEz+rI8fI/1d1fI7Zr7plZfpPH+97+/K4qJ37/lLW+pGm+ho5ScSId7CkvnWihF4w9+8IMNGkAw4FiWP3577GMfW4ty6u+OOuqokZ4Q8XKM9sSkSC39S1ziEk1YpU+d4P9dkEVjnmO53sgDGlap6/A9qxeYgKmFIaIxelKXOI2IXOpepIkYPOme/NKXvjR6NnBu/qM9lNocz4E73vGO7XmTnqm1MvrdfAhstGjMUgpeWNEYaYTMbuZGjPUsszD5gc9yhq5QmyVjlpO0whKXl8yTnvSkNl3SZ6a0FrgREZUjjyeeeOIep/3d3/1dgyAd5/BAYElGXpKDAPva17527GHBjG9XwB0HL5GIk5fjCSec0D5UKAsPYlx4xDmcHy4lSJvZVf5YDhPnUM74HsvoHPIsEUsacuBFGnFc85rXzD9VP9PJ4WUT15Rlxbogi8I8zHFDUj403/72t49ZTD/ucY+rpueXEpCABCSwOwQUjXeHs6lIQAISgMCmicYY6uSxFeMmXCOEIQtjpn/6p38arcyMcQRHBJSukMUV4ka4iPi4hjgRnVken1c3Mhbpci2Be4ucPuMfxmf/+Z//OcoGcb7nPe8ZE1dI+9Of/vRYNrNoHPEx7nnUox41snBl7INRDKtlSyEWN307DYiykS5Hxo6kFWMuyoE1bh5Tkr/swpA8ZNE44mN8joUrIiKiG3+Il6WVJ8vzawEL44iLI4LuRz7ykTHDpXBbUYpwWEzWQhaNI27Es9NOO62Nl3E0S+qzURfiWmndjRsTxs24k4i4cKEYY2mOCKU54EYgzuX467/+683f/u3ftu4jqGvaDS5O4jz0EFYX10IuN6I313D+bW5zm+bBD35wgxCKwB46Ry2Oru9wIZLvB+LFxSb3H+2Cvy9+8Ysj9yNZs0G4rk3iZNGY8+M+h9mf/umfjlxqolGQLm07C7jkI2tAXXme9D3uPIMpR1xSYIRHOSLQnuCPi5J87kte8pI4ZaZjFo1zvIjh4RaCFROscP+1X/u1sbRhXgv5udblngJXPjk9jOywnI8V2kx+wZuJt3xel55GO2JyK5/LvY9FPRz5/cwzz2zud7/7jZ0T5ysa12py8d9trGjMQyW/UOgQdT0swcyMZzRGjvigqQUenPk8/OZ0uYIohWPE3zKwvCHHx4MzB27+fGPhEqI8J5//1re+tY2PWW/E0zLwMMszm3zGzUYtkFYWl8uN/7i5mT2LMrzqVa+qRTP67oY3vGF7Hh2lHPJLnQ5C+YLM5/L5d3/3d9u4mMUuBXSWM0SeLnjBCzbE3xXwjRPnMhM8qZ10xeH3EpCABCQwHwKKxvPhaCwSkIAEhhDYNNGY/UuiX4/AN2m150knnTRmKVcb/2EVlwWtLjcRwRp/opE+R8ZmZUDkyxZ6d77znVuRtTyX/OexFkJeDqVojFBWs0jmGoRcLBIjf6S7k4C4gwAc8WER2LVq86tf/WoToiTn4+c4h5po/IY3vCGf0n7GQCsvlb/97W/f/pY/kEbkjXFol/Uw18Amx8n5tVCKxqxgLQ2l4jrG0fl89j7KAmOcN3QjPIT2LIQiNtfiI178/OJfN8qPCFw7N4vGnIu1J+4kInDNtD66uZbr2Eco0mfyZpK1MhMm2WoY16JlyKJxxIvP7q6JmcyV83EFs5PAvRfpwi0mRmpx0tay3oJLmJ2Emmj8x3/8x9Uo0aayoSPsw191vqBPNMb/eZSXI0Z/uH2tBQwhmeDJ59fqO68859wuFxq0H1a55/j4rGhco7/47zZWNH7Zy17WNjIsUsNCtgspDTOLs8yqlIHZvtxw6WTxXVfgpsoWwlgCl4HNEiJOZiPJRw7cSPE7YioWzZMC1yNkxzW15T/cbPE7M3R9vqCYKYrz8ZGVAy+V+I0jIngt8PDKnaOyA8VDN8dT898U8TI7mS3DWUqTQ+mLiWUxfSEvq2IDQ4MEJCABCSyHgKLxcribqgQksJ0ENkk0RnjK44lyjFCr4Sx0sHq0dO+H68CIE+GnHKuVcSJs5TEPvmfLwMZRESeia9em43FddsnHytkskpWicZ+ogsVjpI2F5k4CFr4RF2VGYJ8U8vgca9KwquaaUjTGDcCkgCVwpI3YWwbcTWZBe0hbwGf1pDhJI4vAnIsV9aRQCpc1H8P5HNpgLdDubnazm7X5w7Kzzxc3onUeM9fGxKVo3DcpUstb7Ts2MguWHBE9+8Lv//7vj11Tsi1FY3SMSW0OZrjsiHxwr8waMLALy2bie/Ob39wbVRZ6ec7uJOS4SB8XJZMChoPZyvvwww/f4/Q+0ZhJpWBHXEz8TAo8OzPva1zjGns8T2nfEScW0ZOep/yWJz64ru/5Nil//jY7gY0UjVl6kP2h4JZgSMg3I8JrGXjZRCPn2LVsJV+XXTfUlgZkk3+Wl+SA9Wxe1jLUAX22cC7LjnibheyaOJ7zwGfcVrBZHssEyhuVpSDBBIvksqMVcbFkJ87jWLOAzj6bcRvRFbIFAb6J88OGzyzvirR4GA4JuQNFp8UgAQlIQALLIaBovBzupioBCWwngU0SjfPGaV2WomUtY1gU4waOpfsHhBLcLbCasmaJXMbH/9nCEEEwB8YqecwzZHyHpSe+SVlyj6vFbM1bisaT9uYhH1lYx4I6C9A5n0M+Z5cTpQV07XqsHfHjzIpTXBPGEnfOLUXjPiGdJfG53kqrTyw9P/GJT4ysro855pjeVazkAcvNiBMtoRayaIxwm8ehtfMRxvPm8eVYmmuGiMblhvKloFpLm++y32yMpMqQRWOE/L7ylNd3/Y8GESwp/xCfvrDK7iUf/vCHj0VfisZDRGCs0CMf6BmzBjQUXD8gFmNgllc5d8WJpXykzcrnnYSsUxFn+ZyqxQ2/SB+3EmWYJBrTDrIOxSrvIYFJh0iTY17BXT5rea72BfYny/HV7p++OPx95wQ2UjTOoimzIn0vz8CYGzk3SRnyw49lQnl2tDw3/s9+h2p+jfODmtnNHLKrCW4WNmEYErL1Mh2MHPBBk2+8msuMfH7f5zzDzIZ+XYGNAiJdNh2ohezknJd7LeQOAh2d/CDifJbtRDocP/CBD9Si2eO7PBvKLK5BAhKQgASWQ0DReDncTVUCEthOApskGudVo11+bstaRhzJxkZDLAjLOOJ/xFxWhTLWifEIPn9zYMVk/MZxiAVsvr78nEVjytEn+mF9mtOfdSyIqJvj6XKJUea36/8sGuNisc+HLj5vc/pdq1270svfkxaCFj6pI04sp2shi8aMb4cEXChEvLioKMMQ0fjkk09u48B6uBTJyzjjf1wyRNr42S1D1iKud73rlT/P/H8WJEtXJJMizdoJLjVyKEXjUjvJ58bnhz70oW35sVrdjcA9yH1+xBFHtGlTB31telLesmiMa84hIRs81iaIch2VPo3Rz6LdcMRVxZDAJFR2oZKfCy9/+cvbOGnD1GdfgCXuNSIvisZ9xBbz+0aKxjxgomENsaQNtFi3xnU09nLJR56pYqnSkJCtYkuH4IjOeTfX0ro2zwwy68YLZchf7jxgiZtDHowzy73TsO+++7bMJu1Kmp2Zd1n/5uVfhx566B5Z46GRl+WwsV4Z8nIvZvTYIG8Is7xJH0spDBKQgAQksBwC+T3FO5nnukECEpCABBZDYJNEY/yxxlgOK1DGE0P+skUdS+T7AmMS/Nhi7YnVIe77sLrNYknkA7+zObDRePzGcSdiJ/HmcR+ieV9gtWdOH2vcWUK5ipT/dxKyaIwv3L6A1XIuxzSiFhuasZKWsStj2exLN+JkjF4LWTTG6GhIyONMNiMswxDRGIOqyBui+pB2zTlZF0F8o+3mkEXj0tgsnzftZ4TNyO+RRx45+PIsjpaGZqVo/JrXvKY33mz0d+Mb37j3/GlPQCTFiA3L+cc97nGjzfHyqu5gwHFeonG5Or0rz1hG5/TLjRgnicZYAedru/a/qqWdJ82ozwjZsJPn5dCAW6DIi6LxUGrzPW8jRePsZD/PbvShyw9jXgg58IDNHRFm+4aE7Ncl3zRcy+6tcQNwLJ3o500P8nnTfL73ve89ls28HOrAAw8c+23afxDVeWlFfro2KyDeq1/96u15XZ2x448/vj2Hjl4ZmPmPtHgY13ZAzS++OHfaI50HgwQkIAEJLIeAovFyuJuqBCSwnQQ2RTQuRcRp+/9xfpebOgQrVqUiwuUxYVzXdSxF4zye4ZraBlXTtMQsGmOs1BfmJRpnK0bKMWmfn7488XsWjdnQvC+U9T1JNMa6+pGPfORoPJoNtrrqjO+HiMY1/8S1fGdr39pq5iGicXZpOSnffb+VK7Dz2PnJT35yLftTf4dhXJ5AmaQRlJFnlw6UJbtiKUXjIaJ99lM9L9GYPZ0e85jHNBiaDW1PlGVeovEQlzZwRejN7aHUryaJxnkTOiZVysmGst7y/3l/rWw0icV55Kdr88ocT3zGf3Ncp2gcVHb3uHGiMT6folFxnGb2Nr+syuUb5VIilsT0BTbCy3kplzvlm3GfffYZi46Hbb521s880CIg8ubdf1mCs5PAzr85X12bDeKvKp/X5Q8s79BZvlDxG5T9g7EhRC2w6WFOa5bP85xlreXR7yQgAQlIoJvAuorGWC2xDHLS32GHHTZarsgqGHaQpgN/+umnd+4H0E1pvr+wzDjnu7bDPB31OGeIH7r55tDYZiXwoQ99qK23aay9Zk3P69aPwKaIxqXP11nGAFxTs+I744wzmite8YoTxxgISPj1xS8uG7NF+qVojEVi/MZxJz6FaW1ZNC43LK+1xnmJxieeeOJYOYb4rK3lJ77L4/CDDz44vu48DhGNEel47+bxb2bPZ6xvcRnB8zG7XRwiGqM7DAlZFEaAK0P+vWsjvLwpWVmGaf4vtZEsGj/nOc8pszbT/6UeU66mnhRpdsNBubKFaykav+c975kU1ei3eYrGtCcmHyYJxbSn293uds2znvWsBhE+1828ROOh/oXxw5zTL13hTBKNyX9ce9nLXraXcz4hr85n5XyE7HO+dD0S59SOOZ+KxjVCi/9u40Tj97///W0Dp6FP8wK70Y1u1F5bztS+8Y1vbH+/7946AAAgAElEQVTDVcSQUOYFkTWH/JIvX47MXMaNyhH/WFjWTvuX/R0xA5zjfO1rX5uzM/XnbBmMWNs1A1Uub0BMr4VSXP72t7/dnpZ3DWY5Q835PDORuXyI9NPy4vzvfe97bbp+kIAEJCCB3SWwrqIxGxTld9A0n1mNw4as+Z29m9TLPket78QGOlEmRA/DehB4y1ve0tZbzZfmepTCXC6SwKaIxuU4gOcUAum0f6XlL0YxeSMznoPsmYM1HcutEcTKa7KhS7kROmO6eJZyxGpxJyGPJ3dTNGbCM5dj6N47XWWdt2jMuDS7LYy8Iv7DDP+qbCaW3VHmjfAQmmshu6fAzcWQgBuMSJ/3fRmGiMaIlREHFrPTtus4v9y0fhGiMeJoXo0M66EhG9VRB1loXbZonH1eR12wipuV3ccee+zIWDG3p9JqOv82lEecl912DPUR/YUvfKFtM+S39F+exdjSp3Ge3KIeatpL5K085hXm2Z1oFqJZjT80YMwZvBWNh1Kb73kbJxpjuRONih1Ah4YzzzyzvY7rEYlzwEdNxIu4PCTg4yquwZk+sz05XPWqV21/Z9lKDviXims5lhu+5XOHfubFmOP82Mc+1nspHbD8sM4XMHMb8U1aYnD00Ue35/X5r8k+cGImFDE5WxC/4x3vyNloP5cO24fMPrYX+0ECEpCABFaCwDaKxvEuxR8l1nK7HRSNd5v47qWnaLx7rNc1pU0RjeGPYU88T7vc4U1bT3mpNUvuGbNNElCwHM6WrWyGlQPuCCOPHFkNMCRgTFMTnZYlGpOfXI6hK1C6yjFv0fiUU04Zy991rnOd3k3ly43LaryzaMym9UMCxmHBar/99tvjkiGicd5UHmvlrvH5HpH3fLEI0Zgks9CHjjI0ZM0Fl6M5LFM0Lo0BsQgvfQTnvPKZVQZR7xxLLag8f9L/WTQeOgHM6u5In2dXmf4k0RidKK7liAA9JDBZc4ELXKC9Nk+aZSNMNsKr3V+1NLLPeUXjGqHFf7dxojEP79zAy5nfLqSPetSj2uto6KWVDT52I94hJvo81LI/Y5Yr5VC6rnjf+96Xfx75hYr0OA5d1sGyEhy+v+IVr9hj4FkuFZnk+4nMMBPJ8ioEb9xnvPrVrx7LY34ZYGHVFe5+97u37FiWMCmwnCPKHUso8gOX37ssmnnw5OUixx133KSk2t+YGaSTwHGIkN5e6AcJSEACEpg7gU0QjbGy4B1W/v35n/9586pXvaqhE42lCCJxvPPiiIVal7unucP+vwgVjRdFdvnxKhovvw5WPQebJBojyMWztFw1OqkecD+BxS/jtxwwnsljiyGu/Ur3feVG4YxjshUm1q1DAoY3CC1sMHbSSSe1lyxLNCYD2aiHd9uQcK1rXWtUDsbJ+IiOMG/ROLuawDIcI6S+kEU02lFt9U8WjUujr1r81DeuS6JdHn744XucNkQ0LkVwXGcOCVgYYzjWVf5Fica5Xe6///5Dsjo654ADDmhZ3exmNxu7bpmi8VOe8pQ2X9yHQzSme97znu011P93vvOdsfJM808WjZkcGyK4Zqvty1/+8nskl9t7aWnMyutosxyH7hNG/zVfh+u2CDxn828f/vCH46fOIysY8jWKxp2oFvrDxonG5YuaWaG+gFVPnhF5wAMeMHYJD6j8Ow23FJXHLmia0UswGjiia7n0KM/8cF75IOdBkDsUQ3wMvfOd7xy7qdgxMwdeWhe5yEXac/KLOp8Xn3FfEWXgZZs3OGCGnXLF76W/5oiDIw+pOI/lt5MCPpjjXERcZqNjR1s6bX0WWFmoz8shutLk4ZWtAWBokIAEJCCB5RHYBNG4tplrF1E6xNkKiXcgO8dnP35d187r+yGiMe99LOj4K4WVeeXDeOZPQNF4/kw3LcZNEo2zEdD5z3/+hg3Q+gLWgjEWYKyRjWRKoe6DH/xgX3TN61//+nYsw/McX/BluMlNbtKeg6uBLoOYuK5cZs4zO0IW53bTPQXpZyvs613ver3l+PKXv9yWGzZ5Je28RWO4xpgSIbIvMPa+0pWu1F7DtbgtLEMWjXF1Ubp7KM8vx+ennXZaecrIcCny2rUq96tf/erY5nK43hgScv8C8boUGxclGh9zzDFjLHFn0hdK69ZSIFymaJwNCPfdd9++oowswbObBup3yJ5YXRFn0Zi4+jQu+my4zoh2lX0LRxqTRGPOyW52MBbse05xDeJzpIlWhJYTAet4Jo3i9yEW07j+iPM5lm0i4va4WAIbJxrTGHMD72uMiL959o8Z03JXUfwV5cbKZx6EXQGBmOUUcQ27nZbhqKOOan+v+Tbi/HyT4EuL2e6uQOcBC+hIE2f5tZCtmoi/K/Biyku8cEWRAz5xIi2OuPeohdKPcp91M7PUES8zxHmZ0JCdQvOsMp3FSQ9nZl5z3Q99GNbK6XcSkIAEJDAfAtsmGkONQVz2V8h7ENdOuxWGiMa7lRfTmS8BReP58tzE2DZJNGZTzwte8ILtWOLAAw+cKHTw7OWcGHtwbbYGRCSO3zj2rfxkzJitb7mm5n+UeHK8fS718gZS17zmNcea4TJF41JUj1WiYxlM/2RBCUOfLELNWzS+1a1u1TJGQJ4U0A9y+lE3X/nKV/a4LIvGnJcnGcqTaV9ZvP7/7J0FuCTVtbYhcEMCCRAmIX+wEIKEIIEAwQlOkAwzuDs3uMvg7hDcLcAM7kEHtyG4BXcGhwlOIML+n7eTVXfV7rI+3ee0nG89z0xVV21996463V+tWhsv8aywEniOW53MnzzjAYSl40FH7CAW57vzzjuT9OTbf//94yShv0RjdAuvJbDwWVbfrUGc828c095XXnnFTte27RSNl1pqqYQlzIqMee3HysasmbfIYtEYL+wsT3hrF29cW708DMsKpVEmGscxmS+55BIrPnOLHuTfzMhaVJQ37qxdbP1bE3GhN998c+pBCeklGseUBuZzz4nGYPMxdJlcJ510UuqPkqHlR5IXUUmbtTgcfww4x7855pijtsX7NUsA5YIkxo2l52aJABubv0jXX3/9+HTtc7yAHK84fPHFF6m03JS4oH74wx8mdRIXmCe5WcYrAtY2tvwxiQ0xlafFlm6KKaaoKw/PYjvPNq8+vjxYOp42xbF04rr94hCLL7548sUPD+kqXld4Ipu3APVyg/dPuKw+nnb6VZAnm2yyULSYAd7n3Jz5R5kyERABERCB/iEwGEVjSPIQ2/9gQrzg7/FAmETjgaDcnjokGreHezfV2kuiMdyJZWy/PdiyiGfWbwHemoiFna222io1dPEr2gsssEBuPGMEE+80ZG3ICpPB7zd/v+d3TtbbjghpfjFwyjzjjDNSbWynaExDVlxxxYQ3v4+vuuqqVPv4QD94g9SYsOX3uTcv2sYLxPt0tk94AF9e/Lvcv71Kuiy+lMVY4Jjky7J9/jbGFovGOCllLQ5LKEr/QIIy+c2eZbTd6mSb59FOn/ldbmlpy/XXX59VZOC3rn/DmHbGjnFk7C/RmLJj0REeWWEdeFCDw5v1i21WHOR2isbxInhZ85w+M598XGbfJ+9ZnzloBQdj0ZhyEeK//PLLulwIxv6NcJwSsszrUXF4CtLTF//whTfPTzvttExdDd3K3/9Im9VfymR9MM8FJ0E/L7h26K/XdCx9nmjMInum1bAldrysdQR6UjTGHZ8/6ja52A4dOjSMHDkysMAcgicXMzdPn4a4REzk2PwPWL582ytFPEnBi5jF9/gDvummm6YuULyDs57qUL5f8I3A9nnm/4DSVp4u85Tw4osvri3E4C9kzvOHJF4Z05dN//zrFcTk2WeffWqLMNxxxx2BC+773/9+woUfrVmv0bAKqmeHyMzNFAb+D51fTR5P3jKLvwBYHcTkqWrEdLZ8bHk1gzhEhOM4+uijw/LLL586T+iRspg6vCpsZTaywGLVNiudCIiACIjAfwj4v7ncd6u+gtlufv7vXSPhKXy7/YNT+s6P7CrGmgXk5fvITjvtVPt7zEPwMWPGpLzm8sqqIhrz/YkHzfzzD4oRtu0426qhKxBsfD7v3Re3E0Gd+vFyIR40wg7fQ/iRkuUJFufn83333ZfUZ6/n8h2NcnhLiR/e/FBpxOBrfagaX5Ly8TayfEWeYngR8TCctiGwIIJwPRDqizU8CLEFxyIrE43jcSjyXLJ6EMes/Xnfcy0tW757Mk6s38GaG/yA5bsn38voQ5U6fXmN7DPWjA3fcYkdy3dEvrsjLLIoD9dNFacEq5PfGLwWzJtx/NClLN4+xHuKBZzLwtdZOZ207TXRmDnN7yX73s4WJx4EYgQPhCzuI6zb4tMstNBCdc45jBOOIz4dbynyu48F7EaPHh249xOm4dvf/nYtHb8P8Si1PHmLhRNS0fJYWoQz3kbldx5zNHZuoi3xb9V2i8b8/Yh/UyMkE1qRfuDMBVvrI1vaHPfD/+ZthWiMYIVwZfUiovG3Ay9vwiAwhuuuu24qjKJ/A5V8WSEVYtHYyserEi2B8CSESfGhAUjDb+Q84/5o5diWOYsIF/8O985slhYxlt/w/I1EV/AhKUjDnMzzku9P0ZgxJp6xtZMt/WKtJ+6h9IXvfF4XIQ2iYtbftnaKxvyt8+FKmU+8iY2DHPOJvvBGAOtAWX/j8BT8vemredHYv11OGFAEXxwDuXd4j2jawf09729cmWhMW4mHHd+n0J/QVvgbSp0rr7xyncDL3/o8I9xOzIa28vYB4VmMH9uZZpopcSLkMw/RsgwnTJ/Pf0/NSq9jjRHoSdEYBPyIif9A+Ynk94kdzJfqPPNet4Q74KaR9wfDyuXmx0WWZbTN0rGNn4z6PHz59Be0zxfvI5RnPdHx5bHPH/esCzUuj9dj8l6XwivXv37g83qPXb4o2Tm+rFUx/5SKvLS1LF6UL5e0fIm3eou2s802W6lgTNkSjT1h7YuACIhA/xEYzKIxf7/4u2R/t/giXmSk54eX/2FseW3LDwY8YuIf6L7cKqIx3npWpveq4nVwO8626oKyiHiWjzbmCYeIk2XfWfjRkuVt4/vov8vx1lP82jltgSPiX1VDeLI+ZHkTZpXDOKy00kpJPkSs2EjD2hfxjyery2/xNMr7vkm5ZaIxPyZ9efEaHHHb+IzzguWBQZHxPRaB2NJnbeecc87C78JF5Red49XmWDzJqp/5h7hlDxPyyuQ68t8Hs8ri+m1GGMiruz+P03/fFx7GdLvhIRz/LfF9jPcRqfIeXPGafdk9yMpD5OV69AuzI6jSnixDOPainZWTtUWIzbrPtVs0pl84LPkF0rPab8cIHZl1v2+1aEy7EK6s3qItY4S4zUMhH3OVxdhj8xrAiBEjUn+z8+rYbbfdCkMzcO/xv5l9OWeffXbchHDDDTekwlL69PE+f9cQsvPMz78qayjllZN3nL+3LP6X5TUat5XPCPl5D9/aKRrTvyzBPqsPMEfkRfj21wUPGvtqXjTmwStze/zxxy+c3wj2RR63XmPK8jS2tnJ9x97BWf3mGM6HVRbNYz2v2JEvLpPvwKTzYn3W9UA7JRrbaPXPtmdFY3BxY+FpRN6Xbr4kcXP07vAxZm50/CHhaRJPjsxYuIYnivHk5kLhx0scRsLysfVfJCi3LGQDPx74UejDXvh6aRfeE0Vxgnz97POlA28kPI19WezTX27uZR43PM30i9xZXvMyot0IwPSRf3kXedw2npBZHrZ5rxPF+eLP/ADIu8HhBX7sscdWFqOJR2Vt4lUfmQiIgAiIQP8QiH/oDyZPY4jGryLn/S1GrF1ttdXq/obzerCP6Wl/4/mRkSeKNCMa02Yfb7NMRLRZ418dzsqDqMAPdmu/38YPlzmHeEo/8syLxni5+BBVvuw4hmJeeRzHS9jnreL1jNerz8M4euMH0s4775xKY+mz+m3nEBGyrJ2iMU4EWQ4cQ4YMyewfHrtZ3mVZ/So6xvdP3i70r2Ybp7y6Ob/DDjvkFotgbGX4rV9HxR/ntwDt6AbrRdHYuBNzd5555sl9sIbIj8BR9hvK7kdZ91aEGzyLeWvBHjwgEtvvR34/+Adt1jbbMucRH+PfVDaf+B1b9FsIscR+oyC4lRnOS5aeLW9xtMIQXPHk956W1ge2eBHyGzjvusD71NpV5SEcv98tPdvYI9f6xNuk9pawbw/7/L1EOPMLJvLmiZWLx3rcXi8aIyLyUIExoKy4fH7T5oWksPbZljnGQobxfR7BOcv4ew4zPHfjevmMcInHc9H6PpTL9WH9xbu9v4w3c/h7wHURt5drCF0Fr92Yt28PGoO1lS3Xd5nxPcLy4GDXrOHsR/iDuA98Zg7wtgDfMczwyLX6uU8U9c/yZG35m2Ll2PditI7YO552cA3ycNfuR1nlcYzF8axMHO6KDPboZvFikcaBv61oS1UePFs9tI/vKNz/WKySMniIwe8A3gjhvoxzhNXBNi8G8kYbbZT0hT7J09got2bb06KxIeLi5Ekur2Vwc+eLNReziZuWri9bxGO8UnglgNfSqnzZ5UupTf4qIRusXfQDT2L+4CLA4iVTJHhbvqItFyJsuDC5CHmSxB/9qkZaXp3kps2T9bwn6VXL6490jNGf//zncNZZZ9VejSSeU19v2P3RPpUpAiIgAiLwfwQGu2jM3yv7jsD2oYce+j84/93ju0YcnooHofzw5e8653kr6phjjkmVhVCb9fevWdGY8AnWZl6bzPKG851ACPfiS1aIhlgw5scx34H4Yc0PDX4Q8GPDCy14rHI+y7xojMBs7cUTlVdMERiHDx+eySerPI7xg8aPA98xy8zH9URsj+2II45I2saPfsJzIWSbgwH94zus9/alL6wDkfUDsV2iMSFTvBjJPt81EclpJ/3gezM/Mm0s2OIk0axxzfgy+THMMcQd5j/XCMIZr9bGjiVZCxXBm7GwMnnIwZhQDsb1hkAehzHIWyS62f61Or8fJ/rYC57GMSN+83Gf47cOAi7havDAy7ofxnn9Z5yCuA/xEIEQQLxZkXfP8fmq7vO7jrcwCDXEtlt/syBo8pYI/SCcS19YV2VWJR3jzBpDtAlHK0R4HvI1Ov7UFYvGVj/3Ne5plI9QXOUhouX1W2srfxeZD1XaSDp0AfQB+sa9x/5m+LI7YR9OXIuEC+VapN1F3rCd0Oa4DYwJYjxtZ7z53sZ3kipjFZfVis/vv/9+7Z6ERvT222+3osjCMvhbykMArm/uhczVKhpYYaE5J5nb9reXLW9hyQaewKAQjQcea36N/MDwP3D4siwTAREQAREQARH4D4HBLhojZvgvyFkCjl/UFs8MHxYqnkf8YPeeS1nhI5oVjRFSfIy9si/1Xsgk/nPs5Yfg7RkgzuT9GEO8W2yxxZL0eXGgvWhM2YQZ8F6+9AEhsVHjB6O1FQE5r52Uy49lH94gXsCIH2KeIz+qiwwPSaubbVb8Tc+a18Jj66/wFLyGa23jra+sRaFpC7wYX0vLfO7LOPh+4VVv5REarchJhDlAnZaeV9Rj89cbr5DnlcePZjwkrSw8p7vBBoNo3A3joDZ2B4E80bg7Wq9WikD7CPC3k+81fGcteivftzD+fuq9uH067fcvAYnG/cu3rvT4x2De64R1GXVABERABERABAYBgcEuGseCKaKfNzxKvLCIt2SZETfXhKws0Sv+Up4VTzAvprHV7T1fWYm+yLywhqeKNwRkfx4v4CIhlrw+TASvh3ox2MqOReOi9SQsT5UtHlLGli1vX+WZ94BlDGMPRcbSykIIL+s3IrQXPGMRmna0QzTmB6H1g23ea+OeE69RWx7Cc/TVGHsrh22VBQp5Ndby0I7Yttxyy+Q8i/cVGQ9M8Epm/HitvGwMi8oaqHMSjQeKtOrpBQISjXthFNWHdhDg76H/zoKHdpnxZo/9fWZxyW74m1rWp248L9F4gEfNh6YgnnDWD7MBbpKqEwEREAEREIGOITDYReNY9MLL0Rsiq32BRghFOCwzQkdZHrbxwmmtEI29UIholhc/OV4lPn4tlZBZvq1Z4QLi/vIjwgvNWSEOvGhMeIpWml98t8i71C8Il7XAEl7TiI54L/NqehXDe9h4sdZEbO0QjYkJam3adNNN4yZlfuaVf8vDltjOfTHmHQvREevxjDPOqPQDk/lidW+wwQZ11R544IHJeUKKFL32zfVoYSvqCurQAxKNO3Rg1KyOJCDRuCOHRY3qEgL+OwsL4cVvmvluEG/dxwrnzSFZewhINO5n7rfddlstli7eH6wK62OiETRfJgIiIAIiIAIi8H8EBrtozJdkE7DY3njjjf8HJ4Sw1157JedZYKWqLbPMMkm+eFGlVojGCLfE1bW25y1W4gW6LEHRx0dmEaKiHxS+7z5+M56jsXnR2BaRidP09TMhRKzftDlLNORVTC/OEfuyGYM3oSX8DzDE5tjaIRr7FdGLFgDzbUWI9d+R8bgfCGNc/NxhtfbYCPFi48uWa4l5Cv9eMD8v6V9WSJxe6Kf6IAKtICDRuBUUVcZgJcDaD/7v6UorrVR7G8nCPvHdhjURDj/88PCDH/wgSduK0FWDlXkr+i3RuBUUC8pggRV/Ydj+t771rVqQ+oKsOiUCIiACIiACg47AYBeN44Xw4njFq622WvK9Ag/XCy64oNI/wlLYd5CTTz45Na9aIRpToI/9usYaa6Tq4AMCsF91fPTo0XVpTj311KSdxDuu2j+EYOvfsGHD6sr1ojGLy7XSiGU7wwwzJPWzQExsLBhs7SP2cVUxnHJIS5xfFt1BdCdmL4v+WXm2ZRGk2AZaNMbTlkUFrU14V1cdQ1aWt3xZcyPuWyOf+SHKAow8lCHEBA9f/IMUq5cfsLERa5qV3S2N3zLXWGgZj3jq6EaTaNyNo6Y2t4uARON2kVe9vUCAv5M4Uvq/o+xPMMEEYeqppw6TTDJJ3bnvfe97dQ4UvcCim/og0bifR2vaaafNnPjXXHNNP9es4kVABERABESg+wgMdtH4lFNOSX1vePfdd5NB5Mv29NNPnzoff/Gu8jmOGdsq0RjvEF9/HFuYsBh2nn5kvea/6667JmksbaNb4gXHAp4Xja+88sqEaat2jjjiiKTdLAIXmw9hkeURHKd//vnnA4uyIb77GNZFLDpBNI5jPBe1t+gcQmyzRqgKWG+22WaZIntW/VmiMe0gXAahKbLy2LGFFlooHHvssbVFfuL512xf+jO/ROP+pKuye42ARONeG1H1Z6AJ8KCd70k+9IT9HY23888/f+D7kKy9BCQa9yN/PENYEZqLYtVVVw3Dhw+v/QDgx5lMBERABERABESgnsBgF41ZPMu+NPOF2scsZh0EO9fMlvi/3lolGlMmC9dZ22Lh7+CDD07OHXroob4Jyb5fcM/K6csW71BvXjQmbnCrzS9gOOWUU6YWuYvF9DiOs28LaTfZZJOEU1bf8cjF25jQD3gtW5pOEI1ZCNDa08z2oIMO8lga2ueaQbz1C+7EbeHaYq6deOKJwcdgzhONaQA/dHH6YGG8sh+7hxxySPj6668bane7Eks0bhd51duNBIiVztsq/CMGv0wERKBvBHgYy3XEQ3Xe/JllllnCfPPNF3iDZ/fdd689gO1bycrVagISjVtNVOWJgAiIgAiIgAj0mcBgFo3xTvTxYJdYYokUR85PM800iSiHFyUeGI3+e+2111LltlI09vFfF1tsscTjF8HNe0kjLmaZF/C23XbbhvtmLLzYTj39LRrHY+djUY8aNSoZM7xe8wyh24+/CZ0Iw6wgjmDJYnk+tMXQoUOTslshGr/88st5zUuO77jjjkmdtMtb7GmMQG9j0si2SFj39cX7jAOLERo72yK0M58Q2gn54r3c/eKSRaKxr4uxIvYvP2zzPMHXWmutYHEafd5O25do3GkjovaIgAiIgAiIQOcQkGjcOWOhloiACIiACIjAoCcwmEXju+++OyV2EaoiNr9WAvF/W2GtFI0Rh2eeeeakH7ag2R133JEcIz4s4l6W+ZjG9LVV1t+iMe28+OKLkz7icY3RzxVXXDE5XuTl7L3METuPOuqowsXWKNs/RCDecWyNxjTOE/N9uX7xvVg0jmMaD/Sian5RQhgSA5x4w15o931hnz6YuEzs70YNAZprlzjJfjwosxs8ESUaNzriSi8CIiACIiACg4eAROPBM9bqqQiIgAiIgAh0PIHBKhojtvpQA7xa/+GHH9aNF8KUCVy8Jl/VeA3wH//4R2byVorGVIDYaW004dsLoiNHjsxsBwdvuOGGJC8LquW1OS7g888/D19++WV8OPk8EKIxMXQnnnjiWvvZ4o2KV7exyIvjTCPxSJ1uuumStITvyBPWrVNx2Ivjjz/eTiXbMtEYbtY+tg888ECSN2snFoVj0Zg8K6ywQlIm4R+q2rhx41LhWKrm8+lYeM/6w6KL3qPYp/P7fnFJ4hJnGeNTxfuZON7+oQmvsne6STTu9BFS+0RABERABESgfQQkGrePvWoWAREQAREQARGICAxW0ZjX5k3sYssiaFlGSApLR+zct956KytZ6hjC4KyzzhommmiigJCGkOit1aIxYQisjUsuuWRNzDVhijZ88MEHvvrU/tNPP53kpYybbropdT7vAzF+ST/bbLOFPffcsy7ZQIjGVOpDN4wePbq2EJuxyIvjTL5nn3021e+HH364rg/xAQReK5vt4YcfHiepjbWlwUM4NoRpxsTS3HbbbXGS1Oc4/ESWaEzIBiuP+VYk5lvhJq4TK5iwLA8++KCdqrylL/PMM09SN2EqygwR3IeXYP54Yy4TMsRiGCNsl5l/QBIvOlmWtx3n7dq0MRto7/B29Fl1ioAIiIAIiIAIVCMg0bgaJ6USAREQAREQAREYAAKDTTRG0MUb00QphBu8VMeOHZtJG29W4rOawLP11luXeqQStsDSs+3PmMY0GvHOh2Tw9dPeIiPvxhtvnLR39tlnr3nsFuV5/PHHk/T078orr6xLPrhDR00AACAASURBVFCi8b333pu0BcHQcygK/RAvIFfm8YsXOuKqH9f99tuvrt9lnsZkmHPOOZNyNt1009z5hLct4+frzBKN44cQJ598cl27/AHG3IvtzO8qQrMvg33KYb5Y+/IevFg+QlbAzNKzRUD2hqey9wC/5JJL/OnMfWIZW5lXX311ZppOOijRuJNGQ20RAREQAREQgc4iING4s8ZDrREBERABERCBQU2gF0Tj+eefP3z22Wd1/z755JOaYIsX5bXXXhuI3+sFO4QmBGPi/xaZFwLJg4dpnsjGgmwmYLHNCmkRi3y0PbY111wzKQev6DK79NJLk/QWsoH6y/pGuSz25vOsu+664e23386skrR4UVsfERy/+OKLurQDJRoTTsPG1PeBlcERNfOM8bM+sEWczYvDS6iRrAXz8PCNzc+VLE9j0jN/fN3XXXddXEytLQcddFAqHXmyRGMy41VtZcKBkCTx4oSkg8lJJ52UpCVPIyEt4oZutdVWSVnMC0J4ZBn1HnHEEUlaayvbeJy8sEzYmKI4xXjG+7Lef//9rOo76phE444aDjVGBERABERABDqKgETjjhoONUYEREAEREAEBjeBXhCNvWjUyD7i2p133lk6ARDfVl555ZQ4xeJyiLl/+ctfaqEOeMUcgdjXT7zWLBGrP0Tjjz76KOU9TTtmmWWW8PXXX5f2jwTHHXdcqu14eyIuIjoTMuC+++4LhB8g7rH1EW/tvLAGAyUa03ZET2uTbYviOBuQESNGpPJtttlm4aGHHqoJn4QhId7z/vvvnwrB4PuV5cVdRTR++eWXU/XS5tVXX70WWoM6iRPsPXh32WWXJH2eaIywzXhb/9mut956AU/dxx57LOBZff3114dhw4al0vCAIO8BiHEq2hJew9fJnKceYg0TWoJ5w/gMHz48SecZkjeOg0xIDt9/0sDk9ttvDyz0SF/Y32mnnZIySYOA3Q0m0bgbRkltFAEREAEREIH2EJBo3B7uqlUEREAEREAERCCDwGAVjYnJ+8QTT2QQyT7EImsIdl4gK9pHGEM4y7L+EI2px4uLtO3oo4/Oqj7zGML4xRdfHIjbXNQvO4fgXhSP1wuDt9xyS2adrTr46quvptpcFsfZ6mVMETmtT0XbxRZbrCaQI4JaOhbaY0FFb1VEY9ITK9vHNrYy/RZRHtEeYd6O54nGlInYuskmmyRpLU/edujQoaWhSHzfsvbxEvaewXl1cZy5xYMWQsR44ZQHL7EhDONlXFSeP4foTrndYL7v9EExjbth1NRGERABERABERgYAhKNB4azahEBERABERABEahAYDCIxjPPPHNYaaWVAkLxKaecUmkxuzx0iIYIiF6w8vt4e5533nmFAlZ/icZjxoxJtQsP4Ubt9ddfDxtuuGGuoIlYTNiEsgUBB1I0po9rrLFG0nfGuarhoY0HNf3y42j700wzTTjttNMScRhh0sfDjj3Vq4rGtO/RRx8NCy+8cGa9CLrmxV1VNKZMQmwQY5oF5qwP8ZY6CYlBaI9WGA8crrnmmiRMSFwf4jhj4ucMny3dXnvtldkMRHBCWnjvdsvDlnIJG4I3NfGfu8UkGnfLSKmdIiACIiACIjDwBCQaDzxz1SgCIiACIiACIpBDoFtFY8Q7Fqkr+xe/+p6DoeHDxEsm1ipiGaEQ8AhFDK7yqj8Cl293HNOVxlC+palSJnkQDC0P26xyq3YUD9oXX3wx4CWMCE7sWDyzKbeKES7B2hJ741bJ32ga4ipbfVV5+To++OCD8PDDDyfjycMBRM6sOMe+b3FdzDdrB+nKjDGibuobNWpULdwJHtDeEHetzKretJTL4n0I05dddllNWL3nnnvCSy+91DKx2LeRfVjgITx69OiaRzFb5lDW+PvxKuPEecrFs51rjWuOMBUx+7g9nfpZonGnjozaJQIiIAIiIALtJyDRuP1joBaIgAiIgAiIgAj8l0C3isYaQBEQARHoRgISjbtx1NRmERABERABERgYAhKNB4azahEBERABERABEahAQKJxBUhKIgIiIAItIiDRuEUgVYwIiIAIiIAI9CABicY9OKjqkgiIgAiIgAh0KwGJxt06cmq3CIhANxKQaNyNo6Y2i4AIiIAIiMDAEJBoPDCcVYsIiIAIiIAIiEAFAhKNK0BSEhEQARFoEQGJxi0CqWJEQAREQAREoAcJSDTuwUFVl0RABERABESgWwlINO7WkVO7RUAEupGARONuHDW1WQREQAREQAQGhoBE44HhrFpEQAREQAREQAQqEJBoXAGSkoiACIhAiwhING4RSBUjAiIgAiIgAj1IQKJxDw6quiQCIiACIiAC3UpAonG3jpzaLQIi0I0EJBp346ipzSIgAiIgAiIwMAQkGg8MZ9UiAiIgAiIgAiJQgYBE4wqQlEQEREAEWkRAonGLQKoYERABERABEehBAhKNe3BQ1SUREAEREAER6FYCEo27deTUbhEQgW4kING4G0dNbRYBERABERCBgSEg0XhgOKsWERABERABERCBCgQkGleApCQiIAIi0CICEo1bBFLFiIAIiIAIiEAPEpBo3IODqi6JgAiIgAiIQLcSkGjcvyP373//O/zrX/9K/vVvbSpdBKoT8POS/di++eabZN5mnY/TV/ms6yEEicZVZorSiIAIiIAIiMDgJCDReHCOu3otAiIgAiIgAh1JQKJx/w7LVVddFcYbb7zav6WXXrp/K1PpItAAgSOPPDKZm7vuumtdzvvvvz85P+mkk9ad78uBc889NylzvfXW60sRXZ9HonHXD6E6IAIiIAIiIAL9RkCicb+hVcEiIAIiIAIiIAKNEpBo3CixxtJLNG6Ml1IPHAGJxgPH2tck0djT0L4IiIAIiIAIiIAnINHY09C+CIiACIiACIhAWwlINO5f/BKN+5evSu87AYnGfWfXTE6Jxs3QU14REAEREAER6G0CEo17e3zVOxEQAREQARHoKgISjft3uCQa9y9fld53AhdffHHYaKONav9OP/30uoIUnqIOSUsOSDRuCUYVIgIiIAIiIAI9SUCicU8OqzolAiIgAiIgAt1JQKJx/46bROP+5avS+4+AROP+YSvRuH+4qlQREAEREAER6AUCEo17YRTVBxEQAREQARHoEQISjft3ICUa9y9fld5/BCQa9w9bicb9w1WlioAIiIAIiEAvEJBo3AujqD6IgAiIgAiIQI8Q6BbR+J///GfLif/jH/9oaZn/+te/6srrRtH4m2++Ca1i08qy6uBWOMCY0IZWWSvLayUb2pU1/5rpdxXRuNE6zz333DDeeOPV/q233noNN6+V/BuuvEUZJBq3CKSKEQEREAEREIEeJCDRuAcHVV0SAREQAREQgW4l0Kmi8UsvvRTOPvvssOOOO4YFF1ywJjItvfTSYY899ggjR44Mf/vb3xpC/tlnn4Urr7wyHH300WHzzTcP8847b63MOeecM2ywwQbhoIMOCldccUWpWHrKKaeEQw89tPbvyy+/DP/+979r7VlllVXCNNNME3bbbbdw6623hk8//bTWviLRmH5YWaNGjarcn7/85S9JvvPOO69yvryE7733XrjkkkvCYYcdFjbccMMw22yz1dj85je/CZtuumk4/PDDw+jRoyuLry+//HKtrDXWWCPMPPPMtbIWXXTRsN1224WTTz45PPjgg3lNafg4c8QYjhs3rpb/+eefD8To3XjjjQMC3VRTTRVWWmmlcNxxxwX62oghnjMv9txzz1oZk08+eZh++ulrc+aoo46qjXVVUZp0Tz75ZNh3333D8OHDw3TTTRcmmmiiwLzeeeeda21++umnKzWPhyjMsx122CEsu+yygXZNOeWUtXIp/4ILLgjvvvtuYVmMqbG7+uqr69Jmicb04frrrw977713WHjhhcOkk04aVltttQCL22+/vXY91BXkDjQqGn/11VfhmmuuCYccckhYffXVw5AhQ8KMM84YNtlkk3D88ceHBx54wJXeHbsSjbtjnNRKERABERABEWgHAYnG7aCuOkVABERABERABDIJdJpojCchQihilHkkZm1nn332cN9992X2KT6IsIQAmlVOfGyFFVYIRcIdQpnl+eSTT8I555yTfLbjbM8///xaM4pE4wsvvDDJi+hHeVVs3XXXTfJZPVXyxWlMAJxhhhmS8nwf4n1E2DfffDMuJvnM2CGuxvmyPh9wwAHh888/T/L2dQcx2Mp/4403wp133lkTUO1YvGVewaxM6OX8mDFjwpJLLpmUH5dlnxHW33nnncIu8ICBdJanaIuwXuTp/dprr9UE26IyOMe4Fon9Rx55ZNKeXXfdta79sWhMH0hXVO+2226bPDCpKzCE0Iho/OKLLwaux6L6ONequZTV3v44JtG4P6iqTBEQAREQARHoDQISjXtjHNULERABERABEegJAp0kGn/88cdh/fXXT4lEiKl4ZeKJiUdmLCDhOVwkAHLe50E0HDZsWEDc2mabbcJyyy1XJ1DjzWheq/Ege9H4lltuSZXt6zGP1iLR+MMPPwwTTzxxUsa1114bV1f3eezYsUl66rN66hKWHECUpP++zXjk4h2Md/cf/vCHsMQSS6TOkxbxPUvQZAzwBvXlzT333DWhFO/wzTbbLPFgtjSLLbZYQIhsxrxofMIJJ9Q8dymfMUTkPvbYY2t1x0IdafPmDcdPPPHEVF8oExGWfiDa49Vr/WCL9/E999yT2RXE9Jj1QgstVGMMm4022qhWti9vzTXXzGwfc4a8Pi0M8OLGy53x83OKdCeddFJmuxoRjfGI5rqxeuk/7UYIZ97YcbZ4lSNsZ1lV0Zi3Arj2fbnMPThSb1wnc+n111/PqrLjjsVzEY9xmQiIgAiIgAiIgAhAQKKx5oEIiIAIiIAIiEDHEOgk0ZgQEV4kQtT64osvUqwIS4Hg69PleRzjqejT7bfffuGDDz5IlceH999/P+y///6ptIQ3yDIvGhOOgvI5hncoIR4QW7faaqska5FoTCLEPmsjYTLK7KyzzkrSE2ajr3bbbbcl5VA//SWER2yvvvpq2GKLLVJpb7755jhZePzxx1NpLr/88roYu4QawIvc+ssWT9hmzIvGVi4PGeJx5jNCrKVhmxcmg3AIPh2hTB599NGUiItwTpgGLwASiiMrbMpNN92UKu+uu+5KlUX/8bqOH3A88cQTdWgOPPDApKx55pknvPLKK3Vp3n777Zpgbn1gnmaJ842IxlYW2zPPPDP14IBQGV4MJg1icpYo79PlxTSmT4jUVicPi5566qlUPxHimYeeP6FVsupMZeyAD77N9FGicQcMipogAiIgAiIgAh1CQKJxhwyEmiECIiACIiACIhBCp4jGxKE1kYhtVoxVGy/iCB9zzDFJejxis7xfeW3dykTEQmjKM8QmHz4Ab8ks86IxZRPLOK7bC1dlovHdd9+dtJHyisIcUC7tsj7h6dwXo5y11lorKYdYxr7NcZmIvXhyWr14e8ZGbGE7XybeEUfX0sK8GYtFY/qVJZBSB/3wwjGxgOMFFhFvZ5lllqR9Q4cODR999FFuE4nf7MN78PAhNj8PiTecZ4zBlltumdSNQOyN897LGNE6z4ipTbxu44xwHVtfROMbbrghLib5HIvjCO2xlYnG9JF4xdbuFVdcMfz973+Pi0k+E/vc87/jjjuSc526I9G4U0dG7RIBERABERCB9hOQaNz+MVALREAEREAEREAE/kugE0RjhCIfpxfhjGNFhpBki9khMF100UWp5MQH9iEEqiyY5T1MWWwry7xoTBiALE9Pn69MNEZwnnXWWRORrChGMYuomZhGOIQiMc23Id6PPbDfeuutOEndZ8I8WN2MVWwsyGbnTz311Ph06vNzzz1XW4yQBfYYtyIxP5Ux40MsGmd55/pseBdbO9k+9thj/nTAQ9qff+ihh1Lnsz4wZj5PHBMb4dnOM8eKDK95PNVZWC5Oy5y2ctjmhYCw8om3TVgXQm1k9aNR0ZjQMUXXJed4iGJtJH1sZaKxf4jC9fXCCy/ERdR99vwR1b/++uu6NJ10QKJxJ42G2iICIiACIiACnUVAonFnjYdaIwIiIAIiIAKDmkAniMaEDjChiW0VgZdBIySE5csK1YB4xOJof/nLXyoJk9Rr5bHNEsi8aLzMMsuUzp0y0ZgCvCCL92tWvaTzHroHH3xwad1FCfDGRfB+5JFHipIl5y699NKEDYuTxebFQGIZP/vss3GSfvnsReO8kAi+4ljYJLaxN0KY2Bwgdm7eWPg8sJxrrrmSfITg8ObDrjBnmJN9MdriPc132mmnphYTbFQ0zvIcjvvhRV84xosd+nmSFZ5i7733TjgSP7qKERLExowtD0U62SQad/LoqG0iIAIiIAIi0F4CEo3by1+1i4AIiIAIiIAIOAKdIBrjHWqiD7FMY6HJNTe1e/vttyf55p9//tS5Rj4QfuDhhx8OXkSjPYQziM2Lxttvv318uu5zFdE49vwlVEdstMW/ho/XcX8bIiUL7Y0ZMyYgUNoYwSC2Z555JjlPOrxEd91110A4gzi+cJy3mc9eNI69zfPKxcPZ+oJnrDfiIdu5Cy64wJ8q3Mej1/LFISgImWDn2CIakoZYtiz+2IjFcxRvex464EmcNV+LyvZlMVax3X///Um7WUAyDuURp+dz/AAoFnDLROPVV189qZO0VYx56t866PQQFRKNq4yq0oiACIiACIjA4CQg0Xhwjrt6LQIiIAIiIAIdSaATRGNis5qohti48cYbV/o3bNiwJB/5y8I1EAZh7Nix4d577w28ur/jjjuG3/zmN6kyrB1ss0Q4Lxoff/zxpWNaRTRG9PJ9ySrXC4+LL754JQ/Y0sa5BITJwPOYeggvQYiQ2WabLZNNlmgMW+9R6zmyv9pqqwXCCLCwHv1tlXnRGC/XKubDGeAVbUYfhgwZkvS5EfERj2Xr8xprrGFF1rbMo3jxRkvLQxJiQLOIIgvYlRmhRIjhbfn9dqqppgq77LJLbYE4QlmUWSOi8ZJLLllWXO08DLmGrV0xwyLRmHlB2BXLi1d21XuBf6DC+HaySTTu5NFR20RABERABESgvQQkGreXv2oXAREQAREQARFwBDpBND7llFMSocgEo75ss+ILI0ThlYtA7AXBKuWXicZXXHGFI5m9W0U0JqePpUuoA8Q3b150/NOf/uRP9XmfBQWJoUsYBi/0lbHJEo1pBKwJzVCWHwGSMf/ss8/63HbL6EXj2KvV0sTb0aNHJ21EtDXWPFDwbSf2clVjLlje6aabrk4Ypw4v0lraeEv8Y8Y3a+5ZW/BOJrRDnNd/ZjwJ70Bf80R6354yT2MeIlQ1/2AlDtVRJBrHYSZ8fxrZZ+HBTjaJxp08OmqbCIiACIiACLSXgETj9vJX7SIgAiIgAiIgAo5AJ4jGhx12WCKAIXaxCF1f/v31r391PQu11+l9WIVYeKIuXoc/7rjjwl133RVuvPHGpB2kzRLuvCB23XXXperL+lBVNEYIJASAtdEvXDZu3LiUqPvOO+9kVdXQMQRbvH+tvnjLIoKIyaeffnotJvTZZ5+dpM0Tja0BtA8RHC9RRNm4bPuMeIzncTPmReOqsYJvuummpE0wRzzHaIu1jW1VEZq8XjTGWzbLEG9ff/31MHLkyIA3sq8r3uc8oUHyDBH6qaeeqi1y5+Mcx+XwGRE1ay43IhqzOF9V857Ql112WSpbkWgci/aI7325D+yxxx6pOjvtg0TjThsRtUcEREAEREAEOoeAROPOGQu1RAREQAREQAQGPYFOEI1HjRqVCGjLLbdcS8YEgQ6xzItovMK+zTbb1LxhH3vsscACZt7uueeeVPqscBf9JRrTDrw9rb0+Li7Cmx1nsbdmjQUCEYStTLZzzjlnrX7CJBCfmHAV3hA6Lf1CCy3kTxXuEy8aMX677bYLk08+eVKGlTXNNNMEPEz7al40rrJQG/V44dLHwma8rV1sCWNS1U488cQkL6JpFXv//fcDDxUY0yxxfZ555qkUR5i5/tJLL9VCrqy44opJO3xfdt9997omNSIax7Gf6wr77wEEeD/OxEX25tnHC+ExLz0HFrDsRZNo3Iujqj6JgAiIgAiIQGsISDRuDUeVIgIiIAIiIAIi0AICnSAax2JtLOb2pZsIiF404/X6Tz/9tLAoL4ySNyt9f4rGfuExPCxNuCXmrfXl5ptvLuxDlZNXX311Uh7lHnLIIUldefn333//JA/hM/pieDfT/ji0wi233NKX4mp5vGhMbOwqduihhyZ9WXPNNVNZ/PgioFc1RFkbo1gMrVIGwvk111wTfH8or9EFD82bmRAXPiY1QmXsbdyIaMxCc1UsXgjvtddeS2UrEo1JSLxu4xiHtkgV1MUfJBp38eCp6SIgAiIgAiLQzwQkGvczYBUvAiIgAiIgAiJQnUAniMZxWABeu69ihEG48847A7FnEd0QzMzOOuusRHwi1EKW17CltS3evSZYsf3www/tVLL1omIrw1NQASEHWJjN2vDwww8HwlaY9yWv67dCUB8xYkRSx9JLL53ilnQ02iGMh7UrDr8Ad8RCvLevvfbaJNxDVETyEY/SFVZYISnPe1UniSrueJH12GOPLc1FW4cPH57UTWxlb1tvvXVyLss716e1fcZtscUWS/IhSpvhefvuu+8Gwo0QFqPMENbx+jbWhAcx4yEC4S3wgPbhS+x8vCVci5XDlvnkrRHRmPxVwqKMGTMmVWcsVJeJxp4/oWWqGveBRx55JLz55puB+dXJJtG4k0dHbRMBERABERCB9hKQaNxe/qpdBERABERABETAEegE0RhhaZZZZknEJuKnegHYNTe1u9tuuyV58IQ0z1wSsQiYCWbE1i0z8i677LJJHvK+/fbbddn6UzSmspNPPjlpw1FHHVUTGq0fBx54YF17+nKAsAdW5hFHHFFaxCeffBIII2F5iAXtx4fYv3aOLeEtygzvZsvTiDgYl+tFY0R1RPYie/DBB5N6qf/pp59OJfeiJuezFldMZQghNUbk8YIuCw1aP9kirpfZFltskeTxQvjxxx+fHK8i9sehIvDo99aoaIwnfpExJ9Zaa62kjRtssEFdcs83yyPbP+zhYQlhN8qM+eYZVxHny8rsz/MSjfuTrsoWAREQAREQge4mING4u8dPrRcBERABERCBniLQCaIxQOOQCXfccUchZ4Q5LxTFr7LvtddeyXmEXi9yxgXjKbrLLrsk6a3c+NV68vW3aEydVj9C+M4775x8fuKJJ+Km9+nzsGHDkjLLFjj7/PPPa4sFWpts+89//jOpG7bLLLNMUiYLkZXx9rF3b7jhhqSsRne8aEzbiC2cZzwY8KIm3s62CJ7lwZMb7tZPYmAzP/IMPn4hutlnnz318AKvV0KNWHknnXRSXlG143jEU4al93GaY3G0LObv888/n5QzZMiQOi/1RkXjmWeeObz88su57WcxSWs322effbYubZloDE/vbb/uuusW8ueBkx9TvLTlaVyHXQdEQAREQAREQAS6hIBE4y4ZKDVTBERABERABAYDgU4RjRHmvJg56aSThgsuuKBOMEKMJPav93xFzGLBNW8XXXRRSsDCSzJLyEQk3GeffVJpTfhCdIutv0Vj6vMimLUFYTKr/XH7qnw++OCDU/2NPVCtDLx28Ra1Nvgt4p63OB40YR/i0ASk5xge1L6sVi2EZ2Ued9xxdfNm3LhxdbGUCd+QZbfeemuqfXiqZ4UqwcPax+Cl/iyWXpwlDQsbetHd2kBoCu897+Nak4bxZ6FI6yfznpATWfPirbfeSgn5LEQYm28XizDG5mNsW52IsoST8Ub9xGPmmrV0XFNZViYak4e411YO27XXXjvQn9iYN9tuu20qbZ43NB7mxHi2f1VCy8T1teqzPI1bRVLliIAIiIAIiEDvEZBo3Htjqh6JgAiIgAiIQNcS6BTRGIB4UhIv1wtGiHJ77713OP/888MJJ5wQWLjMn59qqqlClvjHInYLLrhgKi3iH4ub3XbbbYFYsbwe74Uu4qlSnpWP0BTbQIjGxAW2Ntj2nHPOiZvS589vvPFGqp/Ugaf1FVdcERBMEV29gG/nrS1s4/i2iKCbbrppqt2EwTjggAMCQiH/CEnhvUgp5+ijj+5zP8joPY0nn3zypH5iDBPOg3p32GGHlLcv9fpYwXEDEEERWX1/mZcspkg+5uH6668ffH2k5XiWIbB7z2rSLrHEEjUezGtCMrDQoPdIJg0PPmIjXAZhOHzb8MaF46hRowJiPeE+CCFiaYjpnRUnvBHRGJ7eA3qVVVap1UW9Q4cOTeqizoUWWii89957cdNrn6uIxvDHw9vazxahdfPNNw94alMGorS/VklDbOwsAZ2K41jLV155ZWb7BuKgROOBoKw6REAEREAERKA7CUg07s5xU6tFQAREQAREoCcJdJJoDGDEpj/84Q8pwciLR34fUdLHj40H6MknnwwzzDBDaVmUw0JaCE7ec/Hwww+Pi+z38BRUiMcpQp/va1Z85brGNXBg9OjRdaKnr8/2l19++UBYDNj4xd4uvfTSutqIfewXzLMy8rZ4HBeFfqirIOOAF40JUZLnNW5tIE4ugmGeuGhVELbi8ssvr4mVljdviwh4/fXXF5aJyL7kkkumxjSvPMRo+pLXRjyAY4E5ryyE3rwwFo2IxlyTPGyIH8TE9SK2Mw/yrIpoTF748xAjFobj+uwzDyeyvLetHRKNjYS2IiACIiACIiACnUxAonEnj47aJgIiIAIiIAKDjECnicbgRyxDhMPbcP75508JbXhQEj8XQS8r/EE8fIRYQJzkVX4TmNjirYmHJp6ZPtQCi2jhZcs/PJPjmLfEALbzd999d1xd3efbb789Sb/99tvXnc874GMyV1nIL6+couO88j9ixIhUqA/YsCjhJptsUvNc9YsLnn322Ulf8IzNMsYOUZOwFrFHJSFFNtxwJs3hLAAAIABJREFUw8DiblnxbrPKKzvmRWO8yKn/qquuqtVDHF8bc8RHHgIgfDZiY8eODfvtt1/No9l7pVMuAioiaJ5XbVwPAjme3Hjp+rZRFvOTxRuJyVyljcxZwrcQtgQh3PrJlmsGb2O8mPG4zzOEaZvLWV7SPCyw84cddlitGPrK2PuwHIwr8wWRN0/otjYQxsLKhGuZMUfxGB8+fHgdM+bpnnvuWRcuI6tM3xfq522Ddll8XTAnZCIgAiIgAiIgAiIAAYnGmgciIAIiIAIiIAIdQ6ATReMYDsLXc889VwuJUORNGOfznxGzKOeFF16olROLwT5tJ+z7UA94BfenwYb4sDD+4IMPSoW/qm2hXER7Yv8ivvYH81g09m1jQTTGG6GzFXUjoBMegn94g5cJpL4t8b4xJ242XsjNlMU1QR8R4uPY3nG9rfzMXCG+cbPe4lXbRD0I6swn/6Cnav5OSSfRuFNGQu0QAREQAREQgc4jING488ZELRIBERABERCBQUugG0TjwTY4CKzmOUp4AcRPWTaBItE4O4eOikB7CUg0bi9/1S4CIiACIiACnUxAonEnj47aJgIiIAIiIAKDjIBE484bcEIUmGhctGBb57V84Fsk0XjgmavG5ghING6On3KLgAiIgAiIQC8TkGjcy6OrvomACIiACIhAlxGQaNxZA/b4448nMYaJVVs1Xm5n9WLgWiPReOBYq6bWEJBo3BqOKkUEREAEREAEepGARONeHFX1SQREQAREQAS6lIBE4/YOHItgHXrooeHUU08NLLLnF0jbZ5992tu4LqhdonEXDJKamCIg0TiFQx9EQAREQAREQAQcAYnGDoZ2RUAEREAEREAE2ktAonF7+d94441JKAoLScF26NCh4Ysvvmhv47qgdonGXTBIamKKQK+Jxizk+PLLL5f+Y9HEcePGDdjCiSno0Ycvv/wy1d5WLJTJIpTGgQUbY6MOO8+2v+/vLNhp9bFwp6yzCLBIrI1P0ZZx/PDDDzviuukvgpqr/UW2b+VqPPrGrZW5JBq3kqbKEgEREAEREAERaIqAROOm8DWd+dFHH60Tjeeee26FpahIVqJxRVBK1jEEek00HjZsWN09zD8Ay9r//ve/H2aeeeaw1157hRdffHHAx+b2229Ptfnzzz9vug1HHXVUUuYss8xSV97f//735DxMbrnllro0rTxAeCNjf9lll7WyaJXVAgLHHXdcMj42TkXb8ccfP0w99dRhww03DFdddVX45ptvWtCKzijiO9/5TsJCc7X9YzLJJJMk43HRRRe1v0GDsAUSjQfhoKvLIiACIiACItCpBCQat3dkECuuvPLKcPDBB4eTTjopPPLII+Grr75qb6O6qPZnnnkmILzzT/Gfu2jgBnFTJRqPlwgSJpItvvji4YMPPhiwWSHReMBQq6IcAo2Kxnat2HbJJZcMr7/+ek7p3XVYonFnjZdE4/aPh0Tj9o+BWiACIiACIiACIvBfAhKNNRVEQAREYOAISDSuF40RwhZbbLHw9ddfD8hASDQeEMyqpIBAs6Ix18wvfvGLQFiUbjeJxp01ghKN2z8eEo3bPwZqgQiIgAiIgAiIwH8JSDTWVBABERCBgSPQy6LxT3/600AYhqx/xBHmbYBnn3023HvvvWGLLbao8zjebLPNBmQg2iEaI4ivueaayb8nn3yyX/uq8BT9irfpwmPR+Pnnn6+7bohFTSzw+++/P1x99dXhsMMOCxNPPHHqutloo42abku7C5Bo3O4RSNe/wQYbJPep++67L31SnwaEgETjAcGsSkRABERABERABKoQkGhchZLSiIAIiEBrCPSyaPyzn/2sIUjXXnttmGKKKVIi2NixYxsqoy+J2yEa96WdzeSRaNwMvf7PG4vGVUNNPP3002HGGWdMrpn/+Z//CW+++Wb/N7gfa5Bo3I9wVXRXEpBo3JXDpkaLgAiIgAiIQG8SkGjcm+OqXomACHQmAYnG6XHZc889EwGMV+4vvfTSdIJ++CTRuB+gqsiGCPRVNKaSk08+OXXNjBw5sqG6Oy2xRONOGxG1p90EJBq3ewRUvwiIgAiIgAiIQEJAonGCQjsiIAIi0O8EJBqnEY8ZMyYlgO24447pBP3wqUw0JpTEa6+9Fv79739Xrv2oo45K+jHLLLNUzleWkIVRX3zxxUCogkaszNP4008/De+8804jRbYkLaFL6A+LwLbS4NTomLWifup9+eWXwz//+c+GimtGNIafLYjH9sADD2yobhL/7W9/qy2k98033zScNysD5bz77rvh7bffDo2W2auiMRzeeuutMG7cuCxkfTpGDOsvvviiUl7m5ksvvdTwvaNS4TmJPv744365Dv/xj3/UQrU0ck/OaWJXHJZo3BXDpEaKgAiIgAiIwOAgINF4cIyzeikCItAZBCQap8fhX//6V5h88skTEey3v/1tKgExXZdccsnkH6JUme21115J+mOOOaYueZZojChxwAEHhIUXXjiYiEW7lllmmbD//vsHRNYiKxONEaJ9Px5++OHc4p544omw/vrrh+mmmy6MP/74CRs+/+53vwt77LFHTfTLLSCEkCUaP/TQQ4F4pbPOOmtS7vTTTx/WWWedcNJJJ/WLuPTKK6+EnXfeOaywwgphhhlmSOpF7JxqqqkC473DDjuEDz74oKg7gdi9xs/mAJwoe8EFFwzf/va3a5wmnXTSWpn77bdfLUZwYaF9PHnNNdeEddddN8w+++xhwgknrNXLnJlvvvnC5ptvHv7617+WltyMaAwrLxpfddVVpfUxv0844YSwxBJLhB//+MdJfngtssgiYeuttw6MVSOG8M+1wTXzgx/8ICnzhz/8YW2sdtttt/Dhhx+WFmnXG3267LLLctM//vjjYemll07mwSqrrFI6b+LCmBc2j4irXtX+9Kc/JfnWWmutXGGc/o4YMaLWTjjYOE077bTh97//fWDcyx4w0E9r4+67715rItcufWe+ffe73w3Dhg0LtCm+L5E3695BvPnll1++0r2Da9Xq515ZZNy/zzjjjLDUUkvVrmfr7/e+973adQlj4nWX2VZbbZXUyUMY7JlnngnMoUUXXTS5J1Mu85V7YKsfPJW1cSDPSzQeSNqqSwREQAREQAREoJCARONCPDopAiIgAi0lINE4jRMxi7isJjYgyHgjhqudY1tF2EKcsTyIeLHFojEeqoiXlidr+4tf/CLQljwrE43xsPXl3nLLLZlF7brrrql0Po/fn2aaacKtt96aWQYHvWhMyI9TTjklEVZ9OX4fD+kqAk9upe4EXpannnpqmGSSSSr1B4HtoosuciWkd+FvbWUOwA8ByY5lbX/961/XPC3TJfX9EwLdxhtvXFgn7YA94mCRV2QzovEFF1yQtIFrJxYO4x7C6pe//GWSJ4sVx+B5+umn5wqiVi5je+GFFwbmYF5Zdpz7HbHLi6yKaMzCkUOGDEnqIxZ60YOXvPqYY9Y2tlVjSc8555xJvry3IW6++ebwk5/8JEnn6/H7Cy20UM07Pa+Nd955Z1LGcsstF95///1M1t/61rdS8ax32WWXJJ+vL95n3G677ba86lPXbNE1ec8994S55567tE7G99hjjy28Hn7zm98k5fAwiMVS/cPEuA98Zk4X3ZNzO9gFJyQad8EgqYkiIAIiIAIiMFgISDQeLCOtfoqACHQCAYnG6VFAIPCCwMEHH5xKMBCiMV6A1gbGZ7XVVqt56/385z9PjnMeAfSmm25Ktc8+tEI0RlixdrClLauuumrNC3SzzTaredz58+znCXJeNEYM9vkQ3/BYxlN2ggkmSJ1DBMIruhlDVPTCPXVPNtlkNW9j+rHpppvWvApjUQiv6ueeey6zai8aH3nkkSkBHG9pPB29B631F29mHkw0a7zmj6e0lcuW+vDK3HLLLWsPHWKBfMUVV8wVyvoqGvP6v3/AgUdokZ199tmpNtNuhM2hQ4fWvLfnmGOOgPjo+8W5IsEbL0+fnn0WwVx99dVrXuszzTRT3fmddtopt5llojGe2z/60Y+SMtnnvtEX4+GNn3eHHXZYaTF47/r+ImDHtu+++6bScF3NM888NcZrr712avFCykKgz3vo40VjvIv55+u3fQRlsz/+8Y+pNM3cO/w8zhONL7nkktRbA7RpyimnDMx5HqzMNddcdfcWrtG8a9GLxoceemjNm9r6yRsWsSezncPDvWq4DmPVDVuJxt0wSmqjCIiACIiACAwSAhKNB8lAq5siIAIdQUCi8f8NA+Iir0ybAMA2FkEHQjSmXgTLI444os7LctSoUcmr0aRDSM4SPpoVjRE+vMc1f5uzxNtHH320JiYbM/hlmReNLe3w4cPDgw8+GHil3Ay+eORaGrZFXoiWr2jrRS/KI/xEVkzmTz75pPYqv687yzOcurxobOkRbInva8Z8QmCMvWoRuJo1xDCrl3E66KCD6uYBgmTsiYxom2WNiMaEMyAkxxVXXBGmnnrqpB0TTzxxobctnqD+oQBCZZYISDiAeA6ceeaZWc0O559/flI/PBCgGe/YmGeI+caM7R133BEnq30uEo0JUYAYaeVQH8eaMUIhWHnMFeZNkRECxdIjBMf2wAMPJOdJB8ssYfmuu+5K9YV7CXGHY/PXj40f1zNvYTCXCbnDwwJbNJQwDVXuHY888kjqwQrXT5aVicbcgywcDP1l/JjnMcexY8cGvKqNHduscEG0wYvGlp4+ek9iyuehEmNgadjmzdWsvnXLMYnG3TJSaqcIiIAIiIAIDAICEo0HwSCriyIgAh1DQKLxf4YCESz++4N3Whzvc6BE45EjR+bOES/iIFKcddZZdWmbFY3xOjQhBE/IosWzeA3e0uIlymJbscWiMd6KWSI0+RANveh08sknx8U19Blx2tqHqB2LSXFhK6+8cpIe790si0VjRNy8comD7T1Tl1122awiKx+74YYbkvbRryIRmjYRN9f6j+CJd3BssWhMzNkZZ5wx9Q9Rkfw+rrWViwd1nqcqddEOL9ghBD777LNxM5LPCN5wsvIJ/xDHmSaND0lBm1n8Ls9YbG+22WZLyiSWdtYczBONEQj9/ZK6X3jhhbzqKh8nPrD1k+1jjz2Wm5cHLD7kBLG/veGRPf/88yfl/epXv8rso+V58803U7F/Dz/8cDuVbOP7DW0kbEieEX7E+oPnLdzzjDclLC33DosP7tOXica8pWBlcN8o4scDNn8/4MEFYnJssWiMN33e9U2b/cOTBRZYIC6u6z9LNO76IVQHREAEREAERKB3CMQ/2rfbbrve6Zx6IgIiIAIdRsCLIPzwLhJ+Oqzpmc1hQSYTEIhLy+JMWf/OPffccPTRR9e8ThERYlETYQyPvdgGQjRGdMgTKKw9eOVZP3ld2nvrkqZZ0fjEE09MykcsLGoPdbPYFYtEnXbaaam4ptZezxfhEa/eImNRMevfNttsU5S08BwLgfk5Pnr06ML0nKQPVjeLfGWZF43xcvQexlnp11tvvaRMxMq+Gqx9eA9Cl5QZ3qPey5ZwDrHForH1v8oWoe7KK68snCPE+/VlsThkmXGt+VAV8TyI4wFznZfZddddl2rH8ccfX5clSzRGHPZiLTyrxDOvKzzjANcWoVmMD7GA88w/oGHexQ9zeNhk5eAVXCVsBgvHWR5E1HixwFg0XnzxxQvHmgUOrTwePFS9dyBEZz1wKhKNGReri+22226bhy45zkMc75nMYpyxedGYOVjGkZAw1g4eJvSaSTTutRFVf0RABERABESgiwlINO7iwVPTRUAEuo6AF9T40dtLorH9iG90i2hETM4sGwjR+MYbb8yqOnXs7rvvTkQK+od3rrdmRWNeHffcWBAvyyvT11m070XjKp62fgE+vJKbNRZnIxZsUWxcqyP25M0K/+FF4wUXXNCy5m733nvvhCdeiX01Yhn7cakiglMXgr7lW3jhheuqb0Y0tnKJP004jizzsYy///3vh48++igrWd0xBD0rnzAL3kaMGJGcm3nmmesenPi0to+AyXhZmWuuuaadSraxaMwDAe9JihD6xhtvJOlbseNjAOO1HT8EsjrWXXfdpO3EbI7NP5zIGuc4PZ8J1eK9x+NFMWPROI7zHpcZPyBg7jVz7ygSjS+77LKEB/eYIk9z304eQNgcYDxj86Ix3ullRlxzK2/SSSctS9515yUad92QqcEiIAIiIAIi0LsEJBr37tiqZyIgAp1HQKLxeMmPfX70r7HGGuG1117LHaiBEI0ROMsMocdECrax0NysaIy46kMqUAfCGX+jr7766syYwEVt9qJxFW9Avwgfns79bYQ6IO4t3o4+PAX9zvKK9qIxsV3LzIumeHP21RhnG3c8SYkfW8UuvvjiJB+e3rHFojHep1dddVXdP8ohDixxofEG9963tIswEnCMbccdd0zqX2SRReLTuZ+91zfiofdaXWmllZIyid1c1XxMYMI3xOZFY+KK+xAY9PGpp56KszT9+f333w8TTjhh0p+sh3dc88SNtvHn4UZsPjRFlkd5nN4++/l86qmn2uHaNhaNmQNF1up7R5Fo7EOvzDnnnEXNSp278MILE454EsexnL1onBdr2RfoxWsE+CoPp3z+Tt+XaNzpI6T2iYAIiIAIiMAgIiDReBANtroqAiLQdgK9LBrz2jyLFOX9Iw4ti1DhJcYiTlXEoP4WjfNi6GZNFGINm4AUv2bfrGhMfYhSXrCxutgiAsOPeMrvvfdeVvNSx7xoXCVGsX/FnVAArTJER+K48po/3p0bbrhhmGOOOVILtPl+sl8mGuPxWmbMLysXUbKvxjhbOYhT0047baV/CMWWL6tPsWj8+uuvV2oi8WpXXXXVVNl4/caxwJdZZpkkDcyrmg/HQLt9/FkfcqPM+9XXRxxgY0H4kVjg86KxD49hedZZZx1fXMv2fazdjTbaqK7c8847L2l3njcyMYStndwfqs4Pf33utNNOqbpj0Zi3EMqs7N6B4F/13uHvQfHCiX7uwa+q3X///QkneHFf9+ZFY/5GlJmPzUx58fwvy9/p5yUad/oIqX0iIAIiIAIiMIgISDQeRIOtroqACLSdQC+Lxj/72c9azre/RWPEiqqG2GkCURz/vxWiMe149NFHa8KT1ZO1RbzEezTL89H64kUpBNQya7VoTIiJ888/P+CNmNWHomNlojHeqGXWKtHYv1Zf1Oayc4QQ8NZX0ZgyEOI32WSTFNc4vrD31t1///191YX7ccza22+/vZb+iy++SNU3atSownL8yeuvvz6V1wvRpPOisXH0Hr4cI4Zzq+3aa69N2kUIjy+//DJVxVJLLZWcz3pQQSxia28z29///vepemPROI55nErsPnDv8OOe1Sa7d8RvSrhiUg+uYtH4l7/8ZdLnWOz2ZcT7hLHw7eHtCW9eNK4Sf1uisaenfREQAREQAREQARHoRwISjfsRrooWAREQgYiAROMISMnHvojGeOSaQLH55pvX1YAQZufxiq5qxNq0fLEQ1yrRmLbgNYdwREiCn/70p0mdVrdtEYDw+Iw9NynDi8a8yl1mrRSNea1/vvnmy233kCFDAkIZ4u+9995bC79hfWJbJhrjqV5mrRKNvTiLlyxzoC//4kUemxGN6TtxcD2z2FPWi4eEFKhqxEj25TI+WCwaswBcVSPshi8z9pSPReO55pqrFsPYL0CI5/YHH3xQtcpK6bjOeNPA2nbJJZck+RC2ub7s3PPPP5+csx3iLNt5tlyrfZkb8djFonGV8DnWJrt3bL/99pXuHT78iJVR5GnsRWNCoFS1mFX8wMuLxsQjLzOJxmWEdF4EREAEREAEREAEWkRAonGLQKoYERABEahAQKJxBUguSSwaP/vss+5s9i5xU03MKRONeZ28iiGuEBvXyo1Fs1aKxr491PvYY4+FffbZJ/g4qNYOtsShja1dojEexsstt1zCifYhpiG+8no84xcLVYh1vj8ff/xx3J1U3wdSND788MOTtrUybEezojELnfn5GC8OuOSSSybtZnG7qnbdddcl+RgTPI/NuFZsnA466CA7XLr18bIRYuNF57xojHhICA7snnvuSeqj3iqxrEsbEyXwC0ASwsGMBxrW14UWWsgOp7Y8rOFBgqWLvb1TiRv40Ixo7KvhOsP7GBE2795BTPHYikTjYcOGJf1lv6rFC4nGnvcSjdMkFZ4izUOfREAEREAEREAE2khAonEb4atqERCBQUdAonFjQ/7cc88lIgXizF/+8pfCAhBKvOhRJhp/+9vfzvTUjSsZN25cqh3E6PTWX6Kxr4O+EQeaBbe8F2T8ejt52iUax6Lj2muvXffav+8T+3htm/DGllfZY/Oi10CKxoRF8G1jHrTCWiEae8ES73pvxIW1di+88ML+VOE+8a8tH9uPPvooSe/jJMfesUmijB085q3MH/7wh3UpvGgce8VvvfXWSV7KuPzyy+vyN3PgmWeeSconJrs9sPAPns4888zcKnz4Fbx7W2GtEo19W+zeQZgNf+8YOnSoT1bb9/fPODwF+W0sCddT1S644IIkH/njGN4SjdMkJRqneeiTCIiACIiACIhAGwlING4jfFUtAiIw6AhING5syONYmCzUVWRvv/12SpwoE40RMOwV/KJyr7nmmlS58avyzYjGCDqPP/54uPjiiwOhBPAsLjOEYxNvEHnwPPXWLtF4l112SdqFqBnHifVttP011lgjyUOfXn31VTuVbNslGsfhGuLX6pMGRjssXoaXMmPKgw48sL01KxpTpo0/20MOOcQXH3y4ETySzXs3lSjjgx8LPKuZm2bbbrttUufPf/7zSouPkf/Xv/51kg/hObYi0ZjQDN7D+Uc/+lF4//334yKa+rzAAgsk7bvwwgtr3tXGljmcFS7FKlxttdWSvPPPP78dLt0ec8wxtTcECLNA6AZvjYjGfbl3eOGXuRHfO4pEY7ypjQ0P3LjfVrHNNtssyccYxgvXSTROU5RonOahTyIgAiIgAiIgAm0kING4jfBVtQiIwKAjING4sSH/6quvErEBsSLrdWpfIiKdiRpsq4jGW265pS+ibj8WvhCZvJhGhmZF4+mmmy5pd5VYob6fk002WZ0o2S7ReNFFF036UcXDFc9O33fGDO/P2NolGjP/fNzbeeedty68QtxW5sZvf/vbhAMLRMYhGZoRjQmLsPrqqyflw+yOO+5INYOHEN6jNGsht1SGEMKTTz6ZykPoBm9XXHFFqs6zzz7bn87cj+MZn3HGGXXpikRjEscL6SFst9K4p9g9A64I8PZ5/fXXL6zq+OOPT9KSh8X1yszHVCfPOeeck8rSqGjsRfUqi9PhPWz9m3zyyevuHUWi8YsvvhgmnHDCJD8e7WX28ssvp/L84Q9/qMsi0TiNRKJxmoc+iYAIiIAIiIAItJGAROM2wlfVIiACg46AROPGh3yqqaZKRIqf/OQnqVfmfWnEyfSCB8JIFdF4ggkmCIQhyLNzzz03qZ8y49AU5GtGNCb/7rvvntQxxRRTZHrb+vZtvPHGSXpCQMTWLtF4vfXWS9pFKILYi9G3kwXziBdrApZt8dKNrV2iMe0477zzUm384x//GDcv9Rkx1frCFq/S2PoqGn/44Ych/t7G9cFCdbFtuummSTvwmMVrOs/+/ve/Bx9+AsGZeLjeYjEcsbLI05S2+oXTJp544kwv4TLRmDasu+66SV9gykKHrTIeXFioD+4ffsHL2267rbAa5vfMM8+ctI343UUhTAj3Mfvssyfp8bqFvbdGRGPy7bbbbkl53Dtee+01X1zdPqFFbH6us846def9PTQOT0FiHmpZfgTkhx56qK4MOwAfHweZfMQ3jk2icZqIROM0D30SAREQAREQARFoI4H4x8d2223XxtaoahEQARHobQISjRsf33333TcRKRAdhg8fHp544onE2xdxCs9b8wj91re+laSvIhpTJvFMEaL8a9N4dB544IFJWaTLW4yrWdEY71rvwYewlCVOIzB5T0jaxEJysbVLNI49L/EqjIVjxEcWWPOLtdEP+8cCaLG1UzRmHsTiNoIsoRO84ZWMGOznH4Kujwts6WPRGE9gFl+L/xHigpAleJASu5p5apzY8nnMmDFWbGr73nvvBbzQLT2iLbFlYy/5l156Kcw999xJOtLzECPLuO58/6accspw66231iV94IEH6jzIWQgxy6qIxoSD4SGE9YV9+tcq8w87rA7CczD2ZUbIHMvDduqppw633HJLXTZEex8Kg7RZ8bkbFY1ZLLTKvYNQMQcffHCqrVnie5lojMhu91r6wL0Gb+14XhF2I+5v3lsdEo3T00WicZqHPomACIiACIiACLSRgETjNsJX1SIgAoOOgETjxof8zTffDMTP9MIM+3g6zjPPPKlX6hEXEd4sbZloTGgEL0gisiFKr7TSSgGvPSuHLR6FcfxR602zojHl+Nfkrd655pqrFoqAfiy//PIpsYY0iy22WJ2nImW1SzTG43XWWWdNcSM8A6+xI1ghuuMtbv1ji9f0pJNOmhzLEsH9GGUJbTYOtkUMszoQJZs1QjfE7cY7lTi2m2yySWBBsfg88yfPuzcWja2tjW5POeWUwq6NHDmy7trBu3WFFVYICKWMlQ9jQf3LLrtsXcgCX0ksPJKHa5HrhtARjHfcD75rxqKilVlFNCYt8YZ9uauuumpumVZ21S0exb5s9hHrq9o222xTlx+vY7xs8ezloUPMmQcqWUwaFY1p42mnnVZXPw8CCLdh9w4Eft9HQqjEXs6UVSYak4awI+adbWUOGTIkLLfccmGDDTaoeVP7hwukWWSRRXJjnEs0Ts80icZpHvokAiIgAiIgAiLQRgISjdsIX1WLgAgMOgISjfs25ISeYPEtEyiytvPNN1/AI9GLS2WiMcIKC2sRqzarTDuG2Bl7lvqetEI0pjw8m73ga/VnbRHpsrxYKceXcdlll/mmZu77hdPwsGz5XlyaAAAgAElEQVTG8Eb1cVaz2s4xhGAEMoy+WDoWF4ut3aIx7SHsQJZHqrXbbwlx8OCDD8bdSD43IxoTToVwDXH4iKTwaOepp55KLUbn2+n3ETURSuP4y1FxtY+MW5Y47MtjH0H4zDPPzBRHrdyqojECKw9zfB28YdAKw6OYee/LfuWVVxoqmnjG8f3dl2f7PADDczyPc19EYxp6wAEHpK57qy9ru8oqqwQ8hrOsimhMvueff77OAz+rLo4RHzteDNLXLdHY0whBonGahz6JgAiIgAiIgAi0kYBE4zbCV9UiIAKDjkAsKmS92t1NUA466KCa1yKei3hc9qchcuy1115hiSWWSDxTeU0aj8Njjz02EXURXWgP/xBDY0PUtPPbbrtt7TSC8N57711bwMxELEQkPCfx1szyCPTlXn755UmZ/F2NjRANVifbIsHvnXfeCbvsskuYY445UuEF8BT83e9+F/bcc8+6hc/i+lZeeeWkvqxwD3H6a665JkmP52+zxqvwhx56aC0+rHkkIkrOOOOMNYGYuMCEczDDc9H4IGj5MCGkgamdh3WZETfV0uPt2Ur785//XJvrCF1eYCMsAXMTkb4srMHVV1+dtM/ambdlMTbCRRD6g77nebsX9RHBjvwI8njMmxcoYQ1mmmmmsM8++5TG0Y7LJyY1DzkIm+EFVx5YzDnnnLU43zyQKTPGx/peNlfHjh0bVlxxxSQ9Xq1FYmRZ3f484ra1o6+h2niwwH0EcdszITQIIWfwSKYPRYZXu7WDbVa86rz8xJhu9t7B9Wf120OdvPoQvk899dTafRKvdZtXPNiYYYYZavOWxfPKbIcddkjqPP/888uSBx4iWhvZ5gnwpQV1aAKJxh06MGqWCIiACIiACAxGAhKNB+Ooq88iIALtItBronG7OCLKIa6Wibl9aR8CLx7LnWKI5f3V14HoI2OEmPX5558PRHUDWgfzEBEQkbybDCGSsC+tFNs++eST2jwtE8y7iVOzbeVhVDuv3YG+dxDugushfujTLMfBll+i8WAbcfVXBERABERABDqYgETjDh4cNU0ERKDnCEg07rkhVYdEQAREQAREoGUEJBq3DKUKEgEREAEREAERaJaARONmCSq/CIiACFQnING4OiulFAEREAEREIHBRkCi8WAbcfVXBERABERABDqYgETjDh4cNU0ERKDnCEg07rkhVYdEQAREQAREoGUEJBq3DKUKEgEREAEREAERaJaARONmCSq/CIiACFQnING4OiulFAEREAEREIHBRkCi8WAbcfVXBERABERABDqYgETjDh4cNU0ERKDnCEg07rkhVYdEQAREQAREoGUEJBq3DKUKEgEREAEREAERaJaARONmCSq/CIiACFQnING4OiulFAEREAEREIHBRkCi8WAbcfVXBERABERABDqYgETjDh4cNU0ERKDnCEg07rkhVYdEQAREQAREoGUEJBq3DKUKEgEREAEREAERaJaARONmCSq/CIiACFQnING4OiulFAEREAEREIHBRkCi8WAbcfVXBERABERABDqYgETjDh4cNU0ERKDnCEg07rkhVYdEQAREQAREoGUEJBq3DKUKEgEREAEREAERaJaARONmCSq/CIiACFQnING4OiulFAEREAEREIHBRkCi8WAbcfVXBERABERABDqYgETjDh4cNU0ERKDnCPSSaPzpp5+GU089Nfk3bty4jh+v9957L1x66aVhu+22C/PMM0+Yd955w7Bhw8IhhxzS8W3vtAaeffbZydg///zznda8rmzP448/njC98MILu7IP/d3oO++8M2F0880393d1g7b8kSNHJpyffPLJQcuhHR2XaNwO6qpTBERABERABEQgk4BE40wsOigCIiAC/UKgl0Tj1157LYw33njJv6eeeqpfmLWq0FdffTUMGTIkaa9v+yqrrNKqanqmnIcffjhcdNFFuf2ZbLLJEpYXXHBBbjqdqE7gmGOOSZjONNNM1TO2KOXTTz8dzjnnnBaV1j/FbLbZZgmjVVddtX8qUanhZz/7WcL5+OOPF5EBJCDReABhqyoREAEREAEREIFiAhKNi/norAiIgAi0koBE41bSrF7W559/Hn71q18lIogXjNnfd999qxfW4yn/9re/hS233DKMP/74YcSIEbm9lWici6bPJ9olGn/22Wdht912CxNOOGFAlO1kk2g8MKMj0XhgOGfVItE4i4qOiYAIiIAIiIAItIWAROO2YFelIiACg5SAROP2DPwVV1yREowXWGCBcNxxxwW8aW+77bbwyiuvtKdhHVjr0ksvnbCSaDywA9Qu0XjttddOxlyi8cCOeafWJtG4fSMj0bh97FWzCIiACIiACIhARECicQREH0VABESgHwlINO5HuAVFH3vssYkohmfxG2+8UZB6cJ9abLHFElYSjQd2LhDihVjR/LvssssGrHLCPJj3vUTjAcPe0RUR+93m4l//+teObmuvNU6ica+NqPojAiIgAiIgAl1MQKJxFw+emi4CItB1BCQat2fIdthhh0QUa0es2Pb0um+1SjTuG7duziXRuJtHT23vNQISjXttRNUfERABERABEehiAhKNu3jw1HQREIGuIyDRuD1D5uOgDh8+vD2N6JJaJRp3yUC1sJkSjVsIU0WJQJMEJBo3CVDZRUAEREAEREAEWkdAonHrWKokERABESgjMFhE4y+//DLce++94fTTTw933313YCG6ZoyFusaMGRPOOOOMcPXVV4fXXnstfPPNN4VF/vvf/w7/+te/av822WSTxNN4lVVWSY5znnRF9tFHH9Xq5lXtCy+8MPCq9j//+c+iLMk52mhtYGv297//PVx//fXh2muvDbAqM8oZO3Zs+POf/xxOO+20cM8994RPPvmkLFvl876diy66aMKKxdGy2k/BRQvhvfXWW+Gqq64Kf/rTn8Jzzz1XOlZFDf3qq6/Co48+Gs4999xw8cUX18rzLIvyNnLO99PPLfaff/75Wl/OP//8cN999wXmYxXzZVp6jnFNXHTRRYG55c3P2aw++nHKOs8cueSSS8IFF1wQnn766drY+fL9vi+La8LCU3CtZLXb5/X7pGWMqfecc86pjRVj1lf7+OOPw1133VUri/FmLnnzD4AQu/tivn9ZHPPK9MzIx+ci+8c//hGefPLJ2ngwJoQfGah7B+178cUXw0033RROPfXUWrgT5sTXX39d1OTknGdUdo+0TPT32WefDVdeeWXtPsU4srBmVfN1xmy5T3Ld8DflzjvvDMyTXjWJxr06suqXCIiACIiACHQhgVg0XnHFFWs/yPlRrn9ioDmgOaA50No5MPnkkyfiDCLNrbfe2oV/Of7TZIRbE5rYIoh8+OGH4fe//334n//5n9S5CSaYIMw111zh5ptvrtxfRANER8JJjD/++KnyqA+Wm266aa54utdee9Xl8e21/SOOOCKzTTfeeGOYbbbZMsv49re/HRBXH3/88cy8dhABxer51a9+VTuMoPK9730vOT7xxBMHRLtnnnnGsiVbhBFEvCmmmCJJb+Wx/fnPf14TpGKBJSmg4g5CuC83a/8Xv/hFqrRYNKYNJ554YphqqqnqyhoyZEhYaaWVwoMPPpgqo+gDCxTOPffcYcIJJ6wrD2aU18rY1MxP6/cjjzxSE/e222678KMf/Sg5bueZe3vvvXepIPatb32rlpfrAXvsscfClFNOmZRH35ZZZplwxx131M6XLYT38ssvJ3l/+ctf1vLwAGKLLbYI00wzTXLO2gmnjTfeOFPkfvfdd+vSWz7b/vCHP6zVkfXfCy+8UGs7dVh629Kv+eabL9x///1ZWTOPIQ5vv/32YZJJJqkrj0XZED6xVojGu+++e1IHfUTsrGKHHXZYku8nP/lJrgD80EMPhQUXXDBwnzAmtp1ooonC4osvXhNXi+rkfmB5mJsYC3r6ewesEM65z5gxH04++eTavcHy+y1jM/vss9ceWlmerG0jC+G98847tXkW3/et3mmnnTb88Y9/LH1AxzVteUaPHl1r1jXXXFObS1n3Ae7PPMTpNZNo3Gsjqv6IgAiIgAiIQBcTiEVj+7Km7XjJF1exEAvNAc2B/poDvSQa42mIiFnECvH3gAMOKBUPEJ9XW221wrKsnumnn77meRv/Ke6raIy3phcvrJ6sLSLJwQcfnCsexaIxQtv3v//9un4hLr799tupLuBNN91009WlzWrHmmuuWSpgpgqPPjQrGp9yyimBNmS1zR+DV9kCb4heO+20U2lZlIt4izdqK8yLxghRw4YNK23DLLPMUihce9EYr+IZZpghs8y+isY8VPjtb3+bWabnjuAfP5Toq2jMwwE8/rPEYl8n+zws2n///XOvDxu3J554IiDCxvnjz8wLRHA73ldPYzyjrQy21113nTUld0u/EeotH174seEpy/0gS+C0fLb97ne/G7hu8h74xKIx3u5Z9w4YI9pieDHj/GF1lG233HLL3LdAqojGtB0xOKtdWXXzoO2ll16KsSWf/X0X0Zi3O+wayiqPY/T/6KOPTsrohR2Jxr0wiuqDCIiACIiACPQIgT/84Q+Vv1zmfWHTcQlqmgOaA5oDfZsDeFN2q8Wexvx4t3mAmHPCCSfUBL0dd9yxzvt08803z+02YRdisXSBBRaoic142uFFt9FGG6WECoQF80yzggn/QN388x7DM844Y3Kcc34Mxo0bF2adddakH/SH9HicnnfeebVXo/F0xDvR+soWwTTLvGg888wzhznnnDOVz8pYYYUVUtkvv/zylHc1ItSGG25Y8+TFUxnhfamllkqVhUc2gmtfDNHJWE099dRJufPOO29yHC9Lb97TGO9J68sPfvCDsPrqq9fEpJ133jkltJGGfCZy+fLY5zX4RRZZJCmL9HDbc889a+EcCH+A0BV7MzPXmjUvGvuHH8stt1w466yzAt7HhBhgbltf2TJX4zAT1hYTvBi/lVdeOZXPyuChh73+34inMZ7Fvs2Ix/A+5JBDAvPJe6RS15JLLmnNqm0//fTTZGyZ49YerhWbC3hTx7bLLrskacmDFzwewowNAv6uu+4a5phjjlSatddeOy4m+fzKK6+kQp1QJswPP/zwpDxEb2uf997tq2hM5QsttFBS5lprrZW0J2+H8bc2sI1FePIx730axggezJuRI0fWOMUPDvB6zjIvGnMNxEytHkRis2222Sapnwd0zDk8tHljiHsKTP3cpgyurSyrIhojkFs72PJQiHshIi4PESkbj2ufhnnJmGeZF415Y8XycU/ink/7+d3i56ulIQxIr5hE414ZSfVDBERABERABHqAAN4i9oVL276JPuImbpoDmgN9mQMISR988EHX/iWJRWMYIAjwOnFs7733XkoMRNDIEl3I50UpRIiTTjopEdV8uXgLeoGX/bzXzKu+0h57NxP+4osvvvDV1vbxCvYLxtF3wlnE5kVjmyOEO8DDEE9PvAfx1PPCNfGffagBvBsJa5Bl/A33Itqhhx6alayhY75fI0aMyM3rRWPr21FHHVUXR5cYqgi9lobtpZdemlkuwqNPhzdnlhD+/vvvhyWWWCJJO+mkkwbmWDPmBVhrw7777lvnCYp3JWE4/EMSRNYsM9HYymM+I74TZoJwDGeeeWYYNWpUkrUR0djK/OlPf5oZ5gZGXvgjfd4154VwrpU8IwSN7zciX9YDAMbcC5jUbd7Ucdk+njJ8mNOxMQfWX3/9ZLyt782IxrC3cr7zne/khrmxtuywww5J+vnnn98OJ1tC71h5bPGIzoo7jljv7zP8HeBeFpsXja3crHvH7bffXssKI//w5qCDDoqLrH3GG3no0KFJW7nX4CEdm587xx9/fHy6Np7WLrakJyxHbFwvzGv6aekRurM8rL1obGkR1bNi4sdvkiAm94pJNO6VkVQ/REAEREAERKAHCPBFcY899qh5YfHkXv/EQHNAc0BzoP/nAF5uWeJqN/1ZyRKNi17zZiEj/wr6GmusUdddRFSEIxMM8CwrMjw8vdfvsccem5m8imgcexJusMEGmWXZQcQXLzTiwRcvapclGrNAXJHts88+Sf+JWYrAWGR4MRov0r/55ptFyUvP9VU0xqMyzxDevQfzgQceWJcUge3HP/5x0hdEwiKD/69//eskfZHYWVSOnfNjCc8ib3jybLvttkndCGJZ8ZVj0bhM1O+LaEwYkzyLhcc8IbGKaIzI573b8UjOEvR9W/zDArzsGTNvDzzwQMIQ5rE3u09L/csvv3wqfTOiMfONEBF27RA/Pc9ot49FzWKU3nhY5R9gwcm8x30626cveINb3fGbBqSLx460RX8zmAdWHvfErIddVj8PFPzczIo1XyQa037vqc19Jw6vY3XZFmbWPrZ4P8cWi8bDhw+PkySf4fu73/0uKZO46b1iEo17ZSTVDxEQAREQAREQAREQAREQAREYpARi0ZjXkBETigyvWi8cxK8p+7i4vI6d5QEXl++FNmLcZok1VURjvFqtbXjv0r8yw7vY8rCNvSRj0ZhFz4qMWM54PVqZeO6WGf31r67jEdmM9UU0xts1i7tvByKs9SsrXAEhN+w84/i3v/3NZ8/c9/zxXn/99dcz01U56EVjHlyUlYU47728CZsSmxfmYBSLpnF6P5cJNxKbXwgPVnjplpl/UJPnEV1FNL7llluS8aHuMWPGlFVd86b33q+xh7lfkI4xz/LM9ZVQp80Rts2IxpTLgyErr+jaJNSNpeP6JJa0N8KX2Hk8savcOwinYHnYIqB7i0XjZZdd1p+u27/22muT8piXhNopMsYCsZgYw1lvaBSJxlwbvu14/ZYZc58wG5bPFgb1+bxozLXz6quv+tN1+yxiauWRvuzvT10BHXpAonGHDoyaJQIiIAIiIAIiIAIiIAIiIAIiUI1ALBoTb7jM8H7zr7fH3mY+3mZWPNWs8p9++ulEOEBAyBJsqojG3vOP+MFVDJHCi43EPvYWi8ZZi2f59HfddVeqL2VexpaXWLYmnsSxay1N1W1fRGM8QMsML1tr49xzz12X3McwLfIw9Bm/+uqrlGc64l5fzY9jmZez1eHFVrweY/OiMYJYmTUqGpO+zLxHKOFWssz3I89jGy9gG7//9//+X2WBjnjkli++pv3DDsJZVDFfXrOiMSEzrG2MFSFDsoyYx5ZunXXWqUuyxRZbJOd/85vf1J3PO+BjcxMuw1ssGufFPrY8CO4+BASe4Czo2FchtUg09iI63PJielvbbOtDgiBsxw8FvWhMrPAyI26yjQvbzz77rCxLV5yXaNwVw6RGioAIiIAIiIAIiIAIiIAIiIAI5BGIReMXX3wxL2nq+LTTTpv80D/yyCOTc8RB9SIbCzghupb9++tf/5oSDvGIjK2KaOwX36sixlkdiEgmXLCAl7dYNI6FIZ+WfS+qsKAcwlFZ/zlPGA9rA3ybsb6IxlW8m08//fSkjYiOsfnFznbaaadK/abv3nvxuOOOi4ut/NmLxizkVcW8dzqxYWPz87kKo0ZFYxY3KzMveLJQW5ZVEY2J0WtzjAcTVeYlaQhDY/n8gpEIhniH27mqixlusskmSZ5mRWO84704mnXdI8Z67/+s+ws8rB/rrbdeZTaLLrpoki9+oBSLxngzl9nSSy+dlGftQZjm/kdYnKKQFXHZnksc09h7+JKuqiFiW7vY4uXszYvGsCmz+++/P1VenuhfVk6nnZdo3GkjovaIgAiIgAiIgAiIgAiIgAiIgAg0RMCLxngPZ73inFWg93z0Xo0sBuUFhb7us8hcbGWiMcKQry/2gI7L85/9gkyEIPCGaObLLYo/Sz4vQvp8je7HsZV9m8r2+yIaZzGP6/EL78aiMQKiD/XQaH8t/dZbbx1XW/mzF43L4k5boSzSaHXT/tir04vGWeErrBzbNioaP/jgg5Y1d4vXvLWRBdiyrIpovMgiiyTlWHmNbolBbcbChT5/Ubxey8N2v/32S/I1KxpTHvG1rR1ZHvB+cUYeLGWFYfEPwqysRrexd30sGvMWQpkR3qZonIjhvPLKK4dzzz23dBHWItHYL0pYFNYjbi+LJnoucQx8Lxqvu+66cfa6z48++miqvGbjuddV0KYDEo3bBF7VioAIiIAIiIAIiIAIiIAIiIAItIaAF41ZwKyq4e1owoFfAAoBwY43syVUQ2xlovFjjz2Wqvvhhx+Oi8j9jEe0tReR0AuHsWjMQn9FRoxaK6uZLSE7+mp9EY1ZjK/MikRjYpc201/LmxUioqxddt6LxiyKWMXw9LW62X766aepbF40vvLKK1Pnsj40KhpXGedWicYI/b6vfdmfbLLJkm7zhoAvo4oATmbvjd8K0Zj4vN7jOWa6xBJLJO1kkcrYWAzQ96Ov+ywU6C0WjV944QV/Onef9vDwhDcVitrC3CRcSd5ihkWisX/whwd6VePe6ENoxA+bvGj8v//7v6XFSjQuRaQEIiACIiACIiACIiACIiACIiACIjDwBLxoPMkkk1RugH+FmligZrfddltK5GDhNBbuavRfljhXJhqzIJ8XWIh1WtUOOuigJC9CjbdYNC4L4YF3nbUDr+VG+27pm/G4a4do/O677yb9pv+I59aXRraxCOXHomzfi8ZVFnmjPP/AADEs9kL1onEV7/VOFo29iMiil42Mi6X1cXn9/YMxv/3228uGqHbeP3xohWhMof6etOeeeybtiBd8i8MpkJAF3lg40a5bFqyz/jayJcSMt1g0zqrbp4/3efPj1ltvDcSKJnSKtS/ezjvvvGHs2LFx9lTYjjg8BTHMrZxGxoDYx5aP7YUXXpiqV6Lxf3DI0zg1LfRBBERABERABERABERABERABESg2wjEos/nn39eqQszzTRTIhz42LEIF15QuPvuuyuVVyVRmWhMeAQft7RK/FCr15c9yyyz2OHatlHR+IADDkgYsChgO6wdojEeiJNOOmnSd8TYgTYvGo8aNapS9XvssUfS5qmnnrouTy+JxsTrtutzgw02qOtrowdiD92q15wPB9OIYFnUPsRL6xsPa+xtAb94I9dFnvl43PFif3l5yo43Kxr78unPAw88EHbdddcw/fTTJ321PmctQugfEsSiMWK45eW6qWqPP/54ko/8iNreJBr/h4ZEYz8rtC8CIiACIiACIiACIiACIiACItB1BGLRmJjEZYYn5kQTTZQIBz52LOcmnnji5Fwzi5rF7fDCbp7QxOvhJoSMGDEiLiL3MzE9LV+8eFOjovFFF12UlEWZH3/8cW69/XWiHaIxfcHj0TjiZT7Q5kXjgw8+uFL13jOcWLKx9ZJovO222ybjM/vss8dd7dPnKaecMikTAb6K+Xi6eddylXJ8GmKAEzrD5t9DDz1UO+3vCcQBzrOhQ4cmeVdcccW8ZA0db6Vo7Cs2ARlx3Po744wz+iS1/SLR2C9q+b3vfS8R2esKiQ4Qt9rqZPvkk0+mUkg0/g8OicapaaEPIiACIiACIiACIiACIiACIiAC3UYgFo2PPPLI0i7EosFTTz2VyvOrX/0qERWqii9vv/124HX5tdZaKyD2Eis1tiqi8RprrJHUjTd0lYX9CAPhRfB99903VXWjojGxdL2oQszcKoZnLq/Y00+8I/Gc7qt50diHE4jL8yJbszGNKXudddZJ+o6IVYX/119/HRDtEQ932mmn0EhYkbg/XjQmZqt5m8bp7PNnn30WhgwZkrT5iCOOsFPJthtFY+LcZtmJJ56Y9JWFL994442sZHXHttpqq4AYSJzd888/P3WeeLg232edddbSecuc8J6yrRKNadSWW26ZtIUQFcQft7YRfofxzrNddtklSTvFFFMEFtYsM+YXCxOyMN32228frr322lSWRkVjFlrkYQsPrli8r8wuueSSpM30Mx7PItGYRfmMDdvrr7++rLra+bXXXjvJxwOD+D4l0fg/GCUaV5pOSiQCIiACIiACIiACIiACIiACItCpBGLR+Je//GX46quvcpuLSDL33HMnogHiRizM4eHpxYgbbrghtzw7gRhleYgri4gcWxXRGK9nK4ctC26VGTGZfZ5YBG9UNEYUI8SFlYlA9sUXXxQ2AzHrRz/6UZIHr8dmbPjw4UlZCH551mrROObvQ5fktYEYxsaKLWJWX82LxpQVvzofl0sMWl931kJl3SIas+iY9YWHJ1nGYoU+hEsVwTZeqCyO24vYaPWyLQsL4hfBI32VNmT1JesYC/FZWwg3ccghhySf/397d/Ny2xTHAXxEGSgD5aXLwEAJE0pkgjsgpaRkoJCSkZcYGJFMDOR2B5QUUQbKkIGXSBEGSgZmKN1u3vPyD2x9D+u0z372ec557n3Wc+8vn12389xz9vmttT/rnDP47rXX3nSzty+++GK5b2pk+YZNW9a4bu3lMVcZjLe9hsY5ydbq5UTKpu3tt99e7p/v8vQkzW6hcZYWueSSS5bvz3dnup73tP3MKh7fcHC8nn3bV2j8r4TQuH0iPBIgQIAAAQIECBAgQIBASYFpaJzAIoHjNHzIwSUcHq/Xm33bJeDjg08YkbV8W/iR0HQujGvvyUzccTCX2apz2zahcfo4XmoiM+ESJK3b0nZC6tbXzNCdhuB7DY3T1nvvvbesmdqZ+bkujM9NuG6//faV/TeFneuOpz2f9U3bMd16663t6R2P+x0ax268bm5md3766ac72m1PfPnll8PZZ5+97GtmqU/9277bPE5D4yxN8OOPP86+NevD5qaHzemuu+6a3W/82Tydb4Q3/m5ec801ax2ffvrp5THn2DPDfZ35L7/8MozX+j3rrLOG3377bcUpn9+rrrpqWfOiiy4a8p2Z2zLzN+tGN/M87mdonOO4/PLLl/XPP//85d/brK8+njWdmdjTmcPjY8oNMc8777xl/QsvvHDH7+ZeQ+PxusyxmYbQ4/YT8N52223L9ud+N3cLjVNretVIlheZzhxubeZEXj5XbZmVlNwAABMcSURBVOzik6sqpluv0DgnJ3KD1Px7//33p82edv8XGp92Q6JDBAgQIECAAAECBAgQILAXgbnQOKFALrf+8MMPF0FnwonMvs3SES0wyGPWJV23vfPOOyv7Zp3j3Igpl0+3gOrnn38eElKceeaZy31zWXiCpbltm9A470tgNQ6CU/+5554bvv/++0XbCUWy/MXDDz+8bDfHkwA1HtPtRELj1LjjjjtW6icQ/eijj5aXyMf1s88+G2666aaV/WLfjKZ92fb/zz777ErN2L3wwgtDlicYb/sdGqd21sU+44wzlu0ndM0458RBm8n4999/D0eOHFkJbfOekw3Lp6FxxjVhXsK/tJktIXIcxkuS5AZ+c7Pbs3+V0Hg6gzchYo5zuuRM1v4dLw8Ro3xWv/rqqyFLhWTLSaOcULn00kuX45j95pbvyP4J/8dO8cwyFr///vuiXh6z/Mn4Rompl3/7GRqnseeff36lz2kjS6Vs85366aefVtZFznsffPDB4ZtvvlmGqTkplhv+5XPVjiGPCXyn215D41yRML7JaD6jufHd8ePHl/3Pd+jrr79enNwbt//WW29Nmx82hcYxueWWW1aOI0vkfP7550OOM1tOHGQZjHFAnnYzi3tu6xUaj9uf3qx0rh+n+jmh8akeAe0TIECAAAECBAgQIECAwEkJjEPjBIgJ98ZBRGYWnnPOOSvP5fXMJp3OOJx2JMHlODxsdbOG7LnnnrujZm7GlNmf67ZtQ+O8/4033liZwTpuO+20/7fHLA2xbi3dEw2NE04ePnx4R1u5vDuzMcehZevHjTfeuAxr1jls8/z0svlWP7MDWzCYOj1C49TNDMlx7dZ+ZhVfcMEFsyYJpk52G4fGCelzvK3thJpzbedExW5LYozD0NN5pvEnn3yyPNZ2zO0xwd94yxUC43Cy7Zfvaz6bY7f22uOPP74MLse12t8Jhccna9r7puFqxiBLP7TX9zs0zsmoaT+2vSlijiVXCYxnKLd+5rfw0KFDK8sztNdyQmxu22tonBo56TL3m5vfrYT9c78b99133+zYbAqN015O5F1//fXL8WjHFMPp2LXXciXDuhnJQuN/PwlC47lvhOcIECBAgAABAgQIECBAoIzAODROUJEts3JbODB9TICWGWZtxuimA82MuPEayNN67f+Z7Za1U3fb9hIap84PP/ywuLFca2PdY9YRzUy+dduJhsapl5l8ufw/yzSsaz/PJxBKYN9mw67ry7bPp93xjb3GbY9vMjgOdvfjRnjj/uUGg1kaY9z23N9Z2uDdd98dv/WE/x6Hxs8888zwwQcfrMxmnrZ/7bXXrp3Z3jpRJTROf6drNLfj/fjjj9vhLB8zq/XRRx+dDUHb+/KYoDTrTm8zUzfe43Vyx3Xy98UXXzxkWYfM1G2v7XdonAPMbP1WPydppjeIWyKs+SMzo+++++5ljVZr+pgZr7ud7DiR0DhdypI6N9xww8b287uS3+ssETK3bRMa530JgDNDey6QHh9zPgu7HW9qCY3/HQmh8dwn0nMECBAgQIAAAQIECBAgUEbgr7/+Go4ePbr4l3CzbQlwEyLksvWsC3vvvfcOL7744uIy7bbPto+51D03w8tl8vfcc88iRL766quHO++8c3jiiScWl0JvUyuBVOtrlr/YZkvQlWU2ciyZjZeAMiF21hB+8sknh++++25jmQRIrd08/vHHHxvfM93h2LFjixuEJRjOOqSXXXbZIhS6//77Fy6//vrr9C0n/f8cey4zzxIFOfasq5x1b8dLcCQMbMeWcHzTlmVK2v4vv/zypt0XQWNm8WYm5gMPPDBcd911w5VXXrnwf+yxx4aM4zZh5MaG/tthGhrn6ZwQePXVV4esV3vFFVcs3HPTuMzM3abt9L0d87fffruxK1nnte3/2muv7dj/zz//XL6e/TbN2E+BzH5tNTd99tP+Sy+9tBjvjPtTTz21do3h1M6YZmmLRx55ZDEzPp/NnMTJDRRfeeWVtWtx7ziw/55IgJmlGrJ8TUL5fNcfeuih4c033xza5zwnLrY9nnXt7PZ8Tla1+lkm40S3XPmQ70gsst551ktOKJqlbXI862bbtvZO9rcj64FneYosDZTvTtrP3/ktzVIum36L8rlvDll+ZNOWGyXmM5tZ5VkbPutZ52qJ/Hbkc7fpeFM/6yS3NrdZbiYzw9v+ecxNQee2/N60/V5//fW5XU6r54TGp9Vw6AwBAgQIECBAgAABAgQIECDwfxaYC43/zx6OnQCBUyMgND417lolQIAAAQIECBAgQIAAAQIECOwQEBrvIPEEAQKnQEBofArQNUmAAAECBAgQIECAAAECBAgQmBMQGs+peI4AgYMWEBoftLj2CBAgQIAAAQIECBAgQIAAAQJrBITGa2A8TYDAgQoIjQ+UW2MECBAgQIAAAQIECBAgQIAAgfUCQuP1Nl4hQODgBITGB2etJQIECBAgQIAAAQIECBAgQIDArgJC4115vEiAwAEJCI0PCFozBAgQIECAAAECBAgQIECAAIFNAjfffPNw6NChxb+jR49u2t3rBAgQ6CIgNO7CqigBAgQIECBAgAABAgQIECBAgAABAgRqCgiNa46bXhMgQIAAAQIECBAgQIAAAQIECBAgQKCLgNC4C6uiBAgQIECAAAECBAgQIECAAAECBAgQqCkgNK45bnpNgAABAgQIECBAgAABAgQIECBAgACBLgJC4y6sihIgQIAAAQIECBAgQIAAAQIECBAgQKCmgNC45rjpNQECBAgQIECAAAECBAgQIECAAAECBLoICI27sCpKgAABAgQIECBAgAABAgQIECBAgACBmgJC45rjptcECBAgQIAAAQIECBAgQIAAAQIECBDoIiA07sKqKAECBAgQIECAAAECBAgQIECAAAECBGoKCI1rjpteEyBAgAABAgQIECBAgAABAgQIECBAoIuA0LgLq6IECBAgQIAAAQIECBAgQIAAAQIECBCoKSA0rjluek2AAAECBAgQIECAAAECBAgQIECAAIEuAkLjLqyKEiBAgAABAgQIECBAgAABAgQIECBAoKaA0LjmuOk1AQIECBAgQIAAAQIECBAgQIAAAQIEuggIjbuwKkqAAAECBAgQIECAAAECBAgQIECAAIGaAkLjmuOm1wQIECBAgAABAgQIECBAgAABAgQIEOgiIDTuwqooAQIECBAgQIAAAQIECBAgQIAAAQIEagoIjWuOm14TIECAAAECBAgQIECAAAECBAgQIECgi4DQuAurogQIECBAgAABAgQIECBAgAABAgQIEKgpIDSuOW56TYAAAQIECBAgQIAAAQIECBAgQIAAgS4CQuMurIoSIECAAAECBAgQIECAAAECBAgQIECgpoDQuOa46TUBAgQIECBAgAABAgQIECBAgAABAgS6CAiNu7AqSoAAAQIECBAgQIAAAQIECBAgQIAAgZoCQuOa46bXBAgQIECAAAECBAgQIECAAAECBAgQ6CIgNO7CqigBAgQIECBAgAABAgQIECBAgAABAgRqCgiNa46bXhMgQIAAAQIECBAgQIAAAQIECBAgQKCLgNC4C6uiBAgQIECAAAECBAgQIECAAAECBAgQqCkgNK45bnpNgAABAgQIECBAgAABAgQIECBAgACBLgJC4y6sihIgQIAAAQIECBAgQIAAAQIECBAgQKCmgNC45rjpNQECBAgQIECAAAECBAgQIECAAAECBLoICI27sCpKgAABAgQIECBAgAABAgQIECBAgACBmgJC45rjptcECBAgQIAAAQIECBAgQIAAAQIECBDoIiA07sKqKAECBAgQIECAAAECBAgQIECAAAECBGoKCI1rjpteEyBAgAABAgQIECBAgAABAgQIECBAoIuA0LgLq6IECBAgQIAAAQIECBAgQIAAAQIECBCoKSA0rjluek2AAAECBAgQIECAAAECBAgQIECAAIEuAkLjLqyKEiBAgAABAgQIECBAgAABAgQIECBAoKaA0LjmuOk1AQIECBAgQIAAAQIECBAgQIAAAQIEuggIjbuwKkqAAAECBAgQIECAAAECBAgQIECAAIGaAkLjmuOm1wQIECBAgAABAgQIECBAgAABAgQIEOgiIDTuwqooAQIECBAgQIAAAQIECBAgQIAAAQIEagoIjWuOm14TIECAAAECBAgQIECAAAECBAgQIECgi4DQuAurogQIECBAgAABAgQIECBAgAABAgQIEKgpIDSuOW56TYAAAQIECBAgQIAAAQIECBAgQIAAgS4CQuMurIoSIECAAAECBAgQIECAAAECBAgQIECgpoDQuOa46TUBAgQIECBAgAABAgQIECBAgAABAgS6CAiNu7AqSoAAAQIECBAgQIAAAQIECBAgQIAAgZoCQuOa46bXBAgQIECAAAECBAgQIECAAAECBAgQ6CIgNO7CqigBAgQIECBAgAABAgQIECBAgAABAgRqCgiNa46bXhMgQIAAAQIECBAgQIAAAQIECBAgQKCLgNC4C6uiBAgQIECAAAECBAgQIECAAAECBAgQqCkgNK45bnpNgAABAgQIECBAgAABAgQIECBAgACBLgJC4y6sihIgQIAAAQIECBAgQIAAAQIECBAgQKCmgNC45rjpNQECBAgQIECAAAECBAgQIECAAAECBLoICI27sCpKgAABAgQIECBAgAABAgQIECBAgACBmgJC45rjptcECBAgQIAAAQIECBAgQIAAAQIECBDoIiA07sKqKAECBAgQIECAAAECBAgQIECAAAECBGoKCI1rjpteEyBAgAABAgQIECBAgAABAgQIECBAoIuA0LgLq6IECBAgQIAAAQIECBAgQIAAAQIECBCoKSA0rjluek2AAAECBAgQIECAAAECBAgQIECAAIEuAkLjLqyKEiBAgAABAgQIECBAgAABAgQIECBAoKaA0LjmuOk1AQIECBAgQIAAAQIECBAgQIAAAQIEuggIjbuwKkqAAAECBAgQIECAAAECBAgQIECAAIGaAkLjmuOm1wQIECBAgAABAgQIECBAgAABAgQIEOgiIDTuwqooAQIECBAgQIAAAQIECBAgQIAAAQIEagoIjWuOm14TIECAAAECBAgQIECAAAECBAgQIECgi4DQuAurogQIECBAgAABAgQIECBAgAABAgQIEKgpIDSuOW56TYAAAQIECBAgQIAAAQIECBAgQIAAgS4CQuMurIoSIECAAAECBAgQIECAAAECBAgQIECgpoDQuOa46TUBAgQIECBAgAABAgQIECBAgAABAgS6CAiNu7AqSoAAAQIECBAgQIAAAQIECBAgQIAAgZoCQuOa46bXBAgQIECAAAECBAgQIECAAAECBAgQ6CIgNO7CqigBAgQIECBAgAABAgQIECBAgAABAgRqCgiNa46bXhMgQIAAAQIECBAgQIAAAQIECBAgQKCLgNC4C6uiBAgQIECAAAECBAgQIECAAAECBAgQqCkgNK45bnpNgAABAgQIECBAgAABAgQIECBAgACBLgJC4y6sihIgQIAAAQIECBAgQIAAAQIECBAgQKCmgNC45rjpNQECBAgQIECAAAECBAgQIECAAAECBLoICI27sCpKgAABAgQIECBAgAABAgQIECBAgACBmgJC45rjptcECBAgQIAAAQIECBAgQIAAAQIECBDoIiA07sKqKAECBAgQIECAAAECBAgQIECAAAECBGoKCI1rjpteEyBAgAABAgQIECBAgAABAgQIECBAoIuA0LgLq6IECBAgQIAAAQIECBAgQIAAAQIECBCoKSA0rjluek2AAAECBAgQIECAAAECBAgQIECAAIEuAkLjLqyKEiBAgAABAgQIECBAgAABAgQIECBAoKaA0LjmuOk1AQIECBAgQIAAAQIECBAgQIAAAQIEuggIjbuwKkqAAAECBAgQIECAAAECBAgQIECAAIGaAkLjmuOm1wQIECBAgAABAgQIECBAgAABAgQIEOgiIDTuwqooAQIECBAgQIAAAQIECBAgQIAAAQIEagoIjWuOm14TIECAAAECBAgQIECAAAECBAgQIECgi4DQuAurogQIECBAgAABAgQIECBAgAABAgQIEKgpIDSuOW56TYAAAQIECBAgQIAAAQIECBAgQIAAgS4CQuMurIoSIECAAAECBAgQIECAAAECBAgQIECgpoDQuOa46TUBAgQIECBAgAABAgQIECBAgAABAgS6CAiNu7AqSoAAAQIECBAgQIAAAQIECBAgQIAAgZoCQuOa46bXBAgQIECAAAECBAgQIECAAAECBAgQ6CIgNO7CqigBAgQIECBAgAABAgQIECBAgAABAgRqCgiNa46bXhMgQIAAAQIECBAgQIAAAQIECBAgQKCLgNC4C6uiBAgQIECAAAECBAgQIECAAAECBAgQqCkgNK45bnpNgAABAgQIECBAgAABAgQIECBAgACBLgJC4y6sihIgQIAAAQIECBAgQIAAAQIECBAgQKCmgNC45rjpNQECBAgQIECAAAECBAgQIECAAAECBLoI/AOUjJ8utNWHygAAAABJRU5ErkJggg==" title="Strategic goals can be organized as hierarchies." width="400" /></p>
<p class="MsoNormal" style="margin-bottom: 12.0pt; tab-stops: 26.95pt;"><i><span style="font-size: 12pt;">Fig. 2-1: Strategic goals can be organized as hierarchies.</span></i></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">For example, one of your strategic intermediate
objectives may be to deliver value earlier, so you can get paid sooner. There
are many ways to do this. One tactic could be to reduce the amount of work done
in each delivery cycle. Another tactic could be to do work in parallel, rather
than sequentially. A third tactic could be to eliminate work that does not add
value.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">I decided to use this book itself to demonstrate how
to deliver value early, in a manner that you as a reader can easily verify: I
publish the first draft of each chapter on my blog, as I write them. You get
value early, I get early feedback.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">Of course, publishing all the material on my blog
might undercut sales, but making a lot of money from book sales is not my goal.
I am more interested in spreading useful knowledge, and I happen to like to
write.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">For those of you who believe there absolutely,
positively, has to be a financial goal, yes, there is: So far, my books haven’t
generated much money through sales. They are too specialized for that. However,
they have contributed to me getting work I might otherwise have missed, so
indirectly, they have been profitable.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">A strategic goal and its corresponding tactics can be
broken down into its own set of intermediate strategies and tactics. This book
will teach you how to do that.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">Sometimes the problem is that you don’t know what the
problem is. All you know is that something hurts, and you want to hurt less, or
something feels good, and you want more of it. You will learn how to get a
handle on those situations too.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">This book emphasizes merging strategic planning and
implementation into a unified whole. Most strategy methods separate thinking
and acting. That is a mistake I want to avoid, because just as the way you
think will influence the way you act, the way you act will influence the way
you think. Separate thinking and acting, and you will neither think, nor act, very well.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">Strategic Navigation, the framework for thinking and
doing in this book, is intended to support you all the way, with methods for
how to think and how to do. What you think, and what you do, is up to you
though.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">The methods you will find in this book emphasize short
planning and execution cycles, fast learning, and the ability to change
quickly. In short: Agility!<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">You will learn visual planning, how to implement what
you plan, how to make use of serendipitous events, and also how to tip the
scale in your favor, so that serendipitous events occur a bit more often.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">Strategic Navigation is a civilian adaptation of ideas
from <i style="mso-bidi-font-style: normal;">Maneuver Conflict</i>, a military
strategic framework created by Col. John Boyd, of the U.S. air force. His ideas
have become very important both to military and business strategy. The ideas
have also, over the past decade or so, become an increasingly important
influence on agile software development, as well as the business agility
movement.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">In Strategic Navigation, the strategic framework, is
combined with a powerful planning and problem solving tool, <i style="mso-bidi-font-style: normal;">The Logical Thinking Process</i>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">The original Thinking Process was developed by Dr.
Eliyahu Goldratt, and is a part of the Theory Of Constraints. The version in
this book is based on further developments of the method by Bill Dettmer, and
to top it off, some ideas of my own.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">The name <i style="mso-bidi-font-style: normal;">Strategic
Navigation</i> is a homage to Bill Dettmer’s book of the same name. Over the
years, my way of working has diverged a bit from what Bill Dettmer originally
wrote, but if you read his book, which I recommend, you will recognize The
Logical Thinking Process in Part C: Navigation.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">Each organization is different, and that makes recipes
for how to do things of limited value. Recipes will not fit your situation, and
while trying to follow them <i style="mso-bidi-font-style: normal;">might</i>
work, it can also lead to painful failure.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">Your chances of success will improve if you understand
<i style="mso-bidi-font-style: normal;">how</i> things work, <i style="mso-bidi-font-style: normal;">why</i> they work, <i style="mso-bidi-font-style: normal;">when</i> they
work, and very importantly, <i style="mso-bidi-font-style: normal;">when they
don’t work</i>. Thus, throughout the book, I will emphasize <i style="mso-bidi-font-style: normal;">understanding</i>, not just route doing.
What you will need, is a good understanding of your organization, and the
people in it, as a system, that is, a whole composed of interconnected parts.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">Most of the time, how the parts connect is way more
important than what the parts are, so we will spend a lot of effort on how to
visualize and understand those connections.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; tab-stops: 26.95pt;"><span style="font-size: 12.0pt;">A bunch of connected parts, that influence each other
through their connections, is a <i style="mso-bidi-font-style: normal;">system</i>.
The entire first part of this book is devoted to building a basic understanding
of systems.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 0cm; margin-right: 0cm; margin-top: 12.0pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-size: 18.0pt;">Takeaways</span></b><span style="font-size: 12.0pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-size: 12.0pt;"><span style="mso-list: Ignore;">●<span style="font: 7.0pt "Times New Roman";">
</span></span></span><!--[endif]--><span style="font-size: 12.0pt;">A strategy
answers the question <i style="mso-bidi-font-style: normal;">What is my ultimate
objective, and what intermediate objectives do I need to achieve in order to
achieve my ultimate objective?</i><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-size: 12.0pt;"><span style="mso-list: Ignore;">●<span style="font: 7.0pt "Times New Roman";">
</span></span></span><!--[endif]--><span style="font-size: 12.0pt;">A tactic is the
answer to the question: <i style="mso-bidi-font-style: normal;">How do we achieve
a strategic objective?</i><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-size: 12.0pt;"><span style="mso-list: Ignore;">●<span style="font: 7.0pt "Times New Roman";">
</span></span></span><!--[endif]--><span style="font-size: 12.0pt;">Strategic
objectives can be hierarchically organized.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-size: 12.0pt;"><span style="mso-list: Ignore;">●<span style="font: 7.0pt "Times New Roman";">
</span></span></span><!--[endif]--><span style="font-size: 12.0pt;">There must be at
least one tactic for each strategic objective.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; text-align: left; text-indent: -36pt;"><span style="font-size: 12pt; text-indent: -36pt;">●<span style="font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;">
</span></span><span style="font-size: 12pt; text-indent: -36pt;">Strategic
planning and execution must be an organic whole! Split thinking and acting up, and you will neither think, nor act, very well.</span><!--[if !supportLists]--></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-size: 12.0pt;"><span style="mso-list: Ignore;">●<span style="font: 7.0pt "Times New Roman";">
</span></span></span><!--[endif]--><span style="font-size: 12.0pt;">Your chances of
success will improve if you understand <i style="mso-bidi-font-style: normal;">how</i>
things work, <i style="mso-bidi-font-style: normal;">why</i> they work, <i style="mso-bidi-font-style: normal;">when</i> they work, and very importantly, <i style="mso-bidi-font-style: normal;">when they don’t work</i>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-list: l0 level1 lfo1; tab-stops: 26.95pt; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-size: 12.0pt;"><span style="mso-list: Ignore;">●<span style="font: 7.0pt "Times New Roman";">
</span></span></span><!--[endif]--><span style="font-size: 12.0pt;">In a system, how
the parts connect is way more important than what the parts are.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6.0pt; margin-left: 36.0pt; margin-right: 0cm; margin-top: 0cm; mso-list: l0 level1 lfo1; tab-stops: 26.95pt; text-indent: -36.0pt;"><!--[if !supportLists]--><span style="font-size: 12.0pt;"><span style="mso-list: Ignore;">●<span style="font: 7.0pt "Times New Roman";">
</span></span></span><!--[endif]--><span style="font-size: 12.0pt;">Your organization
is a system.<o:p></o:p></span></p>
<div style="mso-element: footnote-list;"><!--[if !supportFootnotes]--><br clear="all" />
<hr align="left" size="1" width="33%" />
<!--[endif]-->
<div id="ftn1" style="mso-element: footnote;">
<p class="MsoNormal"><a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-02%20Strategy,%20tactics,%20and%20maneuver.docx#_ftnref1" name="_ftn1" style="mso-footnote-id: ftn1;" title=""><i style="mso-bidi-font-style: normal;"><sup><span style="font-size: 12.0pt;">1</span></sup></i></a><span style="font-size: 12.0pt;"> </span><span style="font-size: 11.0pt;">In the first edition of Tempo, strategy was defined as
“the means and methods required to fulfill the conditions necessary to achieve
the ultimate goal of a system”. However, this definition conflates strategy and
tactics. It is better to separate the two.</span><o:p></o:p></p>
</div>
<div id="ftn2" style="mso-element: footnote;">
<p class="MsoNormal"><a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-02%20Strategy,%20tactics,%20and%20maneuver.docx#_ftnref2" name="_ftn2" style="mso-footnote-id: ftn2;" title=""><sup><span style="font-size: 12.0pt;">2</span></sup></a><span style="font-size: 12.0pt;"> </span><span style="font-size: 11.0pt;">The definitions
of strategy and tactics used here borrows heavily from the Theory of
Constraints. It is one of the few definitions of business strategy and tactics
that is consistent with strategy and tactics in other contexts, such as war,
game theory, and games.</span><o:p></o:p></p>
</div>
</div><span><a name='more'></a></span></div><span><!--more--></span>Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-31769458767113039092020-08-10T15:38:00.003+02:002021-04-26T12:00:12.465+02:00Tempo 2.0 - Chapter 1: Create time to think<div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-I80U_j2ZlKY/XzFdtlwAhGI/AAAAAAAB0i0/ssbrFueHvMkawMdt2_tn6IiKHjf8x9AdACLcBGAsYHQ/s2861/IMG_2597_DxO_cropped.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1099" data-original-width="2861" height="197" src="https://1.bp.blogspot.com/-I80U_j2ZlKY/XzFdtlwAhGI/AAAAAAAB0i0/ssbrFueHvMkawMdt2_tn6IiKHjf8x9AdACLcBGAsYHQ/w512-h197/IMG_2597_DxO_cropped.jpg" width="512" /></a></div><p>I made a mistake 10 years ago: I wrote and published my first management and leadership book, <i>Tempo</i>, in Swedish. That cut off most of my friends in the management community from reading it. It also limited the overall number of people who could read the book.</p><p>I have finally decided to do something about it: I am rewriting <i>Tempo</i> to keep it current, and I am doing the rewrite in English.</p><p>I will also publish the first draft of each chapter on this blog. You are welcome to read, and also to review and comment. Please click the comment link at the bottom of this post.</p><p>Eventually, I'll publish <i>Tempo 2.0</i> as a book, but this way, I can deliver value early, and with a bit of luck, I can get early feedback from people with many different points of view.</p><p>Enough preamble, here is the first draft of the first revised chapter. I do hope you enjoy it.</p><span><a name='more'></a></span><p><br /></p><p class="MsoNormal" style="margin: 6pt 0cm 6pt 36pt;"><span style="font-size: 12pt;">We are not fit to lead an
army on the march unless we are familiar with the face of the country—its
mountains and forests, its pitfalls and precipices, its marshes and swamps.<br />
— <i style="mso-bidi-font-style: normal;">The Art of War</i>, by Sun Tzu<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;">Have you ever had the feeling that work in your organization could, and should, be a bit easier and smoother than it actually is? You are probably right. Would you like to do something about it? Reduce the pain, and increase the joy, of working? This book is written for you. I do hope you will find the things in here as useful as I have.</p><p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span>There is a little snag I should tell you about upfront. </span><span style="font-size: 12pt;">This book will be useful to you only if you do quite a
bit of thinking. It is likely that you who read this is a manager or leader.
Most managers and leaders I know are intelligent people, but they often lack
the time to reflect, think, and learn. That is why we will start by creating a
little bit of extra time for you, time to read this book, time to reflect on
it, time to practice, and time to focus on the things most important to you and
your company.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Starting tomorrow morning, do the following:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 6pt 0cm 6pt 36pt;"><span style="font-size: 12pt;">Begin each day by asking
yourself: <i style="mso-bidi-font-style: normal;">What can I do that is of the
most benefit to my organization today?</i><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Focus on strategic decisions. Delegate decisions
concerning the daily work. <i style="mso-bidi-font-style: normal;">Don’t make
decisions that can be made by someone else!</i><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Give the people who work for you opportunities to make
decisions of their own. Even if they make decisions that are worse than the
ones you would have made, your company will still benefit, because it frees you
up to make really good decisions about things that are important.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">I recommend that your first really important decision
will be to read the rest of this book.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Oh, and you will also need to practice, and reflect on
what you learn. To really know something, you will have to spend a lot more
time practicing than reading about it. It is by practice you learn skills and
form new habits.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 12pt 0cm 6pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-size: 18pt;">Is learning worth your time?</span></b><span style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 12pt 0cm 6pt;"><span style="font-size: 12pt;">Acquiring a new habit
requires quite a bit of effort. Letting go of old ones is even harder. Is it
worth it? Ultimately, only you can decide if it is worth it for you, but let’s
do a simple thought<span style="mso-spacerun: yes;"> </span>experiment<a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-01%20Create%20time%20to%20think/Create%20time%20to%20think%20PA1.docx#_ftn1" name="_ftnref1" style="mso-footnote-id: ftn1;" title=""><sup>1</sup></a>
to think it through.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">It is by no means a very accurate experiment.
Nevertheless, it can serve as a guide on how to think about the value of
learning useful things.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;">Reading this book, learning what’s in it, practicing it,
and applying it, requires time. You may regard that time as an investment. So,
how much time is it reasonable for you to invest?<o:p></o:p></span></p>
<p class="MsoNormal"><b style="mso-bidi-font-weight: normal;"><span style="font-size: 12pt;">What is the value of your learning time?</span></b><span style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Let’s say you work alone, or that you only want to
improve your personal life. You use what you will learn from this book to
either reduce the time it takes to execute a recurring task, or to change the
process so you can eliminate it entirely.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">This is just a very rough approximation, so lets say
you work 8 hours per day, 5 days per week. To simplify a bit, lets say a month
is always four weeks, and that you work 12 months per year. You want to recoup
the time you spend improving your process within 5 years.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Thus, if you want to save 1 hour on a daily task, how
many hours can you spend improving your process?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">The task is daily, so you will perform it 5 times per
week, 20 times per month, or 240 times per year. In five years, you will
perform the task 1200 times. The task took 1 hour each time, so if you spend
less than 1200 hours improving it, you will come out ahead.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Given your 40 hour work week, you can spend up to <i style="mso-bidi-font-style: normal;">30 weeks</i> learning how to shave off 1
hour on your daily task.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Let’s construct a table for this:<o:p></o:p></span></p>
<table border="1" cellpadding="0" cellspacing="0" class="MsoNormalTable" style="border-collapse: collapse; border: none; margin-left: 1.5pt; mso-border-left-alt: solid black .75pt; mso-border-right-alt: solid black .75pt; mso-border-top-alt: solid black .75pt; mso-padding-alt: 0cm 1.5pt 0cm 1.5pt; mso-yfti-tbllook: 1184;">
<tbody><tr style="mso-yfti-firstrow: yes; mso-yfti-irow: 0;">
<td style="border: 1pt solid gray; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td colspan="7" style="border: 1pt solid gray; mso-border-left-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 372.4pt;" valign="top" width="497">
<p align="center" class="MsoNormal" style="text-align: center;"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">Frequency
of Task</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 1;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">Time Saved</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 47.4pt;" valign="top" width="63">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Hour</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Day</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 52.15pt;" valign="top" width="70">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Week</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 65.65pt;" valign="top" width="88">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Fortnight</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 55.5pt;" valign="top" width="74">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Month</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Quarter</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Year</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 2;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 Hour</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 47.4pt;" valign="top" width="63">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">9600</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1200</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 52.15pt;" valign="top" width="70">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">240</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 65.65pt;" valign="top" width="88">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">120</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 55.5pt;" valign="top" width="74">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">60</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">20</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">5</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 3;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 day</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 47.4pt;" valign="top" width="63">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">9600</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 52.15pt;" valign="top" width="70">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1920</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 65.65pt;" valign="top" width="88">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">960</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 55.5pt;" valign="top" width="74">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">480</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">160</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">40</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 4;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 Week</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 47.4pt;" valign="top" width="63">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 52.15pt;" valign="top" width="70">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">9600</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 65.65pt;" valign="top" width="88">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">4800</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 55.5pt;" valign="top" width="74">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">2400</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">800</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">200</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 5;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">2 Weeks</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 47.4pt;" valign="top" width="63">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 52.15pt;" valign="top" width="70">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 65.65pt;" valign="top" width="88">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">9600</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 55.5pt;" valign="top" width="74">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">4800</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1600</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">400</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 6;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 Month</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 47.4pt;" valign="top" width="63">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 52.15pt;" valign="top" width="70">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 65.65pt;" valign="top" width="88">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 55.5pt;" valign="top" width="74">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">9600</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">3200</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">800</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 7;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 Quarter</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 47.4pt;" valign="top" width="63">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 52.15pt;" valign="top" width="70">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 65.65pt;" valign="top" width="88">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 55.5pt;" valign="top" width="74">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">9600</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">2400</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 8;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">6 Months</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 47.4pt;" valign="top" width="63">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 52.15pt;" valign="top" width="70">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 65.65pt;" valign="top" width="88">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 55.5pt;" valign="top" width="74">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">4800</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 9; mso-yfti-lastrow: yes;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 Year</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 47.4pt;" valign="top" width="63">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 52.15pt;" valign="top" width="70">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 65.65pt;" valign="top" width="88">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 55.5pt;" valign="top" width="74">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 59.6pt;" valign="top" width="79">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 46.05pt;" valign="top" width="61">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">9600</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
</tbody></table>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><i><span style="font-size: 12pt;">Let it sink
in</span></i><span style="font-size: 12pt;">: You can spend up to 30 weeks on
learning how to shave 1 hour off your daily schedule, and you will come out
ahead, in terms of time spent.</span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Let’s say you are a writer. It takes you 6 months to
write a book. Assuming you can reduce that time to 3 months, you will save 3
months. That is 1 quarter. So far, you have been able to write 2 books per
year.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">We do not have a 2 per year column in the table, but
we can look along the 1 Quarter row, at the 1 per year column, and see that if
we publish 1 book per year, we could spent up to 2400 hours learning how to
produce a book faster. We can double that for 2 books per year, so it is worth
learning if we can spend less than 4800 hours learning it.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">That is 120 weeks, which is about 2 years, 3 months.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">How realistic is that? Well, my first management book,
the original version of <i style="mso-bidi-font-style: normal;">Tempo</i>, took
more than 2 years to write. The book after that, the anthology <i style="mso-bidi-font-style: normal;">LESS!</i>, took about 1 year.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">The next time I considered writing a book, I thought:
What if I apply the things I write about to my own writing process?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">I did, and wrote and published a book in less than 2
weeks. I tried it again, and did it in less than 2 weeks, from planning to
publishing.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">The third time, I wrote a book about how to write and
publish a book in two weeks, in less than two weeks. It was a close call the
last time. As I recall, I published on the 14th day.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Here is the thing: I was, and still am, a slow writer.
I did not learn how to write faster, I removed delays in the process, and I
reduced the size of transfer batches! Exactly what that means, is something you
will learn in this book. The ideas I used are from manufacturing, from software
development, and from mathematics. I just applied them to an area where few
people had applied them before.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">There was one thing that did not go as planned: I
tried to spread my ideas about optimizing the writing process among other
writers. Most just ignored me, and more than a few got upset. The very idea
that someone could write a book in two weeks was an affront. At the very least,
it had to be by working harder, not by working smarter.<a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-01%20Create%20time%20to%20think/Create%20time%20to%20think%20PA1.docx#_ftn2" name="_ftnref2" style="mso-footnote-id: ftn2;" title=""><sup>2</sup></a> <o:p></o:p></span></p>
<p class="MsoNormal"><b style="mso-bidi-font-weight: normal;"><span style="font-size: 12pt;">The value of knowledge increases when more people use
it!</span></b><span style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 12pt 0cm 6pt; text-align: left;"><span style="font-size: 12pt;">It is time to push our
thought experiment a couple of steps further.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Let’s assume that you are responsible for, or at least
have influence over, how people other than yourself work. Let’s also assume
that you are prepared to risk riling up an angry mob, or getting burned at the
stake for witchcraft, or, that you work with colleagues, and for a boss that
likes you to stir things up a bit.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">If you can influence the way 10 people work, what will
the table look like then?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">I’ll switch the scale from hours to days, in order to
keep the numbers reasonable.<o:p></o:p></span></p>
<table border="1" cellpadding="0" cellspacing="0" class="MsoNormalTable" style="border-collapse: collapse; border: none; margin-left: 1.5pt; mso-border-left-alt: solid black .75pt; mso-border-right-alt: solid black .75pt; mso-border-top-alt: solid black .75pt; mso-padding-alt: 0cm 1.5pt 0cm 1.5pt; mso-yfti-tbllook: 1184;">
<tbody><tr style="mso-yfti-firstrow: yes; mso-yfti-irow: 0;">
<td style="border: 1pt solid gray; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p align="right" class="MsoNormal" style="text-align: right;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></b></p>
</td>
<td colspan="7" style="border: 1pt solid gray; mso-border-left-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 374pt;" valign="top" width="499">
<p align="center" class="MsoNormal" style="text-align: center;"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">Frequency
of Task</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 1;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">Time Saved</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Hour</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Day</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 50.5pt;" valign="top" width="67">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Week</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 64.15pt;" valign="top" width="86">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Fortnight</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 53.9pt;" valign="top" width="72">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Month</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Quarter</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1/Year</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 2;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 Hour</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">12000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1500</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 50.5pt;" valign="top" width="67">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">300</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 64.15pt;" valign="top" width="86">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">150</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 53.9pt;" valign="top" width="72">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">75</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">25</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">6.25</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 3;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 day</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">12000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 50.5pt;" valign="top" width="67">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">2400</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 64.15pt;" valign="top" width="86">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1200</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 53.9pt;" valign="top" width="72">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">600</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">200</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">50</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 4;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 Week</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 50.5pt;" valign="top" width="67">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">12000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 64.15pt;" valign="top" width="86">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">6000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 53.9pt;" valign="top" width="72">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">3000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">250</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 5;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">2 Weeks</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 50.5pt;" valign="top" width="67">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 64.15pt;" valign="top" width="86">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">12000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 53.9pt;" valign="top" width="72">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">6000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">2000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">500</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 6;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 Month</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 50.5pt;" valign="top" width="67">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 64.15pt;" valign="top" width="86">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 53.9pt;" valign="top" width="72">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">12000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">4000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 7;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 Quarter</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 50.5pt;" valign="top" width="67">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 64.15pt;" valign="top" width="86">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 53.9pt;" valign="top" width="72">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">12000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">3000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 8;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">6 Months</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 50.5pt;" valign="top" width="67">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 64.15pt;" valign="top" width="86">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 53.9pt;" valign="top" width="72">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">6000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
<tr style="mso-yfti-irow: 9; mso-yfti-lastrow: yes;">
<td style="border: 1pt solid gray; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p class="MsoNormal"><span style="color: #f3f3f3;"><b style="mso-bidi-font-weight: normal;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">1 Year</span></b><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 50.5pt;" valign="top" width="67">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 64.15pt;" valign="top" width="86">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 53.9pt;" valign="top" width="72">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 58pt;" valign="top" width="77">
<p align="right" class="MsoNormal" style="text-align: right;"><span face="calibri, sans-serif" style="color: #f3f3f3; font-size: 11pt; mso-fareast-font-family: Calibri;"><o:p> </o:p></span></p>
</td>
<td style="border-bottom: 1pt solid gray; border-left: none; border-right: 1pt solid gray; border-top: none; mso-border-left-alt: solid gray 1.0pt; mso-border-top-alt: solid gray 1.0pt; padding: 0cm 1.5pt; width: 49.15pt;" valign="top" width="66">
<p align="right" class="MsoNormal" style="text-align: right;"><span style="color: #f3f3f3;"><span face="calibri, sans-serif" style="font-size: 11pt; mso-fareast-font-family: Calibri;">12000</span><span style="font-size: 12pt;"><o:p></o:p></span></span></p>
</td>
</tr>
</tbody></table>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt;"><span style="font-size: 12pt;"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">If you, for example, run a somewhat large-ish software
development team of 10 people, and you work in 2 week cycles (these are often
called <i style="mso-bidi-font-style: normal;">sprints</i>), and it takes the
team 1 day to deploy what the team has built at the end of each cycle, then you
could spend up to 1200 person days, or more than 3 person years, on automating
the deployment process, and it would be worth it.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">If you are in the software business, you might want to
argue that it would not take the whole team one day to deploy software to
production, even if they do it manually. Well, if you count all the associated
processes that might require manual work, like testing, meetings, getting
permissions for this and that, it might well be more than 1 team day.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">It is still common that projects and programs spend
maybe a couple of weeks, build something that almost works, and then move on to
other work, leaving them with incredibly costly manual or partly automated
processes. Nobody knows how expensive, because <i style="mso-bidi-font-style: normal;">nobody does the math!</i><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Some of you who read this might have greater
responsibilities than a single team. What if you run a large software
development program, or department?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Let’s forget the tables, and just have an example for
100 people:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Let’s say you run a project at a pharmaceutical
company. It is a small one, just 100 people. You are developing a new drug.
Doing that can take a decade, and it is not every project that results in
something usable.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">If you have a dud, and have had 100 people working on
developing it for 10 years, you have lost truckloads of time and money.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">Lets say clinical trials normally take 6 years, out of
those 10 years. If you can reduce the clinical trial period by 2 years, you can
stop a failed project two years earlier than before.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">That means you save 200 person years.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">We could scale this up to 1,000 people, and more, but
I think you get the idea:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 6pt 0cm 6pt 36pt; text-align: left;"><span style="font-size: 12pt;">It pays to know things!<br /></span></p><p><span style="font-size: 12pt;">
A relatively small investment in learning new things, can give you an enormous
payoff!</span></p><p></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">We are used to believing that if something will give
us a great advantage, it has to be something really complicated and difficult
to understand.<a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-01%20Create%20time%20to%20think/Create%20time%20to%20think%20PA1.docx#_ftn3" name="_ftnref3" style="mso-footnote-id: ftn3;" title=""><sup>3</sup></a> Sometimes that is true. To build a rocket that can
take humans to Mars and back, or a safe self-driving car, you need to know a
lot of really complicated stuff.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">On the other hand, there are also many things that are
both useful and relatively simple. This book is about some of those things.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 6pt; tab-stops: 26.95pt; text-align: left;"><span style="font-size: 12pt;">If you try to implement what is in this book, you will
become acutely aware that <i style="mso-bidi-font-style: normal;">simple</i> is
very different from <i style="mso-bidi-font-style: normal;">easy</i>. On the up
side, you might also find that it is surprisingly interesting and fun.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 12pt 0cm 6pt;"><b style="mso-bidi-font-weight: normal;"><span style="font-size: 18pt;">Takeaways</span></b><span style="font-size: 12pt;"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><span style="font-size: 12pt;">Figure out the
one most valuable thing you can do for your company today. <i style="mso-bidi-font-style: normal;">Do it</i>!<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><span style="font-size: 12pt;">Delegate
decisions that can be made by someone else.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><span style="font-size: 12pt;">Knowledge is
valuable! A little time invested in learning, can yield great results.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><span style="font-size: 12pt;">Knowledge
increases in value when you spread it in your organization.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; mso-list: l0 level1 lfo1; tab-stops: 12.0pt 36.0pt; text-indent: -36pt;"><!--[if !supportLists]--><span style="font-size: 12pt;"><span style="mso-list: Ignore;">●<span style="font: 7pt "times new roman";">
</span></span></span><!--[endif]--><span style="font-size: 12pt;">Read a little,
practice a lot! Repeat!<o:p></o:p></span></p>
<div style="mso-element: footnote-list;"><!--[if !supportFootnotes]--><br clear="all" />
<hr align="left" size="1" width="33%" />
<!--[endif]-->
<div id="ftn1" style="mso-element: footnote;">
<p class="MsoNormal"><a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-01%20Create%20time%20to%20think/Create%20time%20to%20think%20PA1.docx#_ftnref1" name="_ftn1" style="mso-footnote-id: ftn1;" title=""><sup><span style="font-size: 12pt;">1</span></sup></a><span style="font-size: 12pt;"> </span><span style="font-size: 11pt;">I got the
original idea for this thought experiment from the comic XQCD. I have just
adapted and extended the idea a bit, and merged it with my own practical
experiences.</span><o:p></o:p></p>
</div>
<div id="ftn2" style="mso-element: footnote;">
<p class="MsoNormal"><a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-01%20Create%20time%20to%20think/Create%20time%20to%20think%20PA1.docx#_ftnref2" name="_ftn2" style="mso-footnote-id: ftn2;" title=""><sup><span style="font-size: 12pt;">2</span></sup></a><span style="font-size: 12pt;"> </span><span style="font-size: 11pt;">Some famous
authors, like Georges Simenon, and Michael Moorcock, used to write books in two
weeks or even less. It is worth noting that they did it without the quality
suffering.</span><o:p></o:p></p>
</div>
<div id="ftn3" style="mso-element: footnote;">
<p class="MsoNormal"><a href="file:///C:/Users/self_n/Google%20Drive/writing/books/Tempo/Tempo%202.0/Drafts/Chapter%20A-01%20Create%20time%20to%20think/Create%20time%20to%20think%20PA1.docx#_ftnref3" name="_ftn3" style="mso-footnote-id: ftn3;" title=""><sup><span style="font-size: 12pt;">3</span></sup></a><span style="font-size: 12pt;"> </span><span style="font-size: 11pt;">There is a name
for this cognitive bias: <i>Proportionality bias</i> is the belief that large effects
must have large causes.</span><o:p></o:p></p>
</div>
</div>Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-14558826178243438432020-07-07T16:22:00.000+02:002020-07-07T16:22:18.291+02:00SAFe: Synchronization vs. Decoupling in PI PlanningRecently, I put my foot in my mouth while tweeting. This turned out to be a good thing, not only because it was an amazing feat of dexterity considering my age and body mass, but also because it lead to an interesting conversation, and thus, an opportunity to think things through, and to learn.<br />
<br />
I won’t recapitulate the whole conversation in this blog post, because you can easily <a href="https://twitter.com/bea73/status/1277629443335479301" target="_blank">look it up on Twitter</a>. I’ll provide the tweet that kicked the discussion off though, and give you the gist of the conversation. I have invited everyone who was involved to read and review this blog post, so if I screw anything up, they can jump in and unscrew it again.<br />
<br />
It started with me tweeting:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcA6qv6OU4ISyQZTEBVZbejblx8Dp91AP3j9jWmS1V5umRrulcNknsTVSyV8n-Z0D5c93xKyPTDOrycFEhywvxEjkVC63Do6mgV_e2H9djA_7ntvSYBa20J6Y_F-h724t4SBgc/s1600/Tweet+01.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="152" data-original-width="589" height="102" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcA6qv6OU4ISyQZTEBVZbejblx8Dp91AP3j9jWmS1V5umRrulcNknsTVSyV8n-Z0D5c93xKyPTDOrycFEhywvxEjkVC63Do6mgV_e2H9djA_7ntvSYBa20J6Y_F-h724t4SBgc/s400/Tweet+01.png" width="400" /></a></div>
<br />
That started up a conversation with Henrik Berglund and Beatric During. It did not take many tweets until I wrote:<br />
<br />
“There are plenty of things where SAFe has a very shallow implementation of important ideas. For example, they borrowed the idea of PI planning from Reinertsen, but ignored the limitations he pointed out.”<br />
<br />
Beatric During immediately spotted something a bit off, namely the statement “they borrowed the idea of PI planning from Reinertsen, but ignored the limitations he pointed out”. I slipped up bigly there, because that was not a statement I could back up with facts.<br />
<br />
A couple of years earlier, I had noticed similarities between a part of Donald Reinertsen’s excellent book <a href="https://www.amazon.com/Principles-Product-Development-Flow-Generation-ebook/dp/B007TKU0O0/ref=sr_1_1?dchild=1&keywords=reinertsen+flow&qid=1593979485&s=digital-text&sr=1-1" target="_blank">The Principles of Product Development Flow: Second Generation Lean Product Development</a> and the SAFe practice of PI Planning. That, and the fact that SAFe <a href="https://www.scaledagileframework.com/?s=reinertsen" target="_blank">borrows several other ideas from Reinertsen’s book</a>, had lead me to form a hypothesis that the idea of PI Planning was also derived from what Reinertsen writes in Flow.<br />
<br />
Just to be perfectly clear: I really like Flow. Borrowing from it is a very good thing to do. The purpose of writing a book like this, is to spread knowledge around, so lots of people can use it.<br />
<br />
I have used ideas from that book to help clients, and it has worked out great. I wish more people would read it, and use it.<br />
<br />
The mistake I made was not forming the hypothesis. The mistake was presenting it as if it was a fact.<br />
<br />
Eric Schön asked me to be more specific, so I tweeted the numbers of the specific sections I was referring to:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgL3lrNOsqMugbLiKmmvvU-BBLF_k107GT5RerDAeDoAJ0nsxOsxlDyKB2VvAnILfa3H9_ZyIH02GNasUuVLRIIvqNomI87bEVn_A8-h1aR1HehbRvQGt-xfWmEWewO-bg5_QBY/s1600/Tweet+02.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="207" data-original-width="589" height="140" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgL3lrNOsqMugbLiKmmvvU-BBLF_k107GT5RerDAeDoAJ0nsxOsxlDyKB2VvAnILfa3H9_ZyIH02GNasUuVLRIIvqNomI87bEVn_A8-h1aR1HehbRvQGt-xfWmEWewO-bg5_QBY/s400/Tweet+02.png" width="400" /></a></div>
<br />
On the off chance that you haven’t memorized all the section titles in the book, I’ll provide them here:<br />
<br />
<ul>
<li>F11: The Principle of Multiproject Synchronization: Exploit scale economies by synchronizing work from multiple projects.</li>
<li>F12: The Principle of Cross-Functional Synchronization: Use synchronized events to facilitate cross function trade-offs.</li>
<li>F13: The Synchronization Queueing Principle: To reduce queues, synchronize the batch size and timing of adjacent processes</li>
</ul>
<br />
Section F11 uses project reviews as an example of how you can increase the frequency of project reviews by reviewing multiple projects at the same time. In SAFe, this is done through biweekly System Demos, and, every three months, through a PI System Demo.<br />
<br />
Section F12 uses reviews as an example of an activity that can benefit from synchronization between functional departments. If you have functional teams, working on functional requirements, you would get the same kind of advantages as Reinertsen describes for departments. SAFe uses (usually) weekly Scrum of Scrum meetings, and during PI Planning, a Management Review and Problem-solving meeting to resolve dependencies and make cross-function trade-offs.<br />
<br />
Note that I used the word “functional” several times in the previous paragraph, because I will get back to that later.<br />
<br />
In section F13 Reinertsen states:<br />
<blockquote class="tr_bq">
“If we synchronize both the batch size and the timing of adjacent processes, we can make capacity available at the moment the demand arrives. This leads to a dramatic reduction in queues.”</blockquote>
This is also congruent with how SAFe uses syncronized Sprints, demos, Scrum of Scrums, Product Owner Synchronization meetings, and other artifacts, to synchronize batch sizes and timing of teams working in the same Agile Release Train (ART).<br />
<br />
The mistake I made when I tweeted, was to assume that my unproven hypothesis, that SAFe has gotten its ideas from Reinertsen’s book, was a fact. All the evidence is circumstantial. The practices in SAFe may have been derived from other sources.<br />
<br />
At this point, Donald Reinertsen joined the conversation, and pointed out that the similarities do not in any way prove causality. He did agree though, that the basic principles are the same.<br />
<br />
While I agree completely with the principles listed above, I also believe that there is a bit more to it than that. Let’s check out what Reinertsen wrote about in those other sections I mentioned in my tweet:<br />
<br />
<ul>
<li>B13: The Principle of Batch Size Diseconomies: Batch size reduction saves much more than you think.</li>
<li>B14: The Batch Size Packing Principle: Small batches allow finer tuning of capacity utilization.</li>
<li>B15: The Fluidity Principle: Loose coupling between product subsystems enables small batches.</li>
</ul>
<br />
Section B13 explains non-linear effects that makes transaction and holding costs skyrocket as batch sizes grow. Reinertsen writes:<br />
<blockquote class="tr_bq">
“Our calculated optimum batch sizes are likely to be too large. In the presence of the hard-to-quantify large batch diseconomies, it is important to aggressively test our assumptions about optimum batch size.”</blockquote>
Section B14 says that if we want to use people and resources effectively, we need small batches. Reinertsen writes:<br />
<blockquote class="tr_bq">
“Smaller batches inherently help us get better resource utilization with smaller queues.”</blockquote>
Section B15 is particularly interesting. It says that to work efficiently with small batches, we need to reduce dependencies between them. To quote Reinertsen again:<br />
<blockquote class="tr_bq">
“If we want to start testing subsystems before the entire system is designed, we need to create independently testable subsystems. As we reduce dependencies, we gain flexibility in routing and sequencing.”</blockquote>
Note that this has implications for the SAFe program organization: Teams cannot work independently of each other if they work on subsystems that have dependencies. At the risk of seriously overquoting, here is Reinertsen again:<br />
<blockquote class="tr_bq">
“This illustrates the extremely important relationship between product architecture and development process design. Once a product developer realizes that small batches are desirable, they start adopting product architectures that permit work to flow in small, decoupled batches. These loosely coupled architectures, with stable interfaces, enable us to work in parallel on many subsystems. We can work in parallel with low risk, if we are confident that the work we do will ultimately integrate well at a system level.” </blockquote>
Before putting everything together, I’ll add one more piece to the puzzle. This is a reference I ought to have included in my tweet above, but in my tweeting frenzy, I missed it:<br />
<br />
<ul>
<li>F10: The Synchronization Capacity Margin Principle: To enable synchronization, provide sufficient capacity margin.</li>
</ul>
<br />
We need a capacity margin to synchronize. That means the benefits of synchronization come at a cost. This should not be a surprise.<br />
<br />
Imagine you have two people running a long distance race. There are five checkpoints along the way, and you want the runners to arrive at the same time at each checkpoint, and at the goal line.<br />
<br />
You may think this sounds a little bit weird, but that is what the synchronization mechanisms in SAFe do. Synchronization, in this case, would enable you to have each checkpoint open for a shorter time, and it would enable the runners to exhange information, and plan the best route to the next checkpoint. It would also slow down the runners. Before each checkpoint, the fastest runner would have to wait for the other runner to catch up.<br />
<br />
Suppose one runner is the slowest on stretches one, three and five. The other is slowest on two and four. Over the course of the race, both runners will have to slow down, waiting for the other.<br />
<br />
Imagine you have twenty runners, and twenty checkpoints. It’ll be a slow race. Replace the runners with software development teams, and the race with a SAFe program.<br />
<br />
I’ve been measuring team velocity, and variation in team velocity, in almost every software project or program I have worked in for the past fifteen years.<br />
<br />
Team velocity varies a lot from sprint to sprint. Study a team over a significant course of time, and you will see that the difference between lowest and highest velocity in a sprint, may be a factor twenty, or even more, for a normally functioning team.<br />
<br />
If you have ten teams in an ART, it is a good bet that at least one team will be really slow each sprint. If you have a lot of dependencies, it is likely that other teams will have to wait for that slow team, every sprint.<br />
<br />
What do you call five slow sprints, and a two week capacity buffer? A Program Increment.<br />
<br />
A Program Increment is three months long. That means you get pretty large batches. If B13 holds true, and reducing batch size saves much more than you think, then large batches will cost you much more than you think. Those large batches will also prevent you from doing the fine tuning mentioned in B14.<br />
<br />
How can you see that you have a problem with too many couplings?<br />
<br />
For starters, look at the Program Board. If you have many pieces of string connecting work items done by different teams, then you have a problem.<br />
<br />
You should be aware that the board does not tell the whole story. Some years ago I created a system for real time detection of dependencies, and delays due to dependencies, and found, among other things, that what you see on the Program board is typically less than 25% of the dependencies you have in a single PI.<br />
<br />
For a very rough estimate of how many dependencies you have between subsystems, count the number of strings, multiply by four, then multiply by the number of PIs you have had in the program.<br />
<br />
I created a graph of such an estimate in a program where I worked. It was a red mass of strings, where you could not even see individual strings, except in the periphery. I have come to understand that this is normal for SAFe programs. Few people are interested in reducing the number of dependencies, because few people are aware of the impact.<br />
<br />
How do you solve the problem with slow progress?<br />
Reduce batch size!<br />
<br />
How do you do that?<br />
Reduce couplings between teams, so they do not have to wait for each other.<br />
<br />
How do you do that?<br />
Reduce couplings between software subsystems.<br />
<br />
How do you do that?<br />
That depends.<br />
<br />
Sorry, but my experience is that the answer to that last question is different for different organizations. I have seen organizations where legacy IT infrastructure causes hard couplings, where inability to grasp object oriented programming principles cause hard couplings, where the organizational structure causes hard couplings, where the requirements model causes hard couplings, where the organization’s own process experts cause hard couplings, where the architects cause hard couplings, where KPIs and OKRs cause hard couplings…Usually, there is more than one problem at the same time.<br />
<br />
Everywhere I have been, the problems have been of known types, with known solutions, just not known in the organizations beleaguered by the problems.<br />
<br />
While I cannot give you a solution tailor made to fit your organization in a blog post, I can give you a very general guideline:<br />
<blockquote class="tr_bq">
Decouple when you can, synchronize when necessary! </blockquote>
SAFe does tell you to decouple, it is just that the emphasis is almost exclusively on synchronization. What little information there is on decoupling gets lost.<br />
<br />
I believe there ought to be way more emphasis on decoupling, and I believe people must be trained to understand the trade-offs involved.<br />
<br />
Unfortunately, in many organizations, that means you need to retrain managers, developers, and architects…and many of your SAFe consultants.<br />
<br />
What do you think? Comments are welcome.Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-34751198686023930572020-01-07T01:02:00.000+01:002020-01-07T01:02:38.799+01:00Taking Flight for 2020<div class="separator" style="clear: both; text-align: center;">
</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://1.bp.blogspot.com/-zeC96Y2GYRE/XhPE9-berFI/AAAAAAABzfc/qiXLk2piAqM-imE-e5P_dt4T1YMCbujTACEwYBhgL/s1600/Taking%2BFlight%2Bv02_DAP_Realism.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1065" data-original-width="1600" height="424" src="https://1.bp.blogspot.com/-zeC96Y2GYRE/XhPE9-berFI/AAAAAAABzfc/qiXLk2piAqM-imE-e5P_dt4T1YMCbujTACEwYBhgL/s640/Taking%2BFlight%2Bv02_DAP_Realism.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Chrononauts V: Taking Flight by Henrik Mårtensson</td></tr>
</tbody></table>
It's early in 2020, and I think it is appropriate to make a personal retrospective of the year that was. I am not quite as certain it is appropriate to publish said retrospective, but then again, if I decide not to publish it, I'll probably never get around to writing it.<br />
For me, 2019 has been a very good year, both privately, and at work.<br />
<br />
Let's get the personal stuff out of the way first. I haven't blogged much in this blog, but that is mainly because I have been busy, with work, and with other things.<br />
<br />
My hobbies, like digital art, may not seem to have much to do with my work on process and organization improvement, or my forages into Scrummastery, but actually they do.<br />
<br />
Almost everyone I know who is a really good software developer, or leader, or manager, does have some sort of interest in creative arts. Some play instruments or sing, others write, draw, are into photography, or some other creative activity. Of course, that creative activity may also be programming, building stuff, mathematics, or something else.<br />
<br />
I'll connect the dots between art, software development, and leadership throughout this post.<br />
<h2>
The Things I did When I Didn't Work</h2>
<div class="separator" style="clear: both; text-align: center;">
</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/AVvXsEiZmHSnu1qKnDqL9o31T69pWSKqxCMayL52joBmg8zG7uH2frJZTF5LAKAaR_sMdg7GGcNSSsPXmxB1W141x8l50v1Z2yVokhczX8IuC-6mo5KeoHbpvXXIa27o6i92fI51WiPg/s1600/Arachnic+Battle+v02+IMG_6937_DAP_Watercolor.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1065" data-original-width="1600" height="424" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZmHSnu1qKnDqL9o31T69pWSKqxCMayL52joBmg8zG7uH2frJZTF5LAKAaR_sMdg7GGcNSSsPXmxB1W141x8l50v1Z2yVokhczX8IuC-6mo5KeoHbpvXXIa27o6i92fI51WiPg/s640/Arachnic+Battle+v02+IMG_6937_DAP_Watercolor.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Arachnophobia II: The photo that didn't look like a photo, but was, sort of. Models: Petra Brewitz and Peter Markusson.</td></tr>
</tbody></table>
I have blogged quite a bit at my <a href="http://kallokainphoto.blogspot.com/" target="_blank">art blog</a>, and I blew past 100 published works at <a href="https://www.artstation.com/henrikmartensson" target="_blank">ArtStation</a>. I managed to get excluded from the <i>Planket </i>photography exhibition because my photos didn't look like photos, but then I got included again when I explained why my photos looked like they did. I was experimenting with a modernized version of <i>pictorialism</i>, a photographic style that was popular up to the 1920´s.<br />
<br />
That was a lucky break, partially because it is fun to exhibit my pictures, and partially because the head of the Volvo Photographic Society saw my work at the exhibition, and invited me to visit Volvo to talk about photography, which I did, in the company of a good friend, and collaborator in some of the art projects I perpetrate, Petra Brewitz.<br />
<br />
The invitation to hold a presentation at Volvo, gave me an opportunity to talk about something photographers, like many managers, tend to overlook: Teamwork!<br />
<br />
Even better, it gave me an incentive to think through what I know about teamwork, and to think about the things I know I do not know.<br />
<br />
I've worked in the software business for longer than I care to admit in a blog post. One of the things I have learned, is the importance of teamwork.<br />
<br />
When I took up photography as a hobby, it was natural to apply some of the lessons I have learned at work. One of those lessons is:<br />
<blockquote class="tr_bq">
If you want to do something a bit complicated, you need a team!</blockquote>
At the presentation, I wanted to show that the pictures I make, not made by me alone. They are the result of teamwork. Therefore, I asked Petra to come with me, so that the audience could get a perspective that is different from mine, and so they would see that I work with other people, instead of just hearing me say it.<br />
<br />
Photographers and models are often stuck in a severely outdated model of work relationship: The photographer is the authority, and responsible for both ideas and technical implementation. Models are expected to do as they are told, and not much more than that.<br />
<br />
That isn't much fun, especially not for the models. It is not the road to making great pictures either, because it limits the range of ideas you can work with. It also severely cuts the ability to solve problems along the way.<br />
<br />
Let's take the picture above, Arachnophobia II, as an example. Petra Brewitz, the model to the left, is from Öland, and has an interest in Öland history, including viking history. She is also an amateur photographer (and a programmer, though this is less important for this story).<br />
<br />
The past four years, Petra has invited a small group of photographers to exhibit photos together in Borgholm, a city on Öland, during the Borgholm Harvest Festival.<br />
<br />
It is because I am a member of that group of photographers, I shot the photo of Borgholm castle seen in the background.<br />
<br />
Petra and I were originally working on a viking/Fantasy themed photo session together. At that point, the idea was to create a picture with two vikings fighting a dragon.<br />
<br />
Peter, to the right in the picture, is an experienced model. One of his hobbies is live roleplaying. That means he has a lot of great ideas about Fantasy themed pictures. It also means he has something I sorely lack: medieval weapons and armor.<br />
<br />
Between them, Petra and Peter have lots of knowledge about viking history, and Fantasy. They also have quite a bit of useful props, like swords and armor. I contributed my knowledge of, and interest in, Fantasy, a basic idea and storyboard, the background picture, some skills at 3D compositing, and a 3D model of a giant spider, which I had bought, because, you know, you never can tell when you are going to need a giant spider.<br />
<br />
We all contributed, and the picture you see would not have been possible if we had not, all of us, contributed ideas, props, equipment, time, and quite a bit of work.<br />
<br />
In my professional life, I am sometimes lucky enough to be a part of teamwork like that, but it is usually confined to a single team, or lateral collaboration, when teams work together.<br />
<br />
Only in the rarest of cases do I see the teamwork extend vertically, throughout all levels of the organization. There, collaboration tends to end, and managers often have the mindset of photographers.<br />
<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/AVvXsEiAFnJTpaJkauNygHW0vPSXgXTsoAkqIzgwY9aADcQwUzKCxOr3KVB9Bw0xcYNKscI902oLH0QX8vfD4msHetY0MK6v-wD4H_r_zLKSlQqkw951zVaG5X74OSIYp7weVuOXlQZe/s1600/Cat+and+Mouse+-+Cassandra+Hogfeldt+v02+Overlay+Portraitist4.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1600" data-original-width="1067" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAFnJTpaJkauNygHW0vPSXgXTsoAkqIzgwY9aADcQwUzKCxOr3KVB9Bw0xcYNKscI902oLH0QX8vfD4msHetY0MK6v-wD4H_r_zLKSlQqkw951zVaG5X74OSIYp7weVuOXlQZe/s640/Cat+and+Mouse+-+Cassandra+Hogfeldt+v02+Overlay+Portraitist4.jpg" width="426" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Cat and Mouse. Model: Cassandra Högfeldt</td></tr>
</tbody></table>
<i>Arachnophobia II</i> got me into the Planket exhibition, but it was <i>Cat and Mouse</i> that got me the presentation gig at the Volvo Photographic Society. I had printed the picture on a large canvas, making it the centre piece of my pictures at the exhibition. Cat and Mouse is the result of a collaboration with Cassandra Högfeldt, a model that contacted me after seeing some of my earlier pictures.<br />
<br />
I had been planning a series of Lost World themed pictures, and Cassandra, with her combination of modelling experience and military background, was the perfect model for a set of gritty, yet beautiful adventure pictures. We worked on three sets of pictures during the year.<br />
<br />
Here too, we used ideas from both of us to push the pictures as much as we could. And, it would not have worked without Cassandra's arsenal of daggers, gun props, and other equipment. I supplied sabretooth tigers and other creatures, and a variety of prehistoric environments.<br />
<br />
Again, without collaboration and teamwork, including quite a bit of problem solving, the pictures we made would not have been possible.<br />
<h2>
At Work: Developing the Dependency Jar</h2>
<table 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/AVvXsEi4wTCAftgeOI5GdQw7UGPFVCPtTPuHpUSFbnVZ0h9UlMNDWakVXO8TZ2TCYIk_D79KQRxyDMdUlwVYF80SOI-vD0PbQ3vl-3Fv0_Fx5L9H6d-yAiau_ryX1MtmnherlG84-Rkp/s1600/E0D31774-F221-469C-A3CF-E0ED30D58BC3.jpeg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1200" data-original-width="1600" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4wTCAftgeOI5GdQw7UGPFVCPtTPuHpUSFbnVZ0h9UlMNDWakVXO8TZ2TCYIk_D79KQRxyDMdUlwVYF80SOI-vD0PbQ3vl-3Fv0_Fx5L9H6d-yAiau_ryX1MtmnherlG84-Rkp/s640/E0D31774-F221-469C-A3CF-E0ED30D58BC3.jpeg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The Dependency Jar is used to track dependencies in software development programs.</td></tr>
</tbody></table>
Over the past few years, I've seen some interesting changes in how software is developed at many companies.<br />
<br />
Software has become more complicated, and is now developed not by one team, but by many teams working together.<br />
<br />
This creates new challenges. Twenty years ago, the problem was how to enable people <i>in</i> a team to work effectively together.<br />
<br />
Solutions at the time, like RUP, <i>The Rational Unified Process</i>, which was neither unified, nor very rational, sometimes helped, but just as often wreaked havoc in software development projects.<br />
<br />
The trouble was that RUP was a toolkit, actually a fairly good one, but companies kept mistaking it for a process, with predictably unpredictable results.<br />
<br />
To be fair, the word <i>process</i> was right there in the name of the thing, so if one was sufficiently disinclined to actually read what the RUP documentation said, and perhaps a bit stoned, it was possible to mistake RUP for a software development process.<br />
<br />
When agile methodologies arrived on the scene, in my case in 1999, it felt like I was being delivered from software development hell. Finally, we had a way of working together that actually worked. I was a developer at the time, and we used Extreme Programming.<br />
<br />
Then, of course, companies shied away from the difficult bits in agile, like writing code that worked well and was easily maintainable, and focused almost exclusively on the human interaction bits, and went with Scrum. It was a bit like removing two of the wheels from a car in order to go faster.<br />
<br />
Still, what we got was way better than RUP, even if it did not quite spark the revolution in software development, and business paradigms, that the pioneers envisioned.<br />
<br />
Nowadays, most companies I work for actually have pretty good teams, and understand how teams work very well.<br />
<br />
But, and it is a big but, all the old interaction, communication, and software design problems are still there, they just moved to the space between teams.<br />
<br />
Agile methods were designed for single team projects, and do not deal with multi-team problems very well. That left a big, gaping methodology hole, and methodologists were of course eager to develop new methods to cover it.<br />
<h3>
SAFe is the New RUP</h3>
Most companies seem to have chosen SAFe, and guess what, SAFe is the new RUP!<br />
<br />
I have worked with SAFe for a couple of years now, used it in practice, and studied the documentation. Like RUP, SAFe is a collection of ideas from many different sources. The original ideas are often good ones, but SAFe uses only part of the ideas, and leaves out anything that is difficult to implement, or difficult to sell.<br />
<br />
I'll give you just one example. It is a thing that has cropped up over and over again the past couple of years:<br />
<br />
SAFe uses quarterly events, Program Increment planning meetings (PI Planning), to synchronize multiple teams working together. This is an idea that probably comes from Donald Reinertsen's excellent book <i>The Principles of Product Development Flow</i>.<br />
<br />
In his book, Reinertsen wrote:<br />
<blockquote class="tr_bq">
If we synchronize both the batch size and the timing of adjacent processes, we can make capacity available at the moment the demand arrives. This leads to a dramatic reduction in queues.<br />-Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 189). Celeritas Publishing. Kindle Edition. </blockquote>
That is perfectly true, and that is what PI meetings do. However, the SAFe authors skipped other, equally important parts, like this one:<br />
<blockquote class="tr_bq">
If we are trying to coordinate the simultaneous processing of multiple items, then our schedule will be determined by the arrival of the most limiting item. We need sufficient schedule margin to ensure this item does not delay the entire group. </blockquote>
<blockquote class="tr_bq">
Think of an airline with multiple commuter flights feeding a larger long-haul flight. Since some of the commuter flights may arrive late, we must allow a safety margin for passengers to connect to the long-haul flight. The more feeding flights we are trying to support, the more margin we need.<br />Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 187). Celeritas Publishing. Kindle Edition. </blockquote>
What that passage means is that the benefits of PI meeting can be killed off if you try to coordinate too many teams.<br />
<br />
In other words, very large PI meetings suck!<br />
<br />
SAFe also managed to ignore that synchronization is not always what you want to do:<br />
<blockquote class="tr_bq">
Once a product developer realizes that small batches are desirable, they start adopting product architectures that permit work to flow in small, decoupled batches. These loosely coupled architectures, with stable interfaces, enable us to work in parallel on many subsystems. We can work in parallel with low risk, if we are confident that the work we do will ultimately integrate well at a system level.<br />Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 127). Celeritas Publishing. Kindle Edition. </blockquote>
Working in parallel is way better than synchronizing, <i>if</i> the software design and organizational structure permits it.<br />
<br />
In practice, an optimal solution usually requires figuring out what you can do in parallel, and what you have to synchronize.<br />
<br />
Unfortunately, SAFe encourages using synchronization as a generic bandaid, so companies do not have to improve software architectures, or change their organization.<br />
<br />
This has grown popular, partially because it can alleviate problems in the short term by shoveling the serious problems into the future, partially because it is an easy recipe to follow, and does not require learning, thinking, or changing paradigms.<br />
<br />
The downside is that it locks companies into obsolete software architectures and organizational structures, which makes both the software and the organizations increasingly fragile and vulnerable to the change that goes on in the world around them.<br />
<br />
Which brings us to the picture of the glass jar, the Dependency Jar, above. I needed a very simple tool to track dependencies in teams, between teams, between teams and the organization around them, and between teams and external actors.<br />
<br />
SAFe has a tool for predicting which cross-team dependencies that will have an impact on development during a Program Increment, i.e. a quarter.<br />
<br />
I wanted something that could give me a record of the dependencies that actually have an impact during development. I also wanted said tool to provide me with information I can use to <i>break</i> dependencies, and <i>decouple</i> teams.<br />
<br />
That would give me a way of helping clients hands down beat competitors that rely on SAFe and synchronization.<br />
<br />
Turns out you can do that with a glass jar, a pen, and Post-It notes...and some other stuff.<br />
<br />
Exactly how do you beat SAFe? In terms of popularity, I won't even try. In terms of having a more effective process that delivers more value than SAFe does, faster than SAFe does, and with better return on investment than SAFe does, that is doable, in many, many ways.<br />
<br />
If you are curious about how to do it with a glass jar and Post-It notes, you will be able to read about it in this blog, this year. I spent more than a year figuring out how to do it, and I am still testing and developing various ideas, so I am in no hurry to spill the beans.<br />
<br />
<h2>
More Work: Simple Simulation of the Real Cost of Open Offices</h2>
There is a widespread belief that open offices are the way to go if you want a lot of people to work well together. This belief is not supported by research. There is plenty of research that shows that open offices make people feel awful, and loose productivity.<br />
<br />
As it turns out, you can translate the research data about productivity loss into economic terms. You can also calculate the savings in office space you can make by having an open office plan.<br />
<br />
That makes it quite easy to construct a simulator that lets you check whether the cost savings outweigh the productivity loss, or vice versa.<br />
<br />
That can give a company valuable information about what kind of office design to go with, or whether it is economically beneficial to switch from one type of office to another.<br />
<br />
That is one of the things I did last year. I'll save the details for a future blog post, but I'll tell you I am amazed by how many companies that have only considered one side of the equation, and because of that made the wrong economic choice.<br />
<br />
I'll give you a hint though: In most cases, the right economic choice turns out to be the choice that is also best for the people working at the company, and we have known what that choice is since at least 1979, when Christopher Alexander published <a href="https://en.wikipedia.org/wiki/The_Timeless_Way_of_Building" target="_blank">The Timeless Way of Building</a>.<br />
<br />
<h2>
Summing Up</h2>
Inventing a new practice, the Dependency Jar, that enables companies running large software projects to visualize, mitigate, and even eliminate, dependencies, reduce the need for synchronization, and help organize in ways that support the things they want to build, and coming up with a model for calculating the true cost of plan offices, that is pretty good for a year.<br />
<br />
Personally though, I am even more happy about developing as an artist. Well, some sort of pseudo-artist, at least. I do not work the way most artists do. Instead I combine whatever skills I have as a photographer, with my skills as a process developer, and my skills in building and leading teams, to create the kind of pictures I am interested in. On an intellectual level, I know that in art, it is the results that count, but emotionally, the fact that I break a lot of rules about how to create art, gives me a horrible case of impostor syndrome.<br />
<br />
Perhaps I should also mention that most of the work I've done, has been perfectly normal consulting work, and that the thing that sets it apart, is that I have had the opportunity to work with some really great people.<br />
<br />
2020 has arrived, and I am looking forwards to seeing what it will bring. A lot!<br />
<br />
<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/AVvXsEh_s6xMjlvzkEqiGHcqmlNqRPFKtlsJhbHrHkGwKgfdglkcxv2sjVZXwH9NUWbL8zOX9I-MDQN9XZF0-0K6jyjbMBc6aSb9Maz5-GYgFevOPwspaD9XtBvKCOXoZB9F_9BoTb0i/s1600/T-Rex+Rider+v01+finished_DAP_Watercolor.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="865" data-original-width="1600" height="344" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_s6xMjlvzkEqiGHcqmlNqRPFKtlsJhbHrHkGwKgfdglkcxv2sjVZXwH9NUWbL8zOX9I-MDQN9XZF0-0K6jyjbMBc6aSb9Maz5-GYgFevOPwspaD9XtBvKCOXoZB9F_9BoTb0i/s640/T-Rex+Rider+v01+finished_DAP_Watercolor.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Arrival, a.k.a. T-Rex Rider, by Henrik Mårtensson</td></tr>
</tbody></table>
<br />
<br />
<br />Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-76712805265557772272019-04-07T21:46:00.001+02:002019-04-07T21:46:18.592+02:00Simple Simulator: T-Shaped vs. I-Shaped Developers<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-X-PjzuRKwtw/XKow18VrvbI/AAAAAAABuOQ/hSC47H-0VHwzkfa_rGCrMHWxFAskoL__wCLcBGAs/s1600/IMG_0875_DAP_LeRoy_DAP_LeRoy%2528LeRoy_Reddish%2529.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="957" data-original-width="1600" height="382" src="https://3.bp.blogspot.com/-X-PjzuRKwtw/XKow18VrvbI/AAAAAAABuOQ/hSC47H-0VHwzkfa_rGCrMHWxFAskoL__wCLcBGAs/s640/IMG_0875_DAP_LeRoy_DAP_LeRoy%2528LeRoy_Reddish%2529.jpg" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
Imagine that you are a manager charged with staffing a new development team. You have important choices to make: What kind of developers do you want? Specialists? Generalists who can do a bit of everything? A mix? Is it worth it to pay more for developers who are a bit more skilled?<br />
<h2>
Division of Labor vs. T-Shaped People</h2>
Most companies I've seen over the years focus on cost. When it comes to developers, that means the default behavior is to get the cheapest ones. That means neither depth of skill, nor range of skills makes much difference. For a developer, having a wide range of skills can even be a detriment, because managers do not know which narrowly defined role to put the developer in.<br />
<br />
On the other hand, anyone who has even a passing familiarity with Lean, and know a little bit about agile beyond Scrum, has probably come into contact with the concept of T-shaped people.<br />
<br />
Most companies develop and organize people according to the <a href="https://en.wikipedia.org/wiki/Division_of_labour" target="_blank">Division of Labor</a> principle, the idea that you can increase efficiency by separating tasks into narrow specialities, so that workers can also specialize. This is an important idea. Without it, we would have no industrial revolution, and our world would look very, very different.<br />
<br />
The problem is that while the Division of Labour principle works, it can be pushed too far. If the work requires understanding context, if it requires choosing an optimal solution from a wide range of possibilities, if every solution creates new problems...in short, if it is work like software development work, or management, then Division of Labour can cause as many problems it solves.<br />
<br />
Nobody can learn to do everything, so we should not, and cannot, abolish the Division of Labour principle altogether. What we often need to do, is to shift the balance a bit.<br />
<br />
That is where <a href="https://en.wikipedia.org/wiki/T-shaped_skills" target="_blank">T-shaped people</a> come in. The idea is simple: Train people in more than one speciality, so that they can work with more than one process step. This allows a team to shift more people to the current bottleneck in a process. It also gives each person a better understanding of the context of their own work, and the consequences of the choices they make.<br />
<h2>
The Simulator</h2>
I recently created a very simple simulator in a spreadsheet to illustrate the effects of narrowing down developer skills too much.<br />
<br />
In software development, including agile software development, it is very common to have teams of developers divided into two main groups: front-end developers, and back-end developers.<br />
<br />
Other teams consist of full-stack developers, individuals who know both front- and back-end development. Of course, being a full-stack developer requires a passion for the work, and also a significant investment in training. Full-stack developers are a good example of T-shaped people: People with a growth mindset, trained to do more than one thing, and usually not afraid to tackle new types of tasks.<br />
<br />
Many companies balk at paying for training full-stack developers. The added costs are obvious, but the benefits are a bit more abstract.<br />
<br />
The simulator is designed to make the differences between having specialized developers and full-stack developers a bit more visible.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjG0xI20MZZwfz083ZyG8NP8BorDJReQ9GNPEUKOo7cj201qFhLOPbqwL-YIj4KOuzpDwLlGCkFcoTHNmsjedug5AUav0YVySVcw328lhtRiEi61vJ2Hwnw5gQmbbE4vFeI7XLr/s1600/Line+Graph+01+2019-04-07+165549.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="401" data-original-width="1221" height="210" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjG0xI20MZZwfz083ZyG8NP8BorDJReQ9GNPEUKOo7cj201qFhLOPbqwL-YIj4KOuzpDwLlGCkFcoTHNmsjedug5AUav0YVySVcw328lhtRiEi61vJ2Hwnw5gQmbbE4vFeI7XLr/s640/Line+Graph+01+2019-04-07+165549.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Simulation: Differences in performance between T-shaped and I-shaped developers</td></tr>
</tbody></table>
</div>
<div class="separator" style="clear: both; text-align: left;">
The picture above shows a run from the simulator. The thick gray line shows the productivity of a team consisting of full-stack developers. The thick yellow line shows the productivity of a team that is identical, except that the developers are divided into front- and back-end developers.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The productivity is measured in stories per sprint, <i>not</i> story-points per sprint. Each story requires both front-end and back-end development.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The two thin dotted lines represent the productivity of the front- and back-end developers. Both team simulations use these numbers to calculate the productivity of the whole team, but they do it a little bit differently:</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
For the full-stack development team, since all developers can do everything, the numbers are just added together.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
For the front/back-end developer team, a story is not finished unless both groups of developers have the capacity to work on it in a sprint. Thus, the total capacity of the team in a sprint, is the lower of the capacities of the two groups, multiplied by two. Thus, if the front-end team can work on four stories, and the back end team can work on three stories, the total capacity is calculated as 3x2=6 stories.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
In the initial run, both front- and back-end developer groups can produce 1-10 stories per sprint. The actual capacity is generated by a random number generator. If you have ever measured team productivity, you will know already that in real life, productivity can vary a lot more than this from sprint to sprint.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
It is obvious that the full-stack development team is consistently faster than the front/back-end team, but what does that difference mean? Are full-stack developers worth the investment or not?</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjBxXyDE1dnzzZxi2i0COGv2Ly1BAFR94NyIHYyhHEEiQd_yYSfQmNmCCkDXmtrhQpprON_eeFDA3IsqpVs_MhHgcesLcMUueyCZXujX6z-BxM0Lz-ix8xF3Yzs0AgA0GT9jCN/s1600/Bar+Graphs+01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="411" data-original-width="567" height="462" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjBxXyDE1dnzzZxi2i0COGv2Ly1BAFR94NyIHYyhHEEiQd_yYSfQmNmCCkDXmtrhQpprON_eeFDA3IsqpVs_MhHgcesLcMUueyCZXujX6z-BxM0Lz-ix8xF3Yzs0AgA0GT9jCN/s640/Bar+Graphs+01.PNG" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The simulator calculates the average velocity of the two teams. It also calculates the standard deviation for each velocity graph, and the difference in efficiency between the two average velocities.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Of course, the results will vary from run to run, but I've found that with this initial setup, a difference of about 30% is about normal.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
What this means is that if you have to spend 30% more to hire and/or train full-stack developers, it can still be a good investment.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
In other words, if it requires one day per week to develop and maintain the skills of full-stack developers, the company is likely to come out ahead financially.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
This, of course, is when front- and back-end capacity is, on average, perfectly balanced. What happens if we double the capacity of one of the groups, for example the front-end developers? Well increase the capacity of the full-stack team with the same amount. For example, if the teams had four developers each, we would increase team size to six developers.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-WdZ-5S6LRcw/XKpMWP9gpgI/AAAAAAABuOw/6l6qdG4buVQGnzrMKyP28O7TNc88Mm8VgCLcBGAs/s1600/Line%2BGraph%2B02.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="403" data-original-width="1242" height="206" src="https://1.bp.blogspot.com/-WdZ-5S6LRcw/XKpMWP9gpgI/AAAAAAABuOw/6l6qdG4buVQGnzrMKyP28O7TNc88Mm8VgCLcBGAs/s640/Line%2BGraph%2B02.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
Looks like <i>the difference</i> in capacity between the two teams increased. What is going on?</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMdPprV_fIG6yfDM_QCbEdABupgNW0-NLT7823a46G4x_pXFEsa4KSFBZM3JYfw8LQjRPXlUnTKy2sIGxEfpsl0b389rZOsTKdrPjWFkKUY7kdArYA8ZUnChbEPPbpzDU7oJ6r/s1600/Bar+Graphs+02.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="413" data-original-width="561" height="470" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMdPprV_fIG6yfDM_QCbEdABupgNW0-NLT7823a46G4x_pXFEsa4KSFBZM3JYfw8LQjRPXlUnTKy2sIGxEfpsl0b389rZOsTKdrPjWFkKUY7kdArYA8ZUnChbEPPbpzDU7oJ6r/s640/Bar+Graphs+02.PNG" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The average velocity of both teams went up, but the velocity of the full-stack team increased more. The difference in efficiency increased, which means the team with front/back-end developers is getting less value per developer.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
This makes adding more developers to a team a dicey way to increase productivity, especially since process bottlenecks move around a lot due to the inherent variation in the work. No matter which kind of specialist you add, it will be the wrong kind of specialist a significant portion of the time.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
A simple simulation like this is highly useful as an aid to thinking things through, it is by no means a substitute for thinking.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
For example, there are an infinite amount of different factors that can affect the productivity of a team. Won't that make the simulation invalid? No.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
First, many of those random factors will affect both teams equally. That means the velocity displacement will be equal for both teams, which means the difference in velocity between the teams will remain the same.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Other factors will have quite different effects on the teams. For example, assume that each team has four developers. The front/back-end team has two front-end developers and two back-end developers. If one developer falls ill, the full-stack team has lost 25% of capacity. Thefront/back-end team has lost 50%, because it now has a narrow process bottleneck.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Overall, the full-stack team is a lot more robust. Not accounting for that in the simulation, actually biases the simulation in favor of the front/back-end team. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
This means the full-stack team is easily more productive even though the simulation is actually biased against it.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
What about the standard deviation bars? Do they have anything significant to add to the story? Yes, but I am saving that for another blog post.</div>
Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-34100545297319455112017-10-18T11:28:00.001+02:002017-10-18T11:28:43.038+02:00Why HR Can't Hire PilotsI wrote a rather lengthy article about serious flaws in the recruitment processes used by most companies on Linkedin. The article is named <a href="https://www.linkedin.com/pulse/why-hr-cant-hire-pilots-henrik-m%C3%A5rtensson/" target="_blank">Why HR Can't Hire Pilots.</a><br />
<br />
Before I published it, I asked a few people, HR people and managers to read it and provide feedback. Despite the article being rather controversial in its conclusions, they liked it.Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-53984987284961317202016-03-22T12:49:00.000+01:002016-03-22T12:59:17.751+01:00Five Scrummaster Toolbox Podcasts<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-5apJNnLFz-k/VvEtW_ZJUSI/AAAAAAABGV4/tp-mNCi5rPII_cNMx-2jJXkgtb-kQ344w/s1600/podcast_badge_big.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="320" src="https://2.bp.blogspot.com/-5apJNnLFz-k/VvEtW_ZJUSI/AAAAAAABGV4/tp-mNCi5rPII_cNMx-2jJXkgtb-kQ344w/s320/podcast_badge_big.png" width="251" /></a></div>
The nice people who do the <a href="http://t.sidekickopen47.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XYgdDPSMVcVQTg1qwyjbW7dKLV856dLFkf4XTlDF02?t=http%3A%2F%2Fwww.scrum-master-toolbox.com%2F&si=6064700854370304&pi=189bab20-ebea-4b77-b61b-d17f1694cf6e" target="_blank">Oikosify Scrummaster Toolbox podcasts</a>, asked me to tell you that they, very sensibly, I think, have split their interview with me into smaller parts. (When I get going on a topic I am interested in, well...let's just say we had a long talk.)<br />
<br />
So, if you care for your sanity, I recommend you listen to <a href="http://t.sidekickopen47.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XYgdDPSMVcVQTg1qwyjbW7dKLV856dLFkf4XTlDF02?t=http%3A%2F%2Fwww.scrum-master-toolbox.com%2F&si=6064700854370304&pi=189bab20-ebea-4b77-b61b-d17f1694cf6e" target="_blank">their other podcasts</a>.<br />
<br />
If you think sanity is overrated, or if it is just too late for you, here are the ones where Vasco Duarte interviewed me:<br />
<br />
<ul>
<li><a href="http://www.scrum-master-toolbox.com/2015/03/podcast/henrik-martensson-on-how-he-got-people-to-jump-off-a-cliff-literally/" target="_blank">Leadership: How to get people to jump off a cliff, literally</a>!</li>
<li><a href="http://www.scrum-master-toolbox.com/2015/03/podcast/henrik-martensson-explores-how-to-set-effective-goals-for-a-project/" target="_blank">How to set effective goals for a project</a>.</li>
<li><a href="http://www.scrum-master-toolbox.com/2015/03/podcast/henrik-martensson-on-how-he-got-people-to-jump-off-a-cliff-literally/" target="_blank">The most important recruitment question</a>.</li>
<li><a href="http://www.scrum-master-toolbox.com/2015/03/podcast/henrik-martensson-on-how-he-got-people-to-jump-off-a-cliff-literally/" target="_blank">Introducing the Logical Thinking Process and Process Control Charts</a></li>
<li><a href="http://www.scrum-master-toolbox.com/2015/03/podcast/henrik-martensson-on-how-to-deal-with-sociopaths-at-work/" target="_blank">How to deal with sociopaths at work</a></li>
</ul>
<div>
Tonight, when things have quieted down, I will listen to a few of their more recent podcasts. They've got material there I am very interested in. :-)</div>
Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-11773960298227529102016-03-18T13:28:00.003+01:002016-03-18T13:28:43.400+01:00The question nobody dares to ask about strategy<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://1.bp.blogspot.com/-3bC7biR0fjw/Vqd4clc1S5I/AAAAAAABEPY/37BDSv9xTe8oEMxLXCQWM8cGBOOhWBh8A/s1600/The%2BElephant%2Bin%2Bthe%2BRoom%2B01.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="426" src="https://1.bp.blogspot.com/-3bC7biR0fjw/Vqd4clc1S5I/AAAAAAABEPY/37BDSv9xTe8oEMxLXCQWM8cGBOOhWBh8A/s640/The%2BElephant%2Bin%2Bthe%2BRoom%2B01.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Picture by Henrik Mårtensson</td></tr>
</tbody></table>
<br />
I originally published this article at <a href="https://www.linkedin.com/pulse/question-nobody-dares-ask-strategy-henrik-m%C3%A5rtensson?trk=prof-post" target="_blank">Linkedin Pulse</a>:<br />
<br />
<div>
When I transitioned from my work as a developer and systems architect into working with leadership, strategy, organization, and process improvement, I had a lot to learn. Naturally, I read a lot, I joined interest groups, and I asked questions. I soon discovered that there were some questions that, though very important, were never asked.</div>
<div>
<br /></div>
<div>
The reason for not asking important questions is usually embarrassment. If I know I am supposed to know something, but I don't, then it is embarrassing to ask. Short term, it is often easier to hide the lack of knowledge.</div>
<div>
<br /></div>
<div>
The downside, of course, is that if one does not ask, one does not learn. If nobody asks, nobody learns, but everyone believes everybody else knows…</div>
<div>
This can create a downwards spiral, where nobody knows anything about something, but everybody is to busy hiding their lack of knowledge to notice.</div>
<div>
<br /></div>
<div>
I found that in business, strategy is one of those somethings. I found that nobody dared to ask a very fundamental question about strategy. I also found that the lack of an answer caused confusion, lack of direction, lack of cohesion, cost a lot of money, caused poor working conditions, stress, unnecessary layoffs… I could go on, but you get the gist of it.</div>
<div>
<br /></div>
<div>
What was the question? A very simple one really:</div>
<div>
<br /></div>
<blockquote class="tr_bq" style="text-align: center;">
<span style="font-size: large;">What is strategy?</span></blockquote>
<div>
When I got interested in business strategy, I found business books about the topic confusing. Terminology was defined in rather loose terms. The definitions did not help me in any practical way. There were many different definitions. Some authors even dismissed strategy as a useless waste of time.</div>
<div>
<br /></div>
<div>
I found this difficult to understand. Strategy is important in Game Theory (which deals with business problems, among other things), it is important in Chess, a military organization cannot survive a war without strategy, in ecosystems, animals and plants have survival strategies. Why would business, which is obviously a strategic, competitive game, be any different?</div>
<div>
<br /></div>
<h2>
Strategy is the answer to a Question!</h2>
<div>
I did find one business definition of strategy that worked for me. It is from the Theory Of Constraints:</div>
<blockquote class="tr_bq">
<div style="text-align: center;">
<span style="font-size: large;">Strategy is the answer to the question "What for?" </span></div>
<span style="font-size: large;"><div style="text-align: center;">
Tactics is the answer to the question "How to?"</div>
</span></blockquote>
<div>
In other words, a strategy is a structure consisting of an ultimate goal, and a set of intermediate objectives that, if achieved, will lead to achieving the goal.</div>
<div>
<br /></div>
<div>
The definition also made it clear that for each goal or intermediate objective, there must be at least one corresponding tactic.</div>
<div>
<br /></div>
<div>
Viewed through the lens of that definition, strategy and tactics in a business context made a lot more sense than it had before. The definition works for all strategic games, not just business. It also clearly separates strategy and tactics. Most other definitions tend to muddle them, and get lost in fuzzy lines of reasoning about different scale and scope.</div>
<div>
<br /></div>
<h2>
Confusing Strategy & Tactics</h2>
<div>
Unfortunately, while strategy and tactics as useful concepts started to make sense, the business strategy documents I read made correspondingly less sense.</div>
<div>
<br /></div>
<div>
For one thing, I found that most of the strategy documents I read weren't strategy documents at all. They were filled with material on how to do things, with zero information on why these things had to be done in the first place.</div>
<div>
<br /></div>
<div>
Many strategy documents were actually tactical documents, masquerading as strategy documents. When I found tactics in strategy documents, I used to go looking for actual strategy, but most of the time, there simply was no strategy to be found, just a random collection of things to do, with little cohesion, or even working against each other.</div>
<div>
<br /></div>
<h2>
The Emperor's New Clothes</h2>
<div>
Other "strategy" documents were hilariously obfuscated. Some were obfuscated so well that neither I, nor anyone else, know what is actually in them.</div>
<div>
<br /></div>
<div>
One company I had worked for had got "help" developing a strategy from a rather large consultancy. When I had a look at strategy documents from the consultancy, I found them difficult to read. Suspiciously difficult! So, I ran their documents through a readibility calculator, and found that the language was so complex you needed a doctor's degree in English to figure out what the content was.</div>
<div>
<br /></div>
<div>
Nobody could read and understand the darn things, and everybody was too embarrassed to say anything about it.</div>
<div>
<br /></div>
<div>
What's the use of having a strategy nobody can read and understand? Apart from confusing competitors, not much.</div>
<h2>
Keep it Simple!</h2>
<div>
Personally, I like to express strategies as diagrams, instead of with text only. Diagrams make it easier to build a coherent, and easy to understand, overview.</div>
<div>
<br /></div>
<div>
My favorite method, The Logical Thinking Process, (yes, I know the name is cringeworthy,) is pretty good. I get the overview, and it is also easy to dig down into more detail when necessary. There are plenty of other useful methods around, but one has to do a bit of research to find them.</div>
<h2>
A Game of Interaction and Isolation</h2>
<div>
It is useful to have more than one perspective, so I did not stop with the Theory Of constraints view of strategy. I found very useful material in a military strategic framework, Maneuver Conflict, by Col. John Boyd:</div>
<div>
<br /></div>
<blockquote class="tr_bq" style="text-align: center;">
<span style="font-size: large;">Strategy is a game of interaction and isolation!</span></blockquote>
<div>
How is that useful? Well, if you know that you want to strengthen interactions between yourself and your allies (including customers), and isolate your enemies from each other, then you can check if that is what you are doing.</div>
<div>
<br /></div>
<div>
I found that remarkably often, it isn't. Companies use organizational structures explicitly designed to reduce the interactions of its employees, often because they reuse old organizational designs, without knowing the original purpose.</div>
<div>
<br /></div>
<div>
Conversely, companies do a lot of stuff that separates them from their customers, and drives the customers into the arms of competitors. For example, I can no longer make a phone call to my bank without giving them a password, over the phone, before I even get to talk to somebody. If I were not already a customer, I would not be able to call them at all.</div>
<h2>
Strategic principles</h2>
<div>
In addition to having a clear definition of strategy, it helps to have a set of basic principles of strategy. I mean really basic, so basic that they are relevant to any game of strategy. That is something Maneuver Conflict provides, but business strategy frameworks rarely do.</div>
<h2>
36 Stratagems</h2>
<div>
Speaking of principles, I have found old Chinese texts, like The Art of War, and 36 Stratagems, to be very useful. They provide insight, and they can be used as idea generators. No wonder that Chinese business people study them.</div>
<div>
<br /></div>
<div>
I'll do a follow up article about 36 Stratagems soon. There are stories to tell. :-)</div>
<div>
<br /></div>
<div>
Note: The 36 Stratagems article will take awhile. Might even end up becoming a book, so please don't hold your breath waiting for it.</div>
Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-74816461355811246462015-12-06T12:45:00.000+01:002015-12-06T12:45:18.199+01:00Review: Exploring the Practice of Antifragility<div class="separator" style="clear: both; text-align: center;">
<a href="http://ecx.images-amazon.com/images/I/51ZGc1DNCKL._SX313_BO1,204,203,200_.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://ecx.images-amazon.com/images/I/51ZGc1DNCKL._SX313_BO1,204,203,200_.jpg" height="320" width="202" /></a></div>
<br />
I wrote a review on Amazon for <a href="https://www.blogger.com/First%20disclosure:%20As%20of%20the%205th%20of%20December%202015,%20I%20am%20a%20contributor%20to%20this%20book!%20I%20do%20not%20have%20a%20financial%20stake%20in%20it,%20but%20I%20do%20wish%20the%20book%20to%20succeed,%20because%20I%20believe%20the%20idea%20of%20antifragility%20to%20be%20important.%20I%20won't%20review%20my%20own%20contribution,%20of%20course,%20but%20stick%20to%20the%20things%20I%20have%20read%20by%20the%20other%20contributors.%20Second,%20Exploring%20the%20Practice%20of%20Antifragility%20is%20itself%20antifragile!%20The%20book%20is%20a%20Kindle%20ebook,%20and%20like%20all%20Kindle%20books,%20it%20can%20be%20updated%20with%20new%20material%20from%20time%20to%20time.%20This%20means%20the%20book%20itself%20can%20evolve%20according%20to%20pressure%20from%20the%20environment,%20i.e.%20reviews%20and%20sales%20data%20can%20actually%20make%20this%20book%20better%20over%20time.%20Thus,%20if%20you%20buy%20the%20book,%20think%20of%20a%20way%20to%20improve%20it,%20and%20write%20about%20it%20in%20a%20review,%20your%20wish%20might%20come%20true.%20While%20this%20is%20possible%20to%20do%20with%20all%20Kindle%20ebooks,%20I%20do%20not%20think%20too%20many%20of%20them%20make%20good%20use%20of%20it.%20When%20Si%20Alhir,%20one%20of%20the%20editors,%20told%20me%20about%20the%20book%20having%20planned%20updates%20when%20he%20invited%20me%20to%20participate,%20I%20found%20this%20to%20be%20a%20very%20attractive%20feature.%20Third,%20the%20book%20also%20features%20another%20very%20important%20property%20of%20antifragile%20systems:%20Variation!%20The%20book%20is%20an%20anthology,%20with%20essays%20written%20by%20very%20different%20people,%20who%20have%20very%20different%20backgrounds,%20and%20who%20do%20very%20different%20things.%20This%20means%20you%20won't%20be%20interested%20in%20everything,%20but,%20if%20you%20are%20interested%20in%20antifragility,%20there%20will%20almost%20certainly%20be%20something%20in%20it%20that%20you%20find%20very%20interesting.%20Fourth,%20the%20book%20was%20practically%20useful%20to%20me!%20Two%20years%20ago%20I%20began%20building%20an%20antifragile%20organization.%20We%20are%20now%20more%20than%20350%20people.%20One%20of%20my%20book%20projects%20is%20a%20book%20about%20the%20organization,%20and%20I%20have%20struggled%20with%20explaining,%20in%20a%20simple%20way,%20the%20difference%20between%20the%20antifragile%20organization,%20and%20fragile%20organizations%20in%20the%20same%20domain.%20Todd%20Nilson%20solved%20the%20problem%20for%20me,%20writing%20about%20Nicholas%20Taleb's%20triad%20schema.%20It%20was%20exactly%20what%20I%20needed.%20I%20can%20borrow%20the%20idea,%20adapt%20it%20for%20my%20own%20book,%20and%20it%20will%20work%20beautifully.%20Si%20Alhir%20made%20the%20connection%20between%20antifragility%20and%20the%20OODA%20decision%20loop%20from%20John%20Boyd's%20Maneuver%20Conflict,%20which%20I%20find%20interesting,%20because%20the%20antifragile%20organization%20I%20am%20deeply%20involved%20in,%20directly%20uses%20many%20ideas%20from%20Boyd.%20Again,%20Boyd's%20ideas%20are%20echoed%20in%20Todd%20Nilson's:%20%22%E2%80%A6the%20purpose%20of%20the%20community%20trumps%20all%20else.%22%20I%20also%20enjoyed%20reading%20Elinor%20Slomba's%20piece%20about%20sustainability,%20connectivity,%20and%20diversity,%20and%20how%20to%20use%20simple%20free%20tools%20to%20collaborate%20over%20the%20Internet.%20Valuable%20ideas%20I%20can%20use%20in%20my%20own%20work.%20Highly%20useful.%20Also,%20Slomba's%20ideas%20about%20cascades%20the%20properties%20of%20aggregated%20and%20distributed%20systems%20are%20practically%20useful%20to%20me.%20I%20recently%20released%20a%20book%20about%20reducing%20lead%20times%20in%20the%20book%20publishing%20business.%20The%20method%20I%20wrote%20about,%20and%20use%20to%20write%20my%20own%20books,%20applies%20the%20same%20ideas.%20Slomba%20has%20given%20me%20a%20slightly%20different%20perspective,%20which%20will%20help%20me%20express%20the%20ideas%20in%20a%20simpler%20manner%20in%20my%20own%20books.%20So,%20I%20give%20this%20book%20five%20stars,%20because%20it%20actively%20uses%20the%20ideas%20it%20proposes,%20because%20it%20will%20get%20better%20over%20time,%20and%20because%20it%20was%20practically%20useful%20to%20me%20immediately%20when%20I%20read%20it." target="_blank">Exploring the Practice of Antifragility</a>.<br />
<br />
I am republishing it here:<br />
<br />
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;"><i>First</i> disclosure: As of the 5<sup>th</sup> of December 2015, I am a contributor to this book! I do not have a financial stake in it, but I do wish the book to succeed, because I believe the idea of antifragility to be important. I won't review my own contribution, of course, but stick to the things I have read by the other contributors.</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;"><i>Second</i>, <i>Exploring the Practice of Antifragility</i> is itself antifragile! The book is a Kindle ebook, and like all Kindle books, it can be updated with new material from time to time. This means the book itself can evolve according to pressure from the environment, i.e. reviews and sales data can actually make this book better over time.</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;">Thus, if you buy the book, think of a way to improve it, and write about it in a review, your wish might come true. While this is possible to do with all Kindle ebooks, I do not think too many of them make good use of it. When Si Alhir, one of the editors, told me about the book having planned updates when he invited me to participate, I found this to be a very attractive feature.</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;"><i>Third</i>, the book also features another very important property of antifragile systems: Variation!</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;">The book is an anthology, with essays written by very different people, who have very different backgrounds, and who do very different things. This means you won't be interested in everything, but, if you are interested in antifragility, there will almost certainly be <i>something</i> in it that you find very interesting.</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;"><i>Fourth</i>, the book was practically useful to me! Two years ago I began building an antifragile organization. We are now more than 350 people. One of my book projects is a book about the organization, and I have struggled with explaining, in a simple way, the difference between the antifragile organization, and fragile organizations in the same domain.</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;">Todd Nilson solved the problem for me, writing about Nicholas Taleb's triad schema. It was exactly what I needed. I can borrow the idea, adapt it for my own book, and it will work beautifully.</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;">Si Alhir made the connection between antifragility and the OODA decision loop from John Boyd's Maneuver Conflict, which I find interesting, because the antifragile organization I am deeply involved in, directly uses many ideas from Boyd.</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;">Again, Boyd's ideas are echoed in Todd Nilson's: "…the purpose of the community trumps all else."</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;">I also enjoyed reading Elinor Slomba's piece about sustainability, connectivity, and diversity, and how to use simple free tools to collaborate over the Internet.</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;">Valuable ideas I can use in my own work. Highly useful.</span></div>
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;">Also, Slomba's ideas about cascades the properties of aggregated and distributed systems are practically useful to me. I recently released a book about reducing lead times in the book publishing business. The method I wrote about, and use to write my own books, applies the same ideas. Slomba has given me a slightly different perspective, which will help me express the ideas in a simpler manner in my own books.</span></div>
<br />
<div style="margin-bottom: 6px; margin-top: 12px;">
<span style="font-family: inherit;">So, I give this book five stars, because it actively uses the ideas it proposes, because it will get better over time, and because it was practically useful to me immediately when I read it.</span></div>
Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-86397649273326413102015-12-02T15:27:00.000+01:002015-12-03T14:11:49.922+01:00The season of the jolly speedwriter!<div style="text-align: center;">
<a href="http://www.bokus.com/bok/9789197880176/skriv-och-salj/" target="_blank" title="Visa Skriv och sälj! (HMBMC, 2015) på Bokus"><img alt="Bokomslag Skriv och sälj! (e-bok)" src="http://image.bokus.com/images2/9789197880176_200_skriv-och-salj_e-bok" /></a>
</div>
<br />
<br />
I've been speedwriting again! This time about how to write and publish a book very fast: <a href="http://www.bokus.com/bok/9789197880176/skriv-och-salj/" target="_blank">Skriv och sälj!: Skriv och sälj en bok på 14 dagar</a> (Write and Sell!: Write and sell a book in 14 days) is out on <a href="http://www.adlibris.com/se/e-bok/skriv-och-salj-9789197880176" target="_blank">Adlibris</a>, <a href="http://www.bokus.com/bok/9789197880176/skriv-och-salj/" target="_blank">Bokus</a>, <a href="https://dito.se/e-bok/9789197880176/skriv-och-s%C3%A4lj-" target="_blank">Dito</a>, and <a href="https://bokon.se/ebok/skriv-och-saelj_henrik-martensson/" target="_blank">Bokon</a>.<br />
<br />
Actually, <i>speedwriting</i> is a misnomer. I am, have always been, and always will be, a slow writer. The idea with <i>Write and sell!</i> is to reduce queue and wait times in a book production process, the same way we can reduce it in software development processes (Agile), in product development (Lean Product Development), and in manufacturing (Lean, TOC).<br />
<br />
I am digging down to the queueing theory with this one, and going with it all the way to what to do, and how to do it.<br />
<br />
<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/AVvXsEjAkMS0eZWrB_J6ZAb1W15yML7-kK9NX5MEKc-cPKHK4KBDo2hIGzXdE5wau7n9B1lqvVQfDRu_xCP5C0187jsCCIg7scs5olChfCi3NaS_yMgQkrECaLrxtnJDHttBAgmrESZx/s1600/Skriv+och+salj+lead+time.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="238" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAkMS0eZWrB_J6ZAb1W15yML7-kK9NX5MEKc-cPKHK4KBDo2hIGzXdE5wau7n9B1lqvVQfDRu_xCP5C0187jsCCIg7scs5olChfCi3NaS_yMgQkrECaLrxtnJDHttBAgmrESZx/s640/Skriv+och+salj+lead+time.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Writing and publishing the book took only nine days. I had planned to do it in 14 days, but the gods of time buffering were on my side this time around.</td></tr>
</tbody></table>
Writing and publishing the book took only nine days. The reason why the lead time was so short, is that I utilized Little's Law:<br />
<br />
<b>t</b> = <b>I</b>/<b>T</b><br />
<br />
where<br />
<br />
<b>t</b> is the lead time<br />
<b>T</b> is the production rate<br />
<b>I</b> is the average number of items in queue<br />
<br />
I managed to stir up a bit of controversy in two writer's communities on Facebook when I published the book.<br />
<br />
People are assuming that I worked my butt off to produce faster, i.e. increase <b>T</b> in the equation, and that they would have to kill themselves trying to achieve the same productivity.<br />
<br />
Of course, I am much lazier than that! I chose to <i>reduce</i> <b>I</b> instead.<br />
<br />
How did I do that? Well, one way is to write shorter books, but as it turns out, you do not have to. You can use <i>load balancing</i> instead!<br />
<br />
That is right, the magic stems from applying <i><a href="https://en.wikipedia.org/wiki/Production_leveling" target="_blank">heijunka</a></i> to the authoring/publishing process. Heijunka has been around since at least 1948. All I did was to apply it in a new context.<br />
<br />
I did a bit more than that. I took three other equations from queueing theory, network science, and TOC (specifically from Throughput Accounting), and worked out how to apply them too. If you are interested, well, it's in the book. (Badger me if you are really, really interested in an English translation. The main reason I am not translating the book is sales. Right now it is easier for me to build book sales in Sweden. <i>Sigh!</i>...That's in the book too.)<br />
<br />
Now, instead of trying to push people to learn, I intend to work with those who are curious and willing to try something new, and with those who are interested because they already know. Part of that tactic was to create a <a href="https://www.facebook.com/groups/970297819710098/" target="_blank">Facebook group</a> for those interested in reduce writing and publishing lead time.<br />
<br />
We'll see what comes of it. There is certainly more "speedwriting" ahead.<br />
<br />
I haven't figured out what to call it yet, since it is not really about speed. I am pretty sure the original, Japanese terminology will not fly with writers. No, I need something else...<br />
<i><br /></i>
<i>Smartwriting</i>, anyone?Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-23059694047237487962015-11-28T12:05:00.000+01:002015-12-02T15:53:39.141+01:00Tempo! is available at Bokus, Bokon, and Adlibris<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="http://www.bokus.com/bok/9789197880107/tempo-praktisk-strategi-organisation-och-ledarskap-i-en-kaotisk-tid/" style="margin-left: auto; margin-right: auto;" target="_blank" title="Visa Tempo! : Praktisk strategi, organisation och ledarskap i en kaotisk tid av Henrik Mårtensson (häftad, 2015) på Bokus"><img alt="Bokomslag Tempo! : Praktisk strategi, organisation och ledarskap i en kaotisk tid (häftad)" src="http://image.bokus.com/images2/9789197880107_200_tempo-praktisk-strategi-organisation-och-ledarskap-i-en-kaotisk-tid_haftad" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Click the picture to buy Tempo! from Bokus.</td></tr>
</tbody></table>
<br />
<div style="text-align: center;">
<br /></div>
Tempo! has finally got distribution in Sweden! The printed version of the book is now available on <a href="http://www.bokus.com/bok/9789197880107/tempo-praktisk-strategi-organisation-och-ledarskap-i-en-kaotisk-tid/" target="_blank">Bokus</a>, and <a href="http://www.adlibris.com/se/bok/tempo-praktisk-strategi-organisation-och-ledarskap-i-en-kaotisk-tid-9789197880107" target="_blank">Adlibris</a>.<br />
<br />
In addition, companies hiring me for consulting work, can buy Tempo! from a special web shop, at a considerably reduced price.<br />
<br />
When I wrote Tempo! my intent was to write a practically useful business strategy book in Swedish. I did not want to tell other people what to do with their businesses, that is for them to decide, but I wanted to help out with <i>how</i> to do whatever it is they want to achieve.<br />
<br />
I had seen too many companies where good, smart people just ran into a brick wall when they tried to make things better, not just for themselves, but for everyone in the organization, and for their customers.<br />
<br />
<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/AVvXsEjvY8ac_IIDhPMVlvnK0CJSvfWaSju0DzEzZtKRJnWWi0PclkGk21nI-OPv4ZwD4hHOKfPLli1TfC1unC0kbTsEPcgGqClB8BV4pgdIkZUMqinQetq7wo7j_lbAGEdwXvHAWVLe/s1600/Tempo+sida+40-41.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="424" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvY8ac_IIDhPMVlvnK0CJSvfWaSju0DzEzZtKRJnWWi0PclkGk21nI-OPv4ZwD4hHOKfPLli1TfC1unC0kbTsEPcgGqClB8BV4pgdIkZUMqinQetq7wo7j_lbAGEdwXvHAWVLe/s640/Tempo+sida+40-41.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Tempo! is illustrated with more than 100 diagrams and photos</td></tr>
</tbody></table>
Originally, I wanted to write a book about a practical method for developing strategy. I felt there was a lot of need, because I have seen many companies where strategy and tactics are confused, and where the relationship between strategy, tactics, and organization are ignored.<br />
<br />
This can lead to a world of hurt when the organization tries to do things it is not designed to do, or when it tries to do two or more contradictory things simultaneously.<br />
<br />
Another thing I wanted to provide was a means of <i>clear, unambigious communication</i>. Far to often I have heard people say "<i>We want to work towards the company goals, but we don't know what the heck they are!</i>"<br />
<br />
So, what do you get with <i>Tempo!</i>? Basically three things:<br />
<br />
<ul>
<li>The basics that every manager, and preferably everyone, in your company needs to know about how people work, how processes work, and how your organization works. Expect some surprises here.</li>
<li>A strategic framework, <i>Strategic Navigation</i>, that is basically a civilian adaptation of John Boyd's military Maneuver Conflict framework.</li>
<li>All the methods and tools you need to make it work. </li>
<ul>
<li>Crawford Slip lets you gather and organize information from large groups of people very quickly</li>
<li>TLTP, The Logical Thinking Process, lets you find root causes of problems, find solutions, and then build the project plans you need to fix them.</li>
<li>Process Behavior Charts, a tool that helps you make sense of otherwise very difficult to interpret data in reports.</li>
</ul>
</ul>
<br />
The material has been thoroughly researched, used in practice, and proofread by some of the best management experts around, including Bill Dettmer, Chet Richards, Don Reinertsen, and many, many others.<br />
<br />
Now, with a much better distribution network than before, I do hope more people will find Tempo! useful.<br />
<br />
If you read the book, feel free to <a href="mailto:self@henrikmartensson.org" target="_blank">drop me a note</a>, and tell me what you think of it, if you found it useful, and if you have any suggestions for improvements.<br />
<br />
<br />Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0tag:blogger.com,1999:blog-20843954.post-8473041137578677642015-11-21T18:57:00.002+01:002015-11-23T01:53:54.809+01:00Less! available on Dito, Bokus, bokon, and Adlibris<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-kMcLjjOUVtQ/VlCvF1h5RkI/AAAAAAABD3Y/7ma_FtG1VC4/s1600/LESS_cover_01.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://1.bp.blogspot.com/-kMcLjjOUVtQ/VlCvF1h5RkI/AAAAAAABD3Y/7ma_FtG1VC4/s320/LESS_cover_01.jpg" width="245" /></a></div>
The ebook version of LESS! is now available on <a href="https://dito.se/e-bok/9789197880121/less-" target="_blank">Dito</a>, <a href="http://www.bokus.com/bok/9789197880121/less/" target="_blank">Bokus</a>, <a href="https://bokon.se/ebok/less_bjarte-bogsnes/" target="_blank">Bokon</a> and <a href="http://www.adlibris.com/se/e-bok/less-9789197880121" target="_blank">Adlibris</a>. LESS! is of course also available via <a href="http://www.amazon.com/LESS-Henrik-M%C3%A5rtensson-ebook/dp/B00AE8SJIS/ref=sr_1_1?ie=UTF8&qid=1448128548&sr=8-1&keywords=henrik+m%C3%A5rtensson" target="_blank">Amazon</a>.<br />
<br />
I am very proud of LESS!. I am particularly proud of the fact that I did not write most of it. LESS! is a collaborative work, and working with the other authors has been a privilege I cannot adequately describe. One of my best adventures ever.<br />
<br />
LESS! is about building better places to work:<br />
<br />
Have you ever had a great idea crushed by the words, "we can't do that, because it's not in the budget"? Then you really need to read up on Beyond Budgeting. Bjarte Bogsnes, VP of Performance Management at Statoil and Dr. Peter Bunce, Director of the Beyond Budgeting Round Table, have written two chapters helping you free yourself from the chains of budgeting.<br />
<br />
If you look around you at work, and see people with great potential, but somehow things never get together like they should. The sum of the work is always less than the sum of what the individuals can do. Then Making the Entire Organization Agile, the chapter by Steve Denning is for you. Steve is a former director of the World Bank. He is a deep thinker with unsurpassed practical experience. In November 2000 he was selected as one of the world's ten Most Admired Knowledge Leaders (Teleos).<br />
<br />
If you want to do Lean or Agile, what is you and your organization's position on Theory X and Theory Y? Why do you need to know about them? Because Agile and Lean are Theory Y based, and your organization is most likely Theory X based. X and Y ideas don't mix well. Not understanding the difference is a major cause of failure when implementing Lean or Agile. Dan Bergh Johnson's chapter Agile and Lean do not fit into Taylor's Glove will get you up to speed on the all important fundamentals.<br />
<br />
And that is just for starters. There is lots more, by authors like James Sutton, Karl Scotland, Håkan Forss, Ola Ellnestam, Brian Hawkes, Maarit Laanti, Ari-Pekka Skarp, and me. And you might want to check out the Foreword by John Hagel III. John is a great author in his own right, Director at Deloitte LLP, and co-chairman of the Deloitte Center for the Edge.Kallokainhttp://www.blogger.com/profile/15756733532883677794noreply@blogger.com0