eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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 coded—which 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.
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 engineers—and Im an engineer myself—to 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 them—not 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.
Next Page: Agile processes mean developer accountability.
Agile Processes Mean Developer
Accountability”>
So, have you found developers in non-agile-development shops defining their success in terms of producing code rather than actually meeting the business goal?
In a waterfall model, [developers are] pretty insulated from accountability—and they like that. Its not that theyre slackers. Its not that theyre not doing a good job. Its just the basic nature of engineers to be conservative and nonconfrontational.
Agile [practices] make every person in the process accountable: every product manager, every engineer, every QA. Thats what makes people uncomfortable, initially.
Doesnt a label like “scrum” hit all their hot buttons at once? Isnt it a red flag saying, “Youre going to be right in the thick of all the hard parts of the process, as exposed as any product manager or business process owner to the volatility of the environment?”
It does say that its a team activity, that everyones accountable and visible. It fits very well.
If youre talking to a manager whos heard the distant drums of agile methods, how would you pave the way for that manager to start thinking about agile adoption? What potential concerns or misperceptions would you want to head off before they have time to take root and get in the way of that process?
There are lots of things involved. I think the biggest misconception is that agile development puts out a lot of junk code, that its a down and dirty way to get a product out faster, and quality be damned. I think one of agile [developments] greatest strengths is that it brings much better quality into a product—and all engineering managers really live for quality.
When they understand that agile [development] will give them better quality in their products, they start to buy in very quickly.
Guru Jakob Nielsen offers advice on designing applications for usability.
Click here
to watch the video.
So, would you tell people to promote agile methods for quality improvement rather than schedule improvement?
Absolutely. Theyll get much better acceptance from engineers and from engineering management with that approach.
Do people think of agile development as depending on close collaboration, using techniques like putting two programmers on a workstation or having regular morning huddles? How well does that fit with a geographically dispersed development team using outsource talent?
Its certainly throwing in all the challenges you can when you go to that [distributed] model—but weve demonstrated for 18 months that you can do it. The key to agile [development] is about communication, not about location: that daily phone call for 15 minutes.
It wasnt just [the challenge of developing in] Russia. We also have engineers in Canada; Portland, [Ore.]; Denver; Salt Lake City: five locations where were working. Its [about] the visibility—everyone seeing whats expected and how to go forward.
Theres typically a one-month development cycle—what agile teams call a sprint. The teams have their daily calls, but theyre isolated during that month—except that we do it in two weeks. Theres more of a chance to get off track when youre distributed, so I wanted two-week visibility into the progress we were making.
We structured the working schedules at all the locations—which was a challenge—so that they had a good hour and a half overlap in the development day. After the daily 15-minute call, there was time for e-mail to get into more detail and follow up. We facilitated very strong daily communication.
We had a two-week sprint, where at the end of the two weeks we did a Web session where everyone saw what was being demoed and everyone participated. It gave a sense of one team at one location, even though we were spread around the globe.
At IBM, at one time I had engineers in 32 different countries working on the same piece of code: Im used to facilitating distributed development.
Have a comment or suggestion? Please e-mail Solutions Series Associate Editor David Weldon at david_weldon@ziffdavis.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.