Changing The Engine While The Car Is Running

“To do two things at once is to do neither” 
– Publilius Syrus

A common dilemma facing businesses is ‘How can we develop the next big thing if we have to continue supporting our current offerings?’. After all it’s our current offerings and its customers that are paying the bills and we can’t ignore that can we?!?

Of course not, so let’s multitask. We’ll allocate 50% of each person’s time to doing new development and 50% to sustaining our current offering. It’s mathematically perfect and a great way to fully leverage each person’s expertise but hopelessly flawed in practice. The false economy of multitasking is well documented in both business and life. Not only is it flawed in organizational applications but its avoidance is at the very heart of software Service Oriented Architectures (SOA) with its emphasis on the single responsibility principle (SRP) and separation of concerns.

In our case, with the teams having completed basic Agile training, we were eager to move forward with our Agile transition. But knew we could not abandon sustaining business with our existing customers while we did it. Add to this the stigma associated with software maintenance and we had a hard choice to make.

1. Continue having everyone do maintenance but set aside half their time to participate in the transition. Which we knew would translate to a very slow transition at best and no transition at worst.
2. Leave a few of our key team members behind on maintenance while the rest moved forward with the transition. This would definitely keep the business happy but would do little for the morale and retention of the few left behind.
3. Outsource the maintenance activities so that everyone could be part of the transition. This of course would require extra cost but bearing in mind the false economy of the first option and the potential for operational efficiencies – would it really in the long run?

We chose option 3 and went with a local outsourcer who had offshore operations based in India. The offshore workers were quick-to-learn, eager to please and unlike their North American counterparts had no issue working on software maintenance. Rather, they saw it as a great opportunity to gain North American experience and eventually a ticket to the riches of the West.

The thought of offshoring to India sent shudders through the organization. They had tried it once, failed miserably and were still paying off the technical debt incurred. The big difference this time though was scope of the work being offshored. We weren’t offshoring the future of our core competency but rather the maintenance of a shrinking legacy code base. We made sure any offshoring work candidates fulfilled the following criteria:

1. Existing well-defined processes for workflow and governance.
2. Work that requires low interaction with the business and customers.
3. Work that can be performed during prime shift in offshore location.

Still it was not going to be easy. We were now planning to use an offshore transition to enable our Agile transition. A transition within a transition!

Under the guidance of a dedicated Release Manager with technical oversight and support from the development team, the offshore transition plan and operational models took shape. The development team spent countless hours bringing the offshore team up to speed going through the following phases:

1. Knowledge Transfer
2. Work Shadowing
3. Guided Work
4. Solo Work

It was tedious work for our development team members. They would often lament how much quicker they could do the work themselves rather than having to explain it to someone else to do. Their only solace was knowing that the faster the offshore team came up to speed, the faster they would be freed to participate in the Agile transition.

After 3 months, early results of the offshore transition were promising and dissipated any earlier objections to offshoring.

1. We achieved a full crossover of ongoing maintenance responsibilities.
2. We freed up all employees including those that were previously dedicated to legacy maintenance work to participate in the agile transition and new development work.

If you’re entering into an offshoring engagement solely to achieve cost savings, you will be sorely disappointed. Depending on the scope of work and operational model used, there may not be any cost savings. The real value for us behind offshoring was:

1. The potential for quality improvements such as increased documentation and process enhancements to ease the transition.
2. The opportunity to leverage the talents of your key employees towards improving core competencies and building new business value rather than maintaining legacy value.

We had our (Agile) cake and were able to begin eating it too!