Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.
Reflect on the Agile manifesto and it’s implication for my role. Today’s challenge strikes me as being approachable from a couple of different perspectives. I could look at it in terms of how the manifesto affects my day to day work, or I could look at it from the perspective of how it ought to affect my day to day work, or I could even look at it from the perspective of how the manifesto affects testing as an industry or how well my company as a whole does at following the principles.
For the purposes of this article, I’ll be primarily thinking about this in terms of how it ought to affect my work. What implication does the manifesto hold that go against some of the things I’m doing right now and is there anything I can do to change? What things do I do that align well with the ideas in the agile manifesto?
Individuals and Interactions over Processes and Tools
How well do I do this? In some ways I score high on this one. I really value individuals and interactions and I certainly value them over processes. I probably even at times shift to far away from processes. But tools? I love my tools! To be honest, I don’t think the manifesto is implying we shouldn’t have tools, but I must confess that sometimes I am too quick to turn to a tool when the job could (or should) have been more easily done through interaction. I guess in some ways I also score low on this one.
I do well in valuing individuals and interactions over processes, but I need to continue to grow in having my response to seeing a problem be about how we can solve the problem instead of how I can solve it. I like to strap on my tool belt and get down to business, but without collaboration, am I really following agile principles and (more importantly) am I really being as effective as I could be?
Working Software over Comprehensive Documentation
I very much value working software (what tester doesn’t?) and I’m not a documentation kind of guy. I dislike exhaustive test cases – they feel wasteful to me. I’d much rather do the testing (and record notes on it) then write about the testing I’m going to do. I think this principle does guide a lot of what I do in my day to day testing. Do what I can to get working software and figure out what level of documentation is necessary for effective communication.
Customer Collaboration over Contract Negotiation
I’m not sure how much this one applies to me. I don’t have a lot of direct customer interaction, either to collaborate or negotiate. I would think that I’d value the former over the later but I don’t have a lot of experience in either realm, so I’m going to move on to the next one.
Responding to Change over Following a Plan
I like having plans in place, but I think I’m pretty good at ‘rolling with the punches’ so I guess this one is pretty good. In my own personal life, I’ve actually had to shift a bit more towards having plans in place so that the tides of change didn’t just push me around. In thinking about this, my personality is probably such that I might even take the responding to change thing a bit to far at times. Sometime having the discipline to stick with something for a while longer, rather than changing plans or directions will get better results in the long run.
Conclusion
So in reflecting on the Agile Manifesto, in my own estimation, I came out better than I would have thought going into the process. I guess my values align pretty well with the agile philosophy. I just need to keep working on putting it into practice and working with those on my teams to become more ‘agile.’
offbeattesting 