Part 6 Workplace Challenges

Part 6 Workplace Challenges

77. Visiting Cards

One of the projects I contributed to during my initial years was a contact management system. It was about porting the whole system from dBase II to dBase IV.   Starting mid-80’s until mid-90’s dBase was a very popular database management system. In fact, it was one among the first and most successful database management during those days.  I had some experience in dBase and UNIX and that is what qualified me to take up the porting project.  If you know, most porting projects are one-man projects.  As you can guess, I was the only team member on my project.  And that too on a part-time basis.  I spent 4 hours per day and attempted to complete it in five days.

When I started on this project, I could understand that the earlier system was developed by someone couple of years ago but it was not implemented. There were no active users. There we no bug reports.  I moved the code base to dBase IV and resolved all compatibility issues.  Many of those issues were very small but irritating ones.  Luckily I was all set to complete my work a day ahead of our plan.

My boss came to me on the fifth day and handed over hundreds of her visiting cards and wanted me to enter all of them into the new system.  She wanted to give a life to the system. She wanted to demonstrate the system – with live data, to her administrative assistant.

When this task of entering data came to me, I was hesitant but understood the crux of the matter. Some of my friends did not like that idea, as data entry was a task meant for someone else in the organization.  I had no time to rethink or burn the bridges.

Fortunately, I had undergone a short course on typewriting when I was in school. So, I was faster and accurate than anyone.  More than that, I was there to make a difference. My boss had the trust to reveal all her contacts to me by sharing all her visiting cards.

I took it. It was not exercising my brain in anyways over those two hours on a Friday afternoon.  Nevertheless, I came across a handful of interesting bugs and fixed them too. That step assured us of a smooth roll-out.

Two years later, when Oracle relational database management system entered Indian IT industry, I was one among a small group of engineers selected to undergo a two-week training program facilitated by Oracle – yes, those trainers were from ORACLE Corporation, Redwood Shores.  After this training, I built the next version of contact management system on ORACLE 6.0.

Do you believe in seeing challenges as opportunities?

*-*-*-*-*

78. Fresher’s Aspiration

Later in my career, our team recruited several fresh engineers. One of the questions we used to ask – we do that even today, was to understand the candidate’s aspiration. That day, my colleague and I were interviewing a group of fresh engineers one by one.  As our day ended, we observed one thing. Almost 90% of the candidates aspired to develop something from scratch.  Yes. The answer sounded like, ‘I want to develop something from scratch’.  What is that something? There was no concrete answer or options from anyone.

According to industry statistics observed by Capers Jones, 80% of software projects in our industry are maintenance or production support project. That is the reality.  That applies to organizations of all sorts including product development companies, IT services companies and MIS departments in big corporates.

Aspirations motivate us to accomplish great things in life. When it comes to working in organizations, we must understand the ground reality and embrace what is in store for us. Or go behind our aspirations, take the harder path and experience life.

This discussion does not stop at interview rooms. Aspirations keep us alive.  We constantly validate our aspirations. My team members have met me several times to seek ‘development from scratch’ kind of projects. I have done my best to accommodate them.  Meanwhile, I have encouraged them to come up with ideas and implement some of them on their own.  These days, every one of us have a computer. Gone or those days when we used to timeshare computing resources.

If you aspire to build a new product or application and if you are lucky, you get that opportunity at work. Else, take the initiative to try it from home after work hours or during weekends? Why not? Path breaking products emerged from garages.   And many organizations encourage when you demonstrate your ideas. When you do that, opportunity will come on your way!

Aspire! Understand the ground reality! Never give up!

*-*-*-*-*

79. Transformational Progression

Sometime ago, when one of my colleagues and best friend Vikram was managing a team, an interesting incident happened to one of his team members. Vikram had some expectations on his team member who was in a dilemma. A sequence of events unfolded in his team member’s career subsequent to his meetings with Vikram. That inspired me to narrate a story on that as told by Vikram ‘s team member. I named it Transformational Progression.

Here it is for you.

I am alone at my desk after work on a torching summer day.  My colleagues have gone home. I like the silence around me. I want to stay longer.  This has never happened to me in my previous years in this organization.  Inside me, it is a strange feeling.

Scanning through my emails, I see an old email from my new manager, Vikram.  This email came to me two years ago when I had completed my first project and was waiting for the next.  He wrote that email to discuss with me about my next project that day at five in the evening. I vividly remember what happened that day.

