Metrics and Process Improvement

It's not uncommon to hear that managers are interested in improving productivity in their teams, metrics-wise this means that the indicators that they're looking at, should start to show bigger and better numbers.
Metrics are commonly applied for measuring processes and they in turn reflect internal team organization policies and practices. Following this rationale, managers should start improving processes if they want to have better metrics. But what if processes are something that you can't measure and consequently improve?
Process Definition
According to Wikipedia a process in engineering is "engineering which is collaborative and concerned with completing a project as a whole; or, in general, a set of transformations of input elements into products with specific properties, characterized by transformation parameters".
Processes in Manufacturing
This definition stresses the point that a process implies a set of transformations; further, a process in manufacturing has some interesting characteristics, to name a few:

1. It's standardized, meaning that it has a set of predefined set of steps that has to be followed by workers. Conversely, deviation from the standard produces defects
2. 
   It's repetitive, this is key in factories and shop floors where journeymen perform the same tasks again and again. Perfection comes from repetition, and seniority is based on the number of times that journeyman executed tasks. Repetitive tasks are also great for passing knowledge from journeymen to apprentices, and of course also great for foremen supervising work in floor shops. However, repetition cuts creativity and innovation.
3. 
   It can be extrapolated, the X process in the Y factory can be documented in a recipe format and then sold for use in the Z factory. This rationale of course doesn't consider that the same process in X and Z factories will be implemented by different teams. Again, focus in the process disregarding the human factor.

Process in Services
Processes in service industries like fast food franchises or banks have humans that follow some rules and procedures to provide services to other humans; however, some characteristics of this interaction can be similar to what happens in manufacturing like:

1. It's standardized, there are standards for food elaboration, quality, and service time. Franchises are especially prone to set standards but even the old mom-and-pop type of restaurants has standards that they employees have to meet.
2. It's repetitive, unless you decide to go to a very expensive restaurant, you'll be almost all the time getting the same food-good or bad no matter-that comes out of the same process that restaurant employees followed to prepare it.
3. It can be extrapolated, otherwise there won't be fast food franchises that can offer the same product with the same quality-again, good or bad-in different parts or the world.
   

The Processes in the Software Industry Dilemma
By this time you might have realized that manufacturing or services processes can't be directly translated to software industry, some reasons are:

1. The software development industry requires a high degree of innovation and creativity. This brings a lot of variability over processes; for instance, a test case can be executed by two different quality engineers with different results, one might have executed the test case in two hours and finding no bugs whereas the other might have execute it in half the time and with high severity bugs reported. Is the first quality engineer less effective than the second? Of course not, many factors like expertise, product familiarity, or technology knowledge make the difference. More importantly, the human factor plays here a more crucial role.
2. Work is essentially not repetitive, maybe some parts of testing are but development is certainly not. Programming languages have a very few and well define set of structures like repetition, bifurcation, and comments. However, these are like building blocks that you can use in an uncountable number of ways to achieve the same results. Of course that there are good practices and rules to follow, but human creativity certainly is more valuable than repetition at least in this line of business.
3. Recipes don't work anymore, you can't extrapolate processes from one development team to another because there are too many variables related to people that you can't control. For instance, you can't expect to have the same degree of motivation and commitment in two different teams, again soft-factors like those are what will prevent process extrapolation and consequently standardization.

So, seems like old project management techniques based on process standardization are no valid for this industry eh? Even more importantly, if you can't standardize process how could you improve metrics? I guess the question should be, is it really worth the try to look for processes and metrics applicable to the software industry? My short answer would be no, my long answer you be that we could look for a different type of metrics originated from agile processes.
Scrum Coming to Rescue
What Scrum can bring to help solve the dilemma? For starters, it doesn't prescribe a process/metrics measurement approach which I've described before simply won't be applicable in this industry.
Secondly, Scrum brings a shift in focus from control to empowerment, from contract to collaboration, and from documentation to code. This highly pragmatic paradigm requires many things for work, things like self-discipline and upper-management support, but undoubtedly empowering teams would be the cornerstone.
Just imagine having teams than can create their own process based on their needs; that can discard or modify process that are not longer applicable, and that can be able to achieve impressive results with no formal process in place. For some this might sound like project manager's worst nightmare, but for Scrum purist this could be heaven.
Self-directed teams are essentially highly committed and innovative-they have to be, otherwise they shouldn't have choose the Scrum way-that work at a sustainable phase and creates on the fly whatever process they need. Of course processes come from consensus and this in time generates internal commitment and motivation. In time this produces hyper-productive teams with competitive individuals looking for challenging stuff to work on the next Sprint.