Digital transformation is evolving with changes coming from multiple ends with the goal of
automating processes and delivering greater value for customers. The change is constant and time waits
for none, leaving everyone to run behind with tight schedules limited budgets, and resources. In this
scenario, software practitioners find ways to minimize their workload and maximize productivity.
Easier understanding, achievable goals, and quick turnaround are a priority; thus, paving the way for
agile methodology. This requires greater collaboration between different stakeholders since the
project is broken into multiple bite-size phases.

Despite the success of agile practices, teams often run into pitfalls, primarily due to least/missing –
communication and collaborations – which are the foundations of the agile process. This article aims
to discuss some of the common problems that arise in agile, irrespective of the project size.

Give the Bug its Due Diligence:

Assuring applications are bug-free is the purpose of any tester. They enhance the value of testing/
validation services and ensure that the product is stable post-go-live. However, very often we never
acknowledge the bug in the way it ought to be; allowing the Developer to hinder the configuration
even after the bugs are logged.

Testers must ensure that the bugs are logged, and provide additional information like screen
grabs/screen recordings which can be uploaded into DevOps/ALM tools. This ensures that all the
stakeholders (Development teams & Testing teams) are on the same page and avoids any
miscommunication. Once a build is released, the configuration should be locked, audit trails must be
enabled, and the configuration should be published to the Testing team before the testing begins.

Plan your Sprint:

Gone are the days when products were built completely before entering a QA environment. With
the advent of agile scrum methodology Scrum Masters play a key role in planning a sprint – where
complex product features are torn down into a series of user stories which are then built iteratively
over sprint.

In some of the projects, we have seen sprints being planned for a week with a sizable number of
user stories. Projects that we have come across have had a one-week sprint, and the user stories fail
to get covered effectively and inadvertently spill over into the next sprint. While planning a sprint,
Scrum Masters must take into account the complexity of the project – the changes involved, and it is
always ideal to go for a two-week sprint to avoid spillage and better coverage.

Don’t spread your resources too thin:

Due to the limited availability of resources and increased demands from multiple clients’ –
organizations resort to having their resources juggle between multiple projects, clocking themselves
as BA, Testing, Support, etc., and this often leads to burnouts and a mix-up of priorities– which can
derail the best intentions. It is not feasible for an individual to be constantly involved in multiple
projects at once, thus it is necessary to limit individuals to specific roles/projects; to observe
patience, and monitor how things progress and change. Testers must have a strong say in all activities
that fall under the Testing jurisdiction, this will potentially bring better outcomes for the
betterment of the project.

Don’t be secretive:

User stories are the minute, yet crucial part of any testing/validation service, since it is a basic
explanation of a software feature from the end user’s perspective. For a Tester, user stories function
as a checklist that aids in scenario coverage and enhances the validation.

Despite its importance, user stories are often changed by the Developers and Business Analysts but
sometimes miss out on intimating the tester who is bound to validate the software/ product. Though
their inputs are valued, Tester must be informed of the changes made – either by directly tagging
the respective tester to the user story, or by creating a child story out of the former story and
tagging the Tester concerned.

Too much noise distorts attention:

Communication is an essential part of any project. Daily stand-up calls and emails are all a part and parcel
of the day-to-day communications related to the project. However, stakeholders fail to
communicate the most relevant and much-needed information to the other teams involved.
Cutting the noise in DevOps communication is mandatory as it ensures that important
communications aren’t overlooked. Unnecessary frequent mailing must be reduced, or possibly
avoided. Mails must be segregated and labeled accordingly. Changes made to the existing user story
can be communicated by auto-triggered DevOps mail labeled with a “High Importance” flag. This will
ensure that such emails will not be missed out in the clutter.

Teaser – Trailer – Main Show:

A digital product or service is in a continuous development cycle with frequent fixes and code
changes. Due to this the Testing team often runs into regression and most of their effort and time is
invested in regression runs.

The Testing team must spend its initial effort in creating sanity test packs for any projects/ products
and must use them for any build before the recent build gets pushed into the QA environment. Post
sanity checks, if the build is deemed fit for evaluation, the QA team must confine their daily sprints
to new user stories and defect fixes alone.

Once this step is completed, teams involved should arrive upon an agreed weekly build (say,
Tuesday/ Wednesday), and the regression test should be run only for that build. Promotion of the build
must diligently move from Dev to Test to Staging.

Mandatory Gating Clearance:

User stories are often signed off and proceed to the other tasks. What teams fail to understand is
that the Testing team must have a say and the user stories must be signed off by them as part of go-
live decisions. Very often there is an incumbent risk of issues being released in the signed-off user
stories. If the end goal is to release a product/ service that will cater to the needs of the end-user
and provide high customer satisfaction; then it must be made mandatory for Tester to sign off on any,
and every user story.

The issues discussed above may appear to be too simple at first glance. Nevertheless, many teams
arrive at daily and frequent issues due to the very same reasons discussed above. This impacts their
overall project development and spills into the overall product/ service quality. Thus affecting the
brand’s reputation and customer satisfaction. The core of the problems lies in basic everyday
communication and collaborations, which can be solved if the teams involved work as a single unity,
working together; rather than a fractured state/ union that is disjointed from one another.