Vikram, a well-known manager and expert, was strict and stubborn I thought as I entered his cabin a minute before five.  He greeted me tersely, closed the door and asked me to sit.  I was restless and curious.

“Anil, we are going to start a new project. And I think you have a key role to play here.”

I wanted to interrupt before he started telling me about the new project. I wanted him to know my aspiration. And I did that.

“Vikram, I wanted to talk to you too. I am interested in some work that involves design and development in Java or Python.  I am good at these and that’s what I am interested in.”

“Well, Anil. Listen to me.  I understand your interest.  All of us are software engineers. We are not specialists in certain areas.  We serve our customers. We do what is good for our customers and their end users.  Right?  This new project involves technologies related to your areas of interest but not exactly Java or Python.  This is about designing and developing a test automation framework.  You are going to use programming languages which are similar to Java or Python.”

“Vikram, this is not my core area. I am concerned. A project like this would ruin my career.”

“Anil, Think! You have spent less than three years in this industry. You have more than 25 years of runway. What you are going through is sort of an infatuation. You have some more years to transform and understand your profession.  Doctors do not choose their patients. They consult, provide first-aid and save patients. In certain cases, they refer their patients to specialists. I think this project is going to give you an edge over your experience and an opportunity to prove what you are and grow.  In no way, it will ruin your career or degrade your resume.”

With no words, I remain silent nodding my head. And he continued.

“Professional ethics are in every field. I am sure you must have read through software engineering ethics.  We are here to act in a manner that is in the best interests of our customer consistent with the public interest.  This is a strategic project of our customer. Your contribution is going to make a difference.“

What he mentioned made sense. But I was reluctant. I wondered if he was acting on his self-interest and trying to convince me. I remembered one of my friends came across a situation like this, found a job elsewhere with some pay rise and resigned a month ago. How about that option? A pay rise!  I wanted to take some time and think. Why not? After all, this world is full of opportunities for someone like me.

I paused there for a moment before I responded.

“Vikram, is it ok if I come back to you tomorrow morning?”

“That sounds good to me Anil. I am sure you will think over it and grab this opportunity.”

I know. Vikram believed in collective decisions. He never pushed his decisions with his power of authority. That was the culture here.  All managers were enablers and coaches.

I wanted to discuss this with my father or elder brother but decided not to. I wanted to think and decide it on my own.

That night, I reflected on my meeting with Vikram. He was right.  He believed in my capability and showed genuine interest in telling me what is right. He did not push me with his authority. He was ready to help. His point of view made sense!

The next morning, I went to meet Vikram.

As I entered his room I looked at a quote written on his white board.

“Opportunities don’t often come along. So, when they do, you have to grab them.” –Audrey Hepburn

I smiled.  We had a very short meeting and I accepted the new project.

Working on that project was an exciting journey. I could collaborate with my customer team – a team of developers graduated from some of the finest international universities. I learned a lot about the architecture and design of our customer’s product. With my team members, I did the right things to implement a world-class test automation framework.

Meanwhile my friend who got a job elsewhere found his new job uninteresting.  He made another hop. Whenever I met him he was jittery and restless.  A year after he came to meet me. He was confused and concerned about his growth and wanted to come back.  All, I could do was to forward his resume to Vikram.

Until we accept our infatuations we are bound to remain infatuated. That is my reading of my friend’s situation.

Today, I am sitting alone. I am enjoying the silence around me in my office.  I must tell you why.

As I entered my work areas this morning, Vikram and my team surprised me with great welcome.  They took me out for lunch, and presented me some gifts.  Late in the afternoon, our vice president came by to congratulate me for a reason unknown until Vikram announced my promotion and gave me the promotion letter!  Yes!  A promotion!

I am overwhelmed. It is going to take me some more time to digest. I am happy. I think I did the right thing.  Inside me it is a strange feeling. I call it ‘transformational progression’. I am going through this feeling or I have gone through this.  And it is memorable one!  Vikram helped me move out of my zone of infatuation and guided me through this transformation!   I am going to stay an hour more, enjoy this silence around me before I go home.

*-*-*-*-*

80. Five years’ .Net Development Experience

