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.

Interdisciplinary Awareness

One of the most interesting sessions I attended at Better Software was "You Just Don't Understand Me: Interdisciplinary Awareness to the Rescue" by Mike Tholfsen, principal test manager of the Microsoft OneNote team. (See his blog at http://blogs.msdn.com/onenote_and_education/) He presented a "Team Pyramid" (don't we love all these pyramids?) showing that for a successful team, you need trust as your base. Results are the little top of the pyramid, they come from trust, healthy conflict, commitment, accountability and results.

Mike feels that one way to achieve this is to help people understand their peers' viewpoints better. He introduced an exercise to help people in different roles on the team understand the important traits of each discipline, and trade ideas on what teammates in other roles like or dislike about each discipline.

An interesting point of the presentation was that there was a development team where all the team members scored the same on a Myers-Briggs style test. The manager had hired himself four times. Lack of diversity is not a good thing.

This made me think about the times we've hired a tester onto my agile team. I brought in testers who were great with communication, collaborating with customers, exploratory testing, but not a lot of skills on the automation/technical side. I felt they could contribute value, but my developer coworkers gave them thumbs down. In each case, we hired a very techy tester (fortunately, also good at all the other things).

Mike's presentation made me realize that the developers were most comfortable hiring someone like themselves. This is understandable, but not always in the best interests of the team. Having realized this will help us in future hiring efforts, I think. Do we really not like something about the candidate, or is it just that they're different than we are? Could the differences make us better?

There appears to still be a lot of controversy in the agile community over testers and their role on the team. Interdisciplinary awareness might help agile teams realize that people with a different skill set might add tremendous value to their team.