Optimizing with a Remote Team Member

Last December, our manager moved back to India. He's still a VP and still writes code, although he's not our direct manager anymore.

Although he arranges his hours to accommodate us, working until almost midnight his time, there are still those hours where he's working and we're asleep. Sometimes he's left with no work to do, especially the first day of the sprint when we haven't planned our work yet.

This sprint we're trying an experiment. Our sprint starts Friday. On Wednesday morning, we had a meeting with the remote team member (let's call him "G"), our ScrumMaster, the product owner, our manager, and me (a tester, so I could get the feel for how much testing might be involved). The product owner had come up with three stories to "earmark" for G. We discussed the first story at some length, as it's rather complex and involves a business partner. We didn't discuss the other two stories. G felt the first story would keep him busy for a few days.

He proposed to write his task cards on his Friday morning, and go over them with the rest of the team in our sprint planning. (Now, for all of you who are down on task cards now, I can see why, but it's working for our team). We'll have to write the testing task cards then, too.

Today (Thursday), we had our "pre-planning" meeting. We went over the stories earmarked for G, plus the other stories that might be in this sprint. Tomorrow we will plan the sprint.

The three stories for G add up to almost as many points as the whole team does in a sprint. Now, G is a superman, for sure, but that seems kinda crazy. I have raised this issue. What if G stays busy for several days with Story 1, and other developers on the team free up? Do they have to keep their mitts off G's other stories?

But it's just an experiment. We'll see how it goes. Do you have a distributed team? How do you make sure everyone always has enough work? Please comment.

Agile Tester Skills

A StickyMinds column by Johanna Rothman about exploratory testing on agile projects prompted a discussion about what skills agile testers need on the agile-testing mailing list.

Janet Gregory posted this response, I thought it was insightful.

Johanna talks about the perfect tester skills but acknowledges generalists without coding skills may have a place. I have seen a few teams where none of the testers had coding skills, but worked with the developers to create the automation framework using FIT or some other similar tool.

If the team works closely, and develops a framework that the 'non-coding' testers can use easily, the testers can be very productive. I do agree that it helps the team if the testers can code, but it is not absolutely necessary. Because the whole team is responsible for quality, the whole team usually can solve any problem.

I think that some of the most valuable skills a 'tester' can bring to the table, are critical thinking and understanding of the big picture - implications of proposed changes. Exploratory testing helps to expose issues if testers have those skills, and can use them properly.

She adds in a later post:
I didn't take it one step farther which is to say, that many of the "manual" testers who started using the spreadsheets for Ruby/watir implementation, eventually got comfortable enough to start understanding the code and actually doing some of their own scripting. That shows initiative and proves that everyone is capable of learning :-)

I do think it is absolutely beneficial to understand scripting and coding, and I do encourage learning those skills. I think testers will go so much farther if they do. However, it is important that we don't discourage those testers that don't have any coding skills when they first come to an agile team. I guess those are the testers I work with mostly.

I've worked with "manual" testers who were happy to learn new skills such as automation when given the time and support they needed. I've met so many teams where the testing team freaked out when the development organization adopted agile. Telling testers they need these skills they've possibly never had the chance to acquire is not going to help with the transition.

I also know lots of testers who had no interest in learning new skills or improving. People like that won't fit on an agile team, for sure. But anyone who gets excited about agile and wants to work on an agile team is worth a bit of investment, in my book.

The "Not My Job" Game

Expanding on last week's post...

The NPR news quiz show "Wait Wait, Don't Tell Me" always includes a segment called the "Not My Job Game". A celebrity has to answer questions about something completely unrelated to their own profession. Sometimes, through logical thinking, intuition or both, they're able to guess the correct answers.

Agile team members play this game every day. OK, maybe the questions or tasks aren't completely unrelated to our normal job, but we don't worry much about whether something is really our job or not. If it needs doing, we do it.

My team is about to embark on a theme to rewrite the code that produces account statements we send out for every 401(k) plan participant. We have several outstanding issues about the statements, and I wasn't sure if they are bugs or stories, as we are going to rewrite the statements anyway.

I asked the product owner and the head of plan administration for a quick meeting. We discussed each issue, and decided that the product owner would write new stories to ensure they are addressed. We'll probably need an engineering meeting to talk about potential solutions for one or two of them. Then we'll estimate the stories and we'll have a better idea when we'd better start on this theme, because it has to be done in time for the 3rd quarter statements.

Was it my job to worry about writing stories and organizing this meeting? Some people might say that was the job of the ScrumMaster, product owner, coach or manager. I didn't want these issues to fall through the cracks. Nobody here thinks it's weird when a team member takes on a task such as this.

This is one thing I love about agile development. Each of us is empowered to take the action needed to make sure we can deliver the most business value.

What an Agile Tester Does

This has been kind of a crazy week. I've had to multitask a lot, which I know is bad and inefficient. Here's a sample of the types of tasks I've done this week:
- Write high level test cases
- Automate tests in FitNesse
- Debug problems with Canoo WebTest GUI tool and tests
- Look into three different production issues
- Manual exploratory tests of various stories
- Participate in estimation meeting
- Spend a lot of time getting requirements and clarifications from various customers
- Help team strategize best way to make sure we get everything completed this sprint

If you're an tester on an agile team, are those in line with the things you do? Are you surprised by any of them?

I think some people might not expect a tester to work on production issues, but as testers, we tend to learn a lot about the business domain. It's natural for business people to come ask me where something is documented on our wiki, or how a piece of functionality is supposed to work (at least, how we delivered it, maybe we were wrong on how it should work!) I get interested in production problems because I want to know how we didn't run across a particular issue in testing. Working on production issues isn't in my job description, I suppose, but it helps me learn a lot about the app and what we can do to improve it.

I know a lot of agile testers who do similar tasks. I'm interested in what other things agile testers do.