I have seen Anil’s dilemma in everyone. Once my team member with five years of development experience in .Net platform was stuck. He was stuck with the ambition to hold on to his area of specialization. He wanted to continue. He had opportunities to learn other similar technologies and become an architect. He had opportunities to develop and maintain software across multiple platforms and devices. He was stuck. He wanted to continue what he did.

I shared this earlier. Let me repeat. When I began my career in 1988, I wrote programs using the C programming language. In 1991, I acquired skills in the UNIX operating system and Oracle RDBMS. The next cycle of technology change came sometime during 1996, with the release of Netscape Navigator, followed by several application servers. In 1998, I picked up skills in object-oriented programming and Web technologies. That helped me stay current in my profession. Later, I went through training programs on project management and general management. Of course, I am far from alone in this ongoing learning — it’s a way of life for all IT professionals.

Learning and gaining experience in multiple technologies and platforms is a good thing.  Some of us get to become specialists only if our area of expertise – the platform or technology does not become obsolete.  I agree. There are veteran COBOL specialists, UNIX experts and C geeks. They are minority. They are specialists.  Their rules do not apply to the majority because we are in an industry that is evolving with immense innovation as well as equal amount of obsolescence.

Understand the industry trends.  Anticipate customer needs. Think beyond the programing languages, databases, tools and platforms you know. Renew yourself. Ultimately, what you deliver is what matters!

*-*-*-*-*

81. Landing in a Troubled Project

‘What can I do when I land in a troubled project? Those who made it a big mess are out of it. How can I deliver?’  This question came to me at the time of writing this book.  Landing in a troubled project is familiar to almost all of us.  It happens. We don’t have any control over it unless we know it up front and have all mechanisms to turn it around and deliver.

What happens in the ICU of a hospital when a patient is brought in? It depends. It depends on the hospital, the professionals, and the infrastructure etc.   Even when there are experts with deep experience they come together, collaborate and take decisions.  Meanwhile, they never ignore the immediate steps.  Sometimes they don’t have time for elaborate analysis and discussions. They are led by their tacit knowledge.  They carry a shared vision and act. Meanwhile, the news spreads to all close relatives and friends. They are the stakeholders. They need to know.

You know that you have landed in a troubled project.  What are the troubles? Do your team members have the same level or perception? And how does it fit with the reality or things happening on the ground?  When you land in a troubled project, you need expert help.  Either you need to be an expert or you have to have experts in your team to help you.  The first step is to take the project into ICU.  Let me accept, we don’t have ICUs in our industry but this step is about stakeholder communication.  You have to communicate the bad news so that none of your stakeholders carries a different perception on your project.   The next step is to bring your team members together, get expert help, collaborate and take decisions.

When there is no acceptance or no expert help or delays in decision making, you know you can’t turnaround and improve things.  That is a red signal!  Before it becomes a red signal, raise an alert or carry a red flag to turn things around.   When you do this you can improve the chances of heading in the right direction.

*-*-*-*-*

82. Bug Bash – Making a Winner

In early 90’s one of my colleagues and a friend moved from India to work in the US.  He had several years of experience after his graduate program in science and he worked hard to secure a permanent job in one of the top five product engineering companies in the Silicon Valley.   He specialized in quality assurance and testing. He learned and mastered automation.

During the month of November, weeks after he took charge in his new job, he was in an important meeting with his product manager and team members. One of the products meant for its first release in January was buggy and unstable. That was the first version of the product on Windows 95 operating system and it included several user interface elements that can be operated with mouse clicks. And it has to support the computer keyboard too.  The CEO had announced the release date to the industry and potential customers.  For the product management team there was no other option to deliver a quality product on time. And this meeting was to come up with a plan of action to improve product quality and meet the release timelines.

The product manager suggested a contest in which all team members would participate. The contest was to do a ‘Bug Bash’ – or test the product as much as possible and find as many defects.  It was going to happen over a weekend so that defect fixing can happen over the subsequent weeks.

Those days, working from home was not common because of lack of infrastructure.  Computer users were learning how to browse the internet using one of the world’s first browsers released less than a year ago.  The term Virtual Private Network (VPN) was getting familiar in pockets.

My friend saw that as an opportunity while many of his colleagues decide to find as many bugs as they can by spending some hours per day.  He was passionate. He wanted the customers to win. He wanted his quality assurance manager to succeed. He remembered what his CEO had committed to the world. Everything else became the next priority to him.

