I wrote this article for the company's blog where I'm working now and I want to share it with you in my blog too.
Although there are different variants of how to form teams in the software industry, the most common in companies is to have a application development team responsible for creating software and a QA (quality assurance) team responsible for testing that software.
I started in the software world about 10 years ago, by that time, I worked on researching products, and on identifying and developing requirements to implement in the software.
Due to my responsibilities, I should be in constant communication with the development team and the quality assurance team. From the beginning you could see a strong rivalry between them, such as being fanatics of different baseball teams (New York Yankees vs Boston Red Sox) or soccer teams (Real Madrid vs Barcelona) in the final tournament.
Due to this rivality, the actions of one harmed the other, that is, if the quality assurance team found issues in the software, that meant that the development team did a bad job (point to QA), on the other hand any reason was good to put an issue "Rejected" or "Can't Reproduce", a drafting error, missing a step, etc. (Point to Development).
I also witnessed and participated in endless meetings where they fought fiercely with all kinds of arguments on who was right about the implementation of a requirement or a detected issue. If an issue in production was detected it was very easy to blame the "opposite" team, one said "QA didn't test well", the others said "Development did it wrong" or "delivered late." It was very simple to discredit each other's work and to place the responsibility on the others.
Over time they began to show miscommunication between equipment, failures in delivery times, low quality application development, and to try to solve these problems, the company began experimenting in search of solutions. Among other things, additional hierarchical levels were added to the teams, processes were restructured, methodological changes, etc. Which in my opinion resulted in very little success.
During my career I have worked with many teams, with different structures and different products, however in a major or minor way that rivalry has always been present, and in fact this story is the common denominator of many companies.
Later in the company where I worked it was decided that we should use agile methodologies.
We would start to work using the Scrum methodology which was not at all easy, you have to change many paradigms, and to be honest I didn't think it would work, although I had to take the leap, the order to use Scrum came from above.
As we progressed with the implementation of the methodology I realized that the status quo that was so hard to leave, was gradually diluted until it finally disappeared, but, Why did this happen?
The fact of having meetings every day and that all team members were involved, did that each of the “teams” members gradually understood and internalize that we were working towards the same goal.
It allowed us to understand and appreciate the work of our colleagues and that each of the team members have specific skills that enable them to cope with a greater dexterity certain types of tasks.
This created a work environment where it was understood that the work and effort of each one is reflected in the developed software.
Due to that we are humans, we make mistakes, there will be things we do not know, we'll have problems unrelated to our work, so it's necessary to help each other to achieve the project goal.
It is an indispensable requirement that all team members are aware of the needs of a product and actively participate in the process to achieve that goal. The only way to achieve this is with a very high level of communication.
Over time, developers no longer felt attacked by the people from QA, they understood that everything was just meant to improve. The QA people no longer disqualifies the work that was done and they are now focused on improving the software, improving the application development process and no team member evade their responsibilities.
As the months passed, the team became in a unique and well established team that achieved:
Work delivered with high quality
More work was completed within the same timeframe.
The nighters to achieve deliveries were minimized.
People leave the office in time to share with their families and live their lives.
A harmonious and solidarity work environment.
Although this seems like a difficult story to believe, this is achieved by applying agile methodologies, because these frameworks have a focus on communication and certain techniques that enhance interpersonal relationships and promotes this progress.
If you want to read other articles of my coworkers you can find them here http://www.teravisiontech.com/blog/
Although there are different variants of how to form teams in the software industry, the most common in companies is to have a application development team responsible for creating software and a QA (quality assurance) team responsible for testing that software.
I started in the software world about 10 years ago, by that time, I worked on researching products, and on identifying and developing requirements to implement in the software.
Due to my responsibilities, I should be in constant communication with the development team and the quality assurance team. From the beginning you could see a strong rivalry between them, such as being fanatics of different baseball teams (New York Yankees vs Boston Red Sox) or soccer teams (Real Madrid vs Barcelona) in the final tournament.
Due to this rivality, the actions of one harmed the other, that is, if the quality assurance team found issues in the software, that meant that the development team did a bad job (point to QA), on the other hand any reason was good to put an issue "Rejected" or "Can't Reproduce", a drafting error, missing a step, etc. (Point to Development).
I also witnessed and participated in endless meetings where they fought fiercely with all kinds of arguments on who was right about the implementation of a requirement or a detected issue. If an issue in production was detected it was very easy to blame the "opposite" team, one said "QA didn't test well", the others said "Development did it wrong" or "delivered late." It was very simple to discredit each other's work and to place the responsibility on the others.
Over time they began to show miscommunication between equipment, failures in delivery times, low quality application development, and to try to solve these problems, the company began experimenting in search of solutions. Among other things, additional hierarchical levels were added to the teams, processes were restructured, methodological changes, etc. Which in my opinion resulted in very little success.
During my career I have worked with many teams, with different structures and different products, however in a major or minor way that rivalry has always been present, and in fact this story is the common denominator of many companies.
Later in the company where I worked it was decided that we should use agile methodologies.
We would start to work using the Scrum methodology which was not at all easy, you have to change many paradigms, and to be honest I didn't think it would work, although I had to take the leap, the order to use Scrum came from above.
As we progressed with the implementation of the methodology I realized that the status quo that was so hard to leave, was gradually diluted until it finally disappeared, but, Why did this happen?
The fact of having meetings every day and that all team members were involved, did that each of the “teams” members gradually understood and internalize that we were working towards the same goal.
It allowed us to understand and appreciate the work of our colleagues and that each of the team members have specific skills that enable them to cope with a greater dexterity certain types of tasks.
This created a work environment where it was understood that the work and effort of each one is reflected in the developed software.
Due to that we are humans, we make mistakes, there will be things we do not know, we'll have problems unrelated to our work, so it's necessary to help each other to achieve the project goal.
It is an indispensable requirement that all team members are aware of the needs of a product and actively participate in the process to achieve that goal. The only way to achieve this is with a very high level of communication.
Over time, developers no longer felt attacked by the people from QA, they understood that everything was just meant to improve. The QA people no longer disqualifies the work that was done and they are now focused on improving the software, improving the application development process and no team member evade their responsibilities.
As the months passed, the team became in a unique and well established team that achieved:
Work delivered with high quality
More work was completed within the same timeframe.
The nighters to achieve deliveries were minimized.
People leave the office in time to share with their families and live their lives.
A harmonious and solidarity work environment.
Although this seems like a difficult story to believe, this is achieved by applying agile methodologies, because these frameworks have a focus on communication and certain techniques that enhance interpersonal relationships and promotes this progress.
If you want to read other articles of my coworkers you can find them here http://www.teravisiontech.com/blog/