Does every member of an agile team need to be a software developer?

Question

We recently started using agile methodologies at my company. Because I am quite new to agile, I wonder if our way of implementing it is correct according to the basic principles of agile.

Previously, we had roles such as business analyst, QA tester and software developer. But now management has decided that these roles should be removed and everyone will work as a software developer.

In practice, this means that one software developer will have the same responsibilities as three separate roles previously did (i.e. one business analyst, one QA tester and one software developer).

They justify the change with the fact that this is agile. Is this the way other companies also implement agile?

Answer 1

No. This is definitely not agile. Nor is it a good idea.

Cross-functional teams, i.e. teams that include every role (analyst, server admin, database admin, UX designer, QA tester, technical writer, graphic designer) that is needed to successfully deliver working software, are a staple of many agile methodologies. In fact, in many methodologies, the customer itself is also considered to be part of the team.

Actually, this is orthogonal to agile, though. Cross-functional teams are simply a good idea, regardless of whether you are doing agile or not.

What is true, however, is that with the constant rise of automated testing, developer testing, test-driven and behavior-driven development on the one hand, and software-defined infrastructure, highly automated commissioning, configuration, and deployment, DevOps, and cloud hosting, some of the workloads may have shifted from admins to DevOps engineers, and from QA to development. That does not, however, mean that those roles are extinct. It just means that QA has more interesting bugs to chase because all the trivial ones have been found by developer testing, and admins focus more on enabling DevOps to manage the infrastructure with automated tools than managing it themselves.

There is an easy test to check whether something is agile: when someone says "you do this because it is agile", then it is not agile. Agile is all about self-managing teams that constantly reflect on their processes and adapt them. Whenever someone says "you do this", then it is not agile. It is only agile when the team says "we do this, because after reflecting on our past experiences, we have determined that it works, and we will keep reflecting on it and stop doing it as soon as we determine it doesn't."

Answer 2

Is this the way other companies also implement agile?

Unfortunately, yes. There are a lot of companies where Agile is imposed by management, or at least what they think is Agile (which of course isn't).

If you look in the Scrum guide, which is probably from where your management picked up the idea, you will find this:

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person

But the idea with everyone in the team being a "developer" is that no mater their role (QA, programmer, designer, etc), they all contribute to the development of the application, together, with equal efforts, and equal responsability and accountability. The programmer is not more important than the tester just because she writes the code and the tester just tests it, the designer doesn't create the wireframes then goes away while the front end developers implement them. Everyone is important. Everyone contributes. So everyone is the same from this regard. Job titles don't matter. So that's why everyone is a "developer".

But it doesn't mean all of a sudden the designer starts to do the architecture of the application or writing the code. And on the same train of thought, just because you are now all "developers" because management said so, it doesn't mean you are doing Agile.

Answer 3

What they are doing is nonsense. For example, if you make a software developer take on a QA role:

One, the software developer doesn't have the required experience. It's all things that can be learned, but I personally would start as a junior QA engineer, being far less effective than doing software development work.

Two, people have different talents and go into positions where their talents count. People become software developers because they have a talent for it, and others become QA engineers because they have a talent for that. And both would have been less good in the other job.

Third, if the same person does both software development and QA, they are in conflict. QA finds problems that cause software developers more work. Software developers, like everyone, don't like more work. So what do you expect a software developer working as QA to do?

Answer 4

Although Agile's origins are in the software development realm, iterative approaches to development have been around since the late 50s and was used in early NASA days (see https://en.wikipedia.org/wiki/Iterative_and_incremental_development). These teams obviously were only software engineers.

We have successfully used various Agile approaches at my companies and for the robotics team I mentor. The concept of sprints, spikes and iterative design with overarching epics has proven to be very successful across the entire team -- software, hardware, CAD, marketing, etc. For this we have none of the "DevOps" infrastructure, the kids are doing staightforward prototyping and demonstrations of their learnings on two week sprints. Decisions on how to proceed are made from there, but at the core is a robot that is gradually better each sprint. Role-wise, this consists of "software developers", "CAD guy", "builders" and "outreach". The majority of this team is NOT involved directly in coding software.

For my software companies the team typically consists of developers, testers, devops, designers, and support.

In general, Agile is no one thing and there are many approaches to implementing the philosophy. But at it's core is the idea of iterative development, breaking work down into short tasks, and continuous re-evaluation. Things like daily scrum meetings, backlogs, user stories, etc are often used but not in any way required to be "Agile". Agile is about adapting constantly, and that includes the way a particular team implements Agile itself.

So, short answer -- your management team either doesn't understand Agile is or using this as some kind of justification to eliminate things they feel are a waste of money. It might be justified to make changes, but it is not because Agile is only for programmers.