Ebay has exported Agile software development concepts to its Indian outsourcer, in a bid to address relationship issues that saw an entire software development team resign some 18 months ago.
The team resigned from eBay’s unnamed outsourcer in late 2010, due to difficulties in working with project managers in Britain.
Ebay began working with a new outsourcer, also in India, in 2011. In January this year, it kicked off a series of training workshops to identify and mend any gaps in its outsourcing relationship.
Ebay’s core systems are maintained at its San Jose, California headquarters but smaller projects are run by team leaders around the world, including British technical project manager Megan Folsom.
Prior to the training program, Folsom said eBay's outsourced software development team "operated in a vacuum”.
“They were siloed and operated individually," she told the Agile Australia conference in Melbourne this week.
“They would do demos like clockwork, every two weeks – but the business leaders weren’t showing up to these demos. So the development team was demonstrating to each other.”
Folsom travelled to India with eBay product manager Robin Zaragoza in January to to build trust with the outsourced developers and convince them that iterative Agile principles promote collaboration and produce better software.
The intervention was difficult from the start – mainly because the project and deadline-focused culture at the outsourcer was motivating developers for all the wrong reasons.
“The teams thought we were there because they were not living up to our expectations, and they were being retrained as a punishment,” Zaragoza recalled.
“We hadn’t told them what to expect because we didn’t want them to have preconceived notions, but this meant they were under extreme stress about the workshop for the weeks leading up to it.”
In Agile development, business leaders and development team leaders regularly review project progress and identify any roadblocks that must be cleared for the project to proceed.
Agile development described by advocates as faster, less expensive and more likely to produce business-relevant outcomes than traditional ‘waterfall’ methodologies.
But the methodology requires the ongoing involvement of management and problem-solving developers that aren’t afraid to question and change the process being undertaken.
“Before I went to the workshop, my phone calls with developers were really painful,” Zaragoza recalled.
“I would specify everything, throw it over the wall and the developers would give it back to me. But there wasn’t a lot of collaboration and discussion.”
Zaragoza said she was surprised by the hierarchical structure of Indian business – which explained to her why the developers were so reluctant to think outside of the box.
“In an organisation where you have layers of management, there is a sense of deference,” she explained. “I realised they saw me as the decision maker and were leaving so many decisions to me.
“But I come from a marketing and account management background. You do not want me making technical decisions about our product.”
By using the Agile model as a model to shape conversations, Zaragoza and Folsom were able to create an environment where the developers felt empowered to offer input into the process.
But the Indian developers weren’t the only ones learning from the exercise.
“I realised I was being a bad product owner,” Zaragoza explained. “I wasn’t expecting to learn that, and thought there were going to be many more learnings for developers than for me.
“I realised that I had been trying to protect them; they were never really part of our strategic meetings, and didn’t have context why we were doing certain things, and didn’t understand why they were delivering certain pieces of software.
“I had worried that the business would be critical of the developers and they would take that to heart, but after this workshop I realised that they want, need, and deserve that interaction.
“The level of engagement went from zero to 100 percent. It really reinforced for us that Agile has to be across the entire organisation – and it can’t just be across the development teams. The business has to embrace it as well.”