Introduction
Software engineering organizations strive to deliver high quality code, on time, within budget and at the lowest possible cost. Achieving this is an enormous challenge, as it demands world class develop-ment productivity and schedule predictability. Part of the solution is hiring only the best, most cre-ative, technologically up-to-date engineers. However, in many cases, that’s not possible because of the skyrocketing number of software companies now competing for limited resources. Growing demand for software engineers stems in large part from advancements in technology that have enabled the formation of myriad new companies. These companies are the by product of new technologies such as SaaS1, PaaS2, IaaS3, frameworks, cloud infrastructure, tools for continuous integration and delivery,
collaboration, and mobile computing/communications. Not surprisingly, for a growing number of com-panies, the limited supply of software engineers and access to expertise is a serious product develop-ment bottleneck.
Engineering shortages are an especially acute chal-lenge in Silicon Valley and the San Francisco Bay Area. Large, established software companies and a plethora of well-funded start-ups compete aggressively for talent. Companies are poaching engineers from each other more than ever. Especially painful is losing engi-neers after making significant investments in training and getting them up the learning curve.
Remaining competitive in the talent hunt also can be costly, as companies must offer increasingly aggres-sive hiring and retention incentives. Not only are these packages and perks expensive, new or custom-ized incentives can disrupt compensation structures within an organization, negatively influencing morale and collaboration, which directly impacts productivity.
When hiring requisitions are unfilled, projects are often inadequately staffed. This puts severe pressure on engineering organizations to meet target development goals, especially time-to-market and qual-ity. To offset staffing voids, understaffed product development teams must achieve unrealistically high productivity, something that rarely happens. The result is schedule slip and lower quality code.
________________________
1 SaaS: Software-as-a-Service
2 PaaS: Platform-as-a-Service 3 IaaS: Infrastructure-as-a-Service
3
The limited supply of software engineers in the U.S. is a major cause of the problem. Consider that the U.S. educational system produces the same number of computer science graduates today as it did twenty-five years ago.4
One solution is hiring from the entire global talent pool. For the discipline of software engineering, this is nothing new. Companies have tapped into resources from countries around the globe. However, in many cases the strategy failed to meet expectations. Low productivity eroded anticipated cost savings, and rapidly rising salaries in once cost-effective regions further reduced ROI.
Fortunately, neither higher costs nor lower productivity are always a given, as companies can very suc-cessfully leverage the availability of global talent. NMX Global Software, Inc. (“NMX”) has been doing this for the past fourteen years. Extracting high development productivity and quality from a global workforce requires adjusting project management processes, methodologies, infrastructure and tech-nologies.
NMX has leveraged its global workforce to develop a wide range of advanced SaaS products, includ-ing predictive analytics that Fortune100 companies across the globe use today.5 Numerous lessons
have been learned along the way, driving us to continuously refine and perfect our global software engineering processes. Naturally, our goal has always been to achieve high SW development quality, productivity and on-time schedule performance. These goals are important for our entire workforce, as it enables us to deliver capacity on-demand across a wide range of roles and all levels of talent. Our processes adapt agile methods to the realities of multiple time zones and ESL6 staff, while
deliver-ing superior results at an affordable cost. What follows are discussions of the key challenges of global engineering and examples of the approaches NMX takes to overcoming them.
Communication
Communication barriers can be a fundamental challenge for com-panies employing a global engineering workforce. For example, ESL speakers may overestimate their fluency, making uncertain the amount of a particular conversation they truly comprehend. Foreign accents also can be a challenge for any kind of spoken communica-tion, especially during conference calls involving multiple parties. _______________________________
4 The growth rate averages less than 1% over twenty-five years; it has been zero or negative in fourteen of those years.
Source: The Digest of Education Statistics; nces.ed.gov.
5 Prior to 2013, NMX was the in-house software development team of Numetrics Management Systems, Inc. NMX spun off
from Numetrics as a standalone SW engineering services company upon McKinsey & Company’s acquisition of Numetrics in 2013. http://www.mckinseysolutions.com/solutions/numetrics.aspx
In written communications, such as email, spelling and grammatical errors may lead to misinterpreta-tions and misunderstandings. General sloppiness and poor writing further undermine written commu-nications (and confuse automated language translators).
The solution is to adopt communication strategies that allow teams to use English effectively in the ab-sence of high fluency and literacy. For example, at NMX we limit the use of email, verbal reporting and meetings to communicate status in favor of updates to items in a project management system.
While use of English is our default practice, user input typically resides on a form, in a structured work-flow, which provides significant information context. Wherever possible, we communicate complex design information through the use of source code, tools and diagrams – as opposed to lengthy text/ emails that often contain nuances and/or ambiguities. Such strategies significantly enhance effective-ness even when all participants are fluent in English.
Skill Expectations
Each engineer has a distinctive skills profile, and com-petency varies widely. With a mature technology, such as an RDBMS, there is a wide range of skill levels and specializations. One project may require no more than a trivial setup and configuration of MySQL. Another may require features found only in enterprise-level platforms such as Oracle or MS-SQL; such features require ad-vanced understanding, and they often impact entire pro-gramming models, schema design, operational strategy, and even analytics strategy. NMX continuously cultivates
skills that anticipate these needs. For example, with our “agile-to-agile” engagement model we shift workloads around dynamically to make specific skills available to a client on-demand. Naturally, project leadership first considers the details of technical strategy to correctly match task requirements to skills. We emphasize the importance of this during the early requirements analysis phase, enabling projects to move forward quickly and cost effectively.
Process Practices
Communications and variation in skill level can be significant challenges with globally distributed teams if not addressed effectively. However, there are many other factors as well, and NMX employs a number of process practices within each engagement wherever possible to address them.
5
High Visibility and Transparency
Global distribution of work can make it more difficult to maintain a clear picture of who is doing what, and how projects are progressing. NMX offers clients a high visibility environment. The exact status of any project or individual task is immediately available to the client at all times. Communicating new requirements, reporting defects and problems, and all other program management tasks are activities our clients can perform themselves at any time. High visibility avoids problems that time zone differ-entials can create, and highly structured information makes intent clearer and highlights linkages and dependencies.
Continuous Delivery and Integration
With teams working in significantly separated time zones it is important that any type of work be able to proceed unimpeded, as much as possible. NMX makes work deliverables available in a continuous way through the use of tools such as Maven, Jenkins, etc. For many projects, testing environments are continuously updated so that the cycle time between feature request and testing/visibility is a matter of minutes or hours instead of days or weeks. This is valuable for large work products such as produc-tion websites, as well as small modules of code subject to further downstream integraproduc-tion by the client. Deliverables NMX provides are available on a continuous basis via check-in and builds within client-accessible source code repositories, as well as on continuously updated demo/testing servers. Continu-ous delivery supports our goal of insuring there is always a clear picture of how things are going.
Structured, Asynchronous Documentation vs. Unstructured Synchronous
Documentation
Relying on synchronous, people-to-people communications processes such as conference calls, emails, instant messaging and large unstructured documents can be difficult for geographically dispersed teams. NMX uses highly structured methods of capturing requirements, factoring work into packages, and documenting and publishing decisions in a persistent and asynchronously accessible form. Tools such as formal/traceable requirements management systems (e.g., Accompa, Blueprint), and agile tools that manage epics, stories, issues, defects, etc. (e.g., VersionOne, Jira, Rally) reduce language barrier issues significantly, as much information is organized, structured and prioritized by methods that avoid lengthy ad-hoc prose layered with nuance. Asynchronous methods work better across time zone dif-ferentials, and small elements of documentation kept in an always-shared repository are easier to keep updated.
People Dependent Documentation vs. Machine Executable Documentation
Much documentation in a software development project requires engineers and managers to have the time, motivation and fluency to read and understand it and then take action. During some project phases, such as requirements gathering, there are, by necessity, certain written artifacts that must be immediately read by others. These generate two kinds of friction. First, they must be read and un-derstood each time a new engineer studies the subject matter, and then again each time documents change. Second, they can be wrong and out-of-synch with a real implementation of the ideas; in which case they can do harm, or at minimum, waste time and mislead people. For this reason we minimize the use and need for such documentation. As a project matures, NMX phases out and transforms people-dependent documentation into machine executable documentation; allowing the machine executable document to become the singular and authoritative description, as well as the concrete implementation, of some procedure or configuration. Examples of this approach in action include database schema design tools that emit some DML,7 or for server/service configuration, tools such as
Chef, Puppet and Orchestrate. Such tools and the associated “source code” they use are inherently more accurate and easier for ESL speakers to read, understand and maintain.
Collaboration
Software development is a collaborative effort. Yet, insufficient collaboration processes and infrastructure is a common shortcoming plagu-ing many companies employplagu-ing global develop-ment teams. Having the entire project hosted within a shared workspace is valuable, as is sharing tools and collateral information.
Collaboration in a highly structured way, rather than via random, ad hoc emails/meetings takes some effort but produces more predictable and cost-effective outcomes. Important information such as what is being built, the order in which the team performs work, the status of each item, the time budget various pieces consume, the roadmap for future work, the state of the current system, etc. are collectively the kind of information available automatically via generated reports, instead of regular effort by people. NMX’s communications goal for each project is to spend most of the time communicating design ideas and decisions, rather than status information. Tools to accomplish these
________________________________________________________
7
goals include threaded discussions (rather than email lists), code review tools, formal requirements gathering systems, and use of clear diagrams rather than written text when appropriate.
Development Environment
A major influence on collaboration effectiveness and productivity is the entire development environment shared by both NMX and our client. One of the most productive environments is one in which the project under development is fully deployed at all times in the final, at scale, execution configuration, typi-cally within a cloud-based architecture that can be accessed equally by all global teams. This includes both the client’s engineers and the NMX team. While this kind of arrangement is in some sense “ideal,” it is not always possible or appropriate.
Some kinds of software, embedded systems code for example, may require access to specialized labo-ratory prototype devices (which may be in short supply); in which case, the development environment can be a complex one, often consisting of VPN connections or other remote access arrangements and sometimes simulators to test certain parts of the system design prior to complete integration.
NMX understands what factors can affect productivity in a variety of collaboration scenarios, and we work with our clients to craft a solution optimized for a particular project.
Security Issues
Whenever two organizations collaborate across the Internet, a variety of security policy and procedural is-sues arise. These range from questions of intellectual property protection, roles and access rights, code ap-proval processes and when various test and production elements may be updated. Typically, security procedures are realized through an exacting configuration and tuning of the development environment. We create a development pipeline that is secure and as friction-free as possible. Sometimes this means a code mirror and dedicated test environment that NMX is permit-ted to update and test at will, with a formal procedure for both approval and migration of changes into production. However, there are many scenarios that can be made to work. NMX understands how
security procedures affect productivity, and we work closely with our clients to craft solutions optimal to the particular project.
Summary
Every company faces significant challenges staffing software projects. At NMX we are continuously re-fining and perfecting our processes to deliver engineering capacity efficiently. We adapt agile methods to the realities of managing across multiple time zones and geographical locations, ESL engineers and differences in skill levels, expertise and competencies. Our focus on transparency, continuous delivery, structured executable documentation, and asynchronous collaboration enables us to overcome key challenges in global engineering.
