About Inconsistencies in Management Decisions
We certainly all agree that management is a critical function in an organization.
In certain cicumstances, a bad manager can deadly hurt a plenty alive project, whereas a good one should be able get a tough team back on track by leading them to a strong vision and finely tuning project priorities.
At first, I was tempted to think that healthy agile teams could overcome the drawback of bad management: as a matter of fact, they are supposed to build a strong vision of their accomplishment with the help of a committed customer representative, and rely on their collective intelligence for ensuring quality in the long-run, aren't they?
This of course turned out to be an idealistic point of view. Over the years, my experience has finally convinced me that agile teams also need a strong support from the management for realizing their full potential.
However, this is hardly the case in big companies such as the one I am currently working for... even when the middle management is committed to most of the XP values and principles, it is drowned in an organisation that has decades of old rigid habits and slows down most opportunities we have to be more efficient.
Badly enough, this kind of situation often leads to inconsistent management decisions.
Let me ilustrate this through a short story, in which I suspect the middle-management is unwillingly weakening a strong XP team, by striving to follow the corporate line.
We currently form a 6 person-XP team that has proven its accountability over the 3 last years, by regularly delivering a high-quality product (low defect rate and high end-user satisfaction) with continuous changing requirements, despite a rigid organisation. The values and practices are often reassessed to ensure an agile spirit and avoid the team getting into a lethal rut.
The project has now reached a mature age, and could soon be given a central place in the corporation solution. Based on this fact, our manager wants to be supportive of the agile method and has got the idea to bring application testers closer to the design team, acting as acceptance test writers.
We all felt it was an awesome initiative, that would help us going still further in controlling the product quality; furthermore it looks like we are not far from tests being produced as contractual specifications. How wonderful! This would be a great achievement in our path to a full XP project!
A few persons have thus recently been placed in charge of ensuring the quality of the delivered application.
On this purpose, they have been given two roles :
- detecting hidden defects as soon as possible before the next delivery (a positive feedback in accordance with agility)
- continuing to test the product after that same delivery, and assigning defect notifications to the team.
At first sight, these two assignments look fully compatible with each other.
However, when delving into the details, we could foresee one major reason for their inadequacy: in this system, testers positions will only be justified by the defect rate found in the second assignment. In other words, from their point of view, an eventual promotion would depend upon the number of defects found after the delivery. This is absolutely not the system promoted by Agile!
Unfortunately, this organization only rely on externally visible metrics, and is blind to the internal optimizations that we could develop within the teams.
On my opinion, this example constitutes some evidence of the high difficulty for a well-intentioned manager to help an agile team in a rigid environment: the change supposed to help our day-to-day work has created in reality a whole new set of unforeseen problems.
I want however to conclude this post on an optimistic note. Middle management are the heart of big companies and we assist nowadays to a change of their mindset.
These clumsy decisions are evidence they try to push their organisation in a new direction. It requires time and determination to drive big organisations towards a new set of values.
In certain cicumstances, a bad manager can deadly hurt a plenty alive project, whereas a good one should be able get a tough team back on track by leading them to a strong vision and finely tuning project priorities.
At first, I was tempted to think that healthy agile teams could overcome the drawback of bad management: as a matter of fact, they are supposed to build a strong vision of their accomplishment with the help of a committed customer representative, and rely on their collective intelligence for ensuring quality in the long-run, aren't they?
This of course turned out to be an idealistic point of view. Over the years, my experience has finally convinced me that agile teams also need a strong support from the management for realizing their full potential.
However, this is hardly the case in big companies such as the one I am currently working for... even when the middle management is committed to most of the XP values and principles, it is drowned in an organisation that has decades of old rigid habits and slows down most opportunities we have to be more efficient.
Badly enough, this kind of situation often leads to inconsistent management decisions.
Let me ilustrate this through a short story, in which I suspect the middle-management is unwillingly weakening a strong XP team, by striving to follow the corporate line.
We currently form a 6 person-XP team that has proven its accountability over the 3 last years, by regularly delivering a high-quality product (low defect rate and high end-user satisfaction) with continuous changing requirements, despite a rigid organisation. The values and practices are often reassessed to ensure an agile spirit and avoid the team getting into a lethal rut.
The project has now reached a mature age, and could soon be given a central place in the corporation solution. Based on this fact, our manager wants to be supportive of the agile method and has got the idea to bring application testers closer to the design team, acting as acceptance test writers.
We all felt it was an awesome initiative, that would help us going still further in controlling the product quality; furthermore it looks like we are not far from tests being produced as contractual specifications. How wonderful! This would be a great achievement in our path to a full XP project!
A few persons have thus recently been placed in charge of ensuring the quality of the delivered application.
On this purpose, they have been given two roles :
- detecting hidden defects as soon as possible before the next delivery (a positive feedback in accordance with agility)
- continuing to test the product after that same delivery, and assigning defect notifications to the team.
At first sight, these two assignments look fully compatible with each other.
However, when delving into the details, we could foresee one major reason for their inadequacy: in this system, testers positions will only be justified by the defect rate found in the second assignment. In other words, from their point of view, an eventual promotion would depend upon the number of defects found after the delivery. This is absolutely not the system promoted by Agile!
Unfortunately, this organization only rely on externally visible metrics, and is blind to the internal optimizations that we could develop within the teams.
On my opinion, this example constitutes some evidence of the high difficulty for a well-intentioned manager to help an agile team in a rigid environment: the change supposed to help our day-to-day work has created in reality a whole new set of unforeseen problems.
I want however to conclude this post on an optimistic note. Middle management are the heart of big companies and we assist nowadays to a change of their mindset.
These clumsy decisions are evidence they try to push their organisation in a new direction. It requires time and determination to drive big organisations towards a new set of values.
posted by Pascal at 2:25 PM
0 comments
links to this post
