The Significance of Metrics in Distributed Software Development

My PictureBridging the Offshore Gap
Article in Quarterly Publication of the Austin Technology Council

How SiberLink Makes Distributed Software Development Work By Julie Barnes, CEO, SiberLink, Inc.

CEO Julie A. Barnes, CPA

Spending on IT outsourcing reached $56 billion in 2000 and is expected to top $100 billion by 2005, according to IDC, a Framingham Massachusetts based market research firm. Furthermore, a study conducted by The Conference Board, a business research organization in New York, found that 97% of respondents would outsource their operations again. Why and how is this industry growing?

The recent economic downturn has clearly prompted an increase in the level of outsourcing as many companies search for ways to increase efficiencies and achieve IT objectives with downsized staff. However, the most significant change in the industry has been a fundamental shift in the kinds of IT projects that are outsourced and why. Historically, systems integration was the primary role served by outsourcers, accounting for 35% of the total in 2000. These are the projects that we all normally envision when we think of IT outsourcing: huge banks of programmers working on thousands of lines of legacy code.

This picture is changing – a recent survey of companies considering new IT outsourcing initiatives (2001) reflects a growing demand for applications development (25%), fuller IT roles, including consulting and re-engineering, Client/Server systems (20%), and Internet/intranet and training (15%). While price was the pivotal consideration in choosing a vendor in the past, commitment to quality and flexible contract terms are now placing a close second and third.

When respondents in a survey commissioned by the Outsourcing Institute in 2001 were asked whatt hey believed were the three most important factors in choosing an outsourcing vendor, 48% indicated price; 38% quality; and 33% a flexible contract.

All of these figures indicate a maturation of the IT outsourcing industry and its move up the IT value chain. As the C.E.O. of a Russian-American software development company, I find these figures particularly encouraging for a variety of reasons:

Russian and East European engineers are some of the most highly educated developers in the world.

More importantly, they are critical thinkers who pride themselves in rapidly creating scientifically elegant solutions. Applications development and process re-engineering engage and challenge our specialists to apply their technical knowledge and higher education. While Indian outsourcing organizations have concentrated on a consistent and predictable level of quality for routine coding, programmers in the FSU (Former Soviet Union) have exhibited a strong advantage in R&D – especially in the realm of scientific and antivirus software. Their ability to quickly and thoroughly assimilate domain specific knowledge extends to business applications.

In fact, their higher education in mathematics, statistics, and related sciences give them a decided edge in designing innovative applications.

Large outsourcing centers with substantial infrastructure investments and attendant overhead depend upon large projects to sustain them. Development teams in the FSU are smaller, leaner, and a great deal more flexible – they can afford to take on projects from small and medium sized businesses – where much of the demand for application development exists.

Technical excellence has always been the hallmark of scientists in the FSU and their thirst for knowledge is legendary.

The availability of Internet training in the latest technologies allows them to keep abreast of their Western counterparts. Skills in the rapidly changing Internet technologies such as Java, J2EE, XML, XSL, Messaging, .NET, can be virtually learned and applied to application development.

The ability for the outsourcing industry to successfully move up the IT value chain also entails an entirely new approach to project management and quality assurance.

While broad based, organizational wide policies and procedures remain valuable, shared responsibility for the success of the project must be instilled at the individual level.

SiberLink has built custom applications for clients all over the world since 1998 – at fixed costs. Furthermore, we’ve given all of our clients a 90-day warranty period after the final deliverable and client acceptance before receipt of final payment. Quite obviously, our profitability is predicated upon productivity and quality assurance – we simply can’t afford to ignore opportunities to improve our process.

The following combination of methodologies and approaches has worked in our unique distributed software development model but certainly all of them are equally valuable in other IT environments:

• All IT functions, whether discrete or continuous, are subdivided into iterations (a kind of mini-project) with deliverables and metrics. Each iteration requires a plan from the development team which outlines all tasks involved in accomplishing the objective of that iteration, along with the estimated time for each.
• Projects with time-to-market constraints require short iteration cycles of 2-4 weeks throughout the life of the project, each ending with an agreed upon deliverable and client acceptance.
• Each iteration must end in tested and running code, allowing the client to provide feedback on the direction of the project.
• Business analysts must be heavily trained in requirements gathering and communications, especially in the formulation of use cases. They also assist the client in prioritizing each requirement based on its expected business value.
• Earned Value is tracked daily by the team, and reviewed by both the business analyst and project manager, allowing them to monitor performance and progress so that early action can be taken.
• Requirements are organized in use cases and prioritized by the expected value that they will provide to the Client. Each use case is then assigned to an iteration.
• Defect Root Cause Analysis is performed on all defects found in Unit Testing and on all defects reported by the Client. The results of the analysis are used to improve the process that we use to carry out projects.

As many of you might recognize, we have borrowed heavily from the Personal Software Process (PSP)(SM) and Team Software Process (TSP) (SM) created by Watts Humphrey of the Software Engineering Institute (SEI). In fact, our VP of Software Engineering, Steven Teleki, is an experienced instructor in these disciplines. Often overshadowed by other SEI methodologies, such as the Capability Maturity Model or CMM, PSP (SM) and TSP (SM) emphasize responsibility and commitment at the individual level.

In Steven’s words: “The only way to get accurate plans is to have planning carried out by the people who will actually do the work, and train them so they can make commitments that they can keep. That means that any planning tool must have the ability to distribute planning to each participant and then roll up the results into a master plan. As the work is carried out, participants should compare their own results with what they originally planned in order to better understand the reasons for inaccurate estimates.

The actual data can be used to help plan more accurately on the next iteration or next project.

An integral element of this method is the use of an Excel spreadsheet developed specifically for TSP (SM) to plan and track the progress of a project. Unlike the more popular Microsoft Project, it allows the teams to focus on the most important aspects of the planning work: the plan has to always represent the amount of work that still needs to be done and the plan must reflect the number of hours that the team members are available to work on the project.

Slide for Project Management
The Cumulative Earned Value chart on the left is taken from an intermediate iteration of a recent project. The chart shows that the work progressed at a steady pace during the iteration through the 7th day. Beginning with the 8th day an additional team member joined in to accelerate the project. The project started to move along faster and reached near completion by day 13 (98% done). The remaining work was done in two days as the
team tied up loose ends and released the product. (Day 14 and 15 were a Saturday and Sunday.)

If you’re thinking that all of this sounds like a lot of work, you’re right. Especially in the beginning, developers and clients, eager to get started on a project, will resist efforts to thoroughly plan an iteration. The most common complaint is that an iteration is short, and there is just not much to plan. We believe that when an iteration is short then it is even more important to plan, since even as little as a day delay in the schedule can result in significant delay in the project timeline.

Usually after several iterations developers and clients begin to value their ability to realistically gauge the progress of the project. They find that schedules can be managed and most importantly – commitments can be made and kept.

You can find SiberLink on the web at http://www.SiberLink.com/ and get in touch with Julie Barnes, CEO, at julie@siberlink.com and/or Steven Teleki, Director of Software Development, at teleki@siberlink.com.

More Than a Wordsmith