Part 3 Management and Methodologies - 3.1 Orchestrating

Part 3 Management and Methodologies

3.1 Orchestrating

51. Readiness to Deliver

Long before I started playing bass guitar in a budding professional band, my friends and I aspired to perform on stage.  We were all teenagers and looking forward to perform in a local event.  We came up with a name for our band, collected funds and started hunting for additional players because our band was short of a keyboard player and a lead guitarist.   We had no other option but to hire them to play with us on the day of the event.  Considering the capabilities and choices of those two players, we had to compromise on the list of songs.  As a team, we lacked practice.  Our program started and we did all we can to perform. We had great intentions. We were sincere.  Everyone in our team was skilled.  We wanted to put up a great show but we could not because of obvious reasons.  We could not perform as one team.  We could not synchronize.  At the end of the day, we did not deliver the right thing to meet the expectations of our audience.

Several years later, with more than ten years in IT industry, I got an opportunity to lead a software project.  This project involved development of a large commercial application.  I was one of the two leads. We had a few months to put together a team for this project.  We had less than ten days to start the project.  We were preparing for project kick-off knowing that we were short of a project manager and a business analyst.  Our preference was to get two insiders to join our team. Our backup plan was to contract a project manager and a business analyst from a third party vendor.  We had to go with our backup plan a week before our project started, as we had no other option.  That is how we started our project.  As days went by, we observed a great level of disconnect among team members. The work style of our project manager and business analyst were different as they came from a different organization. As a team, we needed more than a month or two to figure out ways to come together, agree or disagree and deliver results.  During the initial months, we delivered sub-optimal results because we did not synchronize well at the beginning.  We could not perform as one team. There were days of silence among team members. There were delays, issues and firefighting to make it happen.  After three months, we involved an expert to help us improve and reformed the team structure.  It took us another two or three months to deliver better results.

Whether it is an orchestra or a software project team, we need skilled team members.  In addition, we need team members who can sequence and synchronize their interactions and work patterns during the initial days of the project so that they can perform as one team.

Are you the torchbearer of your team? Is your team ready to deliver?

*-*-*-*-*

52. Thinking beyond Stakeholders

Project sponsors, customers, end users, project team members, senior management, members of support functions, etc. are the stakeholders of projects.   Are they equally significant? Alternatively, do you focus more on your senior management and take care of their needs first?  Who comes first? Do you put all your stakeholders in the same platform and give them the same level of importance?

Let us think beyond stakeholders. What is important to our projects? Success! Yes. That is an irrefutable answer!  Success is important.  Who are our success-critical stakeholders?  “A project will succeed if and only if it makes winners of its success-critical stakeholders such as customers, project sponsors, and team members”, says Barry Boehm.

You cannot ignore your success-critical stakeholders. Your customers, project sponsors and team members are among them.  Make them win, your project will succeed.   Ignore them or make them lose, your project will fail!

Stakeholder management is more than identifying, understanding and managing stakeholders. It is about knowing all your success-critical stakeholders and making them win! It is about knowing the rest and catering to their needs. You cannot put them on the same pedestal if you want success in your project. Meanwhile you cannot afford to ignore any of your stakeholders if you want to succeed in your project.

*-*-*-*-*

53. Creating an Impressive and Compulsive Vision

Creating a vision is essential when you want to deliver a product or a project.  The vision you carry as a team needs to be impressive and compulsive.  It needs to be a shared vision known to everyone involved in the process of making it happen.

Why do we need a vision? Why not set goals? And why not just perform our daily work to get things done? Isn’t it vision a corporate buzzword?  Well, establishing a shared vision is necessary at corporate level as well as project level.  Let me quote a Japanese proverb here. It says, ‘Vision without action is a daydream. Action without vision is a nightmare.’

When you have an impressive and compulsive vision for your product or project, your team members remember it. It helps all of you set unified goals to realize the vision.  It enables you measure performance, avoid conflicts and move towards the final target.  Whether you are a project manager, an architect, a technical leader, a developer, a business analyst, or a test engineer, your goals tend towards the shared vision. 

Why does it have to be impressive and compulsive?  Impressive is something that is exciting, inspiring, moving or remarkable.  Compulsive is something that is gripping. Why not an impressive and compulsive vision?  Remember the Japanese proverb!

Involve your team in creating a vision statement for your project. Let them know who the customers are. Let them know the major focus areas are.  Let them know the impact of project success. Let them know the scope.  Articulate the project vision.  Review it. Cut down the unwanted and create a crisp vision statement that does not exceed three to five sentences.  Make sure that it is simple, memorable and inclusive.

