Skip navigation EPAM

Outsourcing Experience Report - LogicLibrary and EPAM

Agile Journal – by Brent Carlson

LogicLibrary, provider of Logidex, has had an ongoing relationship with EPAM Systems, the largest Eastern European technology outsourcing vendor, for over three years to develop its Logidex technology. This experience report discusses the approaches and tools used by LogicLibrary and EPAM to ensure effective communication and coordination between LogicLibrary's Rochester, MN-based development team and EPAM's Minsk, Belarus-based development team.


LogicLibrary developed Logidex using J2EE technology, releasing the first version in July 2001. In 2002, Logidex attracted interest from Microsoft, ultimately leading to Microsoft partially funding the porting of Logidex to the .NET platform. LogicLibrary recognized the need for flexible staffing and .NET specific skills via outsourcing, and selected EPAM Systems in June 2002. This outsourcing partnership has been highly successful with the initial release of Logidex for .NET in 2003, followed by three additional major J2EE and .NET-based releases along with point releases using the shared development model described in the remainder of this article.

Key considerations for shared development

In order for any long-term outsourcing relationship to achieve success, strong cross-site communication and coordination must be established. Coordination needs to span from the strategic to the tactical. The LogicLibrary/EPAM development team uses a wide range of techniques and tools to ensure that release development stays on track over the typical six to nine month Logidex release cycle, including:

    Release planning and estimation practices
    Formal release communication and coordination tools and approaches
    Informal release communication and coordination through scheduled and ad-hoc communication methods
    Synchronization across key SDLC tools

Release planning and estimation practices

As is the case with any successful product or IT application, the list of requirements is always longer than the resources available to implement those requirements. Prioritization must occur on a regular basis for a product or application to maintain its value. LogicLibrary uses a three-stage iterative approach incorporating elements of both agile and more traditional methodologies to release planning and estimation composed of:

    Release scope and feature prioritization

The initial release theme is determined through collaboration between product management, development, and other executives as required. Underlying candidate features consistent with the release theme are then selected for further evaluation, and a target release delivery date is chosen. These features are driven by customer requirements (entered by customers into a hosted Logidex installation configured for requirements management), strategic product functionality and technology needs. As this is a strategic activity, responsibility is not shared with EPAM but is retained solely with the LogicLibrary executive team.

    Top-down feature sizings

Once the initial candidate features have been identified, feature assets are created into the Logidex project management installation used for collaborative project management. The LogicLibrary head of development populates these features with initial top-down work estimates (i.e., sizings) and applies these sizings against a proposed release schedule based on the prior-defined target release date to determine workload fit against that schedule. Work allocations are managed so as to preserve flexibility to add additional customer-driven features in an agile-type manner throughout the release. Product management and development adjusts the feature list and release dates as necessary. Because this is a strategic effort, ownership is retained solely within LogicLibrary.

    Bottom-up work item sizings and resource smoothing

Once an initial top-down release plan fits within the designated release dates, the selected features are then allocated to development team leaders. Team leaders decompose their assigned features into underlying work items (also represented as Logidex assets), specifying detailed bottom-up estimates and development team member assignments. This work allocation and estimation activity is shared between the LogicLibrary and EPAM development teams[1]. The resulting estimates are populated into Logidex and aggregated via a Logidex report[2] to evaluate the decomposed release plan for fit against both resource capacity and release timeline. This report is used throughout the release cycle to track release progress and identify risk exposures. Individual developers are responsible for maintaining accurate work item progress data.

Formal release communication and coordination

Once the release plan is defined and agreed to, the release development begins. LogicLibrary's primary formal release management mechanism, throughout the release development cycle, is the weekly product status meeting. This meeting brings together product management, development project management, operations and QA to ensure that relevant release topics are addressed on a timely basis as the release progresses through its development lifecycle. Lead individuals from these groups (currently all LogicLibrary employees) are responsible for assembling the necessary information for this meeting. Depending upon the stage of the release, the meeting may focus on topics such as design review progress, test plan development and prioritization, defect takedown rates, build schedules or whole product delivery requirements. The product status report combined with additional defect tracking and test plan reports give the product status team a complete view into release progress.

Development and QA team members require a more detailed means of ongoing formal communication than is possible through such summary reports. Information such as feature and work item requirements and design documentation, design review comments, test plans and testing results need to be documented and shared between team members. Outsourcing increases the complexity of such information sharing; again, Logidex is used to accumulate the artifacts and status information that must be developed and shared over the course of a release's development lifecycle.

Five primary logidex asset types are defined for such information sharing:

    Release: the anchor asset for a product release cycle, acting as the collection point for all supporting documentation and release-wide status.
    Feature: a self-contained set of functionality to be developed as part of a release. Each release contains one or more features, and each feature in turn serves as a collection point for requirements documentation and initial top-down estimates as described above.
    Work item: a set of development tasks assigned to one individual within the scope of a feature. Each feature contains one or more work items depending upon its complexity, and the individual developer is responsible for maintaining the work item throughout the release's development lifecycle. Estimates and progress for each work item is rolled up into the product status report and reviewed during the weekly product status meeting.
    Test set: a cross-feature set of test points used for ongoing system and regression testing of the product. Test sets are independent of features and serve as the cumulative test plan used during final system testing prior to general availability of a release.
    Test set result: the results of executing a test set (e.g., number of test points, percentage of test coverage) or specialized feature verification upon integration of that feature into the release. Each new feature is associated with one or more test set results for functional verification, with those verifications later refactored into existing or new test sets.

