Although some problems are inevitable, there are ways to
be more productive in your software development if you are prepared
to take a risk and try some new methods.
Someone who has never shied from change is Tillmann Bruckhaus,
who is an old hand when it comes to alternative software
development practices. In 1999, when he worked as a chief architect
at
Sun Microsystems, Bruckhaus was using distributed teams
consisting of people located outside the company to help meet
development project constraints.
Today, he does the same thing at Numetrics, where he works as
director of analytics helping to build software that uses
business intelligence techniques to monitor the performance of
development teams for integrated circuits software and
firmware.
"We are working with remote teams. We have a team in Pakistan
and they do the database and web programming, while an Armenian
team brings the statistical and data mining expertise," says
Bruckhaus.
Project managers taking this approach should be wary of their
intellectual property leaking into the public domain, warns Struan
Robertson, technology lawyer at Pinsent Masons.
"A popular misconception is that you own the code that the
freelancer develops, and that is not the case. The freelancer owns
the copyright to the code unless you specify otherwise," he
says.
One of the biggest challenges for an executive trying to farm
out elements of a project in this way is managing the
developers.
"You must make the time for the additional co-ordination and
communication. It may be difficult to judge the skill of the remote
team, and you may, therefore, have less confidence in the project's
schedule," says Bruckhaus.
Jack Repenning, chief technology officer at Collabnet, a
collaborative platform for software development, agrees. Repenning,
who has participated in open source software development projects
since the early 1980s, says that for all the technological
advancements that have been made, there are still significant
difficulties facing project managers who employ staff in diverse
locations.
"When you get into a situation where one person goes to bed
before another comes to work, it can all fall apart, and I do not
think anybody has managed that, other than by using scrum," he
says.
Scrum
software development
Scrum is an agile development methodology in which a problem is
divided into a set of discrete tasks assigned to groups. Its name
alludes to the scrum formation in rugby where, as in scrum
development, people fulfilling distinct tasks come together to form
an effective whole.
Scrum emphasises short meetings designed to address immediate
problems and keep tabs on progress on a frequent basis.
Repenning posits the "scrum of scrums" idea, in which a scrum
dealing with a set of related tasks forms part of a larger set of
scrums.
"There is one person called a scrum master in each team who
keeps track of the status. The scrum masters will also meet, a
little less often, and they deal with larger components of the
task.
"The key point is that scrum masters do not have to be as
tightly co-located," says Repenning.
Agile development practices, such as scrum, can be useful in
dealing with the inevitable management overhead that besets
projects with distributed teams.
"The key is that you must ensure the development is very
transparent," says Kent Beck, developer of the
extreme
programming methodology.
Bruckhaus says, "If someone offers to do something for you as
part of a larger development, then sitting back and waiting for the
deadline day and expecting it to be met is a recipe for
disaster.
"That is why agile development can be helpful in this context.
You can work in small time boxes, so you can get a verifiable
functionality back at a faster rate."
Tips to help accomplish this include daily code drops in which
iterations of code are submitted on a frequent basis to a shared
server.
They can then be reviewed by project managers so that any
misunderstandings or potential problem areas are taken care of
before they become damaging.
Automated tests to verify the code quickly and regularly,
without bogging down development staff, are also crucial in
distributed collaborative development scenarios.
When it comes to specifying projects from the outset, it is
worth remembering the mantra "a stitch in time saves nine". This is
especially important when dealing with people from different
cultural backgrounds whom you are not seeing on a face-to-face
basis each day. Ensuring that they understand the scope and
requirements of the project from the start is crucial.
Sourcing the team members
Like many project managers sourcing members of a virtual team,
Bruckhaus focused on people that he knew. He had a network of
people who had previously worked for the company, but had
subsequently emigrated. He was able to build virtual teams using
these individuals as local hubs for talent.
Other project managers propose a more open method for building
distributed groups.
Kevin Wade, founder of IT recruitment firm Topcoders.com,
sourced design and development talent from people that he had never
met, via the internet. "I have built 40 or so websites with
freelance designers and coders," he says.
Wade used web-based hiring sites to find the skills that he
wanted, before starting Topcoders.com specifically for software
recruitment.
The site is due to be relaunched in about four months with new
functionality, including tracking and extra administrative
features.
There are rival sites doing similar things, such as
Rentacoder.com. This site, which serves as a marketplace to connect
buyers with coders, does not charge a finder's fee to the buyer,
but instead charges the developer a commission for a successful
bid. As with Topcoders .com, the payment for the job is held in
escrow (by a third party) until the code is delivered and the buyer
is satisfied.
Scriptlance.com, another site offering a similar service for web
masters wanting to commission script programmers, charges a
commission both to the programmer and the commissioning project
manager, but the percentages are lower - 5% of the bid to the
programmer, and a flat £2.50 fee to the buyer.
Tapping in to open source
Another way to find talent online is to tap into the open source
market.
Many people who think of open source think of Linux, which has
an extensive hierarchical network of developers who contribute code
to the person directly above them in the chain. However, many open
source projects have far fewer people (normally in single figures),
which makes such complex management practices less necessary.
There are tools to help find open source projects and the coders
who contribute to them, and they can also be used to find code that
has already been developed by the open source community.
Sourceforce, a well-known orientation point for the management
of open source projects, is one such point of call, but if you want
to gauge the health of a project, consider a search engine like
Krugle, which was built especially for developers, says Repenning,
who was involved in a project for Collabnet to create an open
source framework for distributed project management.
The Krugle service makes it possible to search for code, or for
the projects themselves. Search results detail metrics such as the
numbers of lines of code and the number of files in the
project.
However, there are some potential pitfalls with open source
projects. First, open source developers will be even less
controllable than virtual teams.
"You need to remember that you are deriving your energy from
this open source dynamic," says Repenning, adding that waving cash
at them will not work.
"To some extent, no software developers anywhere are
coin-operated, but open source developers in particular are not.
They want to do the right thing, their own thing, and you have to
respect that," he says.
For many people, the main rewards for working on open source
projects are intellectual stimulation and recognition for their
work. Consequently, managers have to understand the value of public
praise, says Repenning. Understanding how to build a community
around the project is crucial. That community needs to thrive on
conversations that may well be sparked off by the project
manager.
The other danger for companies using collaborative open source
efforts lies with intellectual property. The traditional GNU
General Public Licence (GNU GPL) dictates that any product using
code developed by the open source community must itself be given to
that community. In this way, it infects everything it touches with
the open source "copyleft" ethos.
Make open source work for you
Fortunately, there are alternatives. The
GNU Lesser General Public Licence GPL (LGPL) makes it possible
for proprietary code and open source scope to co-exist. The BSD
licence does not include the same infection clauses either, and the
Mozilla public licence is also liberal when it comes to the
commercial use of code.
This means that it is legally possible to combine open source
developments with proprietary code (useful if, for example, there
are certain parts of your intellectual property that you do not
want to make public).
However, project managers should be wary of getting code that
they had not bargained for. Proprietary code could make its way
into code contributed by the open source community, or by paid
remote workers, leading to a lawsuits further down the line.
There are ways to protect a company against such dangers. If
using a paid contractor, then put some form of liability clause
into the contract, so that the coder pays in the event of a
lawsuit. Of course, it becomes important to ensure that they have
indemnity insurance and will be able to pay the bills.
Technology can also help here, says Repenning. Products from
companies such as Black Duck Software can scan your code and match
against a knowledge base of publicly known code, to help inform you
of any copyright infringements.
But all of these measures may not help project managers caught
in the headlights, after all. The management overheads required and
the planning and forethought needed to successfully pilot new ways
of working calls for such approaches to be factored into a software
development project at an early stage.
Fred Brooks, author of The Mythical Man Month, was right when he
said that you can not make a software project that is running late
finish earlier by adding more people.
Anyone wanting to shake up their project management processes
should be thinking ahead and treating this as a long term strategy
- not a short term fix.