Back in business - with questions about Test and Development

Long time no see!

I've been silent for a while now, due to the extremely premature birth of my daughter this spring (she was born over 3 months early). Everything is OK now and she (Emelie, is her name by the way) is doing well. It was, not surprisingly, very chaotic times there for a while, and add to that getting used to being a parent which in itself is a big change.

Anyway, for these reasons I haven't really been focused on working with Scrum, but lately, as I'm getting back in to the groove of things here at work, I find myself thinking more and more about Why's and Why-Not's with regard to Scrum & Agile software development.

My team(s) here have expanded during the year. They're now a total of about 15 engineers (about 1/4 testers and 3/4 software developers). Which brings me to the topic of this post; how do other organizations cope with running Scrum in a traditional organization where there's one department for "Software development" and another for "Software Quality Assurance"?

I've managed to bring the Test Engineers into the team by means of physically locating them here where the Software Developers sit (instead of having the testers sit on another floor). Very cross-functional. Excellent! But, that was the easy part, now to the trickier bit; how do you get the team to think of themselves as one unit with a joint mission (and thereby sharing tasks without particular regard to their formal role) rather than one group of Software Developers and one group of Test Engineers? I often have to remind members of the team (more often Software Developers than Test Engineers, to be honest) that tasks such as "Write automatic test" or "Execute test case A" doesnt automatically have to be done by a Test Engineer just because the task description includes the word "test" - it may just as well be done by a Software Developer.

As you can probably guess I am of the firm opinion that every task on the Scrum Board should be up for grabs by anyone in the team (at least that should be the default), regardless of if says "Software Developer" or a "Test Engineer" on the individual's employment contract. They're all comitted to achieving the sprint goal and it's thereby in everyone's interest that every task is completed.

It all sounds good and is easy enough to grasp in theory, but in reality it's harder to achieve. Partly (I think) because this is a traditional organization where people are employed specifically as "Test Engineer" and "Software Developer". People tend to kling to that, and I sometimes have a hard time getting them to step outside the boundaries of their formal/traditional role. A complicating factor is that it is not naturally bidirectional; a Software Developer usually have no real problem of carrying out a task that says "Test" on it, but a Test Engineer is not as often able to carry out a task that says "Program" on it.
Does this support the notion not to try to share tasks across roles?

Well. I like to think of the role "Test Engineer" as a person with a (usually :-)) formal education and experience in the field of "software quality assurance" and that those guys and girls are those who are skilled in identify testing challenges, quality risks and generally ensure that what they (the Scrum team) build is tested "enough". But "Test Engineer" doesnt automatically mean "Those are the guys and girls who should carry out all the tasks with the word 'Test' written on them".

To sum this up; If it was completely up to me I would get rid of the formal roles and just hire "Scrum Team Members" with different backgrounds (some who are more skilled in programming and some who are more skilled in the field of software verification & validation).

As always, I like getting feedback and comments from you about this and other posts.

See you soon(er)!