Thursday, July 30, 2009

Maker's Schedule, Manager's Schedule

One of my colleagues at Pathfinder sent this out to the whole company. I have been on the manager's schedule since 2001. Now [more and more] I'm on the maker's schedule. I realized things were different, but I wasn't able to articulate it until now.

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

Photo Credits
Under a Creative Commons Attribution License

Thursday, July 9, 2009

The Death of Productivity

I don't often re-post from others' blogs. However, I came across a blog post worth passing on. In my career I have never understood working 60+ hours. Even in graduate school I'd work from 10am to 11pm - but only for 4 days a week! It worked for me. I was able to finish my Master's Degree (with thesis and research project) in less than a year. I was happy to be done and never thought about why things had gone so well. Thinking back, per task, I was not a hyper-productive worker. I was constantly suppressing the Shiny Object Syndrome. Apparently my secret was that less is more. That being said, Jeff Shutherland had an interesting post based on experience from a venture capital firm about company who work long hours and the results. He call s it The Maxwell Curve. Take a look:

The Maxwell Curve: Getting more production by working less!