Responsibility in Software Development Teams
Responsibility in Software Development Teams
In this article, we'll review some strategies for allocating responsibilities in large teams. Most Project Managers, in charge of developing a large application or system, have to coordinate several teams responsible for developing certain modules of the application. Therefore it is important to develop work flows that do no overlap in terms of functionality.
In this article, we'll review some strategies for allocating responsibilities in large teams. Most Project Managers, in charge of developing a large application or system, have to coordinate several teams responsible for developing certain modules of the application. Therefore it is important to develop work flows that do no overlap in terms of functionality.
So in this article we will be looking at creating an organizational structure that will ensure the highest probability of success for the project. Keep in mind that the structure is not the only element that contributes to a project’s success.
Before we start to talk about "who, what and when" must provide reports and how communication flows will be organized let us first consider the "classics of the genre" - the most frequent allocations and assignments of responsibilities. Normally it looks like the figure below (Java and Oracle are taken as an example, but you can replace it with any other technology)
Job titles may, of course, vary.
Sometimes you have a very unique combination, like the one below:
I am sure many of you know about these types of structures. Perhaps you are working in one of these right now. Are they effective? Do they serve their function and help managers finish the project faster and more efficiently, with the least possible expenditure of resources? If you are not in a management position, but you are planning on becoming a manager, you're probably also wondering if these structures are effective and if not what could be done.
Consider the examples above.
What is the purpose of these roles and the department as a whole? In addition to making money (depending on the grade level) there is only one goal - to make the product on time, within budget while respecting the required level of functionality and quality.
Now look at the charts above. Do they allow the project to be released on time, with the required functionalities and a high degree of quality? I strongly doubt it. Why do I have these doubts? There are several reasons.
The first reason is the fact that the areas of responsibilities are quite vague. In the diagram above we have difficulties in seeing who is responsible for the timing, scope and quality of the release / project / product? You can say that everyone in the top positions is responsible. And this is true. And if you go lower? Is the Team Lead responsible for the release? Looking at the two schemes above we can’t really be sure.
The second reason relates to the software development lifecycle. For example, let’s say that the analysts have completed the requirements and passed them on to the development team (Analyst Lead > Dev Lead). Developers have specific questions, and they return the documents for revision (Dev Lead >Analyst Lead). The revision is finalized and handed over to the developers (Analyst Lead > Dev Lead). Again, there are questions between the two teams (Dev Lead -> Analyst Lead). And this can continue for a long time. After a while we begin the development process (I am deliberately simplifying this to make my point). In parallel with the development process testers have started to write test cases. At the end of the development we move to testing of code (Dev Lead > QA Lead). Bugs are discovered (QA Lead > Dev Lead). After this feedback the process starts again and other bugs are discovered (Dev Lead -> QA Lead). And so the process continues.
If at any point in this process the leader wants to know the status of the release (for example, the percentage of readiness) let say it appears that our code 90% ready. And then somebody will ask why deadlines will have to be moved and nobody can respond because it’s nobody's fault. Testers did their jobs. Developers developed the products and fixed all bugs that were found. They all wanted to release a good product. But the ball is constantly being transferred between developers and testers, and there is no end in sight. This same situation can also be found between other entities (analysts - developers, developers - developers).
And most importantly the only person that is responsible here is the leader. But he can’t always act as a referee because there are so many development streams and tasks. The key issue here that must be solved are the areas of responsibility.
So, we need to make the Team Lead truly become a team leader. After all, in the examples above, he was anything else but a team lead. He was a Development Lead, a QA Lead, an Analyst Lead etc. But he wasn’t responsible for the full life cycle – from developing specifications through development and all the way up to delivery after a successful testing period. We have to make sure that the Team Lead is responsible for the entire software development lifecycle - only then will he be able to ensure that the project is finished on time, with the right amount of functionality and the desired level of quality.
Stay tuned for our second part of the article where we will look at strategies to increase the level of responsibility and quality in your project.
So in this article we will be looking at creating an organizational structure that will ensure the highest probability of success for the project. Keep in mind that the structure is not the only element that contributes to a project’s success.
Before we start to talk about "who, what and when" must provide reports and how communication flows will be organized let us first consider the "classics of the genre" - the most frequent allocations and assignments of responsibilities. Normally it looks like the figure below (Java and Oracle are taken as an example, but you can replace it with any other technology)
Job titles may, of course, vary.
Sometimes you have a very unique combination, like the one below:
I am sure many of you know about these types of structures. Perhaps you are working in one of these right now. Are they effective? Do they serve their function and help managers finish the project faster and more efficiently, with the least possible expenditure of resources? If you are not in a management position, but you are planning on becoming a manager, you're probably also wondering if these structures are effective and if not what could be done.
Consider the examples above.
What is the purpose of these roles and the department as a whole? In addition to making money (depending on the grade level) there is only one goal - to make the product on time, within budget while respecting the required level of functionality and quality.
Now look at the charts above. Do they allow the project to be released on time, with the required functionalities and a high degree of quality? I strongly doubt it. Why do I have these doubts? There are several reasons.
The first reason is the fact that the areas of responsibilities are quite vague. In the diagram above we have difficulties in seeing who is responsible for the timing, scope and quality of the release / project / product? You can say that everyone in the top positions is responsible. And this is true. And if you go lower? Is the Team Lead responsible for the release? Looking at the two schemes above we can’t really be sure.
The second reason relates to the software development lifecycle. For example, let’s say that the analysts have completed the requirements and passed them on to the development team (Analyst Lead > Dev Lead). Developers have specific questions, and they return the documents for revision (Dev Lead >Analyst Lead). The revision is finalized and handed over to the developers (Analyst Lead > Dev Lead). Again, there are questions between the two teams (Dev Lead -> Analyst Lead). And this can continue for a long time. After a while we begin the development process (I am deliberately simplifying this to make my point). In parallel with the development process testers have started to write test cases. At the end of the development we move to testing of code (Dev Lead > QA Lead). Bugs are discovered (QA Lead > Dev Lead). After this feedback the process starts again and other bugs are discovered (Dev Lead -> QA Lead). And so the process continues.
If at any point in this process the leader wants to know the status of the release (for example, the percentage of readiness) let say it appears that our code 90% ready. And then somebody will ask why deadlines will have to be moved and nobody can respond because it’s nobody's fault. Testers did their jobs. Developers developed the products and fixed all bugs that were found. They all wanted to release a good product. But the ball is constantly being transferred between developers and testers, and there is no end in sight. This same situation can also be found between other entities (analysts - developers, developers - developers).
And most importantly the only person that is responsible here is the leader. But he can’t always act as a referee because there are so many development streams and tasks. The key issue here that must be solved are the areas of responsibility.
So, we need to make the Team Lead truly become a team leader. After all, in the examples above, he was anything else but a team lead. He was a Development Lead, a QA Lead, an Analyst Lead etc. But he wasn’t responsible for the full life cycle – from developing specifications through development and all the way up to delivery after a successful testing period. We have to make sure that the Team Lead is responsible for the entire software development lifecycle - only then will he be able to ensure that the project is finished on time, with the right amount of functionality and the desired level of quality.
Stay tuned for our second part of the article where we will look at strategies to increase the level of responsibility and quality in your project.