*-*-*-*-*

54. Methodologies: What is Right?

For software development, maintenance, testing and production support - or the entire Software Development Lifecycle, we have several methodologies such as waterfall, iterative, spiral, SSAD (Structured System Analysis and Design), RAD (Rapid Application Development), RUP (Rational Unified Process), and Agile Methods (XP, Scrum, FDD (Feature Driven Development), DSDM (Dynamic Systems Development Method), etc.

What is the right methodology for your project? To answer this question, obviously there are two prerequisites.  One, you must identify possible choices. Two, you must be knowledgeable or have experts who can help you in making a decision.  Without these prerequisites, any discussion on methodologies is nothing but a waste of time.  Therefore, the first step is to learn methodologies.  According to Scott Ambler, the author of ‘Disciplined Agile Delivery’, successful software development requires a hybrid approach.

How can we derive a hybrid approach? In his paper ‘The use of systems development methodologies in practice: a field study’, B. Fitzgerald observes that the ability to select the right methodology, processes, and practices comes with experience.  Experienced team members understand that it is very important to customize methodologies and make them context-driven.  In addition, they need to understand that collaboration, focus on continuous improvement and balancing discipline and evolutionary paradigms such as Agile are necessary.

Let us make engineers at all levels understand that it is very important to customize methodologies and make them context-driven.   Let us nurture the culture of collaboration.  Let us improve the focus on continuous improvement.  Let us spread the realization that discipline and teamwork are essential.

It is hard to build software applications or products, which can stay long and satisfy customers. However, creating such applications or products requires excellence in terms of individuals, collaboration, teamwork, focus on continuous improvement, understanding customer needs and several such factors.

*-*-*-*-*

55. Bugzilla Story

Bugzilla is a well-known open-source bug tracking system used by thousands of organizations and millions of professionals all over the world.   It was one of the first products released when Mozilla project was announced in 1998 and mozzila.org came online.  The Mozilla project uses a community-based approach to create world-class open source software and to develop new types of collaborative activities.

Who created the original version of Bugzilla? What was the team size? Which methodology did they follow? The story of Bugzilla will give you answers to all these questions.

Netscape Communications Corporation in mid 90s’ contributed three key technologies to the world. First, the internet browser popularly known as Netscape Navigator. The next advanced version was known as Netscape Communicator.  Second, Secure Sockets Layer Protocol (SSL) to enable secure online communication.  SSL propelled online banking and several other web applications that required high level of security and encryption to protect confidentiality of data.   Third, Java Script, the popular language used to write browser side scripts. 

The product engineering team of Netscape Navigator was a niche team of ten top-notch techies. They were busy building new products and innovative tools for the internet world. Sometime during 1994-95, in order to track and manage bugs reported by their testing team, they needed a tool. They needed a simple browser based tool to begin with.  They did not find a suitable tool in the market and they wanted to build it. They could not afford to seek help from their IT team in building this tool - that would have taken them through at least a two-month cycle involving requirement gathering, design, coding, testing and implementation.  They decided to do it themselves.  One or two developers from the core team created a bug-tracking tool with bare minimum features in less than ten days.  All they needed was a minimum viable product. They named it BugSplat.  They handed it over to their IT team for regular maintenance.

In 1997-98, one of their focus areas was the upcoming Mozilla project.  The vision of Mozilla project was to create a global community of technologists, thinkers and builders working together to keep the Internet alive and accessible, so people worldwide can be informed contributors and creators of the Web. They wanted to reengineer their bug tracking system and make it open-source.  They considered doing this because their bug tracking system was unique, special and much needed by several developers and testers all over the world. 

Terry Weissman, member of the core product team, took charge of that situation.  He created Bugzilla in one week and released it to the world. It was one among the first products that went online as part of Mozilla project.

I was part of the database administration team in Netscape from 1995 to 1999.  Though I remembered this story to some extent, I wanted to check with Terry Weissman.  

Here is what Terry wrote to me when I approached him in January 2014 to know some of the finer details of the Bugzilla story.

“My recollection is that we had asked IT to make a publicly-visible bug system, and they said "sure, no problem" -- and then they took months and months and little progress got made.  I don't remember if they didn't give an estimate of when they would be done, or if they just miserably failed to meet their estimate.  I just remember the frustration of going to interminable meetings and things seeming to go nowhere.

Finally, I took matters into my own hands and wrote the original version of Bugzilla.  Yes, it only took about a week.  It was only me.

My great advantage here was that I had already worked with a bug system written in TCL.  This was BugSplat, an internal Netscape tool. BugSplat was much simpler and used your browser.  I didn't write BugSplat, but I had learned it.  So, I was very familiar with its ways of doing things.  My main learning curve for that week was learning enough MySQL to get things going.  But all the web stuff was straightforward and easy.

I don't really know what was going on inside the IT department and why things were so slow.  I found a way to build one that was well inside mine.”

Some of the well-known organizations such as AT&T, NASA, Facebook, New York Times, AMD and Yahoo use Bugzilla. Do you?

What is your take on this story? Extraordinary. Isn't it?

*-*-*-*-*

56. Dead Snakes

This is not about snakes or other animals. This is about what we do with problems or issues in project organizations or large programs.  Problems or issues take up most of our time.  We engage in either formal discussions or informal gossips. Sometimes, we continue to go over past issues and discuss. We do not respect the lessons learned and move forward.

Jim Barksdale, the ex-CEO of Netscape, in his first executive staff meeting said,

“We have three rules at Netscape. The first rule. When you see a snake, don’t call committees, don’t call your buddies, don’t get a meeting together; just kill the snake.”  

By this he meant, when you see a problem to be fixed, just go ahead and fix it.

“The second rule is, don’t go back and play with dead snakes.”

By this he meant, when a problem has been solved, learn and move forward; do not revisit the problem.

“The third rule is all opportunities start out looking like snakes. So look at problems as opportunities.”

The third rule is simple and self-explanatory.

Software projects involve frequent communication and coordination among team members.  

Remember and share Jim’s three rules with your team.  Make it a part of your culture.

*-*-*-*-*

57. Why do Projects Fail?

We read about project failures now and then. Here are some failures that happened in recent years.

‘California sues SAP over failed payroll software project’ is the headline of an article by COMPUTERWORLD Magazine, Nov 2013. According to this article, more than $250 million was spent on the system called MyCalPAYS and this project dates back to 2005.

‘Senators to Probe Air Force’s $1 Billion Failed Software’ is a Bloomberg article written by Tony Capaccio in January 2013. This is about a billion-plus of tax payer’s money invested in a project that eventually failed.

‘Knight Capital blames software for computer trading glitch’, an article published by USA Today is about how a technical problem in the new trading software resulted in the company sending numerous erroneous orders in 140 stocks listed in the New York Stock Exchange.  According to this article, this issue costed Knight Capital close to $440 million. This happened in August 2012.

‘Troubled HealthSMART System Finally Cancelled in Victoria Australia’ is an article by Robert N. Charette in IEEE Spectrum about the cancellation of HealthSMART system project in May 2012. This project costed Australian $550 million.

Michael Krigsman, a recognized analyst, strategy advisor, and authority on enterprise software leadership, CIO innovation, and social business claims that the cost of IT failure is more than a trillion US dollars per year.

Why do software projects fail?  There are several reasons.  According to a research report titled ‘Social and Technical Reasons for Software Project Failures’ by Capers Jones software projects fail because of one or more of five risk factors -  inaccurate estimating and planning, incorrect and optimistic status reporting, unrealistic schedule pressure, new and changing requirements during development, and inadequate quality control.   In addition to these five areas we must consider, communication and coordination, stakeholder management, expertise of team members, risk management, and transition management.

How can we detect signs of failure early in the game?  Can we do this by reading a requirements specification document?  Not certainly.  Can we do this by examining the status reports? We have tried this all the time. It has not worked!

In 2012, I went to a nearby boutique tailor to stitch a custom-made blazer.  He showed me several designs for short listing. I chose one.  He measured the garment I had purchased to check if it was sufficient.  Yes. It was. The next step was to take measures. It went on for the next several minutes. He filled an order form and agreed to deliver the blazer in ten days. And he said, “I will call you in four days to come down and check if the measures are right! We call it fitting session.”  I accepted.

I got his call in four days and went to check if my blazer was turning out to be a good fit.  Of course, it was not!  He noticed two or three adjustments to be made. But I was quiet happy. There were no surprises waiting. He did those adjustments and delivered the blazer as promised!

That fitting session helped!

In software projects, we can detect signs of failure. To do that, we need to see how working software is evolving.  Going through documents such as status reports or specifications come next.  When we come across signs of failure, we have two choices. Either we can improve the way we create software or we can stop to rethink.

Which one do we prefer? A big bang failure? Or early, fast and small failure?  Which one gives you an opportunity to bounce back, improve and deliver?

*-*-*-*-*

58. Agile Revolution

Sam appointed a construction company to build a mansion in his 2-acre land.  The principal architect worked with Sam in proposing and finalizing the architecture of Sam’s mansion which was about to be delivered in twelve months at a cost of 2 million USD.

A week after signing the deal, Sam drove by his land and found that the work had started.  During the second week, the construction firm cordoned off the site from all sides. Sam thought it was to protect the neighbors or the environment from all the noise and dirt.

Sam’s cousin looked at the designs and proposed a great idea. He said, “Sam, how about a French window on the second floor facing the road instead of a traditional balcony?”  Sam was impressed. He called the construction company.  The architect and his team of engineers met him over lunch and said, “Sam, we will deliver you what we have signed-up for in twelve months. Any changes, we will accommodate later. We will do an impact analysis for each change and provide you our estimates.”

I am sure you are wondering why anyone would construct a balcony and then demolish it to make a French window.

Sam tried to negotiate. It did not work. He canceled the deal.  That is what anyone else would do!

How do we build software and accommodate changes to software system? 

Software systems emerge. Software development is people intensive.

Sometimes on the ground, we get flustered because we perceive that Agile means different things to different people. Let us not get ruffled up! From a project delivery perspective, the meaning of Agile for us is very straightforward and it relates to agile software development and agile methods.  Agile is about delivering working software to our customers in short intervals (or iterations) in a sustainable pace while responding to changing business needs.  All said and done, working software is the true measure of progress. Working software delivered in short iterations provides for better visibility and predictability.  In addition, this enables us to fail fast and fail early.

Let me share some history on how agile revolutionized the way we deliver.  By 2000, the success of agile methods such as XP and Scrum influenced the industry. During February 2001, 17 methodology experts convened at "The Lodge" at Snowbird Ski Resort in the Wasatch mountains of Utah and wrote "The Agile Manifesto."  Gradually, the popularity of agile grew across the globe. Agile gurus and practitioners organized conferences, workshops and events to evangelize and propagate agile methodologies. Lean software development and Kanban spiced up this evolution and got adopted as best practices in agile methodologies.

Adoption of agile methods is on the rise. This trend continues to influence the way we deliver software.

*-*-*-*-*

59. Does Agility Ensure Faster Delivery?

‘Let us propose an agile based approach for this project. That will help us compress the schedule and include multiple releases. I don’t think waterfall approach is going to help in making a competitive proposal. We must deliver this project faster with high quality and competitive cost. In order to win, our approach has to be agile based.’ Does it sound familiar?

We hear suggestions like this more frequently than ever these days in discussions on creating competitive proposals.  These are business discussions with your senior leaders and pre-sales teams.

Let me ask. Does agility guarantee faster delivery?  Undoubtedly, yes is the only right answer we can think of to make some business sense and gain the goodwill of project sponsors but there are other answers too. It is worth discussing this to find a practical answer to this question.

Certainly, adopting an agile approach is a way to enhance visibility and predictability on project progress.  However, can you enforce an iterative schedule and scope on your project team so that you gain the advantage of compressing the overall schedule and cost of your project?  When you enforce a pre-planned schedule and scope – however well concerted it may be, you are not empowering your team to inspect, adapt and learn. This approach will lead to ‘command and control’ culture. We don’t want that to happen because that is not what agile is all about.  Is there an alternative? Yes. There is.

First, your customer and other stakeholders need to know the essence of agility and agile methods. They need to know that an agile approach can enable your team move forward, learn and make things faster provided they are given the right set of tools, infrastructure and governance support to evolve and improve from iteration to iteration. There has to be a good match of mindset and culture.

Second, the product owner or someone who is responsible to provide requirements need to believe in prioritizing user stories or features at regular intervals – and practice it. Moreover, she must be willing to let go some of the low priority features if the release timelines are critical. You cannot do without an effective product owner.

Third, there has to be continuous collaboration in terms of participation in meetings, issue resolution and product demonstrations.  Genuine feedback is essential – without this, you cannot avoid last minute surprises. For this, your product demonstrations and team retrospectives need to be effective.

Fourth, the team members need to be skilled, self-enabled and aligned to perform.  Have you ever observed how rowing happens when a team of ten or more team members attempt to sail through and win a trophy? Skills and competencies are necessary. With these, alignment is paramount too. Without alignment, the rowing boat cannot travel in the right direction at speed. This is where ‘shared vision’ comes in to play. Establishing a shared vision and aligning your team cannot be ignored at any cost.

Fifth, your governance team and customer representatives who are part of the governance team must be able to understand and appreciate technical issues and challenges in the project instead of focusing on getting as many features or user stories done in every iteration.

When you have all these - as well as many other things that I have not explicitly mentioned about, in place, you and your team will be able to maintain sustainable pace, introspect, learn and continuously improve.  That is agility. 

Does agility guarantee faster delivery? It does not guarantee faster delivery because software projects come with several variable factors and the dynamics can be complex. However, agility can lead to faster delivery when you do the right things right.

More than what you estimate and propose in a project context, focus on how you execute, enable, learn and improve.  When you do that, agility can lead to faster delivery!

*-*-*-*-*

60. DWYS and SWYD

In a team meeting with my project team, I was listening to the challenges and issues of team members.  Each team member was presenting the top 3 challenges or issues.  Nita’s turn came. She had spent about six months in our team. She was very enthusiastic and open.  She said politely, ‘I think we do not follow any processes in our team. That is the only challenge I have.’

‘Well. We do have standards, checklists etc.  Could you please be specific and tell us?’ retorted her neighbor.

Nita replied, ‘We do certain things in different ways at different times. We need to streamline have some processes in place. We don’t use our standards and checklists consistently.’

Ravi, our project lead intervened, ‘I agree with Nita. We are not consistent in our approach. We have standards and checklists. We don’t follow them regularly. Do we? I think we need to put our heads together and work on this challenge.  Let us revise our project plan and make sure that we follow it.’

Ravi’s remarks made everyone think.  Most of our team members were nodding their heads with a big yes.

After a few seconds, I appreciated Nita and Ravi and asked everyone to review and revise their project plan at regular intervals.  They agreed to read, revise and follow the plan.

SWYD stands for Say What You Do.  This is about planning and telling what you are supposed to do in your project.  This is your process definition for your project. This becomes a part of your project plan. If you have a process definition and process repository at organizational level, you create a project plan by deriving what is right for your project from organizational process repository.  The first step is to SWYD.

DWYS stands for Do What You Say. That is the next step. By doing this you follow your plan.

At regular intervals, you make course corrections by changing your plan and do what is right rather than following a rigid plan.

Do you SWYD?  Do you DWYS?  In software projects, reviews are cut-short because of reasons such as schedule pressure, unit testing is skipped because of lack of time and governance meetings are by passed because of lack of availability of governance team members.

How can we produce high quality software with inconsistent or low quality processes?

*-*-*-*-*

61. Got a Checklist?

I am sure you have.  May be it is a To-Do list. It lists all items or tasks you have on hand.  As and when you complete a task, you put a tick mark against it to indicate completion.  Making a tick mark is a positive reinforcement.

Some of you maintain a how-to list for certain complex tasks. That list helps you go through a proven sequence of steps one by one and complete the task.  I am sure you use a troubleshooting list that provides a structured approach or sequence of steps to solve a specific type of problem.

Checklists helps us ensure that we do not skip important things.  Checklists helps us ensure effectiveness. Checklists can helps us do repetitive things right all the time and make those person-independent.

You can have checklists to start a project, review the status of a project, to review a document, to review source code, and so on. Simple isn’t it?

You can increase the effectiveness and efficiency of your checklist when you make it short, specific, relevant and up-to-date.  Make it short so that it does not exceed one A4 size page.  Make it specific so that it does not have generic items such as ‘Source code should follow design principles’.    Make it appropriate to your work and do not copy the checklist of some other project and use it before making it relevant. Review and update checklists at regular intervals.

How many checklists do you have? How have you made them effective and efficient?

*-*-*-*-*

62. Why Root Cause?

Our project was running with more than three hundred open defects. Yes. Three hundred. We were three months into the project, and one month away from our first release. The quality analyst approached me and said, ‘I think we must do RCA. That will help us contain bug count.’

RCA stands for root cause analysis.  He recommended 80/20 approach.  The goal was to identify 20% of bug categories that contribute to 80% of bugs.

The technical lead of our project was critical about this suggestion. He said, ‘I understand the root cause of why you are suggesting this.  You want to demonstrate to the organization that we do RCA.  You need evidence. How is it going to help our project? Our team members are busy. They can’t sit in a one-hour meeting to do RCA.’

I smiled at him. The quality analyst was genuinely interested. He wanted to help us turn around our project by reducing the bug count. He knew that firefighting at large does not help. We need to know where to put all our energies to win the battle.

‘Why RCA?’ I asked. 

‘Because the quality analyst wants to demonstrate process compliance’ came the answer.

‘Why process compliance?’

‘Well, the organizational process model recommends certain techniques for RCA and claims that these can benefit projects.’

‘Why is it so?’

‘Because unless we know the root cause, there is no guarantee that we will take right actions.’

‘Why do we need to take right actions?’

‘Because right actions will help us spend our efforts optimally to get desired results.’

‘Do you believe in it?’

‘Yes. Let us give it a try.’

After my five whys, our tech lead agreed to organize a team meeting and our quality analyst facilitated RCA.

In our meeting, we identified 20% of bug categories that contributed to 80% of bugs. In addition, we applied ‘Five Whys’ technique to find root causes to some of the ongoing issues.  It helped!  Two weeks after our RCA and action on the ground, we could see significant improvements in defect trends.

One way to improve the success rate of projects it to find the root causes of ongoing problems or issues and improve the situation.  Finding the right cause is the first step here. Identifying the root cause helps you identify the right cause.  When you know the right cause, you can take decisions to improve and improve.

Is there a reluctance in our organization or team to practice RCA? As ‘Why’. Listen to the answer.  Probe further with more whys.  You will see right actions happening.

*-*-*-*-*

63. Lessons Learned

So, is it going to be difficult for you to deliver? This question came to me twice.  In both cases, I learned some lessons.

I was forming a team for an upcoming project.  We were short of three developers in an eight-member team.  Mathematically, we had 62.5% of our team in place but those three positions were critical positions need form the first day of the project.  I was in a meeting with my senior leadership team to appraise them on the status of various projects.  At the end of my presentation I said, ‘Our new project is starting next week. We are short of three developers. These are critical positions.’

One of the vice presidents in the room said, ‘We know we are short of resources. We have junior developers on board. They are not experienced but they are available.’

And he asked, ‘So, is it going to be difficult for you to deliver?’

I was surprised to hear this close-ended question. He was expecting either a yes or a no from me.  I responded with an obvious answer the most of us would do.  I said, ‘I think it is going to be difficult but we need to explore options. Can we get some contractors? Or find ways to make this happen? That is what I am thinking. I need some support here.’

It was a tough situation.  And it was impossible for me to say no and stop there.  I could not put my foot down.

We started the project as planned. We got three junior developers but they took two weeks to become productive. We could not spend adequate efforts to enable them. However, two of them performed very well. The third developer could not perform well. We had to find another developer to replace that position. Even though we started the project on time, it did not start right. There were delays. We had to firefight to deliver.

A year later, in a different project, my team was waiting for project requirements and preliminary designs from a customer team.  Our understanding was to have these ready at least one week before the start of the project.  As you can guess, requirements and preliminary designs were not ready as planned.

We followed up and started getting them in bits and pieces. In our first conference call, our customer wanted us to use the common source-code control system and he inquired our team about the plan for that week. He asked, ‘So, tell me. Can all developers there start coding so that I can see some code tomorrow morning?’

My technical lead said, ‘Well, the requirements and designs are raw. We need to talk to your business analysts and architect.  We have so many questions.’

‘We can do that. Does it constrain the team there from initiating the work?  Let us start coding.’

I intervened and said. ‘We need to refine the requirements and improve the designs first. That will help us initiate coding. We do not have much information to start coding.’

Then came the question.  So, is it going to be difficult for you to deliver some code tomorrow?

I had to put down my foot and say ‘Yes. With requirements and designs in the current form, we cannot start coding from today.’

That was perhaps a career limiting conversation. Nevertheless, it was not. I was telling the truth.  I was not ready to put undue stress on my team. There was a long pause after my response.  We were looking at each other. Were we going to lose a customer? Were we going to lose our jobs?

None of those happened.

We heard our costumer’s response from the other end.  He said, ‘In that case, let us get things right in the first place. I am ok if coding cannot start for the next day or two.  If it is going to be a delay of one week, that is ok too as long as we improve the way we do things.’

I learned a lot from these two incidents. Next time when you hear ‘So, is it going to be difficult for you to deliver?’ from your boss or customer, remember these incidents.

Sometimes there is no firm yes or no. Sometimes there is. Sometimes you are the owner. Sometimes you are not.

*-*-*-*-*

2.4 Crafting Considerations                       Table of Contents                     4.1 Seek to Understand