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)!

It's all about priorities

I've been pretty silent on my Scrum blog lately (well, for the past few months even). The main reason is that we've been expecting a child and we've had a relatively problematic pregnancy; the climax of which led up to my beautiful daughter Emelie's very premature birth on the 17th of March 2010.

She was born in week 26 + 3 days only, so she is 3 months premature. She was 1230 grams, 38cm tall, when she came out. She entered the world at 09:57 in the morning, with three minutes to spare to my team's Daily Scrum!! :-)

Kidding aside, me and my girlfriend Helene are now living at the hospital in Lund, tending to little Emelie's needs and helping her grow and get stronger.

I'm currently on leave from work and I will continue to be somewhat out of the Scrum & Agile loop for some time ahead. We're taking it day-by-day here.

Such are priorities in life.

I keep a blog about my daughter's progress. You can find it here: Liten Emelie (sorry, only in Swedish - she doesn't know English just yet ;-)).

New version of Backlog Manager

Recently I've had some time to spare, so I decided to refactor my Backlog Manager into a new version.

Here it is: Backlog Manager v10.1

It is more robust than the previous versions, and has better support for Release Planning.

Moved/updated Excel tool links

Due to some technical issues the Excel tools that I've made has been unavailable for a week or so. The files have now been moved to a new temporary location.

Here are new links:

Backlog Manager
Velocity Log
Estimation Sheet