This afternoon, we had our weekly staff meeting. The first half of the meeting was a debrief of our team leads experience in a week long Agile training class. The basic message that I got was the “Agile was cool but too hard for us to implement”. They broke down all of the elements of Agile and walked through the pro’s and con’s. As we all know from Frederick Moore’s “Mythical Man Month”, that there is no process silver bullet. Yet, why do I continue to encounter engineering managers pushing Agile without even knowing the team or the problems. A team software process is not something that can be picked up off a bookshelf. It will ebb and flow depending on the dynamics of the team. For example …

• Is the team large or small?
• What level of expertise are the engineers?
• Is the team co-located in a single area?
• Is the team at professional level that they have the tools in place to support the process?
• Is the team dealing with a lot of legacy code?

The software process you choose is about having the right balance. Do you need to follow Scrum or Extreme Programming to the exact tee in order to gain its benefits? I don’t think so. I tend to think of software processes as a list of best practices. Depending on the dynamics of the team, you can pick and choose best practices to find the optimal productivity and predictability.

The second half of the meeting we had a gentlemen from our support team talk about the state of the world. One of the messages that came forth was how we exceeded all expectations in regards to customer responsiveness and R&D involvement. My first thought was that of pride, but then I realized that maybe this isn’t a good thing. What cost did this extra support come from? In my mind, engineering organizations can be too responsive to the needs of customers. This continuous “feature for feature, fire fighting” takes away from the a development organizations ability to execute on more strategic and/or innovative investments. It’s the role of the director to find the right balance.

This balance also applies to other areas such as ….

• Quality — an engineering director should was not rely on the pure numbers coming from QA and needs to understand the “true quality” of a product. A delicate balancing act must be played to fix the right number of bugs to that make the customers happy but not spend 4 man months on lower priority defects.
• Risk — a project with no risk, is an inefficient project. There needs to be a fine balance of all of the risks to guide the project to a successful delivery.
• Pain — teams need to be pushed to perform at 200% of their capacity. I often tell my new managers that its ok to feel uncomfortable at work (You know what I mean). It means that you are pushing yourself and learning. A good engineering director balances the team past their comfort zone without leading them onto a death march. Sometimes, incurring pain in some areas makes another area better.

And yes, V8 for all engineering managers!