Software Development Processes Out of Balance
I find a lot of software development environments out of balance. It only takes one area of the environment to be out of its element to throw off the entire software development environment.
Business Owners, Project Managers, Software Architects, Developers, Testers, and End Users all need to work together, but a common mistake made is that a lot of processes promote working together too much or not enough.
This unbalance can cause bottlenecks in the decision making process. There is a right time to come together to review progress on artifacts. To early in its development process can derail its progress by introducing unnecessary threads of thought on the subject. To late in the process can cause rework to have to take place that could have been avoided with earlier feedback.
Another dynamic that can have a terrible effect on the project is clearly defined roles that include who has the decision making power in a given situation. No one party should have the final say in all areas, but the party responsible for that area should always have the final say. In other words, beyond the cost of technical decisions, business owners and users should not have any authority when it comes to the final decisions on technology, the technical part of the team such as architects and developers make those decisions. Just as the business owners and users have the final say on business processes.
I have seen horrible results when business owners are allowed to make technical decisions. This usually happens because there is no qualified architect on the project to make proper technical decisions, and then defend the decisions when push comes to shove. In the absence of a qualified architect, I have seen way to many "technical" project managers try to make the technical decisions. More often than not, they are usually just "yes" men and women, because they do not really have the technical expertise to make the right decision.
The same out of balance issues can be found at a team level in an enterprise. An Enterprise Architecture team can very easily create complete chaos for an application development team, or have absolutely zero impact in an IT environment.
There is a lot of talk in the agility space about treating the team as if they have a collective ownership. This is often implemented as "everyone on the team does a little of everything, we are interchangeable".
As nice as that sounds, on decent size projects, it simply does not work. The context is off. The team succeeds and fails together, as one, but they are not clones.
If you apply the same line of thought to a football team odds are you won't be very effective if you try to make the team rotate in and out of all available positions. From center, to quarterback, to punter, to safety, to running back. The same is true on software teams. Developers skill sets must be taken into consideration when the process instance is being created.
Not only developers but every one on the team must be assigned a role, role responsibilities, and role authority. Architects do not tell business owners how to do there business, and business owners don't make technical decisions. Part of the technical decisions made by the architects are what will be delivered and when.
Business owners of course give input as far as their needs are concerned, but they do not decide how it is delivered (technically, not functionally) or when. They can give deadlines, but that just means the scope of what can be delivered will be changed to be able to meet the deadline. Project managers are like the referees, they make sure everyone is playing by the rules. I wish there were more project managers that understood that.
The overall message here is that for a process to be effective, the people in the process must be matched up with the right role, role responsibilities, and role authority depending on their qualifications. Boundaries are necessary to keep everyone in the role assigned. Not walls, boundaries. One of the most valuable lessons I have learned is to proof of concept my development team (more on that here). That way I can make adjustments to assignments and timelines after I have a clear understanding of their capabilities.
The only way to get a process back on track is to get someone involved that is qualified enough to shine some light on the issues, make suggestions on how to adjust the process, and to lead the clean up the messes. The entire team must be willing to be humble enough to accept the mistakes they have made. In other words, be ready to accept the truth that your baby really is ugly. Without that level of acceptance the only other option is to replace the team. That means anyone from the business owners to the developers (Project Managers, CIOs, Architects, Testers, etc.) who refuse to play ball. It often also includes a sit down with the customers to explain the new direction. Believe me when I say they won't be mad, they will be relieved to know their current pain is about to be reduced.
Business Owners, Project Managers, Software Architects, Developers, Testers, and End Users all need to work together, but a common mistake made is that a lot of processes promote working together too much or not enough.
This unbalance can cause bottlenecks in the decision making process. There is a right time to come together to review progress on artifacts. To early in its development process can derail its progress by introducing unnecessary threads of thought on the subject. To late in the process can cause rework to have to take place that could have been avoided with earlier feedback.
Another dynamic that can have a terrible effect on the project is clearly defined roles that include who has the decision making power in a given situation. No one party should have the final say in all areas, but the party responsible for that area should always have the final say. In other words, beyond the cost of technical decisions, business owners and users should not have any authority when it comes to the final decisions on technology, the technical part of the team such as architects and developers make those decisions. Just as the business owners and users have the final say on business processes.
I have seen horrible results when business owners are allowed to make technical decisions. This usually happens because there is no qualified architect on the project to make proper technical decisions, and then defend the decisions when push comes to shove. In the absence of a qualified architect, I have seen way to many "technical" project managers try to make the technical decisions. More often than not, they are usually just "yes" men and women, because they do not really have the technical expertise to make the right decision.
The same out of balance issues can be found at a team level in an enterprise. An Enterprise Architecture team can very easily create complete chaos for an application development team, or have absolutely zero impact in an IT environment.
There is a lot of talk in the agility space about treating the team as if they have a collective ownership. This is often implemented as "everyone on the team does a little of everything, we are interchangeable".
As nice as that sounds, on decent size projects, it simply does not work. The context is off. The team succeeds and fails together, as one, but they are not clones.
If you apply the same line of thought to a football team odds are you won't be very effective if you try to make the team rotate in and out of all available positions. From center, to quarterback, to punter, to safety, to running back. The same is true on software teams. Developers skill sets must be taken into consideration when the process instance is being created.
Not only developers but every one on the team must be assigned a role, role responsibilities, and role authority. Architects do not tell business owners how to do there business, and business owners don't make technical decisions. Part of the technical decisions made by the architects are what will be delivered and when.
Business owners of course give input as far as their needs are concerned, but they do not decide how it is delivered (technically, not functionally) or when. They can give deadlines, but that just means the scope of what can be delivered will be changed to be able to meet the deadline. Project managers are like the referees, they make sure everyone is playing by the rules. I wish there were more project managers that understood that.
The overall message here is that for a process to be effective, the people in the process must be matched up with the right role, role responsibilities, and role authority depending on their qualifications. Boundaries are necessary to keep everyone in the role assigned. Not walls, boundaries. One of the most valuable lessons I have learned is to proof of concept my development team (more on that here). That way I can make adjustments to assignments and timelines after I have a clear understanding of their capabilities.
The only way to get a process back on track is to get someone involved that is qualified enough to shine some light on the issues, make suggestions on how to adjust the process, and to lead the clean up the messes. The entire team must be willing to be humble enough to accept the mistakes they have made. In other words, be ready to accept the truth that your baby really is ugly. Without that level of acceptance the only other option is to replace the team. That means anyone from the business owners to the developers (Project Managers, CIOs, Architects, Testers, etc.) who refuse to play ball. It often also includes a sit down with the customers to explain the new direction. Believe me when I say they won't be mad, they will be relieved to know their current pain is about to be reduced.
posted by tadanderson at 10:30 AM
0 Comments:
Post a Comment
<< Home