Agile Team Dynamics : Developers vs Testers/Designers

Yesterday I had a conversations with one of my colleagues Prakash who works as a tester in an Agile project.

“So how is it going on?”, I asked.

Prakash took a deep breath and said, “Umm…workwise I think I am getting more confident on the application functionality now. However in one of our retrospectives I realized that I have to improve on some of my personal traits.”

“Interesting ! – and what are those?”, I asked.

“One of the points, I also felt myself too is – I take a lot more time to solve a problem.

Second point is a bit confusing to me as team feels that in general I crib a lot but do very little to solve problem. It’s confusing as those same guys tell me to let them know the technical problems I am stuck with and raise alarm before it’s too late. However, I am not able to decipher the exact definition of “too late” here as I don’t know when telling problems to team transforms into cribbing.”, he replied.

I thought for a moment and continued, “At the outset, these two points look different but essentially they are smell to the problems in team dynamics.

From my experience, many a times, these problems occur just because testers are considered second class citizens in developers dominated Agile teams.

Whenever in a team we talk about “we vs they” (or testers vs developers), it essentially means that the team is not working for the success of a Sprint. Instead this team consists individuals who feel that developers and testers have to finish their individual work separately.

So here, the problems of testers do not become the problems of the team but rather become yet another impediment which a Tester has to solve himself. And that’s where the problem of “we vs they” become even more visible.

It looks like as if the team has forgotten  that the end goal for an Agile team is not about finishing individual goals (which may look good to one’s own ego) but to finish Sprint goals.

So in your case Prakash, it looks like developers do not have time to hear and solve your technical problems as that’s why they say you crib a lot. When you become very frustrated with their response and lack of help, you try to fix things on your own. Acquiring a new skill especially in another domain takes time. That way, you are bound to take a lot more time than it could be possible with collaboration within the team.

You could have avoided the problems you have if developers in your team would have been supportive to your cause. It is important in a team that everybody considers himself as a team-member first and developers/testers later. To achieve Sprint goals, everybody has to make efforts and help each other.

Last but not the least your Scrum Master should have taken steps to help you in fixing your technical impediments.”, I concluded.


To be honest it’s pretty common to see this “we vs they” attitude in a lot many Agile teams. It not only happens with testers but also with designers and technical writers too.  In a way, helping out tester/designer looks like an obstruction to the rhythm of developers. However essentially it can be blocker to entire Sprint SUCCESS. Definition of DONE for a customer not only includes the development effort but rather means fully tested software.

ShriKant Vashishtha is an enterprise Agile Coach, IT strategist, trainer, thinker and hands-on geek. He is passionate towards enterprise Agile transformation, quality aspect of software development including TDD, refactoring, Continuous Delivery, DevOps and Test Automation. He can be reached at

Posted in Agile, Agile Testing
3 comments on “Agile Team Dynamics : Developers vs Testers/Designers
  1. Vijiay Rawat says:

    I agree with Srikant. One of my close friend is facing the same developer Vs tester situation(in some other company). Its very disappointing to see that half of his time goes into arguing with testers.

    I totally like the idea that its OUR responsibility as a team to get along and make the sprint successful.

  2. Gaurav Marwaha says:

    What has worked well with my teams is when QC folks get sharp and there is healthy competition between dev & QC this is not simple considering the traditional gap in QC & dev. But is easily achieved if QC teams can automate smoke and get time to play more and find better defects.

    In addition to this what has worked for us is when we orient QC folks to speak more of the dev language; get into code…

    Not easy but given the right push achievable

  3. @Gaurav,

    The ideas you mentioned are really good and practical. Again if they are implemented in the right Agile team-spirit, the results will be pretty good.

1 Pings/Trackbacks for "Agile Team Dynamics : Developers vs Testers/Designers"
  1. […] my last blog I discussed how in an Agile team "we vs they" (between developers and testers) phenomena can […]

Leave a Reply

Your email address will not be published. Required fields are marked *


CommentLuv badge

Welcome to Sampreshan
Technology Strategist, Speaker, Scrum/XP/Agile Trainer Coach and Trainer
Your interest areas

Get every new post on this blog delivered to your Inbox.

Join other followers: