Tuesday, July 14, 2009
Looking Back: Creating a Software Factory – Part 1
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 customer satisfaction. However, the frequent production bugs were too much for the company to bear and requested that I make significant improvements – FAST. At the same time the company was adopting a heavily process driven methodology which required a Command and Control management approach. For example, part of my given goals for the first year was to create an elaborate estimation model for my team so that we could become more predictable.
Phase One - Our first attempt
My team leads and I began to follow “proven” management techniques:
1) We broke the department into three functional teams: Business Analysts, Developers, QA Testers
2) We placed a team lead over each functional area
3) We developed strict phase gates and criteria for work to be handed from one team to the next
4) We implemented detailed metrics collection on all tasks people worked on.
Within a few months the individual team members were actually moving slower than before. Knowing what I know now, this was quite predictable. I had restricted communication, took away individual ownership of the work, took away incentives for success, placed a heavy process load on a nimble team, and was optimizing for process adherence over meeting customers needs.
To be fair: Part of the reason I implemented the strict phase gates and divisions between teams was that we were replacing a number of local consultants with an offshore developer team. Things were not a total failure. Most individuals were moving slower than before, but we could now quickly bring on new offshore developers. The department’s cost hadn’t increased and throughput hadn’t suffered. Slow and steady wins the race? We had moved labor into a cheaper market. Perhaps adding more, slower, labor would increase the overall department’s bandwidth?
Next: A good problem to have – more work. How we tried to increase throughput --->