Development Methodology as a Business Strategy

Although it may not be trendy, it is still often the case that people say that they follow an Agile methodology, but usually explain it in terms of how the product development process happens in isolation of the rest of the business.

Regardless of the flavour of agile, the implementation of the processes should - indeed, must - align with the business strategy. Without some alignment, there is nothing at C-level to indicate that the engineering department is effective, except in terms of project success rate or marketing meeting its goals. To have a measure of effectiveness within an engineering department, then there has to be something measurable at enough detail to make predictions, set goals, compare, & assess.

Agile processes generally provide a framework for being more effective at developing product. The processes themselves need to allow for reflection & adaptability in an iterative sense - continuous improvement. Even if board-level decisions are not agile, the benefits of agile processes can - & should - lead directly into corporate strategy.

To give a concrete example, the cost of an engineering department is usually considered to be linear against resources. However, it is "well known" that a more effective team produces better product (cheaper to maintain & support, easier/cheaper to extend, faster to react to market needs). If there is a company strategy for producing better product (with a goal of lowering maintenance costs), then the process for achieving this - improving the effectiveness of the development team - needs measurable goals.

Candidates for measures - from a product development perspective - might be:

• amount of time spent on rework (cost of problems found in testing)
• amount of time spent on re-implementation (problems found n the field - more expensive)
• estimation accuracy (for features or projects) - not just coming under budget
• velocity - the amount of work the team can do in a time period
• technical debt (the likelihood that something could go horribly wrong over time)
• alignment of skills to needs (training, staff turnover)
• false economies (where a cheaper option costs more because of knock-on effects)

Some of these are traditional measures, but some use a language that is often outside of the understanding of board members (or even C-level).

Now we can understand why a strategy is never applied to a development methodology - it takes a lot of effort to translate the language used in engineering into the language used in business strategy. It is not impossible, it's just the few people are doing it.

The first step is always the hardest. A board has to have goals that cover both outward-facing measures (P&L) & inward-facing (team effectiveness), & these have to be aligned by strategies that inter-relate & support each other.