PLAN FOR IMPROVISATION

This is the final post in my three part series (see parts one & two ) about creating a software factory. After some research I discovered that the practices I saw in India belonged to a larger group of practices named Agile software development . I wanted to start to using these practices locally with my team. Since I had a running factory, I couldn’t retool in mid cycle. I create a small pilot/swat team to try out the practices and find the best way to incorporate them into the team overall. The pilot team consisted of a designer/business analyst, developer, and a QA tester. After a short ramp up time this team was able to easily do lean design, test first / test driven development (TDD) and collective code ownership. Paired programming and continuous integration were going to be more tricky due to some corporate policies in place. The team was quite fast since the department’s heavy weight process didn’t impede them. Less defects from development meant less time in QA and faste...

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 mor...

A few years back, while managing a software development department, I developed an efficient software factory based on lean principals that directly supported a $2Billion per year business. It didn’t start out that way and took a couple of attempts to get it working well. When I acquired the department things seemed to be in chaos. • Developers would take on work directly from customers and disappear until it was promoted into production by the same developer • No load balancing of work among team members • Little communication with co-workers or management • Very little formal documentation existed for code that required periodic regulatory audits • No consistency between developers’ code • Therefore, nobody could work on each other’s code • Post-product release bugs were the norm, not the exception In truth much of the team had their heart in the right place. They had been working with some of our customers for 10+ years and were absolutely focused on custome...