Introduction
In my tenure in the tech industry, I’ve had the privilege of serving as a senior developer, dev lead, and head of architecture. I’ve collaborated with numerous cross-functional and horizontal development teams, and I’ve seen firsthand how the structure of these teams can significantly impact productivity and project outcomes. This blog post aims to inform developers, QA professionals, dev managers, and CTOs about the merits of cross-functional teams and the potential pitfalls of segregated development and QA functions.
After reading if you wish to read a detailed comparison of Cross-Functional teams versus the hub and spoke model of QA and Development then please read this post.
The Power of Cross-Functional Teams
In my experience, cross-functional teams—where each member is a recognised subject matter expert in their field, be it UI, QA, DevOps, backend, event-driven architecture, or APIs—are incredibly effective. These teams don’t just acknowledge expertise; they actively share knowledge, coach, and mentor each other. This collaborative approach fosters a unified team where QA, developers, and product teams are integrated rather than segmented. Everyone in a cross-functional team works towards a common objective, regardless of the methodology—be it Scrum, Waterfall, or Kanban—without the friction of competing for resources.
The Challenges of Segregated Teams
However, I’ve also encountered many teams where development and QA function as distinct units. Often, work is passed along somewhat haphazardly between these groups, akin to a hub-and-spoke model where developers are on the periphery, all vying for the same central QA resources. While this model has its merits, my experience and recent literature suggest it’s largely an anti-pattern. Competing priorities from different teams create bottlenecks and increase waiting times, as every additional line of communication introduces delays. We need to view waiting time as an obstacle to be eliminated. More communication channels and conflicting priorities inevitably complicate understanding and slow down the development process.
The Misalignment Issue
If developers are merely handing off work for QA to pick up in isolation, regardless of whether they are using Kanban, Scrum, or Waterfall, the output cadence from developers can exceed what QA can handle. This misalignment can lead to a backlog of unfinished or undeployed work, potentially riddled with defects—whether from requirements, design, or other aspects. This is particularly problematic when functionalities build upon each other. Defects discovered only during testing can corrupt the work and affect related functionalities, forcing weeks’ worth of work back to the drawing board, disrupting the backlog, and wreaking havoc on project timelines.
A Smarter Approach
While I’m not suggesting that developers need to start writing test cases or using test frameworks outright, I am indeed implying that there might be smarter ways to approach this integration. Teams must remain vigilant and prepared to adapt their strategies to maintain flow and efficiency. If you find yourself in this situation, take immediate action to address these challenges and realign your team’s focus on efficient and collaborative workflows.
The DevOps Analogy
To further explore the benefits of QA cross-functional teams, consider the evolution of the relationship between developers and operations. A few years back, developers would develop and then pass it over to operations to deploy and set up the infrastructure. Then came thought leaders in our field like Gene Kim, who wrote The DevOps Handbook and The Phoenix Project. Some people who’ve never experienced TrueAgile may look at this as a fairy tale, the land of hope and honey. However, others who have experienced RealAgile, even if it’s for a brief, fleeting moment in their career, will understand that it is not a fairy tale. It is achievable by any organisation where the leaders and the culture embrace the ideals.
I’ve worked under some very good Agile leaders, and I can assure you that what’s mentioned in books like The Phoenix Project and The Unicorn Project are not fairy tales. They are real, achievable goals and outcomes. You just need to believe. Of course, it can be stifling if you’ve worked in a bureaucratic, heavy-process, waterfall organisation that relies heavily on on-prem software requiring rigorous installation. But once you’re in a SaaS world, and especially if you’re using the cloud as your development and production hosting systems, you can 100% move to this, and it is not a fairy tale.
Trust me. I’ve worked with numerous people over the years and had that luxury. I’ve tasted true Agile. I’ve also tasted waterfall. Lately, I’ve been trying to get it back. I want that Agile movement again. So, if anyone doubts that, I also recommend looking at the books I recommend on my website. I will get a commission if you buy anything from that link. Please do it. It will help me write more. But I can assure you 100%, if you embrace the books, it is not a fairy tale. You can do it. You just need to believe and push. From my own experience, I’ve seen teams go from buggy, three-week monthly releases to being able to release at least twice a week, three to two times a week. I’ve seen this. I’ve participated in it. But what you need is the mindset.
Of course, for teams that do not have that mindset, you need leaders who raise the bar for the entire team and organisation. Again, it is not a fairy tale. It is not a fairy tale story to tell your development teams that you can achieve it if you work hard. No, it is real, and it’s possible. All you need to do is go read some use cases. Read some books. Watch some presentations of other companies doing it. Read books on Amazon. They used to deploy like once a month. Now, they deploy thousands of times daily. Hundreds of thousands of developers are deploying into production daily. No one company is a unicorn when it comes to this. It is possible. Companies of all sizes, of all budgets, can do this. And the only thing that has to change is your mindset. The golden highway is in your grasp and in front of you. All you need to do is want it.
Conclusion
Therefore, if it can be done with developers and operations, it can be done with developers and QA. I don’t want to coin the phrase “QDev” or “DevQ” all because it doesn’t roll off the tongue very well (but I am happy to). However, developers and QA can work together. Developers are already writing unit tests. If you’re not, start now. Using tools like Postman, you can 100% write API contractual tests for your projects. Why wouldn’t you want to? Wouldn’t that make your life easier when testing your work? Surely, you’d test your own work. Then, wouldn’t you want to sit next to a QA team member and ask, “What do I need to do to ensure my code is robust?” Sit down with the QA before you start developing and reviewing the test cases. Understand what’s going to be tested so you can code accordingly. Work with them over time to understand other testing aspects and then feed that loop back into your development process.
Some people may say that separate QA functions are ideal. They are not. Those who have experienced cross-functional teams will tell you this. If you have experienced cross-functional teams, please let me know if I’m wrong. Share your alternative ideas or experiences. But unless you reach out and try something new, how do you know you’re doing it the best way possible? Try new things. If you’re following a five or ten-year-old process, you’re not moving forward; you’re going backwards. So, embrace the change and move towards a more integrated, collaborative approach.