I talk a lot (and write a bit) about software teams without separate disciplines for developers and testers (sometimes called “combined engineering” within the walls of MS – a term I find annoying and misleading – details below). For a lot of people, the concept of making software with a single team falls into the “duh – how else would you do it?” category, while many others see it as the end of software quality and end for tester careers.
Done right, I think an engineering team based approach to software development is more efficient, and produces higher quality software than a “traditional” Dev & Test team. Unfortunately, it’s pretty easy to screw it up as well…
How to Fail
If you are determined to jump on the fad of software-engineering-without-testers, and don’t care about results, here is your solution!
First, take your entire test team and tell them that they are now all developers (including your leads and managers). If you have any testers that can’t code as well as your developers, now is a great time to fire them and hire more coders.
Now, inform your new “engineering team” that everyone on the team is now responsible for design, implementation, testing, deployment and overall end to end quality of the system. While you’re at it, remind them that because there are now more developers on the team that you expect team velocity to increase accordingly.
Finally, no matter what obstacles you hit, or what the team says about the new culture, don’t tell them anything about why you’ve made the changes. Since you’re in charge of the team, it’s your right to make any decision you want, and it’s one step short of insubordination to question your decisions.
A better way?
It’s sad, but I’ve seen pieces (and sadder still, all) of the above section occur on teams before. Let’s look at another way to make (or reinforce) a change that removes a test team (but does not remove testing).
Start with Why?
Rather than say, “We’re moving to a discipline-free organization” (the action), start with the cause – e.g. “We want to increase the efficiency of our team and improve our ability to get new functionality in customers hands. In order to do this, we are going to move to a discipline-free organizational structure. …etc.” I would probably even preface this with some data or anecdotes, but the point is that starting with a compelling reason for “why” has a much better chance of working than a proclamation in isolation (and this approach works for almost any other organizational change as well).
Build your Team
The core output (and core activity) of an engineering team is working software. To this end, this is where most (but not necessarily all) of the team should focus. The core role of a software engineer is to create working software (at a minimum, this means design, implementation, unit, and functional tests). IMO, the ability to this is the minimum bar for a software engineer.
But…if you read my blog, you’re probably someone who knows that there’s a lot more to quality software than writing and testing code. I think great software starts with core software engineering, but that alone isn’t enough. Good software teams have learned the value of using generalizing specialists to help fill the gap between core-software engineering, and quality products.
Core engineering (aka what-developers-do) covers the a large part of Great Software. The sizes of circles may be wrong (or wrong for some teams); this is just a model.
Nitpicker note: sizes of circles may be wrong (or wrong for some teams) – this is a model.
Engineering teams still have a huge need for people who are able to validate and explore the system as a whole (or in large chunks). These activities remain critically important to quality software, and they can’t be ignored. These activities (in the outer loop of my model) improve and enhance “core software engineering”. In fact, an engineering team could be structured with an separate team to focus on the types of activities in the outer loop.
Generalizing Specialists (and Specializing Generalists)
I see an advantage, however, in engineering teams that include both circles above. 
It’s important to note that some folks who generally work in the “Core Engineering” circle will frequently (or regularly) take on specialist roles that live in the outer loop. A lot of people seem to think that discipline-free software teams, everyone can do everything – which is, of course, flat out wrong. Instead, it’s critical that a good software team has (generalizing) specialists who can look critically at quality areas that span the product.
There also will/must be folks who live entirely in the outer ring, and there will be people like me who typically live in the outer ring, but dive into product code as needed to address code problems or feature gaps related to the activities in the outer loop. Leaders need to support (and encourage – and celebrate) this behavior…but with this much interaction between the outer loop of testing and investigation, and the inner loop of creating quality features, it’s more efficient to have everyone on one team. I’ve seen walls between disciplines get in the way of efficient engineering (rough estimate) a million times in my career. Separating the team working on the outer loop from core engineering can create another opportunity for team walls to interfere with engineering. To be fair, if you’re on a team where team walls don’t get in the way, and you’re making great software with separate teams, then there’s no reason to change. For some (many?) of us, the efficiency gains we can get from this approach to software development are worth the effort (along with any short-term worries from the team).
Doing it Right
It’s really easy for a team to make the decision to move to one-engineering-team for the wrong reasons, and it’s even easier to make the move in a way that will hurt the team (and the product). But after working mostly the wrong way for nearly 20 years, I’m completely sold on making software with a single software team. But making this sort of change work effectively is a big challenge.
But it’s a challenge that many of us have faced already, and something everyone worried about making good software has to keep their eye on. I encourage anyone reading this to think about what this sort of change means for you.
In no way am I saying that this model is wrong or right in a given context, but are you saying that there is something special about not having labels such as “QA” or “Operations”? Speaking just of myself, I have proposed fixes to developers, I have done code reviews with developers, I have written unit tests, I have done manual testing and I work with operations on production issues. I however have a label of “QA” attached to my role. I really don’t care if they call me ‘bug catcher’ or ‘developer’ or ‘SDET’, but it seems that the major difference between our development model and yours is in naming.
Perhaps you would argue that it isn’t the naming but the way you look at the work. Don’t get me wrong, I appreciate that there is less ‘us vs them’ involved in that sort of model. That seems like a real and realistic win to be had for teams that have a lot of infighting. On the other hand, there can be less central planning around the given activity. If you say there are no operations, you might have less planning around new hardware needs. When a machine goes down, you buy another and wait for it to ship to you. If you need an automation framework for functional testing, a ‘developer’ throws something together for the team with little consideration of any other teams who might need it later. I get a sense that this is in some ways a matter of preference, or perhaps culture. “Agile” vs “Waterfall” in how much planning should go on. But with no one whose focus is on an activity like “QA” for the organization, you may only get short term thinking. Scrum suggests a scrum of scrums might help get the different groups talking together, but who are the heads of the different groups that need to come together? Who is doing this? The ‘architects’ or a random member of the team? It seems to me that in order to get the most value out of that sort of meeting, you need to know what sort of perspectives would you need. I would say someone who is interested in testing, someone interested in development and someone interested in the operations and someone who is interested in the business. That gets back into those old fashion divisions. How do you get the right advocates to advocate beyond their own team?
I would like to hear how you feel the higher level considerations get taken on, particularly since you are in a larger organization where that is a valid consideration. I would like to know how you keep from ending up with only short term wins and have people thinking about the long term. Finally, I wonder how, given what at least in the past was such a heavily metric-oriented company, gets informed if a given team is doing enough testing outside of the team. That is to say, how do you keep track of particular teams and their integrated approach? How does the larger organization know they have enough subject matter experts in a particular team?
I really am interested in hearing how you organize and don’t mean this to be an attack on what you have described. Even if my present team does not subscribe to this idea, there maybe useful ideas buried in your answer that we can use. Thanks,
– JCD
One-team is one solution to the artificial walls that I see between disciplines on many test teams (e.g. throwing code over the wall, or blaming so-and-so for blocking). I’ve seen the approach help teams with both individual and team accountability.
That said, it’s absolutely possible for an engineering culture without those problems to exist and thrive. This approach is a solution that removes walls and encourages collaboration. You may not need it – and that’s not a bad thing.
“The core output (and core activity) of an engineering team is working software”
Specifically working software that produces the desired business value. I like to remind both testers and developers (and PM and designers…) that they have the same job, and that is its description.