Looking Back: Creating a Software Factory – Part 2
In my last post I talked about the first iteration of the software factory I created. In it I talked about how I followed traditional management techniques to add offshore developers and testers to the team. The changes slowed individual productivity, however we could cheaply add more people from a cheaper labor market.The result was that overall the department hadn’t suffered any deterioration in throughput.
Phase Two – A good problem to have – more work. Or…A learning experience.
Once the department was stable and was beginning to enjoy some level of regularity the leadership team and I were beginning to look like heroes. We had substantially changed the mix of the department without changing the overall budget and throughput. Our success was not a secret either. We started to receive weekly visits from managers in other departments wanting to talk to us and learn from our experience.
Good things rarely last: Unexpectedly, the external market environment changed and more work came - actually twice as much work. We needed to add a lot of capacity quickly. By this time the detailed metrics were beginning to pay off. My initial estimate based on other offshore teams I had worked with in the past was that the offshore team would be 2x – 3x slower than the local team for the first 6 months. However, this offshore team was almost as fast as my local team – but with fewer technical defects. When capacity was needed we decided to add more capacity offshore.
3 months later…
The onshore team was working 50+ hours a week fixing defects from the offshore team. Depending on where you sat the requirements being handed over to the offshore team were inadequate or the offshore team couldn’t understand them. Luckily, the technical defects in production were still low - this was an internal problem.Another problem was that the managers (both in Chicago and India) were putting in 60+ hours re-planning work to accommodate schedule overruns and handle our constantly changing customer priorities. It became obvious that our previously successful model couldn't scale. Quickly, I was on my way to India in order to meet the new team members and find out why, initially, they had been so successful and why that success hadn’t lasted.
Welcome to India
The first couple of days I was there the senior manager was away. I was able to avoid the usual dog & pony show and just sit with the team. I quickly realized that there wasn’t anything fundamentally wrong with the team. They were motivated, a close knit team, hard workers, and had a great technical team lead. They even had a team moto, “Stealth, where challenging is sporting.” Due to the highly sensitive data the team was working with, they were in a secure “vault” which afforded few distractions from outside. These are all good signs and success factors. When I asked the team about what had changed they said that earlier they were updating existing models, but the new kind of work was different every time. It suddenly clicked. The factory model we created was based on recurring simple changes to an existing code base. This type of work could be optimized. Previously, each time a team member saw a new customer’s code based they lost some time learning it, but they only paid that cost once. The new type of work required some domain specific analysis to understand what the customer wanted and then some technical analysis to find an appropriate solution. This team that was 12 hours time shifted from the customers had very little opportunity to learn the customer’s domain and solve their specific problems. We needed a better model. But, first I needed to understand why they had ramped up so quickly compared to other offshore teams I had worked with in the past.
When I first got to the “vault” I noticed the team was doing something really unusual to me. At first I attributed this to cultural differences and didn’t consider this was possibly their greatest differentiator. With little manager oversight and a locked vault to hide what they were doing, they shared a single computer and worked on the same tasks together. I also noticed they met together before they wrote any code and discussed the approach and how to test it. Their technical team lead had just written a presentation on unit testing and was the local TDD police - making sure everybody wrote tests. Finally, as I started to get to know the team better, I noticed some of the QA testers were sitting with the developers while they wrote code. This was my introduction to paired programming and Test Driven Development. That evening I started to do some research into these practices which changed the way I approached software forever. I was ready to begin implementing these changes back in Chicago.
Next: How the factory retooled itself and reached high efficiency --->
Phase Two – A good problem to have – more work. Or…A learning experience.
Once the department was stable and was beginning to enjoy some level of regularity the leadership team and I were beginning to look like heroes. We had substantially changed the mix of the department without changing the overall budget and throughput. Our success was not a secret either. We started to receive weekly visits from managers in other departments wanting to talk to us and learn from our experience.
Good things rarely last: Unexpectedly, the external market environment changed and more work came - actually twice as much work. We needed to add a lot of capacity quickly. By this time the detailed metrics were beginning to pay off. My initial estimate based on other offshore teams I had worked with in the past was that the offshore team would be 2x – 3x slower than the local team for the first 6 months. However, this offshore team was almost as fast as my local team – but with fewer technical defects. When capacity was needed we decided to add more capacity offshore.
3 months later…
The onshore team was working 50+ hours a week fixing defects from the offshore team. Depending on where you sat the requirements being handed over to the offshore team were inadequate or the offshore team couldn’t understand them. Luckily, the technical defects in production were still low - this was an internal problem.Another problem was that the managers (both in Chicago and India) were putting in 60+ hours re-planning work to accommodate schedule overruns and handle our constantly changing customer priorities. It became obvious that our previously successful model couldn't scale. Quickly, I was on my way to India in order to meet the new team members and find out why, initially, they had been so successful and why that success hadn’t lasted.
Welcome to India
The first couple of days I was there the senior manager was away. I was able to avoid the usual dog & pony show and just sit with the team. I quickly realized that there wasn’t anything fundamentally wrong with the team. They were motivated, a close knit team, hard workers, and had a great technical team lead. They even had a team moto, “Stealth, where challenging is sporting.” Due to the highly sensitive data the team was working with, they were in a secure “vault” which afforded few distractions from outside. These are all good signs and success factors. When I asked the team about what had changed they said that earlier they were updating existing models, but the new kind of work was different every time. It suddenly clicked. The factory model we created was based on recurring simple changes to an existing code base. This type of work could be optimized. Previously, each time a team member saw a new customer’s code based they lost some time learning it, but they only paid that cost once. The new type of work required some domain specific analysis to understand what the customer wanted and then some technical analysis to find an appropriate solution. This team that was 12 hours time shifted from the customers had very little opportunity to learn the customer’s domain and solve their specific problems. We needed a better model. But, first I needed to understand why they had ramped up so quickly compared to other offshore teams I had worked with in the past.
When I first got to the “vault” I noticed the team was doing something really unusual to me. At first I attributed this to cultural differences and didn’t consider this was possibly their greatest differentiator. With little manager oversight and a locked vault to hide what they were doing, they shared a single computer and worked on the same tasks together. I also noticed they met together before they wrote any code and discussed the approach and how to test it. Their technical team lead had just written a presentation on unit testing and was the local TDD police - making sure everybody wrote tests. Finally, as I started to get to know the team better, I noticed some of the QA testers were sitting with the developers while they wrote code. This was my introduction to paired programming and Test Driven Development. That evening I started to do some research into these practices which changed the way I approached software forever. I was ready to begin implementing these changes back in Chicago.
Next: How the factory retooled itself and reached high efficiency --->
