Search This Blog

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 Testers2) We placed a team lead over each functional area3) We developed strict phase gates and criteria for work to be handed from one team to the next4) 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 --->

Popular posts from this blog

This is from a product I use daily. Who wrote this code and thought they were done? Who approved these two button styles next to one another?

I have this vision of a developer choosing a library that made their development life easier. I picture this code going straight into production use without review. Next, I picture the designer who works there rolling their eyes, checking out, and heading to LinkedIn to see what other opportunities exist.

I'm being unfairly harsh, but it makes me wonder what other sloppiness is happening inside this product.

Originally posted on ForeverCar Blog: https://blog.forevercar.com/an-easier-way-to-decide You probably have far more important priorities than taking the time to research vehicle service protection plans. That’s where we come in. When we set out to create the latest innovation to our consumer shopping platform, we vowed to keep it simple. If you are not shopping for vehicle service protection at forevercar.com, you are likely sitting across the desk from a loan officer at a bank or a finance manager at a dealership. There are a couple problems we've identified with this scenario: It’s bad timing. You are typically involved in a larger, more complex loan transaction involving your vehicle. Taking the necessary time to research the offering is impractical and highly unlikely to happen in that moment. That’s why most people pass on vehicle protection at the bank or dealership. Wrong amount of detail. There’s a lot to this. A service contract is full of important coverage details, financ…