When I see explanations of product development failure that blame others, I try to look beyond the regrettable outcome of the past project. I delight in finding clues about the likely outcome of the next project.
The counterweight to a perceived lack of 'management understanding and support'
One of the common factors cited by individual contributors when projects have failed is the lack of "management understanding and support." That is regrettable.
What about the next project? What can you do to shape future projects for a more favorable assessment?
Here is some vital background:
- Recognize that managers don't value your burn down charts, story points, standup meetings, or most of the agile rituals that are practices of an Agile development team. They are artifacts of your process. They are proxies for value.
- Most managers are not going to be telling their manager friends about your agile artifacts. There will not be a favorable discussion about your agile process at their home or at the gym.
- Most managers tend to value their favorite metrics. These tend to be the metrics valued by MBAs and accountants and sales managers and business development executives. Some of these may be called vanity metrics.
- Asking for more "understanding and support" is not going to move the needle. The same is true for most discussions about improving company culture. Don't waste your time asking for more respect for your dogma. Promises relating to these items are transitory.
- Debates about "when is the product going to be ready" and "fast-tracking the project" and "delegating responsibilities" take up a lot of time and don't produce much value.
The appropriate goals are to find the mutual items of value and deliver value.
Here are a few suggestions to shape the way managers behave:
- Discover the language the resonates with managers and translate your conversations to use the appropriate management jargon when your are in the management boardroom. Since the project exists to provide value to some customer segment, encourage discussions that incorporate value related to customers which results in aggregate metrics like the quarterly and annual numbers that drive manager’s behavior.
- If there is a request for some report or attendance at a long meeting that is not going to have a favorable impact on delivering value, challenge it. Ask for clarification. Recognize the detrimental results of interruptions and take active measures to minimize intrusions from anyone not adding value to the project.
Here are a few suggestions for individual contributors:
- Minimize the time you spend complaining about a lack of management understanding and support.
- Invest more time in becoming a better developer. Become faster and better at recognizing what is valuable to the project. Invest in improving the effectiveness of cooperation and collaboration with others contributing to the value of the project. Invest in ways to reduce the time it takes for a new developer to be an effective and efficient contributor.
- Insist on the time you need for uninterrupted concentration for certain types of work.
- Invest to make the next project better than the current one.
- Do NOT babble about being 'more agile.'
- Insist on disintermediation. Let everyone contributing to the development effort be able to see how their activity relates to value. Don't acquiesce. Do not accept an assignment if the person delegating it to you can not explain how it will add value to the project.
- Find mentors and peers that will monitor your progress to become more awesome as a valuable, motivated development professional.
Strive to be more awesome
Produce recognizable value because when you do that, you will be recognized as a person that everyone wants to be on their next project team. Instead of trying to change the management culture directly, become a more awesome developer. You will be a happier developer.