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
 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?

Thursday, 11 August 2016

Its not Them, its US

 I usually put a negative rating, when a candidate uses "They" to refer to their existing companies. I have this issue even when the project teams across refer to each other as "They". It can be Dev is working on it, or QA is testing it but it never needs to be "They" are working on it or "They" have done it wrong. Its US, WE and if cant be that then a very fundamental question needs be asked.

Today I interviewed a girl for a QA position, I asked her what does your company do... and she started with "They" are into.... then each time I asked her a question about the team, product, project I hear this word "They". Towards the end of the interview I asked her a question "When you refer to your company as They is it because you are quitting or is it because you don't like them?" her answer matched her experience and hence there is no point in talking about it.

I always see this as an issue, if a team member starts referring to another team in 3rd person, or for themselves. In any case such reference just says you are connected enough. I also analyzed that the one who starts calling other team members as "They" sooner or later converts into a Loner, Anti-Team member.

Anti-Team attitude drags good from happening, it drags you into political war, it drags into un-productive conversations and debates. It yields US vs Them stream in your team, a high risk for a working team.

The "They" thing also occurs when someone does not want to be counted as a part of the team, at times to not be linked to a failure, embarrassment or has a feeling of superiority if not inferiority. Next time when one of your team member use "They" for another, stop them. Next time you interview a candidate who says "They" for their existing team / organization educate them.

For life is too large to accommodate your own as WE instead of THEY and it is too short to make it US vs THEM.


Lets do it forever

I have to deliver a product that will change the way of the worlds, problem is I am taking forever to deliver it. You lose the value of what you are doing, if you don't do it in time. For a few times in last few months I experienced how most valuable thing become useless, just because it did not complete in time.

We need to understand Agile much better to be able to value time. Agile is not about delivering in sprints, about creating iterations, about talking Agile, about telling how we scrum...

Agile is about iterating every day, asking for feedback and improving every few hours, getting a minimum value delivered every day.

Let's Agile, Let's not do it forever. 

Tuesday, 9 August 2016

Prioritize or Die

I was late for office, I had time given to a banker guy to meet me at work. I had to pick some stationary for my son, I had to go to the bank and deposit some money which I was carrying in cash, I had to make a call to a potential customer on the way, I had a report to send to my boss, I had a issue to be responded that affected a customer,

All of this was running in my mind when I was driving to work and every fraction a thought was triggering on why I did not read that " 7 habits of successful men". In any case I had things to do, I had important things to do. When I finished my day, I was left with 1 thing... the most important one. Priorities can be so much a killer, specially when you procrastinate or do not care about it most importantly if you don't prioritize.

Priority is usually a challenge, for most; this is just not natural. A husband and wife at the age of 45, staying in my neighborhood once told me that they lost both their parents and never had time to even sit and speak to them since it never made a priority in all the trips, travel, work and running a business.

Priorities are to be thought of carefully and executed with some level of commitment to avoid mess. Since my experience with messed up priorities I have always worked them out on a simple rating scheme.

Impact vs Effort : Higher the impact and Lower the effort makes it easy to decide the priority. A simple rule is to fit the items to be worked out in a simple chart

Every item goes into a simple table

Task                                 Impact Score                       Effort Score
Fix Issue with door            7                                            5
Shop clothes                       3                                           8
Pack Bags for Travel          8                                           4

The scores are then sorted by high impact and low effort and life can be easy to decide the priority. Most times since this information is never analysed before starting work, people tend to miss on priorities,

BTW there is no excuse to missing priorities for forgetting and procrastinating.



Monday, 8 August 2016

Why am I not on that email?

A few days ago, someone from my team IM me, in despair wanting to have a chat. I agreed. We went to a meeting room, where he raised his disappointment on why he is not on the emails shared between one of the project teams. Since I myself was not on the email, I curiously asked about the email. Wanting to know what was in the email, that a person has to raise an alarm. The email was about an instruction from one engineer to another asking for certain changes in a feature he/she was working on.

I was forced to ask a question, Why do you need *that* email to be sent to you? The answer was enlightening "I should know what is happening". A mistake many new managers do. They want to know everything that is happening, even if they are not required to know. But I was not interested in knowing that.

I asked another question "What would you have done, had you got the email in first place?. The answer not surprisingly was "I wasn't required to respond on that email" I should just be "For Information" on it. The killer was the answer to next question, I asked "Say you did not get this email, what wrong would happen?" the reply surprised "Nothing, But then I am not responsible for anything goes wrong, not for that thing but any other task that relates to people or task involved in the email"

I guess this type of thing is clearly an Identity challenge, someone immediately starts thinking if he/she is not on an email, means his/her identity is in danger. It means that his or her identity or existence is questioned and the threat comes from the person, who missed you in the email. A potential conflict. It may start with "why" and may end with him/her. I responded very clearly by mentioning that lesser the emails, better I can work, lesser the meetings, productive I can be, The lesser I am needed, the better I can innovate.

If the email is not asking me any question, answering any of my question, informing or alarming me about any fact there is no point in me having the email.  Next time you get worried about why you are not in a meeting or email, please ask the questions above before you get into a position of vertigo.



Thursday, 4 August 2016

Mind your meeting

I was called in a meeting a few days ago, a meeting to discuss the release plan. I went into the meeting only to realize I was not required there, a few moments later I realized a bunch of people in that meeting were not required there either. I waited to listen, just of curiosity to find out the meeting was not required. I spent 12 minutes end to end for that meeting, I spoke exactly 25 words 20 of which were repetition of an email I had already sent for the release plan.

Meetings have been a biggest time killer for me, I have already started avoiding them as much as I can. A lot of these meetings that get the first priority rejections are the one's that come in form of an invite without any agenda.

Last week when I finished reading Steve Jobs by Walter Isaacson I realized how important it is to not be in a meeting, when I started searching for a few articles around each of those elements that were covered in the book, I came across Gloria Lin's amazing response to a question on Apple's concept a very interesting tool DRI - Directly Responsible Individual in meetings. Someone who owns the task , agenda and drives the agenda item to an end.

But more importantly someone who makes the meeting meaningful. Off late I started observing what different people do in these meetings and found out..

1. A few pretend they are listening, but they are in back of mind thinking about how amazing sex they had last night.

2. A few don't just know why they are, but think maybe ahead something that relates to them would come up.

3. A few just hang in there, you know because "I was invited".

4. A few know they are not needed, but then they don't have anything else to do and this one is a big time filler in the time sheets.

5. A few have to speak as they don't want the one to have not contributed.

6. A few have a purpose but are diverted by use-less conversations, dragged to kill.

7. A few ...... who are needed, who value the meeting and who have objectives to take out of it.

The DRI should also ensure that no non-required entry is allowed. I like the tool. I hope and wish to use it. I look forward to lesser meetings and more productive use of my time.