Q&A: Alpha Bay's CEO Jack Blount sees outsourcing as an affordable way to find development talent.
Two key trends in enterprise software development might seem to be in collision. The cost reduction opportunities of offshore development could appear to lie on a different path than the productivity gains and the business alignment benefits of agile development processes.
Demonstrating that a development shop can pursue both options at once has become the charter of Jack Blount, president and CEO of Alpha Bay, an enterprise software company in Salt Lake City that produces retail-sector applications.
Blount spoke with eWEEK Technology Editor Peter Coffee about his offshore experience in working with StarSoft Development Labs, a service provider based in Cambridge, Mass., with development centers in St. Petersburg and Kazan, Russia, and Dnepropetrovsk, Ukraine.
How did you get involved in outsourcing agile development work to Russia?
I was in search of an outsourcing firm. I met an old IBM colleague of mine in a New York airport on my way back from a trip, and he mentioned that he knew of some very talented outsourcing firms in St. Petersburg. Id mentioned that I was looking for companies with scrum and agile development experience.
I did some Internet research [and] pulled up half a dozen companies that seemed significant. I contacted the CEO of StarSoft and found a fit.
When you say you were looking to do some outsourcing, was your main motivation cost reduction or a need to find more people than you could find locally?
It was a bit of both. We needed to add about 25 Java programmers who had agile [development] experience to a team of about 25 or 30 that was already in place. We had run ads through various channels, we had hired a recruiting firm and we were coming up empty-handed here in the States with additional talent even though we work from three locations. We had a main office in Salt Lake City and offices in Denver and Toronto but were coming up cold.
Like any company, were always looking to save money, and adding 25 engineers certainly [would have] added a lot of cost in the U.S.; we decided that the right answer was outsourcing and started that process.
How long have agile development skills been part of what you seek when hiring developers?
Id say Im one of the early pioneers of agile [development]. I started doing something similar at a startup in Dallas in 1993, and we actually thought of packaging and productizing our process along with a set of tools at that time. We thought of calling it demoware because of the emphasis on building something in a couple of months, when you actually have to be able to demo what youve codedwhich is a big part of agile [development].
We quickly got distracted with our core business, which was wireless computing, and we decided to leave the processes to other people. Through four companies now, Ive been a very dedicated agile development shop.
Click here to read eWEEK Technology Editor Peter Coffees perspective on what holds back the widespread adoption of agile development techniques.
When you say youve had trouble finding developers with agile development skills, is that because they dont take to it quickly? Is there a lot of re-education required to get people into the principles and the pace of that approach?
Yes, unfortunately, thats true. Ive found engineersand Im an engineer myselfto be fairly conservative people that are fairly resistant to change. Agile [development] is a radical departure from the waterfall method thats been taught and used for the past 20 years in software.
Theres also a side to agile [development] that I think makes developers resistant to it: Thats the feeling that its Big Brother watching themnot that its going to make them more efficient and work better, but simply that its a way for management to watch what they do more closely. Thats becoming less so now that its becoming fairly accepted and people are seeing the successes.
There is a mythology that developers dont like specifications and documentation. Do you actually see developers react with suspicion when theres less of that scaffolding around them, when theyre being evaluated on their pace of actually getting code done? Do they wonder, Whats the catch?
Very much so. When Ive gone into companies that were using waterfall methods and taken over development responsibilities and explained what agile [development] was and why we were going to do it, Id say that between 30 and 50 percent of the engineering staff either resigned or threatened to resign because they would not work in that environment.
Most only wanted me to know how violently uncomfortable they were with it. But within a very short period of time, what Ive found in four companies is that once they use it, they become absolute advocates of it.
Whats the biggest issue of perception that leads to initial resistance to adopting agile techniques?
Engineers see themselves as very successful, writing a lot of code. In a waterfall process, they blame [any problems on] product management, they blame bad specifications [and] they blame unrealistic schedules.
Agile processes mean developer accountability.