He had known basic concepts and functionality of this product but he was not well-versed in the new version. That did not deter him. He grasped it in couple of days and went on to test it over the weekend. He stayed long hours and tested the product.  He found more than one thousand bugs.  He was the topper. His manager awarded him a gift voucher and a citation.

I remember him telling me this story.  He was thrilled about the number of bugs he found and how it helped them release the product.  He did not do it for the gift. He did it to make winners out of his customers! He grabbed that opportunity.  He delivered the right thing.

When is your next opportunity to deliver?

*-*-*-*-*

83. Understanding the Edges

You can make a difference to what you deliver when you understand the notion of edgecraft.  In his book Free Prize Inside, Seth Godin presents the concept of edgecraft. In everything what we do and deliver there are edges.  Find an edge and go all the way to the edge and make a difference.

Here are some examples.  When you deliver, create a remarkable release note that can help your customers.  When you deliver, create an impressive demo kit or a video that can make the lives of your consumers simple and easy.  Or go with your deliverable and deliver a training session that stands out as a differentiator. These are a few simple examples.

Read Seth Godin’s book. His book is a great source of information on how you can differentiate what you deliver by ideating and implementing simple things.

When you understand and practice edgecraft you are noticed.  You get an opportunity to identify the right free prize to your customer.

In project teams, an effective and efficient knowledge transfer process enables smooth delivery. Writing a clear and concise bug report can improve efficiency. Being there for customer can add value to what you deliver.  List all the edges and think how far you can go and demonstrate your skills in edgecrafting.

*-*-*-*-*

84. Communication Woes

We were in a project-kick of meeting of a large mission critical maintenance project in US. In his concluding remarks the vice president of our customer said, ‘One thing is very important to succeed in this project. In fact, it is essential for every project. It is communication!  Communicate well to improve efficiency. Good luck!’

Our team returned to India. Couple of months after this meeting we were moving into steady-state operation. Our team members were capable of identifying and fixing software defects.

That is when this email interaction started.  Rahul, one of our team members in India wrote to John. John was the tech lead working with our customer in Cincinnati, US.

From: Rahul

Sent: Monday, February 11, 2002 6:19 PM

To: John         

Subject: Database Trigger Issue – 3456

Hi John,

Today I tried to fix the db trigger issue 3456 for order_details table.  However, when I recreated the trigger I got an error that needs to be resolved by the database admin.    Hence this will take two more days to complete.  I will update you tomorrow.

Regards,

Rahul

The next day morning, Rahul saw a response from John.

From: John

Sent: Tuesday, February 12, 2002 10:00 PM

To: Rahul        

Subject: Re: Database Trigger Issue - 3456

What is the error number?  Have you raised a help desk ticket to the DBA team?

Regards,

John

Rahul was busy working on another issue throughout the day.  The next day, he responded to John few minutes past six in the evening.

From: Rahul

Sent: Wednesday, February 13, 2002 6:19 PM

To: John        

Subject: Re: Database Trigger Issue - 3456

It is Ora-3412.  Helpdesk ticket:  234598

Regards,

Rahul

Probably John was busy with something else. He wanted to know the status and responded the next day.

From: John

Sent: Thursday, February 14, 2002 10:00 PM

To: Rahul        

Subject: Re: Database Trigger Issue - 3456

What is the status on this?

Regards,

John

Rahul responded on the same day!

From: Rahul

Sent: Thursday, February 14, 2002 6:19 PM

To: John         

Subject: Re: Database Trigger Issue - 3456

The help desk ticket got resolved today. I fixed the issue and included it in the build.  It is working fine.

Regards,

Rahul

John verified if the issues was fixed and wrote to Rahul.

From: John

Sent: Friday, February 15, 2002 10:00 PM

To: Rahul        

Subject: Re: Database Trigger Issue - 3456

Pl verify if the issues is fixed.  I am not seeing the expected behavior.

Regards,

John

When Rahul received this mail on Friday, he was too busy with two other issues. He did not respond until Monday and his response was very crisp.

From: Rahul

Sent: Monday, February 18, 2002 6:19 PM

To: John         

Subject: Re: Database Trigger Issue - 3456

I fixed the issue and tested it.  It is working.

Regards,

Rahul

This did not help John as he could not understand when this issue was fixed. Rahul’s response was not detailed enough. John responded to Rahul.

From: John

Sent: Monday, February 18, 2002 10:00 PM

