I really like being agile and how it helps the team to communicate on what's important now.  I don't really believe agile happens all by itself.  The team needs guidance about what's important on the product backlog and it needs a supportive Scrum master to clear impediments.  Aside from the guidance from these people, the team finds the best ways to communicate and work together to accomplish what the stakeholders need.  I find that this model allows me to accomplish the important things faster than under a more traditional management structure.

I think one reason for this is that communication is more direct.  It's also very easy to see when any team member (including me) is off-course.  This allows for quick correction and is a more effient means of getting things done. Everything we do is done in the context of what value it brings to the end customer.  I've held these values since the first software projects I've ever worked on.  Software has to meet its requirements, be free of bugs, and useful to the end customer.  Agile projects complete the communication loop back with the customer via working software tht passes functional acceptance tests and product demonstrations.  Agile testers also facilitate communication about tests and in-progress functionality to the product owner.   This doubly makes sure the software being built is what the customer will want.

In my case, I was fortunate to start my testing career as a release engineer.  I was responsible for finding blocking bugs in builds before they went to traditional QA teams for testing.  I became self-taught in exploratory methods (without knowing the proper name for this kind of testing).  I learned the name when I read James Bach's website.  I often seeded my exploratory tests by inspecting code diffs to find areas of change which required my testing.  It was a fun and efficient way to add quality to the system.  I also had the QA team backing me up so I knew I didn't have to find everything.  I found a lot though, and this allowed the QA team to focus on more thorough testing too!  All in all, it was a win-win situation!

From the above experience, I learned that what we now call agile testing was both possible and effective on waterfall projects.  They didn't really call us agile testers back then, just "development testers".

On any team where I work, I assess the strength and capabilities of the team and try to fill in the weakest area that have the most risk.  This is another agile practice:  basically it's called "being adaptable".  Agile team members cannot stay in their silos and work only in their areas of specialty.  With collective code ownership, everyone is expected to chip in and get started on the next most important task.  I really like the effect when the whole team is thinking this way!  There is still much more room for me to improve my agile testing practices.  Automation tools are getting better in that they require less programming to create tests.  Coaching and working on a team that does this well is one of my next goals.  Defining more testable stories is the other practice I see big benefit in doing better as a team.  I also want work alongside more traditional testers and coach them through the lessons I've learned so far, and the new ones that we can learn together.

At this point you more or less know what has shaped me into the agile tester that I am today.  In the next section I'll give you the URL to my LinkedIn profile.  With the context you have here, you should better understand each of the jobs listed on my profile.