Wednesday, 15 November 2017

Hold the snafu


Communication can never be easy, especially when you are working over phones, Skype and other such media tools and I don’t say its only verbal communication. A week ago my wife asked me over whatsapp
“On your way home, can you bring some tablets?” my reply “Yes” and we ended up in a late night fight when I asked her “what medicine? O that one?” No it was not a problem of commitment vs delivery it was a simple issue of communication. Going by the regular expressions as we follow in India, my answer was “Yes, I can” I never said “Yes I will”.

The more I work with the teams, the more I have realized that this is really a standard. The Yes has variable meanings here.

Yes = I understand
Yes = I know
Yes = I will do it
Yes = May be I can do it, I will try
Yes = Maybe I will try

The same rule applies to 2 mins… and no when I say the same rule applies, when I ask my wife how long it will take her to be ready to go out, that’s the answer I get. I have embarked a few 2 mins rules going by such experience.
2 mins = now
2 mins = 2 hours
2 mins = tomorrow
2 mins = never
The same rule applies to “Right”

Right = Correct
Right = Right Hand side
Right = Straight [Specially if you are down south in India]
Right = Go Ahead

Over years even “OK” has frightened me. Last time I asked a dev “That POC will be done this week? His answer “OK”. Only when I went to him to question about it, did I realize that he meant OK as in it is OK and not that he will do it.

Even “I will “is a threat at times, I will doesn’t guarantee the time, it just guarantees the intention only. Next when you work with remote teams make sure the expressions are handled and understood well.    
Or be ready for the snafu

   

Thursday, 8 September 2016

Mahabharat - The Epic Tale

I first read Mahabharata a few years ago (Not to mention I have seen the TV show that used to run on Doordarshan). The Epic story never stopped fascinating me. Each time I read, it intrigued me to look at a different perspective of life... My reading of Mahabharata was a Pandav driven perspective, until I was introduced to "Mrityunjaya" by Shivaji Sawant a point of view of Karna. The book enlightened and I had a feeling that Mahabharat is not just about Kaurav and Pandav's, it truly meant more. More than a myth, an epic story, a political saga, a display of passion and greed. Mrityunjaya made me think there was another hero in this story, Karna. Not that the Mahabharat projected him as a villain, but then who fights for the evil is also termed Evil.

Then came  I was introduced to Devdutt Patnaik's Jaya. Mahabharat with a different angle. Devdutt patnaik, kind of challenged the belief of Duryodhana as a villain, yet gave a lot of details that were never told in earlier books I read. Then I happened to fumble over "Palace of Illusions" by Chitra Banerjee an English book on Mahabharat from Draupadi's point of view. Whilst a lot of the content in this book appeared superficial, I was amazed how a perspective changed the villains, affiliations and allegiances between people. Ignore if someone tells you this book is shit, you still got to read it :). A year or so passed when I stumbled upon "Ajaya - The roll of dice" this was Duryodhan's point of view and what an amazing one. Yet again in the battle of good and evil, perspective can be so important. This also made my belief stronger that your behavior is controlled by where you see things from. Ajaya is one of the good books I read on Mahabharat. Months between came "Yuganta" a marathi book by Irawati Karve, this is a wonderful book that portrayed bheeshm, Kripacharya, Dronacharya and others in a very secular light. I enjoyed this book and yet again the battle between if Mahabharat was ever about Good vs Evil started. My stop on Bhyrappa's "Parva" was a new way to see Mahabharat without any magical elements, no curses, no divine elements. Although I read the marathi version of this translated by Uma Kulkarni, I am very sure it would not be any different in Kannada.

My next stop was "Yugandhar"  a book in marathi and from Krishna's perspective. I think this changes the flow in which we think about Mahabharat as you then start lining up events to justify or judge good and evil. A week or so ago I ended up with "Duryodhan" a book in marathi by Kaka Vidhate... Now this book is not just a fascinating tale, but also an epic narration by several characters (majorly Duryodhan), just adds fuel to the thought process on was Duryodhan really evil or Mahabharat was a dirty political saga.

My curiosity just doesn't end, reading so many articles and short stories on this Epic, I ended up creating my own wish list.. Books I still have to get my hands on, here are a few names...