To: Rahul        

Subject: Re: Database Trigger Issue - 3456

What was the error? Did you fix it yesterday? Or just tested it again?

Can you please send me the details?

Regards,

John

Obviously with frustration, John did not stop there. He wrote this mail to Amit - Rahul’s manager.

From: John

Sent: Monday, February 18, 2002 10:30 PM

To: Amit       

Subject: FW: Re: Database Trigger Issue - 3456

Hi Amit,

Could you please call me to discuss this?  I think there is a violation of CM process & I am concerned about the clarity of emails as well.

Regards,

John

Amit tried to reach Rahul on his mobile phone but he could not. Obviously it was half past ten in the night.  Before calling John, he wrote this email to Rahul.

From: Amit

Sent: Monday, February 18, 2002 10:32 PM

To: Rahul  

Subject: Database Trigger Issue – 3456 - MEET ME IMMEDIATELY

Hi Rahul,

I understand that there was some CM issue and your email to John was not clear enough.

We need to discuss this. Meet me.

Regards,

Amit

This week-long email interaction resulted in customer escalation.  Amit had to intervene and work with Rahul in setting things right.  In a team meeting Amit put forth the following three points to avoid such communication woes.

In all forms of communication including written forms such as emails,

• Ensure 3Cs.  Be Clear, Concise and Complete.
• If the issue is not solved even after 3 hops, talk over phone to resolve the issue.
• Use the bug tracking or issue tracking system so that pending issues are visible to everyone in the team.

I am sure you can relate this with something similar from your experience. Some of us are techies. In doing multiple things, we lose customer focus. We did not ask enough questions to understand why something needs to be fixed and at what time-frame. We perceive that email conversation between two people indicates progress. We forget to realize what needs to be delivered. With all these and several other reasons you may think of we embrace inefficiency.  At end, when we deliver, do we deliver great customer experience?

What are your proactive measures to avoid such communication woes in your team?

*-*-*-*-*

85. Three Things You Can’t Do Without

Delivering in IT industry is different from delivering in other industries.  For example, in manufacturing industry, a vast majority of professionals need to have adequate competency to work with machines to deliver.  The need team skills too. It is okay if they don’t read, write or speak enough to master their skills because the level of automation and stereotyping are very high in manufacturing industry.  Of course, in manufacturing industry those who specialize in design, simulation and modeling, and research and development need to focus on reading, writing and speaking – at least two of these with a varying degree of importance from time to time.

If you want to deliver in IT industry, you cannot constrain yourself to learning new programming languages, tools and technologies.  You need to focus on reading, writing and speaking.  As you grow from the level of a junior programmer to lead a small team of engineers, you need more than your alacrity and confidence in solving technical problems or expertise in writing complex programs.  Reading is mandatory to begin with and you can choose either writing or speaking or both.  These skills help you build self-confidence and deal with teams.

No doubt, leaders need to be great observers, readers and thinkers. That is not enough. Those who go beyond these and communicate well through writing and speaking become powerful leaders.

How do you share or plan to share your knowledge or give back to your community of professionals? There are several ways.  You can become a mentor or coach. Also, you need to be able to express your knowledge by speaking in forums or writing knowledge snippets, blog posts, articles, papers etc.

In order to deliver great products and services, keep in mind that there are three things we cannot do without - reading, writing and speaking. 

*-*-*-*-*

86. Dark Processes, Dark Documents and Dark Patterns

Jim Sinur, Vice President, Gartner said, ‘Dark process an unofficial process used to deliver results and not visible to management.”’  Jim specializes in BPM (Business Process Management).  What he said applies to delivering software too.

Dark process is a process that helps you deliver results but it is not visible to your management and it is unofficial because it is not part of your process repository.  Dark document is a document that helps you deliver results. It is a document you shared with your stakeholders. It can bind you legally and have consequences. You are unaware. You have not got it approved by your manager and legal department.  That is scary! Isn’t it?

Every organization has dark processes and dark documents.  ‘Dark processes result in lost efficiency. Dark documents result in legal exposure.’  This is what Leonard DuCharme mentions in his article ‘Beware of Dark Document’.

Let me elaborate.

Let us assume that you are following a dark process. You do this because, it helps you deliver results. It improves your efficiency.   You are not sharing it with it anybody.  Nor do you take the initiative to institutionalize it by partnering with the right teams.  The result? Lost efficiency!  Should I extend to say that it will result in lost knowledge as well?

