This post is an excellent example of procrastination by choice. There is no story as such. Just an attempt to solve a puzzle in my head. This post is for all my testers friends who are choosing / moving / pushed to play different roles in Agile contexts, and the new role might be very different from that of a software testing professional.
If you are not one of those friends/connections/acquaintances, you may stop here and read something else more helpful for you. But, probably, this article, even remotely, may be beneficial.
I propose to read it, and you decide for yourself.
Let me begin…
Some of you (my friends) might haven’t read Context-Driven Testing (CDT) principles. Yet, some of you were performing testing aligned with CDT principles. So if you don’t understand what CDT is, help yourself by clicking https://bit.ly/CDTPrinciples and staying for a few minutes at the landing page.
Now, suppose that, in the past,
- You have practiced testing in alignment with Context Driven Testing principles.
- You demonstrated decent self and people-management skills.
- You solved some problems of some size, importance, and urgency daily.
- You understood what it takes to exist in a cross-functional team. One meaning, to me, is to continue developing different skills.
Then, I guess, it might become easy for you to start gracefully and firmly in ever-growing agile contexts within the software development space.
If you have ever talked to me about this before, I would have said the following to you.
Please don’t forget Context Driven Testing principles.
I usually prefer to remember them in the order of 3-6-1-2-7-5-4
But, of course, you may have a different order or may not be. As long as your testing is aligned to those principles in your context, that’s perfectly okay.
Please read the Agile manifesto carefully, and think of a value (left over right) that you haven’t learned (directly or indirectly) from CDT principles. Please note that I am not saying to look for a direct 1o1 mapping here :).
For example, pay attention to ‘Individuals and interactions over processes and tools.’
Note: Whenever something inside you tempts you to call something a law/standard/custom in Agile, remind yourself of this statement published on the top of the manifesto stating,
‘We are uncovering better ways of developing software by doing it and helping others do it.’
If you become ScrumMaster, please remember that you are first and foremost a facilitator in this role. From Jerry Weinberg’s books, I got to know about three types of management. Micro mgmt., Motherly mgmt., and Masterly mgmt. So, if you ever choose to be a ScrumMaster, you would want to play a Master Facilitator role. You would want to empower and enable self-organized teams to flourish within the culture.
**I am not, by any means, an authority on ScrumMaster role’s do’s and don’t, so let me stop here, for now.
I am still looking for credible references for the Product Owner role to understand this role better. For now, I am content with https://bit.ly/PO-TA-DEEPTEST.
If you have become a PO/PM by now, can you help me by posting some credible references in the comments section? Please make sure that those references are at par with what I posted so far 🙂
For the Business Analyst role (if that exists in Agile contexts), I may wish to connect you with people who identified customers’ real problems, proposed reliable solutions, and helped teams deliver those solutions. I worked with some of the very humble, down to earth yet highly knowledgeable business knowing leaders. They are still focused on their new missions, as far as I know.
In parallel, you might want to read and make sense of the following laws [https://bit.ly/LawsofSD]
- Conway’s Law – My all time favourite and I am trying to understand
- Ziv’s Law – I recently came to know about and sounds very familiar to me. How about you?
- Humphrey’s Law – Reading now!
The important thing: Please start / resume conversing with the people who bring money to the table. We call them salespeople. They know that the successful culmination of any job is to the outcome of collaborative work on many fronts. They know that people buy from people. They usually know more about the business while testers often focus on functional aspects of the products. You may want to spend good time with ‘Sell‘ by Subroto Bagchi.
Did I not tell you that I am just attempting to solve a puzzle in my head. I am not successful yet but you my friend should have got some ideas by now.
Signing Off for the day.
testing journey Redefined 