The Agile Mindset: Cultural Changes for Successful Transformation

Agile transformations can be a challenging undertaking, and many organizations struggle with what is probably the hardest part of the transition: adopting an agile mindset. It is imperative that teams embrace the agile culture before they can fully embrace agile.

Let’s discuss the major cultural shifts needed for a successful agile transformation. Full article-> https://blog.gurock.com/agile-mindset/

Collaborating to Make Decisions

As I always like to say, agile is more a mindset than a process. It guides you to a better way of working and collaborating in order to deliver the most value to your users. But how you choose to implement those guidelines is up to you, and most teams coming from a traditional style of software development find this aspect the most challenging.

Teams are left to find ways to work together rather than having a process forcing them to do certain actions, follow certain processes, or organize specific meetings. There are no templates or techniques to adhere to and no rules to follow strictly.

This may come as a surprise and leave teams guessing since they are used to being told what to do and how. Agile drives them to think on their feet as they plan and replan their way through the development process. Read More–>

Being Comfortable with Visibility & Exposure

Agile gives everyone a voice and values every person’s opinion. Many teams have been used to only the manager speaking for them or having one representative in most meetings. As a result, some team members may feel flustered now that they’ll occasionally be in the spotlight. People who are not used to voicing their opinion are expected to speak in all forums. Hiding behind the team is no longer an option in agile.

This also means team members are valued as individuals and everyone’s contribution is recognized. Agile treats all team members as equals, whatever their role or designation. They are expected to estimate their own tasks, pick things to work on, collaborate with other team members, and provide value by the end of each iteration. Continue Reading–>

Increasing Communication and Collaboration

Communication is a big factor in agile teams. Developers and testers are always expected to be co-owners of their features and user stories, so they need to collaborate constantly. Business analysts and product owners also need to collaborate with the team to ascertain requirements, answer questions and get clarifications.

Single-scheduled points or meetings during the day are no longer enough. Teams need to learn to collaborate rather than handing off work from one person to the next. The tester-developer relationship sees a new dynamic of working toward the same goal rather than against each other. This may be the toughest of all cultural shifts, so it needs proper grooming from the managers and product owner.

We can no longer rely on metrics like the number of defects logged to find which tester performed the best, or defects logged against a feature to find developers’ efficiency. These are not useful measurements for agile teams and are not good for promoting collaboration.

Managers must encourage team spirit. Instead of pitting developers and testers against each other, managers should promote collective ownership of a user story by a developer and a tester. Continue Reading–>

Embrace the Agile Mindset

Ceremonies and meetings can be organized and repeated easily, but the culture and mindset that are needed to succeed in your agile transformation journey do not come in a single day. Time and patience will be required to resolve people issues, answer questions and doubts, and schedule multiple types of training and team activities to get everyone on board. But these small steps can go a long way toward making teams understand and embody the spirit of agile.

Please read, comment and like my article at TestRail blog https://blog.gurock.com/agile-mindset/

5 Ways Agile Testing Is Different from Traditional Testing

My latest article for stickyminds.com focused on the essential differences between Agile and traditional approach of testing >> published here

****

The agile world is abuzz nowadays with talk about agile testing and the key role of testers in an agile project. Some even say testers are the key piece of an agile team, arguing that they define the success or failure of the team’s attempts to be agile.

But what makes agile testing different from traditional testing? It’s the distinctions between the agile and traditional software development approaches, but also the adaptability of testers in these very different environments. Agile demands more from its testers, and, in turn, it values them more, too.

Let’s look at five main things that make an agile tester’s life different from that of a traditional tester.

Continuous Involvement

In traditional projects, the test team works mostly in a silo, and there is little or no interaction needed with developers or other teams on a daily basis. But in agile, the test team is integrated with the Scrum team instead of being a separate unit. They need to be continuously involved in all aspects of the project, starting with the requirements and design of each feature. This makes the testers’ days busier with discussions, meetings, and interactions where they need to put forward their opinions.

Agile necessitates that everybody report to the Scrum team first and their separate testing or development team later. In my experience as a part of a Scrum team, we would discuss our vacations or skill training needs first within the Scrum team, then inform our test manager afterward.

Essential Tools

Agile needs tool support more than traditional projects do because of the pace of development and continuous iterations. Each iteration brings along some regression work from the previous iterations that needs to be automated quickly.

The same is true for test data generation, white-box testing tools, and static analysis tools, which become a necessity in an agile system. Given the time and quality constraints, performing white-box tests using control flow or data flow analysis, static analysis of code, or reviews for code and documents is no longer optional. Instead, it’s a mandate to prevent defects and ingrain quality into each work product.

While in traditional projects, tools may be a luxury we might not be able to afford, in an agile project they become a necessity. Testers need these tools’ abilities in order to achieve their quality targets.

When my team began our agile transformation, we had one automation engineer who would work on automation scripts for the entire project. But when pacing through the sprints, we quickly realized that one automation engineer was not able to keep pace with automating all features in all sprints. So, everybody started pitching in by scripting the features they tested, and eventually it was mandated. The automation expert was only used for framework-level implementation, and later he was absorbed as a functional tester.

Due to frequent changes in the application within the sprint, we would follow an (n–1) approach to automation of our product, automating the features of the nth sprint in the next sprint, then subsequently using them for regression. But due to overload of regression building up as we progressed, it was crucial that each tester be able to perform and use the tools effectively, building up the test suites every sprint.

Multidimensional Skills

A traditional project has set expectations from the testers and testing activities. Each phase of testing gives set outputs, such as test design and specifications in the design phase, functional issues and defect reports in the execution phase, regression tests and retest results in reruns, and acceptance test reports in the end phase. This pattern does not leave much room for anything else because the project is already hard-pressed at the deadline.

But an agile tester’s viewpoint covers not only the functional aspects of what he is testing, but also many broader aspects of the application. He need not be a performance testing expert to suggest during the design discussions that the design might not be able to support too many users. He may not be a usability expert, but he can suggest better ways to design the web form of their user story. He may not be a technical writer, but he may be required to review the installation guide steps. An agile tester has to have a broader perspective of quality in his project’s context and possess skills in all those areas.

Effective Communication

Agile requires effective communication among the team members at all times, and testers play a key role in establishing and maintaining that. For example, as a part of a Scrum team, a tester will be required to wear many hats: that of a requirement critic for the product owner, of a design reviewer for the developers and architects, of a functionality expert as a tester, and of a release adviser to the manager. Testers have to give their opinions and ideas at all stages of the project, which may be not required (or even much welcomed) in a traditional project.

Testers act as the binding force of the team when they work in pairs with developers, sharing their test cases and ideas, as well as when they work as a quality reporter for the manager, with daily statistics and defect metrics for each sprint. The art of verbal and written communication is essential in an agile project.

Quick Feedback from Testing

The most important difference for agile testers is the quick feedback being given from the testing perspective at every point. The agile timeframes are shorter than on a traditional project, and testing needs to provide feedback about project quality on a regular basis. Daily stand-up meetings, design discussion or review meetings, the user story verification status, and sprint retrospectives all require constant feedback from testers.

There is some additional pressure because the direction of the project gets defined by this feedback, and there is no final “quality gateway” at the end if the project does not meet the deadlines or quality goals. This keeps the testers on their feet at all times, unlike in traditional projects where testers are required only at the end of the project for a sign-off.

Working in an agile environment can be challenging for testers coming from traditional projects, but by being open, flexible, and adaptive, they will find that an agile team is a wonderful place to be a tester.

Do share your views!

Cheers

Nishi