Let us assume that you are using a dark document.  You do that because, it helps you deliver results. It keeps your customer happy.  You are unaware of the legal consequence. May be it is about someone’s IP. May be it is about something else that you are not supposed to reveal.  You are not sharing this document with anybody. Nor do you take the initiative to review that document with your legal team. The result? Lost reputation, litigation, penalties, brand erosion and much more. 

‘First of all, we should think about why dark processes come in to play.’  Is that what you are thinking?  Can there be an organization or business without any dark process? The answer is no.  There will be dark processes.  How about identifying them and making them mainstream processes?

How about dark documents? Don’t keep them in dark. Go and review those with your legal team!

I learned about dark patterns sometime in 2013.  Dark pattern is a type of user interface that appears to have been carefully crafted to trick users into doing things, such as buying insurance with their purchase or signing up for recurring bills - that is how darkpatterns.org defines it.  Every time I do online booking of air tickets, I do the math and see the sub-totals. In most cases, travel insurance is included by default and I have to go and disable it.   That is a trick played on users like you and me.  After all, as I mentioned in the first chapter, we consume what we create.  And the entire user community consumes what we create. Can we afford to create these UI anti-patterns?  These are dark patterns as they trick end users and make them spend and consume more than what they intend to do. By the time they notice what happened, it is too messy or late to correct it.

Do you know of any dark patterns? Submit it at darkpatterns.org. Let the world know what you know.

*-*-*-*-*

87. Heard about GDD?

GDD stands for Google Driven Development. Sadly, that is how many software engineers develop software these days.  They rely on internet search heavily.  For everything from trivial programming tasks to technical problem solving, they are dependent on Google search, content posted at StackOverFlow or other web sites.  They copy and paste program snippets into their code and attempt to make it work.  They make it work somehow!  And they make it work however sub-optimal the code may be. Because they don’t know if their solution is sub-optimal or not.  The habit of reading programming instructions or documents on application programming interfaces is never a proactive practice for them.

With this habit, when there is no internet connectivity, GDD programmers are handicapped. They don’t make progress.  And these days it is hard to find several programmers who write programs from start to end without having to do internet searches.

Obviously, this approach, no doubt, is a time waster. This happens with a false belief that there is a solution – a right solution, out there for everything available at ease and all you need to do is a Google search to find answers to your problems. Will this approach make you a better professional?  Won’t it make you lose focus and spend numerous hours in searching and backtracking to deliver what you want to deliver?

Here is the truth. One cannot live away from gaining strong fundamentals.  Judicial usage of internet search is okay to increase the speed of problem solving. That will enhance efficiency. Google search cannot be the only means to start programming and end with compiling your code.  When you don’t accept this fact, your knowledge will continue to remain shallow.  The cut-and-paste culture cannot lead to good programming practices, sound knowledge in this complex industry.

Think! There are GDD practitioners in this world.  They may be in your team. They are productive when the corporate network is super fast and Google is efficient. They take a coffee break when the network is down. For every program of twenty lines they do at least five internet searches before they resolve all compilation errors.  They think that it is heroic to do internet search while programming.  They cannot refactor their code because of obvious reasons.  They think that books and manuals are for dummies!  When you don’t notice it or ignore it or improve the situation, you deliver crappy products, sub-optimal solutions late in the game!  That is not a winning strategy.

Mindless cut-and-paste does not help you deliver. I am sure you don’t want that to happen.

*-*-*-*-*

88. What Do Testers Deliver?

One of the primary pursuits of software testers is to verify if the application under test conforms to system specifications.  In this pursuit, testers create bug reports whenever test cases fail.  This is how the professional life or journey of a typical software tester starts.  At some instance in this journey a realization strikes.  It is a voice from within and it says, “The quality of bugs matters more than the quantity.”  This is when a software tester understands the true meaning behind the purpose of testing. This article presents a real life story to illustrate this phenomenon.

