Monday, 20 March 2017

10 things I learned from being AGILE.

10 things I learned from being AGILE.
  1. I do not have to worry about knowing everything about the product / feature right at the beginning. I can take my time to learn the product feature by feature. And get to learn together with the team and from many about the product right from it's discovery phase. 
  2. AGILE is almost like studying myself. What works for me and what doesn’t. And to learn dynamically to make necessary changes when needed.
  3. Learn on the GO what technique / method / approach works for that context and discard the rest.
  4. Switch to the right sources of knowledge. It's about also being a pendulum when needed, shift left / right to deliver.
  5. To not buy the garbage, but question and learn than mere adherence. To go figure out who can help, to have my own point of contacts who can help and to network with the learned. This means - To be DRIVEN.
  6. AGILE - Is not the ultimate rule book of do’s and don’ts.
  7. Quick and dynamic is what it makes me in how I begin to do things (requirement gathering to release and beyond). 
  8. To invest and better my own learning. To work on improving the code, the tests and the rest is good. 
  9. There is a good kind of urgency in Agile, to get things done.
  10. I can be honest and not be questioned for being honest. In the planning meeting, I can freely / honestly share my presence and absence plan. It makes people honest and keeps them that way.
Finally, 
When taught well we can learn from this professional experience of being agile and make other aspects of our life better.
Do not be blinded. 
Figure out what works for YOU and apply it.

Tuesday, 14 March 2017

Problems are short-lived.

Problems are short-lived.
  • If we genuinely wish to resolve it.
  • Find and learn ways to solve it. And in the process of solving it, learn and equip oneself to address the problem if it recurs.
  • Communicate and seek help to learn ways of resolving it.
  • Set out to tackle it head-on post equipping oneself.
  • Set a target date for it to be resolved. So we can move on to solve the next one.
  • Learn from anyone equipped to address it, without a bias.

Here is an experience sharing of how I tried to address a problem.

Gung-ho
I tried to recently help an employee who was in trouble and had called to ask for help stating 'You help everyone and hence I came to you'.
I was happy go lucky, trying to help others. The joy I got when their problems were getting resolved and the feedback I was receiving was enthralling. Without re-thinking, I was willing to help this employee too.

While I was away, the same employee threw a temper tantrum which arose from an unfulfilled *ask/want. When I came back in office, I tried to address the problem which the employee had shared over the call. I wished to help and address the problem face to face in a benevolent way.

(Later did I learn that the employee was not performing few tasks because it was not something that the employee wanted to do to get to the next level). *Ask/want, was to get promoted.

I believe that 'there is no professional problem which effective communication cannot solve'. And clearly effective communication was not happening because the employee when we met to resolve the problem was firstly talking continuously. (Yes, this means less listening).
Secondly, is reading too much into my facial expression (which as I am well aware off, reflects nothing but what I communicate and utter justly) and conveying that 'I know what girls are. I can read their facial expressions and derive what they say and mean do not match'.
It has thus far not happened to me, that I said something and meant another thing. I am direct and say what I mean at all times.
Am there and fully present, listening to the employee and have offered to help and this happens! And the employee continues to demean.

A few days ago, there was no need to offer kindness in this situation (as I was away and did not have face to face connect with the employee) but training only. This time I did offer kindness to the employee and professionally. I conveyed to the employee that I am here because I wish to help. And left the room thinking 'All this I had to listen to because I tried to help you out in your difficult situation!'. What I did do was, respectfully listen to the employee, the concerns, immediate action points for both of us, convey the do's and don'ts and leave.

I recollect what I learned at Fiona Charles workshop at European Testing Conference on Leadership, from management related tweets of Esther Derby and blog posts of Johanna Rothman that it is so much better to not heed to the negativity around and move on to what you set out to do. This allows me to focus on the good and rest the rest.

There are territories one must not cross as a leader when problem solving, like the one's mentioned below.
Offer to help those:
  • Who do not wish to learn - (How can tutoring help in this case?).
  • Who have a 'i-know-it-all' attitude - (Who can tutor someone with this kind of perspective to problem solving?).
  • Whose confidence you have not gained yet.
  • Who are brainwashed time and again (they are in a vicious circle).
Moral:
Do what you set out to do, but beware some do not want to be helped.
Invest your time where it's worth it.
Ignore the negative and give a listen to this song 'What a beautiful world' by Louis Armstrong :)
Truth be told, be kind. BE KIND to yourself, so that you can be kind to others.

Wednesday, 22 February 2017

Mindmapping And Common Pitfalls To Avoid

There was one occurrence of plagiarism of my work. A blogger by mistake had passed the blog and map I had shared, as their own. I felt bad for that person, if I had mentioned my name or had personalized it (with my signature / logo) then I would not have put that person in that situation. 
I am to blame as I shy away from making my work copyrighted / add a signature. 
My knowledge sources are many. I refer books, articles, watch videos created by others, learn from many and from their experience. My credit goes to those who share their learning, which constitutes almost every learner. 

Another incident that triggered me to collate common pitfalls to avoid when we share our work with wider audience is when I posted my own work over a year later without revisiting it. A learner from the community TeemuVesala reviewed and provided with input to revise it. Thanks Teemu.

Based on these events plus the mind map exercise that we conducted at my work place, as a result of which I got to pair with DanAshby to review the mind maps has helped me create the below mapThis can also save time, effort, reputation and credibility when we share our work.


Click on the images to view it in it's original size.



Friday, 17 February 2017

European Testing Conference 2017

I have earlier shared my experiences with conferences (local and others) but being at European Testing Conference was a tad different experience as a speaker and as a participant.

As a participant

What I liked?

