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.