Anita, a software test engineer joined our project team several years ago.  That was her first project on her first job.  She held an undergraduate degree from a well-known college.   She was very fast in finding failures.  She would find failures against test cases and raise bug reports.  She topped in doing this.  She was happy with this progress. However, her interaction and relationship and rapport with developers became unhealthy.  Every defect she found involved not only additional research and debugging but also a great deal of conversation and negotiation. Sometimes more than five out of ten defects reported by her would end up in categories such as ‘Not a Bug’ or ‘Duplicate’.   Eventually developers started seeing no value in her bug reports.  She was demotivated.   When we analyzed this situation we understood that she was not collaborative enough and did not think through before creating bug reports. Somehow she was passionate about maximizing the number of defects but not paying attention to the quality of defects.  This episode turned out to be an unpleasant experience for her as well as the developers. One of the senior members in our team coached her and she was willing to learn and improve. It took her several weeks. She was getting better.

One day she was extremely happy because a bug she reported was fixed on the same day.  The developer who fixed it was impressed too.   I appreciated her and asked, “This is awesome. How did this happen?”  She retorted, “Thank you! I know, I did my homework before reporting this bug.  I discussed it with our developer, understood the context, did additional testing by considering related scenarios and created a better report. This approach helped us reduce debugging time.”  I smiled at her with a sign of satisfaction.

Gradually she become a successful professional and started contributing to large projects.

Several years have passed.  Nowadays, I am not playing the role of a full time developer or tester or project manager. I am a specialist. I work with organizations and teams. I write, speak, coach, consult and do several other things.

In 2013, I was using an online application that facilitates conference management and includes features such as attendee registration, speaker submission and so on.  This is a new system developed by an enthusiast who is a hardcore techie. Sometimes he works with one or two developers supporting him. Otherwise, he does it by adding features, resolving issues and making it better.  As a member of program committee of an upcoming conferences, I use this system daily.  All of us in the program committee are aware of the known issues and one among them is a pagination issue – we had to refresh the web page couple of times to get the right number of records.

The other day, I observed incorrect number of submissions under a specific category in spite of multiple attempts to refresh a page. I was reluctant to relate it to the pagination issue. I thought it could be due to some issue with the browser cache and went on to complete my tasks of the day before I investigate it further.  That issue did not leave my mind.   I did not react either. I remembered Anita’s happiness when she did it right and got that bug fixed efficiently. I asked myself, “Is this a bug or issue worth reporting?”  The answer was not affirmative.  I wanted to get back to the system and explore it further so that I can help the developer with my bug report.

Late in the evening, I went back to the system. Even though I was able to reproduce that defect I started examining the corresponding behavior under various scenarios and compared it with similar features.  To me, the ability to reproduce is a necessary but not a sufficient condition to report a bug and this bug was not worth reporting yet. I wanted to narrow it down and isolate it so that I can write an informative bug report. 

After multiple attempts, I started getting some clarity. I isolated it to a specific scenario across screens. It appeared to be a programming error or configuration error. I reported it with all my findings.  And the bug was fixed within an hour!

Looking back, I find that these are the small incidents worth sharing as they leave behind some takeaways. Test case failures are most probably the leading indicator of defects.  However, a test case failure need not be defect itself.  It is the responsibility of a software tester to do additional probing or research to isolate the failure in order to write a meaningful bug report.  Next time when you come across a failure, ask yourself, “Is it a bug worth reporting?”  Also, attempt to analyze it further and write a great bug report.  When you do this you will enjoy your work and become a valuable contributor in your team.

*-*-*-*-*

89. Leading to Deliver

Do you play the lead role? How do you lead to deliver? What is your style? What do you believe in? Who is your favorite lead? Why? 

Some of us play the lead role or look forward to becoming a lead soon. The rest of us have been there and done it.  Moving up in the ladder and becoming a lead is an event of pride. It is a promotion. It is an enabler. Does that provide one superiority or authority?  Before this promotion was announced you were part of the team. What are you part of now?

Leading to deliver is what matters.  In your lead role you are part of the team.  This role does not give you any amount of superiority or authority.  You are special. You continue to do what you are good at and you take up extra things as well – some of them will be non-technical.  That is what you do to enable your team.

You care for your team members irrespective of their specialization.  You appreciate your team members in public and credit them for all the good work. You own failures and deal with negative feedback in private.  You don’t take the path of command and control. You become a servant leader.  You don’t attack your team members. Neither do you display the signs on anger or other negative emotions.  You admit when you are wrong.  You practice fair play and honest feedback. You welcome new ideas and never do you believe or act as if you are indispensable.

You live the act of leading to deliver.

*-*-*-*-*

