Name your favorite book on Agile?
I can’t pick one favorite agile book. I suppose I could say _XP Explained_ since that started it all for me. But there have been many great books since then.
Who is your hero?
Oh, this is an interesting question too! I have many heroes. But maybe my biggest heroes are my current team. Mike Cohn took over this team in 2003 and brought me in as a tester. I have learned so much working on this team for most of the past seven years, and I have been able to pass those experiences along to others. I have been on some other rockin’ teams in the past as well. My coworkers are my favorite heroes.
What do you do when you are not working?
My normal job is working as a tester on a really cool team. I spend a lot of my spare time writing, presenting and coaching, helping other people be successful with agile testing. But I still have time left for my avocations, such as driving my miniature donkeys, hiking with my husband and our dogs, gardening, and enjoying our travels.
What is a skill or strength that sets you apart from others?
I work in a ‘real job’ on a ‘real team’. We have successes and failures. I find ways to share those success (and failure) stories with other people, so they can make faster progress in their journey.
What (or who) inspires you?
My biggest inspirations come from the people I meet at conferences, and via Twitter. Every day someone tweets at least one link to a blog post that really makes me think, that inspires me to try something new or different. I’ve been able to take a lot of great ideas back to my team and we’ve implemented some of them to good effect.
Question from our reader Tom
“…agile teams…” — Should the “team” itself be ‘agile’? How do you know who should be on a team? How does having a pool of developers from which a team can be constructed differ from just having a fixed set of developers? How do those two scenarios change any relationships with testers being made part of the “team”?
I’m struggling with the context for this question. In my experience, it works best to have a team together for at least the life of a project or epic. The team needs to include whomever it needs for that project or product – programmers, testers, BAs, DBAs, sys admins, visual designers, UX experts, performance test experts, whatever. The self-organizing team frequently does retrospectives to see how they are doing and whether they might be missing a particular role or skill set, and decide how to solve that – with more training, with hiring someone else, whatever.
I prefer to have testers integrated into development team (by the way, we are all ‘developers’, not only the programmers). There are cases where it makes sense to have a separate test team, such as for testing embedded software, but the testers should still collaborate closely with the development team throughout each iteration and release.