Blog 56fedaf1524ce830d9000084 2016-04-01T23:32:51+03:00 A simple test to find out about the maturity of your development team 56fedaf3524ce830d90000e8 2016-04-01T23:32:51+03:00 2014-06-03T23:00:00+03:00 <h3 class="null" style="color: rgb(96, 96, 96); font-family: Arial; font-size: 16px; line-height: 16px; margin: 12.708333969116211px 0px 6.3541669845581055px;">If the answer is &ldquo;YES&rdquo;,</h3> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">you may not need to read this further. Ask your team for some detail to make sure that there is logic behind the short answer, but most likely your team is doing fine. As a next step, you may or may not consider&nbsp;</span><a href="http://colabpro.com/services/nearshore-software-outsourcing-solutions/" style="font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;" target="_blank">outsourcing&nbsp;</a><span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">&ndash; depending on your business rationale.</span> <h3 class="null" style="color: rgb(96, 96, 96); font-family: Arial; font-size: 16px; line-height: 16px; margin: 12.708333969116211px 0px 6.3541669845581055px;">If the answer is &ldquo;NO&rdquo;</h3> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">&ndash; you are likely to have an issue with your team&rsquo;s maturity.</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">&nbsp;</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">Here are the typical reasons that prevent an organization from using outsourcing or distributed development:</span> <ul style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;"> <li>poor development processes, standards, practices</li> <li>unclear team responsibilities and inter-team interfaces</li> <li>poor communication skills on team lead / project management level</li> <li>weak infrastructure support</li> <li>over-ambitious individuals in team management</li> <li>poor quality of current code, as a result of all or some of the above&nbsp;</li> </ul> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">If you will follow up with another simple question:</span> <h3 class="null" style="color: rgb(96, 96, 96); font-family: Arial; font-size: 16px; line-height: 16px; margin: 12.708333969116211px 0px 6.3541669845581055px;">&ldquo;Why can&rsquo;t we outsource?&rdquo;</h3> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">you are not likely to hear any of the reasons just mentioned. You will hear how unique the team&rsquo;s skills and competences are, how complicated the product is, or how &ldquo;nothing of this can be outsourced, as it will ruin everything&rdquo;.</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">&nbsp;</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">Our experience shows that a mature development organization can support outsourcing or distributed development in most of cases. It does not mean that you have to. Ability to outsource and the business rationale for it are relatively independent issues.&nbsp;</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">&nbsp;</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">You do need to understand what is behind that &ldquo;NO&rdquo; as the initial answer. Leaving it unaddressed may contain risks regarding your team&rsquo;s deliverables as well as decrease your sourcing flexibility.</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">&nbsp;</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">At the very minimum, our advice is to find out what are the reasons for responding with a &ldquo;NO&rdquo; to the simple question.&nbsp;</span><a href="http://colabpro.com/services/outsourcing-advice/contact-us-regarding-outsourcing-advice/" style="font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify;" target="_blank">Let us know&nbsp;</a><span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14.44444465637207px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">if we can help you with this.&nbsp;</span> <div>&nbsp;</div> We can evaluate Agile maturity of your organization in 4 hours 56fedaf3524ce830d90000e4 2016-04-01T23:32:51+03:00 2013-10-21T12:25:00+03:00 <h2 class="null" style="color: rgb(64, 64, 64); font-family: Arial; font-size: 18px; line-height: 18px; margin: 7.390625px 0px 3.6875px; background-color: rgb(253, 253, 253);">&nbsp;</h2> <table border="1" cellpadding="10" cellspacing="0" style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);"> <tbody> <tr> <td style="border-collapse: collapse; width: 224px;">Activity</td> <td style="border-collapse: collapse; width: 95px; text-align: left;">Time in minutes</td> <td style="border-collapse: collapse; width: 201px;">Comments</td> </tr> <tr> <td style="border-collapse: collapse; width: 224px; text-align: left;">Fill application form to participate in assessment</td> <td style="border-collapse: collapse; width: 95px;">1<br /> &nbsp;</td> <td style="border-collapse: collapse; width: 201px;">&nbsp;</td> </tr> <tr> <td style="border-collapse: collapse; width: 224px; text-align: left;">Receive invitation to register your Agile Team leads for survey</td> <td style="border-collapse: collapse; width: 95px;">14</td> <td style="border-collapse: collapse; width: 201px;">&nbsp;</td> </tr> <tr> <td style="border-collapse: collapse; width: 224px; text-align: left;">Submit your Agile Team Lead information (name, email)</td> <td style="border-collapse: collapse; width: 95px;">15</td> <td style="border-collapse: collapse; width: 201px; text-align: left;">This may require even less if you have your project manager/ &nbsp;team leaders list ready.</td> </tr> <tr> <td style="border-collapse: collapse; width: 224px; text-align: left;">Team leads receive invitation to take Agile Team Lead survey</td> <td style="border-collapse: collapse; width: 95px;">30</td> <td style="border-collapse: collapse; width: 201px;">&nbsp;</td> </tr> <tr> <td style="border-collapse: collapse; width: 224px; text-align: left;">Team Leads fill in survey</td> <td style="border-collapse: collapse; width: 95px;">120</td> <td style="border-collapse: collapse; width: 201px; text-align: left;">50% of respondents spend less than 2 hours to fill in survey.</td> </tr> <tr> <td style="border-collapse: collapse; width: 224px; text-align: left;">Receive VAMI report</td> <td style="border-collapse: collapse; width: 95px;">60</td> <td style="border-collapse: collapse; width: 201px;">&nbsp;</td> </tr> <tr> <td style="border-collapse: collapse; width: 224px;">Total</td> <td style="border-collapse: collapse; width: 95px;">240 minutes</td> <td style="border-collapse: collapse; width: 201px;">&nbsp;</td> </tr> </tbody> </table> <h2 class="null" style="color: rgb(64, 64, 64); font-family: Arial; font-size: 18px; line-height: 18px; margin: 7.390625px 0px 3.6875px; background-color: rgb(253, 253, 253);">Agile Team Lead Survey</h2> <p><span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">&nbsp;</span></p> <table border="1" cellpadding="10" cellspacing="0" style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);"> <tbody> <tr> <td style="border-collapse: collapse; width: 189px;">Area</td> <td style="border-collapse: collapse; width: 189px;">Number of questions</td> </tr> <tr> <td style="border-collapse: collapse; width: 189px;">Team lead demographics</td> <td style="border-collapse: collapse; width: 189px;">3</td> </tr> <tr> <td style="border-collapse: collapse; width: 189px;">Professional experience</td> <td style="border-collapse: collapse; width: 189px;">5</td> </tr> <tr> <td style="border-collapse: collapse; width: 189px;">Agile project characteristics and demographics</td> <td style="border-collapse: collapse; width: 189px;">11</td> </tr> <tr> <td style="border-collapse: collapse; width: 189px;">Project practices</td> <td style="border-collapse: collapse; width: 189px;">54</td> </tr> </tbody> </table> <h2 class="null" style="color: rgb(64, 64, 64); font-family: Arial; font-size: 18px; line-height: 18px; margin: 7.390625px 0px 3.6875px; background-color: rgb(253, 253, 253);">What you will get? - &nbsp;Assessment report<span style="color: rgb(80, 80, 80); font-size: 14px; line-height: 21px; text-align: justify;">&nbsp;</span></h2> <p><span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">22 pages</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">17 diagrams</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">180 numeric values</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">Top 5 development priorities</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">Top 3 areas of misalignment</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">Agile Maturity indexes, gaps and distribution in 20 areas within 4 categories</span><br style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);" /> <span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">Comparison of your results to market average and top performers</span></p> <h2 class="h2" style="color: rgb(64, 64, 64); font-family: Arial; font-size: 18px; line-height: 18px; margin: 7.390625px 0px 3.6875px; background-color: rgb(253, 253, 253);">Next steps?</h2> <p><a href="http://colabpro.com/vendor-services/vendor-agile-maturity-assessment/" style="color: rgb(51, 102, 153); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);" target="_self">Learn more</a><span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">&nbsp;and&nbsp;</span><a href="http://colabpro.com/vendor-services/vendor-agile-maturity-assessment/apply-for-vendor-agile-maturity-assessment/application-form" style="color: rgb(51, 102, 153); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);" target="_self">apply</a><span style="color: rgb(80, 80, 80); font-family: Arial; font-size: 14px; line-height: 21px; text-align: justify; background-color: rgb(253, 253, 253);">!</span></p> Drupal outsourcing research 56fedaf3524ce830d90000e0 2016-04-01T23:32:51+03:00 2013-10-04T14:15:00+03:00 <p>Research will be done in following phases:</p> <h2>Definition of Drupal skills areas</h2> <p>We will propose our initial list of skills/experiences associated with Drupal projects and will ask you to review the list, rate particular items and come up with additions/replacement.<br /> Purpose of this exercise is to create list of skills and experiences (or possibly several versions of list with different level of details) essential for Drupal projects.<br /> Input from both suppliers (how they structure their capabilities) and customers (what they are looking for) is important at this stage.</p> <h2>Gathering supplier information</h2> <p>Once skills list will be fixed, we will convert it into survey and&nbsp;will offer signed suppliers to fill in information about their company skills and experience as well as Drupal related service offerings.</p> <h2>Survey report</h2> <p>Once survey information will be collected, we will distribute survey report to those, who indicated interest in results.</p> <h2>Audience of survey</h2> <p>&nbsp;</p> <table border="1" cellpadding="10" cellspacing="1" style="line-height:21px;width:608px;" width="231"> <colgroup> <col /> <col /> <col /> </colgroup> <tbody> <tr height="14"> <td height="14" style="height:19px;width:71px;">Participants</td> <td style="width:119px;">&nbsp;What is expected?</td> <td style="width:119px;">Why to participate?</td> </tr> <tr height="14"> <td height="14" style="height:19px;">European customers looking to outsource Drupal projects to nearshore (offshore)</td> <td>Review skills list</td> <td>Find vendor options for your next Drupal project</td> </tr> <tr height="14"> <td height="14" style="height:19px;">European Drupal vendors looking to extend their capabilities with nearshore resources</td> <td>Review skills list</td> <td>Find nearshore delivery partner</td> </tr> <tr height="14"> <td height="14" style="height:19px;">Nearshore (Eastern European) outsourcing companies looking for Drupal projects</td> <td>Review skills list<br /> Submit company skills inventory</td> <td>Present your capabilities<br /> Find Drupal customer</td> </tr> </tbody> </table> <p><br /> Why European customers? - Because Colabpro primarily focuses on services for European customers<br /> Why Eastern European vendors? - Because Colabpro primarily focuses on nearshore solution provision<br /> <br /> <a href="http://eepurl.com/Gkge1" target="_blank"><img align="none" height="86" src="https://gallery.mailchimp.com/68a281df7fa83094b7a60987b/images/sign_up.png" style="border:0px;height:86px;line-height:14px;width:209px;" width="209" /></a><br /> and take part in our Drupal survey in any of activities:</p> <ul> <li>Review Drupal skills categories</li> <li>Submit your Drupal skills and experience</li> <li>Receive survey summary report</li> <li>Request proposal for Drupal development</li> </ul> Bulletproof Outsourcing 56fedaf3524ce830d90000dc 2016-04-01T23:32:51+03:00 2013-09-24T11:00:00+03:00 <p><img alt="" src="/assets/52414f719cd74523f4000a52/bulletproof.png" style="line-height: 1.6em; float: left; width: 544px; height: 509px;" /></p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p><span style="line-height: 1.6em;">There are more questions to be answered, there are tons of blogs and books written about it, however these are probably the first ones to answer.</span></p> <h3>Project outsourcing is not a rocket science,</h3> <p>but it requires quite some knowledge and skills, gained through experience.</p> <p>If you have not done it or if your previous project failed, you can</p> <h3>Ask us these questions:</h3> <p><strong>How do I find the right supplier?</strong></p> <p><strong>How do I make sure I am prepared?</strong></p> <p>We will help.</p> <h3>And &ndash; by the way &ndash;&nbsp;<span style="line-height: 1.6em;">there is no such thing as bulletproof outsourcing.&nbsp;</span></h3> <p>For any non-trivial software project &ndash; outsourced or not &ndash; there are chances to fail.</p> <p>What we can do is to reduce the risk of failure as much as possible.</p> <p>Have a pleasant and safe journey!</p> Why we launched outsourcing vendor Agile maturity assessment 56fedaf3524ce830d90000d4 2016-04-01T23:32:51+03:00 2013-08-30T11:00:00+03:00 <h3>What if Agile experience is one of project requirements?</h3> <h3>How to compare Agile experience and maturity of your potential service providers?</h3> <p>When we first faced this requirement, our immediate reaction was &ndash; you should count the Certified Scrum Masters (CSMs) &ndash; since Agile is pretty much Scrum in most cases.</p> <p>But does the number of CSMs provide you with useful information? &ndash; Well, &nbsp;it basically tells you how many people were sent to a few day training sessions. It does not mean these people have done or will be doing any Scrum project activities, it just tells they attended classes.</p> <p>Your next attempt could be to identify the number of people with Agile skills. This would give you more information &ndash; but you may end up with a large number of people who passed the training a few years ago and have never had even a single daily stand-up looking better than a relatively small group of people using most Agile practices systematically.</p> <h3>Selecting agile framework</h3> <p>After some attempts to come up with a set of measurable items summarizing Agile maturity, we understood that such assessment requires an Agile maturity framework. And we found one - <a href="http://colabpro.com/roadmap-for-agile-success/">Roadmap for Agile success</a>.</p> <p>Roadmap for Agile success provides several areas of Agile practices which should be taken into account and describes particular practices associated with 3 levels of Agile maturity.</p> <h3>Building assessment process</h3> <p>Our next step was to build a whole assessment process to evaluate against the selected assessment framework.</p> <p>What were our requirements?</p> <ol> <li>It should be efficient and fast - we should be able to get reliable assessment results within hours and days rather than months and years</li> <li>It should cover framework requirements in the form of quantitative measurement</li> <li>Results should reflect actual experience rather than the creativity of companies&rsquo;marketing departments</li> </ol> <p>So we came up with the idea that all Agile Team leads &nbsp;in the company to be assessed should fill in a survey on practices used in one of their recent projects.</p> <h3>Benefits of the survey</h3> <p><strong>Accountability</strong> &ndash; we are collecting information about actual practices within a specific project reported by a team lead. If you are interested in understanding how your prospective project manager was handling the previous engagement &ndash; you can get his/her individual results as well as a comparison to the company and industry averages.</p> <p><strong>Assessment of several areas and categories </strong>&ndash; some may be more relevant to you than others &ndash; focus on those that you find essential and important</p> <p><strong>Numeric results </strong>&ndash; you can see average values as well as top and bottom values for all categories and compare competitors side by side.</p> <p><strong>Usage density </strong>&ndash; you can find out how widely Agile is used in an organization and to what extent. It tells you much more than any pass/fail certification.</p> <p><strong>Simplicity </strong>- it is easy to run. Just get the list of vendor&rsquo;s Agile Team Leads, make sure they fill in their survey (which takes 1-2 hours on average) and get your VAMI results. &nbsp;</p> <p><strong>Cost</strong>&nbsp;&nbsp; - the survey is free.</p> <p>So now when we have Agile experience as a requirement and selection criteria for a project, it is quite simple to get the evaluation done &ndash; we request participants to pass VAMI assessment and compare their results.</p> <p>That simple.</p> <p>And you can do it as well.</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> Partner vs. Vendor Mentality 56fedaf3524ce830d90000d8 2016-04-01T23:32:51+03:00 2013-08-29T23:20:00+03:00 <p><span style="line-height: 1.6em;">I&rsquo;m starting this article in this manner because I want to establish the fact that we do what we do because &ldquo;usually&rdquo; it&rsquo;s what we want to do for work and for many of us, we want to excel at our work and make it rewarding in ways beyond just the monetary kind.</span></p> <p>This leads me to make some very specific statements on one of the most challenges areas of being in business and/or working as a professional that interacts with others each day in order to make the world go round; being viewed as a partner vs. a vendor.</p> <p>One of the most useful tools I know of is the dictionary. Looking up the meaning of a word often sheds light on words we use regularly.</p> <p>For example, the word &ldquo;vendor&rdquo; in the dictionary is defined as &ldquo;a person or agency that sells&rdquo;. Fair enough, that is a simple, straight forward definition. It makes complete sense and if you are someone who sells a product or service then being called a vendor is accurate.</p> <p>The word &ldquo;partner&rdquo;, however means something a little different. Partner is defined as &ldquo;a person who shares or is associated with another in some action or endeavor;&nbsp;often as it relates to risks and rewards&rdquo;.</p> <p>I don&rsquo;t know of any company, services or product oriented, that specifically wants to be referred to as a vendor. Not that they would mind or even find the term incorrect or offensive. I imagine most like the idea of being referred to as a partner. Ultimately how strongly you feel about either word comes down to what your business model and culture is really all about. One references more of a transaction mind-set and one more of an involved, professional relationship. Unfortunately, in the corporate world, vendor tends to have a worse connotation than partner, often giving the perception of a company that &ldquo;just wants to sell you something&rdquo;.</p> <p>Both terms are good. Both have their place. Both are often confused by the people that these companies try and sell to.</p> <p>There are some good articles on the partner vs. vendor topic. I&rsquo;m not looking to add another list of do&rsquo;s and don&rsquo;ts or differences between the two. Rather, I want to focus on the term partner and I want to do that so that the executives and managers that are involved in buying &nbsp;products and services from companies that view themselves as partners can take notice and perhaps make the distinction that they are in a relationship with a partner.</p> <p>Yes, partners still want to sell you something but they also want to develop a lasting relationship that they see value investing in to not only transact business together but to help both companies (yours and theirs) become better, more profitable and deliver more value to the ultimate customer, the buyer/user of their product or service. Sounds like motherhood and apple pie but truthfully, if you&rsquo;re a company that has experienced this in speaking with prospects that don&rsquo;t know or want to know the difference between the terms, then you fully appreciate what I&rsquo;m attempting to articulate here.</p> <p>What problem are we trying to solve? We want to be viewed by our clients and future clients as a partner oriented firm. We don&rsquo;t want to just be classified as an approved vendor on the global list. We want to be a firm that constantly looks at ways to add value to our client relationships even if it means there is no immediate sale. We want to behave differently so that there is trust established early.</p> <p>To do all this means we need to communicate to our clients and future clients how we operate and how we want the relationship to work.</p> <ul> <li>It means being vulnerable and taking risks.</li> <li>It means facing rejection since some people won&rsquo;t want or care about partner vs. vendor.</li> <li>It means saying no to some things instead of yes to most things.</li> <li>It means not winning every deal</li> </ul> <p>If you want to be viewed as a partner then it means qualifying them as much as they qualify you.</p> Do a pilot not a demo, when selecting outsourcing partner 56fedaf2524ce830d90000bc 2016-04-01T23:32:50+03:00 2012-12-07T16:35:00+02:00 <p>The pilot approach makes sense, sinceyour position to discover shortcomings, issues and in-efficiencies with the vendor is suited to small, usually not business critical projects. If the timing is not critical for the larger project, this is a good way to start.</p> <div> <p>On the outsourcers&#39; side the suggestion to start with a pilot project is frequently used. Usually it comes with: &quot;try a small pilot with us and you will see how good we are&quot;.</p> <p>My advice to customers is: Yes, it is good to start with a pilot if you lack deep experience in outsourcing, or for a specific type of projects.</p> <p><strong>Pilot or demo</strong></p> <p>But - do not do the pilot just to check the vendor&#39;s capabilities. Why? - you may get a demo instead of a pilot. A pilot should bring you working and tested, production grade software that brings value to you. A demo is something else.</p> <p>The demo is usually impressive, since it is done for a specific purpose - namely to demonstrate that it works and that the vendor is capable of&nbsp; delivering it. But there is a significant risk that you will have a completely different picture of it, when you need to scale, the complexity increases and you are under time pressure.</p> <p>So - do a pilot as a proof of concept, not for validating the vendor&#39;s capability.</p> <p><strong>Things you may find useful:</strong></p> <ol> <li>Use a pilot as an opportunity to set-up and validate processes. Outsourcing usually affects processes on the customer side. This is an opportunity to formalise changes, get feedback from your organization and fine-tune it.</li> <li>Validate your assumptions about the outsourcing scope. A pilot project can potentially show that the vendor is capable of doing more or indicate that some of the activities you were planning to outsource does not work as expected - so it would be good idea to postpone it, or give it a second thought.</li> <li>Set your expectations and performance gap analysis during the pilot project, as well as after the completion of it. Use the pilot to tune your metrics.</li> <li>If the pilot fails, do a root-cause analysis. We are frequently facing statements &quot;we tried it once, it did not work&quot;. Very rarely is the concept of outsourcing entierly wrong, but it is hard to make it work for you.</li> </ol> <p><strong>Conclusion</strong></p> <p>There is no logical reason why outsourcing of software development shouldn&#39;t work, unless it is a core activity and your competetiveness depends on the software develeopment skills of your trade secrets. Even in those cases we see an increase of outsourcing activity.</p> <p>There is a zone where outsourcing of software development is&nbsp;recomended, and you should try by using a pilot project. If you make sure you are really getting a pilot and not a demo and it still fails, it is more likely that you need to make some adjustments to your own&nbsp;approach&nbsp;and possibly be better prepared for it internally.</p> <p>Some reasons for the failure can be due to your vendor selection, such as lack of technical or domain skills and cultural differences: Others can be on your side with wrong expectations, lack of comparative metrics and business alignment, lack of motivation from your stakeholders and teams, etc.</p> <p>It is important to understand this and to do your homework - you will get it right the next time.</p></div> Requirements for an ODC and a Project are different 56fedaf2524ce830d90000c0 2016-04-01T23:32:50+03:00 2012-12-02T14:20:00+02:00 <p><span style="line-height: 1.6em;">When you outsource a project, you are looking for:</span></p> <ol> <li>Technology skills</li> <li>Domain expertise</li> <li>Resource availability and the right skills level</li> </ol> <p>If the project is of significant size (20+ engineers), you should check the availability of the core team along with the time frame for filling remaining positions.</p> <p>Are there any differences if you are looking to build an ODC with a goal to transfer some of your ongoing and new project activities?</p> <p>Initially it seems, that the requirements are the same. You still need to evaluate the potential vendors&#39; technology skills and domain expertise and immediate resource availability. Depending on the importance of the project you may have more strict requirements on all of the positions.</p> <p><strong>In some cases using the same criteria may work well</strong></p> <p>However - there are some specifics of ODCs from my point of view, which should be taken into account:</p> <ul> <li>While the exact match of technical requirements are very important for a project just because you don&#39;t want spend time and resources on training for one single project, it may not be that critical for an ODC. Especially if finding the exact match in the inventory of available skills is a challenge. Since this is a long-term activity, it may be sufficient to have individuals with a similar core skills profile who are capable to fill skills gaps efficiently.</li> <li>The same applies for domain expertise. As it&#39;s highly probable that the vendor will need to acquire the very deep domain knowledge required in the specific area, the customer should not expect focused knowledge to be available from day one. A proven process and a track record of how to obtain such knowledge may be more important.</li> <li>In the ODC the seniority is important since you want to secure a smooth knowledge transfer from the core team members to new developers as the ODC should be able to scale with the work-load.</li> </ul> <p>While browsing vendor success stories of developing ODCs you may find that in most of the cases, vendors did not have any significant domain experience when setting up the new ODC. However, a substantial number of the ODCs later became competence centres, attracting additional projects.&nbsp;</p> <p>In fact - if a supplier is building an ODC in new domain area, the customer can be reasonably assured that the best possible resources and skills will be assigned to it development - from internal resources as well as from the approach to the job market. However, if there are more than one ODC with close profiles, taking key resources out of an existing ODC to fill the gaps in a new, will not be a priority for any vendor. As a customer you would not be too excited to see your key people going somewhere else. Most vendors have a policy to not move people from the core team of an ODC in order to preserve the knowledge within the team, in the best possible way.</p> <p>Therefore - as there is more than just the skills and the experience from technology and domain point of view, it is important that your vendor candidates:</p> <ol> <li>Can demonstrate an ability to build and scale ODCs in a domain where they have limited experience</li> <li>Can provide enough resources to kick-start the ODC</li> <li>Has capabilities and local brand to attract and hire high quality resources</li> <li>Has a proven ability to build strong and motivated teams under pressure</li> </ol> <p>As result - when starting the ODC you may put experience and existing skills under lower priority, primarily focusing on:</p> <ol> <li>Track record of building ODCs (even in other technology areas)</li> <li>Efficient HR processes to staff and maintain core team</li> <li>Attrition</li> <li>Ability to scale - both up and down</li> </ol> The Offshore Development Center: ODC 56fedaf3524ce830d90000cc 2016-04-01T23:32:51+03:00 2012-10-10T16:20:00+03:00 <p>Here I go with some obvious statements so please be patient.&nbsp;Outsourcing is still hard. Outsourcing still represents many challenges and moving parts that are typically not accounted for from the onset of an engagement. Even more difficult is the captive model that some companies use. While it is designed to provide more ownership and control, in some cases it ends up being treated in a similar fashion to a standard outsourcing relationship and in turn removes the &ldquo;competitive advantage&rdquo; it was meant to deliver.</p> <p>One model that has been around for some time and is often overlooked is the Offshore Development Center or as it is affectionately called; ODC. This model&nbsp;is generally used for developing, testing, and deploying software offshore with the benefit of having a core, dedicated team and infrastructure. The idea of a core team means that there is the benefit of maintaining an external outsourcing relationship but having an internal or captive-like attachment to the team since they are designed as an extension of your organization. In other words, the best ODC setups look more like employees vs. vendors.</p> <p>Let&rsquo;s talk about the ODC in more detail. The ODC model is designed to be more cost-effective than simply outsourcing a project. The team is managed by a local Project Leader following the customer&rsquo;s expectations and instructions. An ODC commercial structure means that the customer pays a fixed fee monthly with an agreement to deliver either one large project or a set of projects. This also means that an ODC has an annual review cycle to adjust rates if needed, conduct performance evaluations, assess total quality and align the investment with the company&rsquo;s overall budgeting process, as would be done with any entity within the business.</p> <p>The customer&rsquo;s advantage with an ODC model is that they can truly operate this team as a natural extension of their own and gain more visibility and control over costs. It also means that establishing a process and discussion for extracting more value is now possible. Due to the nature of how an ODC works and the commitment of the core team, there is typically more flexibility in how the team works, how it introduces new methodologies and approaches and how it can be setup to take on a stronger focus on business value vs. just working software.</p> <p>ODC characteristics include:</p> <ul> <li>A dedicated core team</li> <li>A dedicated area or facility that houses your corporate brand and culture</li> <li>A dedicated infrastructure (hardware, software aligned with your business)</li> <li>A dedicated security policy that meets your requirements and regulations</li> <li>A dedicated education and training program</li> <li>A dedicated HR program</li> <li>Team flexibility to scale up or down as needed without increasing costs or subverting the budget</li> </ul> <p>Keep in mind that some may liken this to a BOT (Build, Operate, Transfer) model and while some ODC setups do transition to this, it is not necessary and can be quite expensive. The BOT approach is, in effect, a form of an ODC (apologies for all these acronyms) but the distinction of actual ownership is important. The comparison is similar to leasing vs. buying a car. Both may require similar cash outlay upfront but the lease offers the advantage of change more frequently with less cost instead of the buying option which puts you in a more restrictive contract with the added joys of depreciation.</p> <p>The table below represents a high-level contrast between a traditional outsourcing arrangement and an ODC arrangement. The table reflects how the customer-supplier relationship is affected and what are common scenarios. You will likely have others to add if you currently outsource at any scale but these are perhaps the most common contrasts when discussing an ODC.</p> <table class="table table-bordered table-striped"> <thead> <tr> <th>Traditional Outeourdng Settee</th> <th>ODC Engagement</th> </tr> </thead> <tbody> <tr> <td>Transaction model - no commitment</td> <td>Contractual term commitment</td> </tr> <tr> <td>BID for every project</td> <td>Continued planning of work</td> </tr> <tr> <td>Limited or no investment from Supplier</td> <td>Supplier invests in ODC design</td> </tr> <tr> <td>Task oriented relationship model</td> <td>Strategy and value led approach</td> </tr> <tr> <td>Supplier operates with limited risk</td> <td>Ownership mentality present</td> </tr> <tr> <td>Utilization and leverage model needed</td> <td>Core team with flexible staffing</td> </tr> </tbody> </table> <p>What else can a customer expect from an ODC?</p> <p><strong>Value</strong></p> <ul> <li>The supplier can offer an improved commercial model because visibility and commitment are improved</li> <li>The supplier&rsquo;s total cost of operating is reduced in an ODC and the customer can/should benefit from this savings</li> <li>The supplier is more engaged and interested in understanding output and outcomes so more value is derived that maps to the customer&rsquo;s goals</li> <li>Significant improvements in retention rates thus lowering the traditional challenges or attrition</li> </ul> <p><strong>Flow</strong></p> <ul> <li>The ODC core team principle means that over time learning curves are shorter and time to market is faster</li> <li>The time spent in developing BIDs and RFI/RFPs is shortened or completely nullified, thus more time spent on delivering value</li> <li>Flexibility in staffing allows rapid adjustments and keeps the work moving</li> </ul> <p><strong>Quality</strong></p> <ul> <li>Team learning and cultural integration changes focus, improves overall quality</li> <li>Supplier can better prepare for work; resource and capacity planning improved, demand better understood</li> <li>Knowledge transfer is better managed and executed, retained and used across the team and customer organization</li> </ul> <p>Working principles for an ODC need to be designed and diligently followed. These include three important areas:</p> <p><strong>ODC Steering Committee</strong></p> <ul> <li>Represented through an agreed governance and escalation model that involves senior management from both sides as final decision making authorities</li> <li>Quarterly reviews to monitor ongoing work, make adjustments and ensure that the cultural mindset is being adopted and maintained</li> <li>Annual review for joint strategic business and technology planning</li> </ul> <p><strong>Relationship Management</strong></p> <div> <ul> <li>Clearly defined roles and rules of engagement to ensure consistent and frequent communication and collaboration from each side</li> <li>Face time between key roles in each location (planned, quarterly visits each way are critical to the success of these relationships) &ndash; out of sight, out of mind is a recipe for failure</li> <li>Well defined communication processes to exchange important and needed information with stakeholders, i.e., weekly reports, corporate social media platform and so on.</li> </ul> <p><strong>Performance Management</strong></p> <ul> <li>Defined measures and metrics that communicate value for the business not just software metrics; dashboard tracking approach is common</li> <li>Common language definitions that are specific for this relationship, i.e. what do we mean when we say done? what does great look like for the relationship, for the project, for the business?</li> <li>Defined processes for how knowledge is transferred/managed, how IP is handled</li> </ul> <p>In an economy where most are cost conscious but still see outsourcing as a critical and necessary part of their strategy, forming an ODC might prove to be an effective way of introducing more agility into the outsourcing relationship and in turn deliver greater long term value. Any organization that is outsourcing needs to understand the models that are possible and available and not be sold strictly on the one they are presented with by a supplier. The best suppliers (not necessarily the biggest only) will openly embrace an ODC model since it also helps them build the longevity in the relationship they seek.</p> <p>&nbsp;</p> <p>Alex Adamopoulos is the CEO of Emergn, a global professional services consultancy.&nbsp;<a href="https://twitter.com/a_adamopoulos" target="_blank" title="@a_adamopoulos">@a_adamopoulos</a></p></div> Outsourcing or Captive? Which is the best alternative? 56fedaf3524ce830d90000c4 2016-04-01T23:32:51+03:00 2012-10-02T17:45:00+03:00 <p>At a first look, own development (Captive) centre can be very attractive. At least if the capacity is needed over reasonably long time over several project cycles. Owning a team seems to have some strong advantages:</p> <ol> <li>We hire exactly who we need - not someone who is assigned to our project</li> <li>It will be easier to control execution - since we &quot;own resources&quot; and can communicate without layers</li> <li>Low costs - just a small overhead and salaries to the team members</li> </ol> <p>But is this simple analysis entirely correct? Are there any additional risks associated with the Captive option? Let me develop the 3 initial points from above to a more realistic set:</p> <ol> <li>Hiring. The demand for high-quality resources is high so the competition is fierce. There are clear advantages to have a locally established employer brand. Absence of such brand significantly reduces your ability to hire the best and at the rate you may require. The business model of outsourcing is however directly related to create attraction of the best possible people which allows them to resolve HR issues in more efficient manner.</li> <li>Local supervision and Team dynamics. From case to case you may have issues in a project. Somebody is under-performing, somebody is leaving, you are getting mixed feedback from different team members. You need somebody on the ground to resolve it, but you may lack a manager senior enough to handle the situation or to discuss issues individually or collectively. The efficiency of the Captive centre drops very fast if senior staff needs to be sent over frequently to handle issues that arise. Once you have your team set, it can be very complicated to scale it up and down. &nbsp;There is always a risk that your first down-scale will become your last one since you lose credibility in the local labour market. The ability to engage temporary help with the right skill-sets may become an issue as well.</li> <li>The low cost assumption. There are of course other costs than salaries and a low overhead. Secure office facilities with adequate infrastructure and secure communications will have to be set up. Infrastructure&nbsp; with servers and computers, network, including phones and mobile devices need to be acquired along with development tools and software licenses. The management issue above probably needs a a more permanent solution, even for a small team. Administration, legal compliance, tax and accounting need to be resolved. And how about the cost for training and development of personal skills? These are all the kind of costs that are normally included in the rates from most serious outsourcing companies, which you need to manage on your own in a Captive solution.</li> </ol> <div><strong>What is the solution?</strong></div> <p>In order to set up and successfully operate your captive nearshore centre, you need to find good local manager:</p> <ul> <li>Experienced well reputed manager with technical skills and business acumen needed to operate an independent remote unit.</li> <li>A leader who is able to motivate and manage a team from all aspects. In fact more or less an entrepreneur.</li> <li>A person who is very well connected in the local development community. A person that developers trust.</li> </ul> <p>This can seem like a simple task. However, people with such qualities are very hard to get since they:</p> <ul> <li>Are looking for opportunities to manage a team of at least 20-30 (unless your project is extremely attractive to them from technical prospective)</li> <li>Persons with these qualities are very likely to be engaged in their own outsourcing firm rather than interested in running someone else&#39;s operation</li> </ul> <p>Experience also shows that to find a viable economy of a Captive centre one should have a plan to run it and grow it over long term. It is also well known that Captive centres are less advantageous for team sizes below 80-90 developers.</p> <p><strong>So, if you:</strong></p> <ul> <li>Managed to hire a capable local management with an experienced leader</li> <li>Your team size is 80+</li> <li>You do not expect significant deviations in workload/team size</li> <li>You are prepared to invest time and money to build it up</li> </ul> <p>it is probably worth to consider building/developing a Captive organisation.</p> <p><strong>For everything else there is Outsourcing!</strong></p> <p>So how does an outsourcing vendor resolve the issues mentioned above?</p> <p>Hiring:</p> <ol> <li>Employee referrals and connections - in most cases it is the most efficient hiring approach.&nbsp;</li> <li>Local brand - outsourcing companies invest in building a strong image and reputation of being a high-quality employer. This takes years to accomplish.</li> <li>Efficient hiring process - selection and validation of candidates including training of candidates</li> </ol> <p>Management:</p> <ol> <li>Larger pool of resources to identify and promote capable managers</li> <li>Existing relations to team members and a process to grow the right people</li> <li>Local supervisors monitor projects and get involved on per need and upon request basis</li> <li>Administration and related tasks are handled by people who are experienced and educated in the local systems and practices</li> </ol> <p>Volume fluctuation, flexibility:</p> <ol> <li>A well operating outsourcing company keeps a bench to allow for fast ramp-ups of teams</li> <li>A larger resource pool (company wide) allows for allocating people temporarily to other projects (and circle them back later)</li> </ol> <p>As a conclusion, the Captive Centre may be less attractive than you initially thought. If you are running large or long term projects, it might be an option. But even then you most likely need a local partner to set it up properly.</p> <p>Otherwise there is outsourcing to near-shore locations in Europe available that provides low cost and excellently managed development organisations. On the route make sure to avoid outsourcing pitfalls that are all around!</p> <p>Picture from: Freepik.com</p> Outsourcer says: Do Not Outsource Your Software Development! 56fedaf3524ce830d90000d0 2016-04-01T23:32:51+03:00 2012-09-19T19:40:00+03:00 <p>However, the economics of outsourcing are far less straightforward than the labor rates comparison suggests. There really is&nbsp;<a href="http://www.firstlinesoftware.com/blogs/labor-arbitrage-isnt/" target="_blank" title="no such thing as “labor arbitrage” in software development.">no such thing as &ldquo;labor arbitrage&rdquo; in software development.</a>&nbsp;Unlike copper or wheat, all developers are not created equal, so you are not exactly trading commodities. Furthermore, outsourcing is definitely not without risk, as discussed below. So the concept of arbitrage doesn&rsquo;t apply, and with it goes the whole proposition.</p> <p><strong>Losing Financial Ground</strong></p> <p>First of all, are we comparing apples to apples? Yes, that overseas firm only charges you $20/hr for a developer. But how much value are you getting in that hour? How competent is that developer? Are you getting strong people on your team, or mostly recent college grads with questionable skill levels? What experience do they have? One experienced $100/hr in-house developer may well produce more value for you than 5 or even more junior $20/hr people overseas.</p> <p>Also, remember that you need to train external resources. Initially, they don&rsquo;t know your product, they don&rsquo;t know your process, and you haven&rsquo;t worked together before, so it takes time before they can begin to produce value. While necessary, the investment in a learning curve definitely eats into projected savings. And that senior in-house developer who is fully up to speed will be outperforming them again.</p> <p>Now let&rsquo;s say you are beyond the initial knowledge transfer. Are you realizing those savings yet? Hardly. With software development, communication is key. It&#39;s hard enough at times to explain to an experienced person in the same room what you want them to build. Imagine doing the same with someone who is thousands of miles away, relying mostly on email and IM, and sometimes on voice and video Skype calls. Software development is a highly involved social process, with people sharing complex ideas and abstract concepts. And no, documentation won&rsquo;t completely remedy this: you can&rsquo;t really document everything about a system up front, and any written text is always subject to multiple interpretations. Plus, the market changes so quickly that, by the time your documentation is complete, it&#39;s typically obsolete and new requirements are driving a different system. Software development deals with tacit knowledge and emergent understanding. Again, hard enough in-house and even more challenging with an outsourcing supplier (think cultural differences, accents, communication barriers, etc.).</p> <p>What about the ability to put more bodies on a project? For example, you are late in your release schedule and tempted to add cheaper offshore resources to meet deadlines. Unfortunately, if you do,</p> <p><a href="http://en.wikipedia.org/wiki/Brooks%27_law" target="_blank" title="Brooks’s Law">Brooks&rsquo;s Law</a>&nbsp;is likely to take effect. This famous principle states that adding resources to a late project will make it&nbsp;<em>later&nbsp;</em>or, as formulated more colorfully by its author Fred Brooks, &quot;Nine women can&rsquo;t make a baby in one month&quot;. Even when a project is not late, more people does not equal more value. With the complexities of communication, a larger team moves more slowly, sometimes significantly so, and productivity is consequently lost. Your investment may buy you more developers overseas, but not necessarily more value in the form of marketable software for your dollar.</p> <p>Also, don&rsquo;t forget the extra management costs you&#39;ll expend communicating with and monitoring the performance of your supplier. Aberdeen Group&rsquo;s research shows that over 76% of customers report project administration and vendor management costs to be&nbsp;<em>far higher than expected</em>, which won&#39;t come as a surprise to anyone who has done any outsourcing.</p> <p>Finally, consider the overall risk of project failure. The stats vary but, depending on the source, between 30% and 50% of outsourced projects fail outright: they are either abandoned completely (and the work is brought back in-house at additional cost), or fall radically short in terms of the functionality and business value they deliver. Granted, not all in-house projects are completed either but, with outsourcing, the risk of project failure is higher.</p> <p>So please, do not outsource your software development.<br /> Unless you absolutely have to. And unless you do it with Agile. More specifically, Scrum.</p> <p><strong>The Scrum Breakthrough</strong></p> <p>Sometimes keeping a project in-house is not an option. For example, you may need to ramp up your development team quickly to ship a product by a specific date or risk of the window of opportunity closing, but you know you can&rsquo;t hire enough high quality people in your geographical area. If you are going distributed, you are essentially outsourcing and at least some of the difficulties inherent in traditional software development apply. Outsourcing to a company using Scrum, however, will help you overcome the obstacles that make the traditional approach unwieldy and inefficient, and that cause endemic project failures.</p> <p>Inspired by the Toyota Production System (TPS), Scrum was first introduced in a conference paper by&nbsp;<a href="http://www.youtube.com/watch?v=LjBN2CjKDcU" target="_blank" title="Dr. Jeff Sutherland">Dr. Jeff Sutherland</a>&nbsp;and Ken Schwaber in 1995. Scrum is designed around several foundational principles and practices, including development in short iterations, incremental delivery of potentially shippable software after every iteration, prioritization of features around business value, and direct customer involvement in planning, elaboration and acceptance.</p> <p>Unlike the traditional &quot;waterfall&quot; approach, where all software is delivered once, at the tail end of the project, Scrum focuses on providing a continuous flow of value to the customer, which minimizes project risk and increases return on investment. With Scrum, catastrophic project failures like the recent&nbsp;<a href="http://www.zdnet.com/blog/projectfailures/california-abandons-2-billion-court-management-system/15363" target="_blank" title="California Court Management System (CCMS) $500 million debacle">California Court Management System (CCMS) $500 million debacle</a>&nbsp;are impossible by definition.</p> <p><img alt="Didyouknow" id="img-1346325361396" src="/assets/51f811539cd74549d61beecd/blog_didyouknow1.png" style="line-height: 23px; border: 0px solid rgb(204, 204, 204); float: right; width: 350px; height: 498px; margin-left: 10px; margin-right: 10px;" /></p> <p>Sutherland&rsquo;s research shows that, when run properly, Scrum can help achieve&mdash;even on a large, globally distributed project&mdash;the type of<a href="http://www.youtube.com/watch?v=Ht2xcIJrAXo" target="_blank" title="hyperproductivity/extreme velocities only thought possible in small co-located teams">hyperproductivity/extreme velocities only thought possible in small co-located teams</a>, velocities that are several multiples of the productivity typically seen in waterfall teams, in-house or offshore. Applied in the context of outsourced, distributed software development, Scrum acts as a catalyst of communication and as a powerful spotlight shining onto every aspect of the client-vendor relationship, forcing accountability on the one hand and unleashing tremendous productivity on the other.</p> <p>Sutherland, who currently advises the investment team at Boston-based OpenView Venture Partners and coaches OpenView&rsquo;s portfolio companies in the use of Agile development techniques, explained to me that he counsels OpenView&#39;s portfolio companies with this exact advice: either outsource to Scrum companies or don&#39;t outsource at all.</p> <p>Steve Denning at Forbes&nbsp;<a href="http://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/" target="_blank" title="calls Scrum a major management discovery">calls Scrum a major management discovery</a>&nbsp;and even contends that its founders should receive a Nobel Prize in management, if there was one. Can Scrum in fact help you add people, including offshore, and&nbsp;<em>go faster rather than slower</em>? Can it help you reliably deliver software when working with outsourcing vendors? My own answer to these questions is an unqualified &ldquo;Yes&rdquo;, but please investigate and find out for yourself. Especially&nbsp;<em>if you are outsourcing</em>, I don&rsquo;t think you can afford not to. And I suspect your competitors already have.</p> Mitigating the Data Management in the Cloud Conundrum 56fedaf3524ce830d90000c8 2016-04-01T23:32:51+03:00 2012-08-23T20:00:00+03:00 <p>The growing use of the cloud is now threatening to add further complexity to the management of data quality - and even fewer organizations are taking this into proper account. According to a recent report by&nbsp;<a href="http://technologycourses.wiki.mtnbrook.k12.al.us/file/view/Data_In_The_Cloud.pdf">Ventana Research</a>, only 15 percent of organizations have completed a quality initiative for their cloud data, and that number drops to five percent for master data management. So, it comes as no surprise that less than a quarter of organizations trust their cloud data, while just under 50% trust data from on-premise applications.</p> <p>While cloud applications per se don&#39;t necessarily pose an immediate danger to data quality, it is in moving data between cloud and on-premise, and when integrating data between the two, that issues are most likely to arise. This is primarily because even those companies that have instituted data quality management processes are unable to extend them to data produced by cloud applications.</p> <p><strong>Ease of use over quality control</strong></p> <p>Cloud applications are often provided by companies whose business models are based on providing functionality and ease of use rather than quality control. The content (in this instance, the data and its quality), after all, is the customer&#39;s concern. While many cloud application providers offer service level agreements (SLAs) that outline their data management practices, the reality remains: when going to the cloud, the owner is essentially surrendering oversight of the data in exchange for flexibility and elasticity.</p> <p>While cloud applications can provide significant business value, they can also severely complicate data management. For obvious reasons, the more critical to the business the data produced by the cloud application, the more complicated the problem of integrating the cloud data back into an on-premise data store.</p> <p><strong>Hypothetical case</strong></p> <p>Let&#39;s consider, for instance, a hypothetical bank that already collects and manages large amounts of customer data, and has made considerable investments in building a reliable master database and ensuring its data quality. What would happen if the bank introduced a cloud-based campaign management and execution platform to automate and enhance its direct marketing? Simply creating a database for such a highly involved function is a serious project in and of itself, but maintaining the quality of the in-house data will now require ongoing and elaborate integration with the cloud to keep the structure and the unique identifiers of the core database intact. As a result of the new implementation, the bank would likely be facing significant data duplication, serious integration overhead and related data quality risks, not to mention a much higher amount of work to keep things running smoothly day-to-day.</p> <p>What if the bank had the option of keeping the data on-premise where it&#39;s governed by its internal data quality and management policies, rather than have it duplicated in the cloud - and yet continue to have access to the business logic in the cloud? If the computing process could be &quot;re-mapped&quot; so the bank could retain control of the data while enabling the cloud application to &quot;borrow&quot; the relevant data for processing as needed (and write the appropriate data back), the business would be able to reap the benefits of the SaaS model while escaping the data quality management problem. Such a solution would effectively extend quality management practices to cloud data, thus eliminating the conundrum.</p> <p><strong>Cloud-to-earth</strong></p> <p>One may think of it as a &quot;cloud-to-earth&quot; connector that combines reliable communication across an unstable network and a robust queuing mechanism on both ends with a separate data access layer that uses a logical representation of the physical data structures to implement comprehensive mapping between the cloud and the on-premise data.</p> <p>This approach is not without its trade-offs: some amount of automation, speed and cost savings may be lost in exchange for data quality. But it would also include an element of &quot;having your cake and eating it too.&quot; The connector allows companies to leverage software in the cloud, thus reaping all the benefits of SaaS, without significant changes to the data governance processes; the on-premise data would be seen by the cloud apps as though it actually does reside in the cloud.</p> <p>With analysts predicting that growth in cloud&shy; based applications will outstrip that of on&shy; premise applications over the next few years, companies must address the existing gap between the needs and capabilities of integrating data between the cloud and on-premise. Mitigating these effects with a cloud-to-earth connector is one way of avoiding the costly errors that might otherwise arise from the inconsistencies or inefficiencies that often result when reconciling different sets of data.</p> <p>Konstantin Polukhin is a managing partner of First Line Software Inc.</p>