90. The Delivery Trap

Manish met me during my evening walk that day.  That was my routine fifteen-minute walk at work.   Manish was the project manager of our large project. I was the program manager.  All of us in our team decided to stay little longer that day to ensure release readiness and deliver the final build of a large application we had developed.

Manish said, ‘Our team had spent several weekends and long work hours on weekdays.  Let us go to the cafeteria and get them some chocolates and other goodies.  That should motivate them to complete the work today.’

We went to the cafeteria and bought lots of goodies for our team.  We had done this more than ten times and our team members were used to it. They needed genuine support more than anything else. That is because we were in a trap.  Some months ago, we were driven like a herd from one crisis to another. There were unplanned tasks, unexpected priority changes, unmanaged requirements creep and employee turnover.  Executing a fixed project with distributed teams put us thorough this trap.

We, the senior leaders were upbeat with impressive stories, experience sharing and systematic analysis of different situations.  All these steps helped us improve some of the intermediate checkpoints or milestones but we failed to control the crisis.   Crisis management and timely delivery happened because of a small bunch of star performers or heroes.  We had a team of skilled engineers with great intentions. 

During the initial months, I observed was most of the days our team members were busy and stressful.  Some of the openly claimed that they were busy because of over-commitment and unrealistic estimates. It was like traveling in a moving ship.  There was no time to stop and introspect.  Our first and probably the only priority was to deliver on schedule. That blind folded us from everything else.

One of our top performers in our team left us after five months from the start of this project. And it created a ripple effect before we could contain attrition of team members.

Our customer tolerated this, because there was no alternative.  The only strategy that worked was ‘push-and-get-it-done’.

We fell into this trap because of two reasons. First, we, the leaders were yielding to pull factors from all directions.  Next, we were able to sense the bad smells without knowing how to deal with them.

 

When the next phase of the project was about to start we planned for a team meeting to reflect on how we can improve and avoid falling into that trap.  We had several ideas, suggestions and tips on what to avoid.  We realized that lack of effective teamwork will potentially put us back in to that trap. We embraced simplicity and clarity in what we do.  Simplicity in designs, scripts and tests. Clarity in our vision, goals, plans, roles, responsibilities, communication, participation, ground rules for team behavior and so on.  In the following months, we could experience effective meetings, understanding, interactions, decisions and action on the ground.  That was a rewarding experience.

One day, some of our team members came with a box of chocolates for us.  That was the outcome.  Later years, I accepted that we could not do much to motivate our team members. Motivation is the result.  Motivation is something that the individual needs to initiate. It has to come from within. For that, all we need to do is to inspire.  Inspiration fuels energy around us and results in motivation.

It is okay to share goodies and treat your team members. It is good as long you are genuine and show action on the ground. However, there is no guarantee that distribution of goodies is going to work all the time when there is lack of caring and appreciation.  There is one thing that can work all the time in this world. That is incorrigible optimism coupled with an inspiring character.  When you believe in these and become an inspiring leader, you can motivate your team to ensure effective teamwork.

Find an inspiring leader and seek mentoring.  You will minimize the chances of your team getting into the delivery trap.

*-*-*-*-*

91. Delivering the Impact

Delivering it right at the right time.  Else, you may miss the opportunity to delivering the impact.  Terry Weissman delivered Bugzilla to the world.  That was the first-ever open source bug tracking system delivered to global users.  That was the time when IT organizations around the world were floundering to build or buy tools for bug tracking – many of them were managing their show with spreadsheets or home grown and buggy tools.

Hotmail revolutionized the way we communicate.  Sabeer Bhatia and Jack Smith delivered Hotmail to the world in 1996. They wanted to revolutionize and democratize communication. They wanted to build something that was never built before. And they did it. Within six months, one hundred thousand registered users flocked Hotmail.  This count scaled to 20 million users over the next sixteen months. In 1998, the impact delivered by Hotmail resulted in a $400 million acquisition by Microsoft.  That was the hot news among the IT and business communities all over the world.  Post 1998, Hotmail continued to be one of the popular free email service on the Internet.  By 2014, it had 350 million registered users.

Deliver before someone asks for it.  Create a market. Create your customer segment.  Those who deliver to create the impact, create the impact. And others just follow.

*-*-*-*-*

5.1 The Silver Bullet                        Table of Contents                   7. Delivering the Bad News