The big constraint in Development and how it can bring down a team
I always consider the primary constraint in software development to be time. While technically this constraint could be considered a function of money, it is difficult for a developer to assert direct influence over budget. Most organisations require developers to go quite high up the chain of influence in order to try affect the proportion of budget development have access to. Supply and demand factors for the product that development are supplying is difficult for them to directly influence, in most corporate structures sales and marketing are the real influencers of this factor. Yes they rely on the quality of product that development provide, but it is unlikely that and improvement in the product quality will have an equivalent impact on sales. The ability of sales and marketing to reach new customers and alter demand is a much more influential factor.
It is one of the great features of software development that you can essentially do anything the customer asks for, but only if you have enough time. Developers realise how precious this commodity is. There will always be bugs in the product that can be fixed, there will always be ways you can enhance the existing features and there will always be brand new features which can benefit the customer. As your team is not infinite in size and your system resources are finite you are always unable to write super efficient bug free code covering every desired feature.
All the time a developer is working on a given section of work they will be performing cost benefit decisions, how much time do they spend optimising their changes for performance, how much time do they spend reviewing/testing it for bugs or coding defensively against them. They weigh these factors up against what they perceive as the risks of the code and against the relative importance of the change.
Software developers have normally entered the field due to a natural aptitude for logic. Logical reasoning will commonly be a very important to how they perceive the world. This is critical in understanding how best to manage a team of developers. A manager must be able to provide logical reasoning for the decisions he makes and more importantly communicate these reasons effectively to their team.
The development team will often know what processes appear to be impeding their time, they will be aware of many of the issues the product they are working on, and have a good idea of how long each will take to fix. They will probably even be able to provide you with an ordered list based on their cost benefit analysis of what should be done. Now if that list tallies with the managers scheduling plans then the team will be functioning smoothly, the developers will naturally respect the managers decisions. However, if that list does not tally then there is potential for a break down within the team dynamic.
The manager will need to explain their priority order clearly and provide rational explanations for the differences in opinion. I have not yet been in a team where the developer has not altered their opinion in the face of rational argument. It is vital that the manager should be open to change in the same way. If the manager cannot provide a consistent rational argument to influence a change in opinion of the developer they should strongly consider if their ideas are the best way forward. If the decision making is obviously particularly contentious then it is important for the manager to review their decisions at the end of the process and if they were wrong admit to this, if they were right they should provide this evidence to the team. Everyone has some level of ego so obviously this should not be presented in a gloating manner, however, as I have stated developers tend to work from a logical stand point, if the manager adequately proves their decision making process was effective then the developer will be able to maintain their respect and the team should continue to function well.
The more the developers see the decisions of their manager as irrational the more respect they will lose, the lose of respect will lead to reduced communication and a drop in the effectiveness of the team.
Developers normally want to release the best products possible and realise that the product quality and breadth is influenced by the time available to code any seemingly irrational scheduling or processes eat into this time and are seen by the developer as barriers thrown up to stop them producing a great product. I have not spoken to a developer yet who does not agree with the agile manifesto and I believe it is clear that this document was borne out of experiencing frustratingly irrational management processes that the developers saw as restricting the precious resource of time.
It is one of the great features of software development that you can essentially do anything the customer asks for, but only if you have enough time. Developers realise how precious this commodity is. There will always be bugs in the product that can be fixed, there will always be ways you can enhance the existing features and there will always be brand new features which can benefit the customer. As your team is not infinite in size and your system resources are finite you are always unable to write super efficient bug free code covering every desired feature.
All the time a developer is working on a given section of work they will be performing cost benefit decisions, how much time do they spend optimising their changes for performance, how much time do they spend reviewing/testing it for bugs or coding defensively against them. They weigh these factors up against what they perceive as the risks of the code and against the relative importance of the change.
Software developers have normally entered the field due to a natural aptitude for logic. Logical reasoning will commonly be a very important to how they perceive the world. This is critical in understanding how best to manage a team of developers. A manager must be able to provide logical reasoning for the decisions he makes and more importantly communicate these reasons effectively to their team.
The development team will often know what processes appear to be impeding their time, they will be aware of many of the issues the product they are working on, and have a good idea of how long each will take to fix. They will probably even be able to provide you with an ordered list based on their cost benefit analysis of what should be done. Now if that list tallies with the managers scheduling plans then the team will be functioning smoothly, the developers will naturally respect the managers decisions. However, if that list does not tally then there is potential for a break down within the team dynamic.
The manager will need to explain their priority order clearly and provide rational explanations for the differences in opinion. I have not yet been in a team where the developer has not altered their opinion in the face of rational argument. It is vital that the manager should be open to change in the same way. If the manager cannot provide a consistent rational argument to influence a change in opinion of the developer they should strongly consider if their ideas are the best way forward. If the decision making is obviously particularly contentious then it is important for the manager to review their decisions at the end of the process and if they were wrong admit to this, if they were right they should provide this evidence to the team. Everyone has some level of ego so obviously this should not be presented in a gloating manner, however, as I have stated developers tend to work from a logical stand point, if the manager adequately proves their decision making process was effective then the developer will be able to maintain their respect and the team should continue to function well.
The more the developers see the decisions of their manager as irrational the more respect they will lose, the lose of respect will lead to reduced communication and a drop in the effectiveness of the team.
Developers normally want to release the best products possible and realise that the product quality and breadth is influenced by the time available to code any seemingly irrational scheduling or processes eat into this time and are seen by the developer as barriers thrown up to stop them producing a great product. I have not spoken to a developer yet who does not agree with the agile manifesto and I believe it is clear that this document was borne out of experiencing frustratingly irrational management processes that the developers saw as restricting the precious resource of time.
Comments