{"id":893,"date":"2014-10-27T14:47:29","date_gmt":"2014-10-27T21:47:29","guid":{"rendered":"http:\/\/angryweasel.com\/blog\/?p=893"},"modified":"2014-10-27T14:49:32","modified_gmt":"2014-10-27T21:49:32","slug":"to-combine-or-not","status":"publish","type":"post","link":"https:\/\/angryweasel.com\/blog\/to-combine-or-not\/","title":{"rendered":"To Combine… or not?"},"content":{"rendered":"

I talk a lot (and write a bit) about software teams without separate disciplines for developers and testers (sometimes called \u201ccombined engineering\u201d within the walls of MS \u2013 a term I find annoying and misleading \u2013 details below). For a lot of people, the concept of making software with a single team falls into the \u201cduh \u2013 how else would you do it?\u201d category, while many others see it as the end of software quality and end for tester careers. <\/p>\n

Done right, I think an engineering team based approach to software development is more efficient, and produces higher quality software than a \u201ctraditional\u201d Dev & Test team. Unfortunately, it\u2019s pretty easy to screw it up as well\u2026<\/p>\n

How to Fail <\/h3>\n

If you are determined to jump on the fad of software-engineering-without-testers, and don\u2019t care about results, here is your solution!<\/p>\n

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\u2019t code as well as your developers, now is a great time to fire them and hire more coders.<\/p>\n

Now, inform your new \u201cengineering team\u201d that everyone on the team is now responsible for design, implementation, testing, deployment and overall end to end quality of the system. While you\u2019re at it, remind them that because there are now more developers on the team that you expect team velocity to increase accordingly. <\/p>\n

Finally, no matter what obstacles you hit, or what the team says about the new culture, don\u2019t tell them anything<\/em> about why you\u2019ve made the changes. Since you\u2019re in charge of the team, it\u2019s your right to make any decision you want, and it\u2019s one step short of insubordination to question your decisions.<\/p>\n

A better way?<\/h3>\n

It\u2019s sad, but I\u2019ve seen pieces (and sadder still, all) of the above section occur on teams before. Let\u2019s look at another way to make (or reinforce) a change that removes a test team (but does not remove testing<\/em>).<\/p>\n

Start with Why?<\/h5>\n

Rather than say, \u201cWe\u2019re moving to a discipline-free organization\u201d (the action), start with the cause \u2013 e.g. \u201cWe 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. \u2026etc.\u201d I would probably even preface this with some data or anecdotes, but the point is that starting with a compelling reason for \u201cwhy\u201d has a much better chance of working than a proclamation in isolation (and this approach works for almost any other organizational change as well).<\/p>\n

Build your Team<\/h5>\n

The core output (and core activity) of an engineering team is working software. To this end, this is where most (but not necessarily all<\/em>) 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.<\/p>\n

But\u2026if you read my blog, you\u2019re probably someone who knows that there\u2019s a lot more to quality software than writing and testing code. I think great software starts with core software engineering, but that alone isn\u2019t enough. Good software teams have learned the value of using generalizing specialists<\/em> to help fill the gap between core-software engineering, and quality products.<\/p>\n

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.<\/p>\n

  \"image\"<\/a>     \"image\"<\/a><\/p>\n

Nitpicker note: sizes of circles may be wrong (or wrong for some teams) \u2013 this is a model.<\/p>\n

\"image\"<\/a><\/p>\n

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\u2019t be ignored. These activities (in the outer loop of my model) improve and enhance \u201ccore software engineering\u201d. In fact, an engineering team could be structured with an separate team to focus on the types of activities in the outer loop. <\/p>\n

<\/h4>\n
Generalizing Specialists (and Specializing Generalists)<\/h5>\n

I see an advantage, however, in engineering teams that include both circles above. \"image\"<\/a>It\u2019s important to note that some folks who generally <\/em>work in the \u201cCore Engineering\u201d circle will frequently (or regularly) take on specialist<\/em> roles that live in the outer loop. A lot of people seem to think that discipline-free software teams, everyone can do everything \u2013 which is, of course, flat out wrong. Instead, it\u2019s critical that a good software team has (generalizing) specialists who can look critically at quality areas that span the product. <\/p>\n

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 \u2013 and celebrate<\/em>) this behavior\u2026but with this much interaction between the outer loop of testing and investigation, and the inner loop of creating quality features, it\u2019s more efficient to have everyone on one team. I\u2019ve 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\u2019re on a team where team walls don\u2019t get in the way, and you\u2019re making great software with separate teams, then there\u2019s 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).<\/p>\n

<\/h5>\n

Doing it Right<\/h3>\n<\/p>\n

It\u2019s really easy for a team to make the decision to move to one-engineering-team for the wrong reasons, and it\u2019s 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\u2019m completely sold on making software with a single software team. But making this sort of change work effectively is a big challenge.<\/p>\n

But it\u2019s 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.<\/p>\n","protected":false},"excerpt":{"rendered":"

I talk a lot (and write a bit) about software teams without separate disciplines for developers and testers (sometimes called \u201ccombined engineering\u201d within the walls of MS \u2013 a term I find annoying and misleading \u2013 details below). For a lot of people, the concept of making software with a single team falls into the…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[1],"tags":[],"class_list":["post-893","post","type-post","status-publish","format-standard","hentry","category-allposts"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/893","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/comments?post=893"}],"version-history":[{"count":0,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/893\/revisions"}],"wp:attachment":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/media?parent=893"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/categories?post=893"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/tags?post=893"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}