Developer, Program Manager, O&M Engineer, Tester, Business Analyst; these are some of the common roles/titles assigned to people working in Agile teams. Roles help define the responsibilities and contributions that are expected of each person. Roles give structure to a team and create a hierarchy of decision making. Roles, however, have the potential to lead teams into information silos and unproductive specialization.

“It’s not my job!”

It’s near the end of the sprint, there are stories that need testing but the team Tester is already at capacity. The Business Analyst is away on vacation and Developers have started working on Technical Debt because they have bandwidth. The Team Lead asks one of the developers to help out with doing functional testing for a few of the remaining stories. The developers reply with “I’m a developer, not a tester!”.

This type of response is very common, people are resistant to expand beyond the roles in their titles. This type of behavior hurts the team because it sets up single points of failure. If a Business Analyst is out of the office, will business requirements not be clarified? If the tester is out, will functionality remain untested? The answer is “no!”. A team cannot depend on any one individual to continue in their mission to deliver working functionalities.

Should Business Analysts and Testers learn to code then? Absolutely yes! Software Development is a very complex field and learning to develop requires a certain mindset. However, everyone in a team should at least have fundamental knowledge of it. A Tester can benefit from this and eventually write automated functional tests. A Business Analyst can determine what feature requests are feasible and not. Even a Project Manager with some understanding of software development may be more able to create projections and estimates.

Developers can also benefit from performing other non-development tasks. Working on writing of acceptance criterias and requirements gathering can improve communication skills. Working on functional testing provides insights into different areas of an application and provide an overall picture of how a system works. Even attending meetings that are non-technical in nature can lead to a better understanding of a business unit or client needs.


Communication and knowledge sharing are keystones of a good team especially in an Agile environment. A team that can share responsibilities amongst each other will always be more successful than one that creates silos of information.

Comments are closed.