Statement

With completing the first five sessions of the course, we were able to gain an understanding
about the key aspects of decision making, leadership attitudes and effect of unexamined
assumptions. These are some topics which we otherwise neglect and take for granted. The
following is an introspection into an incident that one of our group members had experienced
during his work at a software firm and associate it with the learnings from the course.

Premise
The premise of the situation was in relation to my role as a QA Engineer in my previous
organization. I was part of a team which worked on a project for an overseas client. The
project was basically the development and release or launch of a book translation application.

The team was following a Scrum framework, which essentially means that the project will be
split into sprints and the team is supposed to hand over an intermediate deliverable to the
client at the end of each sprint.

For the situation under consideration, the team is currently working on the sixth sprint and the
sprint output needs to be delivered in the next two days. It is usually at this point that the
developers complete the development tasks and provide the build to me for testing, so that it
can be launched without any bugs/errors before the deadline. But during this sprint, the
developers still hadn’t finished their tasks and so the build wasn’t made available to me for
testing. As per the developers, the tasks for the sixth sprint were a little complex than initially
expected. Hence, there was apprehension whether the sprint deliverable can be released in the
next two days. There were two options available:

1. Work extra hours to complete development and testing.

2. Influence the Product Manager (client) so that the deadline be extended.

In case we chose to go with the second option of attempting to get a deadline extension, then,
the manager would have to convince the client on the daily Thursday morning standup call
about the difficulty in getting the project delivered on time. The project manager, without a
second thought, was quick to finalize upon the first option and asked the team to quickly
catch up on the tasks so as to not default on the Thursday EOD delivery deadline. There was
no concern raised by anyone within the team and hence everyone got on to their work.
However, as time ticked by, the target seemed to become unachievable. However, there
wasn’t a thought of raising apprehensions before the project manager. The QA team had still
not received the build for testing as on Thursday night (one day before the delivery deadline).
The QA team finally rose and took the apprehension to the project manager. The project
manager swiftly rubbished off the apprehension by saying the he had firm belief in the
development team and that they would ensure that there are no major bugs before pushing it
to QA. So that the QA might not need to test much and could quickly give a green signal for
the release of the new developments.

On Thursday morning’s standup call, the project manager assured the client that all was
going well with development and that he could expect the new works to be live so that the
client can start testing it from Friday morning (Australian time). The client was in no way
briefed on the unexpected blocker (obstruction) they faced during the development, which
was unanticipated during the sprint planning session.

The development team had finally finished their part of the work and pushed it to QA for
testing by Thursday, noon. The QA team started off with the smoke test (the initial set of
quick tests run before diving into in-depth testing). During the smoke test, major issues
popped up in some unrelated modules (modules that were different from the ones being
developed). For some unidentified reason, the newly made changes had some way adversely
affected the old settings/modules. This was a heavy blow for the development team since no
one in the team expected that the other modules would get affected.

Finally, after hours of debugging (attempting to identify the source of the issue), the
development team noted that one of the APIs they had used in the new module was the same
API that was used in a previous module and that would have been the source of the issue.
However, understanding the issue was just the beginning. Getting the issue resolved by
Thursday EOD was evidently unrealizable. The team would not be able to push the final
build live with these known issues. There was no way the project manager also could approve
the release as quality of work submission was an essential characteristic of the organization.

Eventually, there was no release on passing the deadline and the client did not receive any
new updates on Friday morning, as was assured by the project manager. The instances
leading to the failure to complete the work on time was detailed by the project manager to the
client on Friday’s stand up call. However, it was too late and the client informed the team by
mail that he was so disappointed with the lack of proactiveness and dedication of the team.
Argument

From the above incident, it is evident that the issue started off with the hasty decision taken
by the project manager. He did not look into analysing the many alternatives he had in front
of him. Understanding the alternatives and evaluating the major consequences of the different
alternatives could have led to better decision making.

Another aspect of the decision-making process was unexamined wrong assumptions made by
the project manager. The project manager would have thought that the client would in no way
agree upon a deadline extension. This is contrary to the experience the team had with the
client so far. There were many instances wherein the client had agreed upon relaxations in the
past (when they were backed up by genuine reasons).

Also, no one in the team raised any apprehension against the decision of the project manager
even if they had plenty of them. This was an example of group conformity at play wherein
the group simply yielded to group pressures.