http://www.accolo.com/ en ishannon@accolo.com Copyright 2008 2008-11-13T17:31:00-08:00 http://www.accolo.com/insights_and_expertise/accolo_blog_detail/thinsourcing_great_white_paper_on_bpo/ http://www.accolo.com/insights_and_expertise/accolo_blog_detail/thinsourcing_great_white_paper_on_bpo/#When:18:31:00Z Matt Cooper mentioned “thinsourcing” to me in an email a while back, but it wasn’t until yesterday that I tracked down the piece to which he was referring.  Turns out, he was talking about a white paper written by someone at DialAmerica. If you haven’t had a chance to read it, it’s well worth it. Thinsourcing: A New Way for Businesses to Operate succinctly explores the differences between outsourcing, insourcing, and “thinsourcing.” According to the author, thinsourcing is the happy medium between out- and insourcing: it combines the autonomy of an outsourced provider with a service that is “virtually indistinguishable” from the company itself. The ideas expressed in this article are at the heart of any good Business Process Outsourcing (BPO) service and is a worthwhile read for anyone interested in learning more. This particularly resonated with me and others here at Accolo because this is the nature of the service we provide. Thinsourcing—great white paper on BPO 2008-11-13T18:31:00-08:00 http://www.accolo.com/insights_and_expertise/accolo_blog_detail/why_cheap_can_be_scary/ http://www.accolo.com/insights_and_expertise/accolo_blog_detail/why_cheap_can_be_scary/#When:16:48:01Z While pitching our value proposition recently, a CFO I spoke with exclaimed “how and why are you so cheap?” I was taken aback, because frankly, I never thought of us as cheapos. But the fear and doubt in his voice was a familiar tone. It should be, since I myself used it yesterday when I received an email regarding a 7-day cruise for $199. Nonetheless, Mr. CFO led me to think about why, in such an economy wherein frivolity is out of style, cheap is still one of the scariest things out there. If “smart buy” were synonymous to “cheapest”, then it would simplify things for everyone. Since this is not the case, let’s put a tube of toothpaste through my value decision matrix to find the comedy in how scary the purchasing decision can be. For $4, you get a brand-name tube that seems to have everything…cool packaging, tartar-control, whitening agents, and an on-call massage therapist (which I could really use). For $1.99, you get a generic paste that also claims to have all the goodies – even the packaging looks cool so it must be ok. But then for $2.50, you can get a brand-name that’s on sale yet is slightly smaller in size than the other two (therapist not included). Impressively, I’m able to calculate (or read the supermarket pricing label) how many cents per ounce I’m paying so I can look at cost on a level playing field. But now I’m stuck with questions about taste, cleaning power, squeezing ease and whether or not other toothpaste users in the house will agree with my decision. The fact is, no matter what, I need the toothpaste. So why not just buy the cheapest one? Why doesn’t everyone? Because the fear of cheap sinks in. If I really need something, then I’d rather pay a little more lest I suffer the consequences. In this case, bad breath, ugly teeth and unpleasant visits to my dentist. Fortunately, there are products out there that are truly a great buy and at times, are also the most affordable. Like locally-grown organic fruit at my farmer’s market. Or my VOIP that has eliminated my international phone bill. Or the super soft towels I bought at a major department store chain that is closing. Or Accolo (yes, here comes the plug) which is the #1 On-Demand RPO solution and is such good value (cheap, to Mr. CFO) that it can put 6% or more of a VC’s investments back into a company’s core business. So let’s not be too scared of cheap. It takes some thought, research, trial and error and sometimes even personal sacrifice (last year’s ugly haircut comes to mind) to find true value, but once you do, it’s worth it. Why cheap can be scary 2008-10-30T16:48:01-08:00 http://www.accolo.com/insights_and_expertise/accolo_blog_detail/green_hiring_and_incentivizing_companies_to_go_green/ http://www.accolo.com/insights_and_expertise/accolo_blog_detail/green_hiring_and_incentivizing_companies_to_go_green/#When:07:21:00Z The term Green Hiring can take a lot of directions, at Accolo we like to think that our current and prospective employees like working for a company that values the environment and tries to make a better workplace for them. But there will be more to come on this topic in a new Bright Paper later this month...for now I want to focus on the second topic. As most of us have heard there is a common opinion that it is hard to make your company green. But some of us would challenge this, and rightly so, since there are so many things a company can do, and, in most cases, not do to become more environmentally friendly. But in some cases this can be true as it relates to larger scale initiatives like adding solar panels to your building.  To help lessen this burden we developed a program called EcoPartnership. Essentially we will provide a discount on our services to our clients equal to their investments in greening their company. However, we aren’t a non-profit, so we cap the discount to 10% of what a company spends with us so that we can stay in business. We are also setting up a list of EcoPartners that our clients can use to spend this discount to make it that much easier for them. We also reserve the right to reject applications from Offset companies that are part of huge oil companies or the application of any other organization that is not really focused on helping the environment. As part of our beta launch we are reaching out to potential partners so that we can have a strong list of partners for our launch next month. We’ve already taken great strides to become a more environmentally friendly company and you can use the list of things we’ve done as an aid for others, click here to see what we’ve done to be easier on the earth. I look at this as a win-win-win-win situation for the environment, our clients, our EcoPartners, and our company. Please visit the site and share it with any companies that may be interested in partnering with us! http://www.accolo.com/ecopartnership/ Green Hiring and Incentivizing Companies to Go Green 2008-10-09T07:21:00-08:00 http://www.accolo.com/insights_and_expertise/accolo_blog_detail/what_does_your_recruiting_cost_you_when_you_arent_hiring/ http://www.accolo.com/insights_and_expertise/accolo_blog_detail/what_does_your_recruiting_cost_you_when_you_arent_hiring/#When:23:02:00Z “The time to repair the roof is when the sun is shining.” - John F. Kennedy With the markets headed south and uncertainty headed north, we are talking to a lot of companies that are putting hiring on hold.  It’s easy to focus on your hiring process when you can’t find people fast enough to support your growth, but not thinking about the process and infrastructure during a downturn can be both a lost opportunity and a negative influence on the oh-so-dear bottom line. With a traditional internal recruiting function, the majority of costs are fixed—recruiter salaries, benefits and overhead, and annual or multi-year contracts with applicant tracking systems, job boards, resume databases and other tools.  You can always let your recruiters go, but then you’re starting from scratch when you have hiring needs again.  During a drop in your expected hiring volume, your recruiting costs on a per-hire basis can increase geometrically. Let’s say you built an internal infrastructure to support 20 hires at an average compensation of $80,000 per hire.  The average internal recruiting department is going to spend about 13% of the compensation hired according to Staffing.org’s most recent data.  This means your budget would be around $200,000, or $10,000 per hire.  If you were to reduce your hiring expectations to 5 hires, you would need to trim $150,000—75%—of your recruiting budget to maintain your cost per hire.  Realistically, you are locked into enough fixed costs that you’d be lucky to reduce it by 25% to 50% without having to completely rebuild the department when things pick back up.  This means your per hire cost would be $20,000 to $30,000—a 200% to 300% increase over your current spend. Many smaller firms will turn to contingency recruiters to meet all of their hiring needs.  You only pay if a hire is made, and the headhunters will drop their rates to 15% of compensation.  Seems logical, right?  We are entering a period where the supply of quality candidates will outstrip demand.  The emphasis will shift away from sourcing passive candidates and toward filtering through the mass of emails and resumes.  Why would you pay 15% of compensation for a headhunter to filter resumes? It may seem like the path of least resistance, but you are building corporate habits that put the most expensive source of candidates at the center of your hiring efforts.  This is going to be a hard habit to break when the economy rebounds and placement rates jump back up. The advantage of any outsourcing model—whether it’s recruiting, HR, IT support or development—is the ability to scale both up and down with your need.  We’ve been through this cycle before—there were a lot of unemployed recruiters in 2001-2003 (and many ended up in real estate sales and mortgage brokerages).  I know that recruiting may not be on your list of priorities, but you may want to give it a second thought. What does your recruiting cost you when you aren’t hiring? 2008-10-07T23:02:00-08:00 http://www.accolo.com/insights_and_expertise/accolo_blog_detail/so_little_historical_perspective_in_recruiting/ http://www.accolo.com/insights_and_expertise/accolo_blog_detail/so_little_historical_perspective_in_recruiting/#When:04:34:00Z I was approached last week by an executive for a new company to remain nameless that came up with an innovative new concept… let companies offer cash referral awards for jobs.  Wow!  This has been done many times since 1996 and this executive had done no research.  While he’s a very pleasant guy, he and his team have missed the fact that every company that has tried this has failed for the same reasons.  The basic reasons are that the job’s description is too generic, there is no guarantee of fair consideration, there is no follow-up and the average person needs more than money to serve up his friend.  In other words, it takes more that a bit of gold to solve a complex problem like connecting the two people who matter, the hiring manage and the right candidate. So Little Historical Perspective in Recruiting 2008-09-09T04:34:00-08:00 http://www.accolo.com/insights_and_expertise/accolo_blog_detail/measuring_requirements_and_design_effectiveness_in_software_projects/ http://www.accolo.com/insights_and_expertise/accolo_blog_detail/measuring_requirements_and_design_effectiveness_in_software_projects/#When:00:34:00Z Good user experience is critical to a good software product, especially a software product delivered within the confines and quirks of modern web browsers.  For this reason all design and requirements gathering activities at Accolo are performed by full time employees, while off-shoring almost all implementation through contractors and vendors. We know how to measure implementation effectiveness and productivity using a development backlog and concepts like Running Tested Features (RTF). So, how do we measure design and requirements effectiveness? Implementation measures do not do a good job of measuring design effectiveness, so we devised a measurement that we lovingly call the Feature Punt Ratio (FPR).  For you football fans (“American Football” for our friends outside the U.S.) you are painfully aware of what a punt means.  You didn’t reach your goal and you need to relinquish control of the rock to the other team.  It’s not much different in software development, you didn’t reach your goal on a particular feature and you have to punt it away into another development iteration. The Feature Punt is the number of features that were planned for implementation in an iteration that failed to get implemented because of requirements and design inconsistencies, changes or flaws.  Compare the number of features punted due to design and requirements problems against the number of features implemented in the iteration and you have the Feature Punt Ratio. Features may be punted for various reasons.  Like most applications, we have actions in our application that are available to some users and not others.  We had this user permissions information sprinkled throughout each action’s requirements document.  During the iteration it was clear that the engineers did not understand how the action permissions related to each other.  The best way to communicate the permission interactivity was to put together a permissions matrix.  When the engineers got he permissions matrix, mid-iteration, they determined they would not be able to complete the feature. More generically, we’ve seen feature punt because we failed to consider a particular use-case.  We changed the requirements to account for the missed use-case in the middle of the iteration. The changes were significant enough that the engineer was no longer confident that the feature could be implemented in the original iteration, so it was moved to the next iteration.  It is not uncommon to realize some missed use-cases when implementation begins, so this is our most common reason for feature punt. After an iteration is complete an inventory of features implemented is taken.  Hopefully all features that were committed to were completed in the iteration and maybe some more.  If some features were not implemented you evaluate the features to determine if they were not implemented because of design and/or requirements issues or because of implementation problems. You then apply this basic ratio: Features Punted/Total Features implemented * 100 You get a percentage of features punted versus the total features implemented for the iteration.  We strive for a feature punt ratio of Measuring requirements and design effectiveness in software projects 2008-09-04T00:34:00-08:00 http://www.accolo.com/insights_and_expertise/accolo_blog_detail/agile_development_off_shore_and_problems_with_the_backlog/ http://www.accolo.com/insights_and_expertise/accolo_blog_detail/agile_development_off_shore_and_problems_with_the_backlog/#When:22:49:00Z A couple of weeks ago I wrote about Agile software development off-shore. In that post I mentioned that the single most important item when planning and managing an Agile project off-shore was a well developed, force-ranked backlog of development priorities. While this is absolutely true, there is one key challenge to managing an Agile project off-shore through a development backlog. The problem? It is difficult to accurately estimate delivery dates. For engineers the idea of committing to a delivery date is like asking Bob Dylan to let us know when All Along the Watchtower will be finished and ready to record. You don’t rush genius. However, we all know that the stakeholders and business folks cannot run a business on “it’ll be done when it’s done.” We all have resource constraints, so in all but the rarest cases a delivery estimate is necessary. The problem is that Agile process requires that designs are only completed right before implementation begins. That means that most feature development time estimates are done without any designs to reference. That is a problem when your technical architect and lead designer are 10 hours apart and don’t speak the same native language. In traditional development teams, the designer and the architect would sit down together to estimate the time to implement each feature based on the technical architect’s understanding of implementation and the designers understanding of future feature design. Without the ability to quickly and easily discuss implementation time and feature designs it is necessary to sit down and go over each feature estimate, talk about the design and determine if the estimate is accurate. I’m not yet sure what the optimal frequency of these meetings is, but I think it should be done each time there is a major update to the backlog. Agile Development Off-shore and Problems with the Backlog 2008-08-27T22:49:00-08:00 http://www.accolo.com/insights_and_expertise/accolo_blog_detail/follow_up_outsourcing_for_impact_and_vc_money/ http://www.accolo.com/insights_and_expertise/accolo_blog_detail/follow_up_outsourcing_for_impact_and_vc_money/#When:16:25:00Z I was chewing on some numbers over the weekend that tie together my post on Friday about the use of VC funds and the post of a few weeks ago about outsourcing for financial impact. Let’s say we have a company that just raised $3 million and plans on hiring 30 people over the next 2 years.  Assuming an $80K average comp per hire, they are going to add $2.4 million to the payroll.  According to Staffing.org’s 2007 survey, the average company spends 14.9% of the compensation hired on recruiting expenses—internal recruiters, contract recruiters, applicant tracking systems, job board postings, research, occasional headhunter usage, etc.  Based on this estimate, this company will spend about $360,000 to hire these 30 people.  If the company were to outsource the recruiting function (or just manage it well themselves), they could cut this down to 7% to 8% of compensation and save $180,000.  The savings represent 6% of the original invested amount -- a pretty staggering number that should raise some eyebrows at both VCs and their portfolio companies.  Follow up - Outsourcing for Impact and VC money 2008-08-25T16:25:00-08:00 http://www.accolo.com/insights_and_expertise/accolo_blog_detail/where_is_your_vc_funding_going/ http://www.accolo.com/insights_and_expertise/accolo_blog_detail/where_is_your_vc_funding_going/#When:17:26:00Z Accolo raised a Series B round in June of 2007 from Altos Ventures with three goals in mind: 1) Finally get ahead of the hiring curve on the Client Services side of our business (the folks that do all of the recruiting and consulting work) 2) Ramp our sales team and build a formal marketing department 3) Accelerate the development of our core technology As I look at where the money is going, at least 60% of it is for hiring full time employees and 30% towards technology development contractors/resources.  The other 10% went toward a kegger and new coffee machine (just kidding, Ho - just curious if you ever read this stuff).  Anthony Lee of Altos Ventures estimates that 70% to 90% of a company’s expenses in the early days go towards headcount. Given that level of investment, why do most small, venture-backed companies not have any formal way of spending those dollars?  We talk to companies every day that recently closed funding, have a lot of money to spend (and the associated growth expectations) and a short time line, but have NOTHING in the way of a formal process to hire or dedicated resources to get it done.  Most either spend a truckload on contingency recruiting fees or assign whoever isn’t in the meeting to run recruiting.  It’s a common cliché that the people you hire is the single greatest investment you make.  You know where this is all going, but I’ll proceed anyway.  Let’s say you have $5 million to invest and expect a good return.  You decide to let me invest it for you.  You are aware that I have no formal training in investing, no tools or research to leverage, and stock picking is one of a hundred things I have to do everyday.  How confident are you in the returns?  If you’re lucky, I’ll pick by throwing a dart at the newspaper stock quotes.  Come to think of it, I’m not even sure if they print those any longer. When Accolo has its multi-bazillion dollar IPO in a few years and I become a rich uncle to startups, the first question I’m going to ask is what plan is in place to spend the 90% of my money wisely?  A company that recruits by asking an overworked office manager to post on Craig’s List and then forward resumes to a CTO that is working 80 hours a week is at best the equivalent of throwing darts at the newspaper.  What is the cost to the company of a bad hire?  What is the opportunity cost to the company of a hire not made?  It’s somewhat surprising how many startups make their most important investment without a formal process or the resources to do it well. Where is your VC funding going? 2008-08-22T17:26:00-08:00 http://www.accolo.com/insights_and_expertise/accolo_blog_detail/agile_development_off_shore/ http://www.accolo.com/insights_and_expertise/accolo_blog_detail/agile_development_off_shore/#When:20:14:00Z At Accolo, we identified a specific product development opportunity and went out and secured a small round of funding to support it.  After we shored up the round of funding we took a look at what we were trying to accomplish and our staffing options to accomplish our goals.  There were a few obvious approaches: 1. Hire a small team of full-time employees as developers, qa personnel and design folk and purchase all the tools to support the development effort (project management and QA tools) 2. Hire a mix of full-time and contract employees for development, qa and design and purchase all the tools to support the development effort (project management and QA tools) 3. Hire full-time design personnel and outsource the development and qa effort to an on-shore vendor 4. Hire full-time design personnel and outsource the development and qa effort to an off-shore vendor Option 1 and 2 were both out immediately.  We didn’t have the funds to pay the high prices for people in the bay area nor the time to recruit and manage those folks.  Option 3 seemed like a good idea, but my experience with vendors on-shore in our price range has been bad (one of these experiences may be a topic for a future blog entry).  So, option 4 seemed like the best bet.  So, the next step was to look around for potential off-shore vendors.  We picked a vendor in the Ukraine that has both a good track record in actual product development, not just IT tasks, and who also happens to be under the same VC umbrella as we are.  We figured that if they are under the same VC umbrella then there would be extra incentive to do well for us. So, since August Accolo has been working with a 10 person team in the Ukraine to build our primary product development initiative.  We have maintained design and functional requirements writing on-shore, most recently adding a person filling a business analyst role (we actually stole her from another unit in our company). We chose an agile approach to the project with the Ukrainian vendor.  So, what are the key lessons I’ve learn in making agile development techniques successful with an off-shore development team?  The main success factors to off-shoring an Agile development project are (1) collaboration tools, (2) development backlog, (3) Well defined iteration management process and (4) mockups. Collaboration Tools Collaboration tools become extremely important in off-shoring agile projects.  Because of the time-zone and language differences written communication is vital. Collaboration tools must facilitate three things: (1) Rapid person-to-person communication during overlapping hours (2) communication of requirements and mockups (3) iteration management The good new is that it is not necessary to go out and buy expensive collaboration tools to make this possible.  Most off-shore vendors made the investment in project and iteration management tools, now all you need is a way to communicate with the team members.  At Accolo we’ve been able to accomplish our collaboration goals using all free tools, Skype, Trac and Google Docs.  Skype provides not only free voice communication, but also a nice IM tool.  We use Trac’s Wiki features to embed mockups and write requirements around those mockups because it allows for easy linking between different design documents.  You could really use any Wiki for this.  We use Google Docs for managing our feature backlog (more on this shortly), permissions model and complex requirements that we want to communicate using spreadsheets. Development Backlog Usually the first engagement with the off-shore project team will be with a project manager or technical lead that will work to understand your business, requirements and direction.  We spent hours with our newly assigned project manager from Kyiv in conference rooms looking at demos, drawing on white boards and discussing our short, mid and long term goals.  This was all great stuff and the PM left the US feeling like he understood our business and goals.  However, we left out one key thing that caused a lot of confusion and wasted time, we did not produce a development backlog.  We went for a few months of shifting priorities and unreasonable expectations before we realized we needed a backlog to manage our priorities.  This was an especially big problem when trying to set stakeholder expectations.  Stakeholders typically don’t care about development challenges, they just want to know what is going to be built and when.  Without a backlog of sufficient detail it is very difficult to communicate priority and timing with stakeholders. There are different approaches to development backlogs, our definition at Accolo is a list of features, each of which can be completed within a development iteration, all force ranked relative to every other feature. My advice to anyone starting an agile project with an off-shore team is to create a development backlog first.  At Accolo we are fortunate to have an existing application.  So, for our first pass at the development backlog we listed all the key pages in the application in a Google Spreadsheet; one application web page per spreadsheet row.  Then we added row after row of subfunctionality per page until will had a 250+ row spreadsheet.  After that we went back to our feature wish-list (all the things that have come up in brainstorming sessions) and added a row to the backlog spreadsheet for each feature.  So, what Accolo ended up with was a list of 400+ features all force ranked in a list. The next, and most important step, is to force rank every entry in the backlog relative to the other features in the backlog.  This is tedious work, but it will go faster then expected.  At Accolo we started from the top with 1000, with the feature with a priority of 1000 being the most important, and then working down from there evaluating every feature’s priority against the last ranked feature.  We use a “Priority” column in our spreadsheet that can be resorted as priorities change. TIP: Try to keep as much of the related sub-functionality prioritized together.  For instance, if you are creating a search feature with two subfeatures, autocomplete and reset, try to prioritize autocomplete together in the backlog.  As developers are working on functionality they tend to “get in the zone,” meaning the developer is very focused on the feature and he has a keen understanding of how the feature works.  It is often most efficient to have the developer complete as much of the subfunctionality as possible while the developer is “in the zone.” The next step is to identify the minimum feature set for releases.  For instance, at Accolo we identified the minimum functionality for an internal only, non-production alpha release, an open beta release and a full-featured production release.  Because our backlog is in a Google Spreadsheet we put a line in the spreadsheet deliniating the minimum requirements for each release (we make these lines orange so they stand out).  Defining minimum feature set for releases is a good way set expectations.  You can tell stakeholders that you have completed x number of features while we need to complete y features for a release.  You can even estimate delivery by looking at statistics about implementation time for the completed features and estimate the gap between completed and not completed features. The importance of a backlog cannot be overstated.  The lack of a backlog at the beginning of our project is the single biggest mistake we have made when off-shoring development using Agile development techniques. Well defined iteration management process Early in any Agile project an iteration duration is chosen.  I’ve often seen iterations of 2 or 3 weeks, but never less than 1 week.  This, of course, depends on your project, but most web application projects do well with a 2 or 3 week iteration length.  Once the duration of the project has been agreed upon by all development personnel the iteration must be broken down into deliverables that will ensure iteration quality and provide requirements for future iterations in a timely manner.  Here are the basic requirements for iteration planning: * Features are broken down into small enough chunks so that each chunk is completable in an iteration * Feature is complete ONLY if QA and stakeholders have accepted the feature as fully functional - we use the concept of Running Tested Features (RTF) * Engineers commit to the number of features that can be completed in the iteration based on designs and test-cases In order to support the basic requirements for iteration planning we have developed a schedule of deliverables based on our 3 week iterations.  The deliverables are assigned to designers, engineers or project management and are expected at the same point during every iteration.  Below is a diagram of a typical iteration plan and deliverables.  The example below goes from the end of iteration 12, through iteration 13, to the beginning of iteration 14.  The engineer commitment for iteration 13 happens on the last day of iteration 12, Friday.  On the first day of iteration 13, Monday, a discussion happens to determine priorities for Iteration 14.  By setting the priorities for iteration 14 the designers and requirements folks now know what to design.  The designs for Iteration 14 will be due at the end of the second week of iteration 13, Friday.  Once the designs for iteration 14 are complete at the end of week 2 of iteration 14 the QA folks start writing test cases for the new requirements.  The test cases for iteration 14 are written during the last week of iteration 13.  The engineers then use the designs and test-cases to estimate development effort and make a commitment for iteration 14.  Of course, during this entire time the engineers are developing the features for iteration 13 and the QA personnel is testing iteration 13. Well defined roles and team structure Accolo is a web application, so we have typical web application project team roles.  We have management, design, implementation/engineering and QA.  Of course the roles depend on the project.  We are heavy on the web design as opposed to, for instance, middleware vendors who will be heavier on the engineering design.  Otherwise, this split is pretty common for any software project. One key thing you must understand when managing off-shore vendors: Your off-shore vendor doesn’t know what type of personnel you need better than you do.  Even if you consider yourself non-technical you have a better understanding of how your team should be staffed than the off-shore vendor.  Don’t let the vendor dictate staffing decisions that don’t make sense.  Don’t be afraid to tell the vendor the types of people you need and make changes as quickly as possible if you see delivery problems.  Off-shore development engagements are not successful if you hope to just “throw requirements over the fence.” You must actively manage the vendor and the personnel choices that vendor makes. The Accolo application is very user-centric, making heavy use of complex user interfaces.  The most important aspects of our application is a simple and highly-usable user interface with heavy automation done on the back-end.  So, when our vendor began staffing our project with exclusively back-end developers it didn’t seem right.  However, we were brand-new to off-shoring development with an established vendor and we didn’t realize the importance of actively managing the vendor.  We ended up with back-end developers trying to do front-end work.  Back-end developers are typically un-able, un-willing and un-interested in doing front-end work.  So, we were getting poor front-end work and angering our back-end developers.  It took us a few months to realize we needed to actively manage the vendor.  We made it clear to the vendor that we though a 1:1 front-end to back-end developer ration was more appropriate.  It took a project manager change, but we finally got what we wanted.  Today we have 3 pure front-end developers and 4 back-end developers (with some front-end capabilities). However, while development/engineering staff and structure is important QA is critical.  QA polices the requirements, making sure that what is implemented meets the requirements.  We were lucky to get a very good QA person.  If you choose to off-shore the QA function of an Agile project make sure you get a QA person that understands your business, takes ownership of the requirements you produce and is not afraid to mix it up with engineers.  I think a 2 developers to every QA person is a good ratio even when off-shoring an Agile project. We are starting to see problems with only 2 QA people.  We don’t have anyone on our team who can write front-end automated tests (we have standard automated unit-tests for the back-end).  If you have an application using complex front end technology for a rich user-experience make sure you have a person available, if not dedicated to your team, that can architect and write automated front end testing. Design is key, mockups are critical If you have an application that requirements a rich user experience you cannot off-shore the design function.  The front-end design must be heavily controlled by the people closest to your customers, you.  Trying to communicate the nuance of required functionality to off-shore designers will not be successful. There is a saying that floats around our team, “pictures save a thousand words.” I think anyone involved in software design can relate to this adage.  There is no better way to clarify requirements than to show what the user-interface will look like.  You can then add detail around each element of the page and speak to the back-end processing related to the feature group.  In off-shored Agile projects this is even more true for two obvious reasons: 1. Time Zones: A lot of time can be wasted clarifying requirements when the implementation team is on the other side of the world.  As stated previously, there is no better way to clarify requirements that a picture of what the page should look like 2. Language Barriers: There are varying degrees of English proficiency between team members on any off-shored development team.  I would extend the adage written earlier to say “pictures save a thousand words and doesn’t depend on a particular language.” Obviously this has limits because pages have words and labels, but the point is valid.  A person can look at the layout regardless of language proficiency and get the gist of the requirements. The production of the mockups and supporting requirements must be done on-shore with direct access to the business stakeholders.  So much nuance is derived from the short meetings and informal encounters between business folks and design folks.  Hire FTEs and/or contractors to do the design and requirements work. Conclusion Don’t make the mistakes we made early in our project.  Have at least the beginnings of a development backlog that has been force ranked before engaging an off-shore team.  Make sure that the off-shore vendor comes with a project management software suite for development and issue tracking.  Establish the way that mockups will be produced and requirements detail built around the mockups.  Develop an iteration deliverables plan so that every team member knows what deliverables they are responsible for and when those deliverables are due.  A consistent iteration deliverable pattern will allow the development team to get into a rhythm.  Hire great design personnel on-shore and focus on mockups with written requirements augmenting the mockups, not the other way around.  And definitely don’t try provide only written requirements, you will find yourself going around and around in circles clarifying requirements. My off-the-top-of-my-head-because-I-haven’t-had-time-to-research-it estimate of productivity is that off-shoring an Agile project gets you about 80% productivity compared to a full on-shore team.  This is raw productivity not taking into account innovation benefits you get from an on-shore, full-time team.  But, if you can get an off-shore dev team at 80% or less of what it would cost you for an on-shore team it is justifiable. Agile Development Off-shore 2008-08-04T20:14:00-08:00