Attendees and speakers got to attend the workshops scheduled on pre-conference day.
The workshop that I chose to attend 'Test Leadership' helped me share some of the problems that I have had with my stint as a tester, test manager and a leader.

Special mention of Speed meet.
  • One goes to conferences to listen and learn about new tools, new features of an existing tool, to learn about techniques first hand from the creator, speakers and volunteers who have signed up to teach.
  • To find solution to a problem that they are facing.
  • To discuss problems and meet people who can help them build something together.
  • Speed meet gave such an opportunity for the conference goers to meet a mentor / friend who can help them learn.
  • This meet brought many Twitter friends closer. Mostly the introverts / ambiverts to share about themselves.
  • At conferences we witness many rushing from one talk to another. If lucky, we get to spend time with a mentor and learn from them during the break/s. At ETC, breaks were scheduled to accommodate such meetings to happen frequently. It was great to see people come out of a talk and share their learning with others who were in a different talk. I listened to three attendees from 'Mob Testing' workshop during such breaks.


What Lessons I Learned?

To take 'me time' to learn lean leadership and to use that time for strategic thinking (that I learned from Johanna Rothman 's blog) even when there are interruptions.
Learning to say no, different ways of handling interruptions.

Many suggestions were shared by the audience and Fiona Charles who ran the workshop, on handling interruptions.
Some suggestions were to use the below methods to let your adhoc audience know that you are now available / not.

  • Red / Green flag at the desk.
  • Flag up / down.
  • Head phone on / off.
  • Block your calendar.
Participants from around the world shared book references, articles to read and techniques to learn and use for some of the problems shared in this workshop. Glad to have been a part of this workshop with Fiona and the attendees.

What I liked and learned from?

Fiona and her way of running the workshop.
Listening to your audience and letting them converse and share their experiences is very much needed when we run a day long workshop.
Providing your feedback when needed and when you have something valuable to add is what I learned from both Fiona and the audience.
Keynotes by Kevlin Henney, Gitte Klitgaard and Fiona Charles.
And I did love Finnish culture which is different from where I come from and is grand.

As a speaker

Instant feedback for my talk from the organizer Maaret Pyhäjärvi was valuable.
I could with the help of this feedback, convert the talk to an exercise during the Open Space which was held at the end of Conference day 2.
I was introduced to Market place for the first time here.
Market place is where the willing participants come forward and ask for knowledge on specific topics to be re-shared. Mob testing / programming, Calabash, Creating and using re-usable mind-maps were topics that I recollect were talked about again. 
Thanks to participants few of whose name I recollect Sergey, Evgeny Borisov, Miroslava Nikolova, Vivien Ibiyemi, Ru Cindrea, MaaretP, Kevlin Henney, Bettina Stuhle, who were present at my talk and provided feedback.
Loved speaking to this audience, I just wished they would be a little interactive. Later did I learn from Kevlin Henney that the Finnish audience is a bit different from the US audience where I had earlier spoken at. Lesson learned, I have to change my style of delivering the talk differently based on the audience and where they come from.


Overall

A nice experience conferring at ETC 2017.
Gained confidence to change the style of the presentation on demand and based on the feedback and deliver at Open Space. 
Met a lot of brave and independent people from the community, learned from them a lot professionally and personally. 
Met leaders from the community and made new friends.
Learned that I can help the community in my own way.

LLewellyn Falco, was a grand host and organizer of the conference. From this experience, I learned to extend my help / support to two leaders who will be conferring in Bangalore, next month.

My thanks to
Mentors Carsten Feilberg, Isabel Evans for their valuable time and guidance. 
All my friends at European Testing Conference who equipped me for Finland. 
The organizers (all involved) who facilitated and provided with timely help. 
My organization who gave me time to be a part of this learning.

European Testing Conference comes to Amsterdam in 2018, stay tuned and to know more:
Follow EuroTestingConf on Twitter and hashtag #ETC2017 #EuroTestingConf #eurotestconf
http://europeantestingconference.eu/2017/


Image credits:
Photographer, Twitter, Llewellyn Falco.
Speedmeet

Thursday, 16 February 2017

A few tips to mindmappers

As I started out to mind-map the test ideas for a feature that I was testing / learning to test, many lessons were learned and are now shared below in the form of tips to use when we create or reuse mind-maps created by others.

Reviewers and the community of learners helped shaped the way I today create maps.
Some of them from the community who read / used the maps provided me with valuable feedback which are incorporated in my learning and is brought to you in the form of these tips.

Hope these tips can help when we start out to build a map and share it with wider audience.


























Make it generic - Here it means, do not feed your audiences with steps to re-create but only act as a trigger to move on with an idea to test.





























Earlier shared at European Testing Conference
Slides:
http://europeantestingconference.eu/2017/topics/#jyothi-rangaiah
http://www.slideshare.net/JyothiR2/creating-and-using-reusable-mindmaps

Coming next - Common pitfalls to avoid when mind-mapping.

Thursday, 26 January 2017

How to pick a mind mapping tool?

For those of you all who are starting out to mind map and like to know what tools are available and on which devices/OS, here's a non-exhaustive list of mind mapping tools collated. Hope it helps you pick a tool that you can make use of.

How to pick a tool?
  • Make a list of tools to explore
  • Shortlist few based on the device / operating system you use
  • Explore the features available
  • Compare it with the rest of the tools available
  • Choose one that best fits your need
  • Use it for free, check the features available in the paid version
  • Try to use other tools when in absolute need
  • Continue to explore a new tool that's made available
  • Contribute to the open source community by suggesting improvements or by reporting bugs found
  • Get in touch with mind mappers (mind mapping community) to learn what / how else they use the tool
  • Engage with the learned to learn tips and tricks


Mind-mapping tools
Click on the image to view it enlarged.