Randaamoozham - They say this is a malyalam book having Mahabhart from Bheem's point of view.
Kapatneeti - A marathi book, that gives a detailed view of politics of the time.
Dhananjaya - Arjun's point of view
Radhey - Karna's point of view.
Yajnaseni - Draupadi's point of view
Jyeshtha - Yudhishtir's point of view
Karna's wife - Vrushali's point of view
Shakuni Shuvala - A baloch version talking about the Gandhar prince
The Winds of Hastinapur - A feminine look at Mahabharat
Kounteya - A Tamil book with a Point of view from Kunti

If you know more, do let me know. I would be glad to add up to this list. 

Tuesday, 30 August 2016

Brainstorming is not Q&A, Don't make it one

Crowd sourcing ideas is an effective way to innovate, but do brainstorming really create the required effect? This has always been a question to me, the brainstorming sessions I am required to attend for the product feature work we do, at times just sound like Q&A sessions, they lack the luster, effectiveness and are always around the first idea that gets discussed on how a feature need to work.

Typically the product group would organize the session with the internal team, One of the tester (also sort of semi owner of the feature) would give a brief about the feature, a small discussion would then take place of how, where and who and that's when the shit hits the fan; questions start pouring in one after the other, all of these questions are really different scenarios and typically when no questions are left the brainstorming is concluded.  

Anchoring is what causes this damage and kills the objective behind the brainstorming itself. It always is a challenge in brainstorming sessions, something like the 1st idea that gets discussed is the one that kills the creative originality of any potential idea(s) that could turn in later. Once the first idea hits the floor, everything you discuss is around that idea.

A brainstorming can be made effective by:

1. Right People
Involve the right people, one that are spectators would not be of help and may just divert the focus of the group by asking questions just to prove that they are a part of the group discussion. People with appropriate knowledge in given area are needed to be given preference over those in the org charts. Senior Managers should be given a attendee hat in the first part of the session, to avoid the low hanging fruits getting picked first and diverting the focus.

2. Divide in groups
Brainstorming sessions are effective only if the group is divided and has different ideas on the table to discuss. Brainstorming can be more effective in a group divided with different base ideas, allegiances.

3. Cap the time
A time cap should be levied on the participants, so the brainstorming isn't hijacked. Ofcourse the moderator can allow participants on a case by case, but then the vocal participants can end up taking over the session and at times without having fruitful discussions.

4. No repeat, No Blocker
A lot of brainstorming sessions end up repeating the same ideas, topics, points by different attendees. This is a NO GO. Just moderate when that happens. Ideally a whiteboard can be handy so everyone can see what is covered and what is not. I attended a brainstorming on City Civic issues and the group actually put up a list of items they wanted to cover, allocating time to each point. Everyone was free to add to that list but the moderator was deciding the time. This gave a good start as several ideas started turning up when some items were discussed and by the end of first 3 ideas almost 20% of items made new to the list and some got dropped.

5. Conclude
Never forget to conclude the brainstorming. If no actions, no tasks , no objectives or goals are defined within the brainstorming session, likelihood is you have just wasted that time with no yield. List the actions and dont forget to follow up.

A few dedicated effort in preparations, organizing the topics, execution can help the brainstorming be fruitful. The goal needs to be concluding post all ideas are discussed. I have also liked Candour a tool to collect and collate ideas. Next time you are brainstorming, turn the Q&A to a real discussion. Share your ideas, just not be interested in questioning or challenging others.

Thursday, 18 August 2016

Know your tools

A colleague a few days ago passionately spoke to me on how we don't have access to new tools that are storming market and provide some amazing features. I could not disagree for the world of internet always fascinates me with its offerings. Our discussion had started around "what do we do to make our tests better"specially to have a stimulation to our customers usage patterns or infrastructure, New tools, processes, technologies would certainly help, but then when we have new things do we really exploit them to the best? Did we try the best out of the old ones? is switch to the new thing, just arbitrary?