Informal release communication and coordination

Perhaps the most challenging aspect of a multi-site development project is maintaining a regular flow of informal communication between team members. It is obviously not possible to walk over to your teammate's office when he or she is located eight time zones away. LogicLibrary and EPAM use a combination of scheduled communication meetings and informal communication tools to ensure that team members stay on the same page and are working on the highest priority items.

The primary means of informal communication used by LogicLibrary and EPAM is the daily synch-up conference call. Similar to XP's stand-up meeting, the daily synch-up involves both Rochester and Minsk development personnel and walks through the day's priorities and hot topics. The meeting's focus may be on build coordination, critical defect assessment, customer support topics or other development-related items. Because of the difference in time zones between Rochester, MN and Minsk, Belarus, this meeting is scheduled early in the day for Rochester to allow for overlap with EPAM's workday. The EPAM team also time-shifts its work day to start later in the morning so as to maximize the overlap time. Synch-up meetings vary anywhere from five minutes to one-half hour depending upon the day's needs. Topics requiring more than five minutes discussion are spun off to separate meetings involving only those parties directly involved in those topics.

Instant messaging (IM) is another key communication tool used across the development team. Developers are encouraged to keep their IM application active whenever possible to ensure that they are accessible to other developers. IM serves as a very effective replacement for the "over the cubicle wall" informal conversations that any developer will tell you are essential to keeping the team moving forward.

Email is also used as a regular means of communication. Logidex emits email notifications to interested parties when asset updates or forum activity occurs, which is very useful in alerting team members to pending design reviews and active discussions on design and implementation topics. Point-to-point emails between developers and email threads that circulate among team members on a specific topic are also commonly used, as would be expected in any effective development organization.

Synchronization across key SDLC tools

The combined LogicLibrary/EPAM team uses a variety of SDLC tools. Maintaining synchronization between those tools is key to successful code development and build management. The Logidex code base is maintained in a version control repository (given the size of the combined Logidex/EPAM team, Perforce[3] was selected for this purpose). All developers have commit access to this single Rochester-hosted repository, with codelines established for each release once that release goes under maintenance (the main codeline is used for current release development as per version control repository best practices). All submitted jobs must be correlated with either a work item or a defect for traceability purposes. Individual developers are free to build and deploy their code under unit test to a dev-level testing stack; however, only promoted jobs built through the formalized build process may be deployed to a QA-level testing stack. Test stacks are deployed at both Rochester and Minsk, and developers can access stacks at either site as needed.

All defects discovered during testing or reported by customers are tracked in a Rochester-hosted Bugzilla[4] defect tracking system. Developers and testers across both sites have write access to this system. Defects referenced by jobs incorporated into a release are automatically flagged by build tooling as built and ready for verification. Bugzilla's email notification facility can then be used to notify the QA team of the outstanding queue of ready-to-verify defects.

Finally, the Logidex project management installation is connected to these development tools through metadata integration. For example, a Logidex build results in the creation of a build asset stored within Logidex - this build asset contains hyperlinks to the list of defects resolved by jobs in the build.


Outsourced development, whether explicit (through engagement of an outsourcing firm) or implicit (through use of open source components), can provide real value to a development organization. However, with that value comes increased risks and complexity. LogicLibrary has found that these risks and complexity can be managed with a disciplined approach to project management that incorporates strong documentation practices and planned communication at all levels of the project. Appropriate tool use greatly increases the likelihood that such documentation and communication will take place. In the end, visible management commitment to such tools and practices is mandatory for any outsourced development project to have a chance at success.

About the author

Brent Carlson, recently named to InfoWorld's 2005 Top 25 CTOs, is Vice President of Technology and Co-Founder at LogicLibrary, Inc. He is a 17-year veteran of IBM, where he served as lead architect for the WebSphere Business Components project and held numerous leadership roles on the "IBM SanFrancisco Project." He is the co-author of two books: SanFrancisco Design Patterns: Blueprints for Business Software (with James Carey and Tim Graser) and Framework Process Patterns: Lessons Learned Developing Application Frameworks (with James Carey) and a frequent presenter at industry conferences and regional user groups. Carlson holds 16 software patents, with eight more currently under evaluation.

[1] In general, LogicLibrary team members retain architectural and high-level design responsibilities, with detailed design and implementation tasks shared across both LogicLibrary and EPAM staff. EPAM team members contribute both mainline software development skills (e.g., IDE plug-in and add-in development, .NET server-side expertise) as well as supporting roles such as QA and performance testing.

[2] Logidex uses the Eclipse BIRT reporting platform. The Eclipse Business Intelligence and Reporting Tools (BIRT) project is an open source, Eclipse-based reporting system that integrates with your application to produce compelling reports for both web and PDF. Additional information can be found at

[3] Perforce is a commercial source code management system. More information is available at

[4] Bugzilla is an open-source defect tracking system. More information is available at