Often in the context of managing software development and even the business around it, we tend to invest much more time and effort focusing on the process and mechanics of software delivery and much less on the content itself. As a consequence, there is insufficient investment into the product definition (or elaboration) process and resulting unpredictability with regards to the success of the product in the marketplace (or its alignment with customers' needs). While the organization focuses on the dates of delivery as the key milestones to achieve and celebrate, it fails to set specific expectations or measurement criteria with respect to what the product needs to achieve in the market or with customers. I have rarely seen processes or operational structures in place that can 'directly' facilitate such measurements or accountability.
Similarly, people are more apt to accept the failure of certain features in the marketplace ("customers and markets are changing too fast and product couldn't be delivered yesterday when we really needed it") than delays in shipment. The exec responsible for feature/content of the product will often have a clear idea of what they could easily sell in the market today and even support the need to invest more heavily in engineering to achieve the "immediate" delivery needs. But they are less clear or committal towards even the near-term future. In the absence of the sales team meeting its quarterly revenue goals, the typical response would be "if we had x features today, we could easily make the quota". Of course, when those features are delivered, the target changes to the next delivery date on the roadmap (or so it seems, at least to me :))
As all this attention and pressure diverts to the engineering team, it is easy for them to feel that the organization is not taking the responsibility for developing enough of a vision or strategy (or a commitment towards this strategy) against which to focus its execution tactics. The behavior of the sales and marketing teams is often viewed as 'deflection tactics' to keep the pressure off of them.
Recently, I came across a presentation by Phillip Armour titled "Of Zeppelins and Jet Planes" in which he contends that software is a knowledge store and not a product, therefore, software development needs to be managed as a knowledge acquisition process and not a product production process.
While Phillip appears to focus on development processes and methodologies, I can easily relate the argument to changes in operational and organizational tactics and behavior to place a deeper emphasis on the decisions regarding 'what to build' rather than the obsessive focus on 'how' to build it'.
This is not to suggest that there is always sufficient clarity with respect to the specific requirements that constitute a product definition or direction. As Phillip points out, this is becoming more and more of a moving target, therefore, our methods must allow us to deal with such a moving target. My point here is simply that this is something the organization must recognize and react to and not just the engineering team.
http://www.corvusintl.com/biograph.htm#Phillip%20Glen%20Armour
Sanjiva, Mallorca, Oct 21, 2005
Comments