Years ago, we were using Charles as a web proxy to find out what was happening with our web application on every request. We swiftly moved to fiddler (For many in our team don't remember why this transition happened or since when we started using Fiddler or even why Wireshark was not chosen over Fiddler). The answer then was our webapp testing needed 2 things

1. Decrypting the traffic
2. Ability to view the request and response headers and info in a seamless way

Both these features were not provided by Charles then, the Internet Developer tools on browsers were not complete and Charles was memory expensive. Fiddler on other hand was turning light. When it comes to Charles we still have a feature or 2 that we miss in fiddler and that is where knowing these tools is so important.

Throttling your bandwidth   is one feature we can use and use it effectively using this proxy to ensure we test in a closely stimulating environment. Our customers who are located in desert areas and using the tools, would be having a very unpredictable bandwidth and latency and Charles allows you to configure this. SO much that it can let you define the bandwidth and the latency in which you can test your product and tell how the performance is if not set a defining benchmark if it works.

A small feature from a tool can be so important in defining how your product can shape.. but then.... Do you know your tools? Well Enough?

Wednesday, 17 August 2016

Scrum : Who is for what?

Scrum very clearly defines a simple rule for the attendees and the participants. No unwanted noise. When the scrum guide states "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum. The Daily Scrum is not a status meeting, and is for the people transforming the Product Backlog items into an Increment." It really has a reason. Most scrums I just see it ends up becoming a Q&A session. Majority of times it is a status update meeting, for all those who want to know what is happening in the project, this sounds like the best time to know the details.

Scrum to be effective needs to be technical. Really.  Dev teams need to discuss line of code, architecture, blockers, dependencies. Things that managers don't understand. The scrum Master also need to be a bit careful on who to allow as a participant and who to allow as a attendee. For most times I have found myself getting into a scrum as an attendee only to be tempted to participate. This temptation, I surely see cannot be survived by many and they end up driving a scrum to an endless and slightly meaningless turn.

I always suggested our scrum teams to take some discussions offline, maybe as adhoc post scrum meetings, just so there is no time wasted for everyone in the room or even the development staff that has no need of listening to it. A scrum can really go long when there is no censor over the attendees and participants... I drew a small table suggesting how a scrum meeting longed with different attendees and participants...

 Attendee / Participant
 Impact
 Additional Time
 Product Owner
 Questions, Clarifications, How to do, what to do kind of discussions sneak in.
 10-25 mins
 Leads / Managers
 Questions like What are you working on, what is the status, when will it be delivered, etc. etc.
 12-25 mins
 Non Team members
 Updates from other products, questions or discussions that have no team connections
 5-10 mins

Your scrums are to progress the backlogs. Your scrums are to list and help remove impediments. Your scrums are to be on same page in regards to the tasks in hand. Your scrums are to make the hustle effective. Your scrum gives you ability to show what is stopping you and move further.

Scrums are not for Status updates, Scrums are not for non core members to get answers from core teams, Scrums are not for planning projects or discussing solutions.

If your scrum is short, it will be crisp.
If your scrum is objective, it will be fruitful
If your scrum is balanced, it will be result driven...


Start scrumming, not mobbing.



Tuesday, 16 August 2016

What is non-negotiable?

This performs a bit slow, I left it there.
I think we can address it for future.
Well it has been like this forever, I know its trivial work, but I dont know if I should touch it.
I had found the issue, but thought it was too trivial to stop the release.
It was going to be too much work, so I did it this way.

When you start hearing this, and many such things; You have to be warned that you are on the wrong side of the road. And if you dont realize it, this one should be a NON-NEGOTIABLE one as well. Quality is important, and most time overlooked. Walter Isaacson in his book "Steve Jobs" mentioned each time Jobs did not like something or found something was not up to the mark he called it "SHIT"

There are several things in a project / development lifecycle, that purely needs to be seen as NON-NEGOTIABLE, yet we choose others over them.

Time over Quality
Scope over completeness
Technology over Usability
A brainstorming session over documented specification
A hurriedly completed feature over a value emitting function

and each time we make this negotiation, we create a great deal of debt, Technical Debt that is hard to manage. A project team needs to decide what is negotiable and what is not. In a lifecycle we have and would always come across things that would need to be ignored, at times prioritized low, or be compromised. But these are situations that put your basic attitude towards development to test. The day you start negotiating quality, is the day you lose focus to success. Rest can still be achieved, still be raced to, still managed. Quality cannot be.

A typo on your login can be more embarrassing than having missed a button to cancel a process. Quality needs to be seen as oxygen to your product. When you start juggling the oxygen, you are prone to faint, if not seize to breathe.

Think over, next time you are in a compromising state, you negotiate and what?