This is a guest post by Nishi Grover Garg.
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.
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.
Teams looking to transition to agile must foster their decision-making capabilities first. Team members must be trained on problem-solving, working together to reach a consensus and finding best practices they would like to follow. Agile will give them goals and guidelines. They should be able to find the best way to achieve them together.
Agile gives everyone a voice and values every person’s opinion. In the Scrum methodology, each ceremony, including the daily standup, sprint review and retrospective meeting, gives a platform to everyone to raise their points and questions.
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.
Due to this complete transparency, each task that is accomplished on time, every useful action that is performed, every help that is rendered to others and every step that is taken toward better quality is now recognized and appreciated at the team level. This means that your accomplishments are your own and the team’s success is credited to each person’s success.
Getting people on board with this type of independence is important. We must show them the benefits of this approach and mentor them on things like task estimation, risk analysis and verbalizing their opinions.
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. It is also imperative that the product owner shows equal importance to both co-owners of a user story. In case of issues, questions should not be targeted to a tester alone, and in case of a good delivery, the appreciation also should be given to both.
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.
Help us improve this page!
What problem are you trying to solve?
Read more about how the QA team at ELEKS evaluated different test management solutions and why they ultimately chose TestRail.
This post covers how to show test coverage, manage requirements traceability, and create a traceability report in Jira.
Learn about the pros/cons of using Jira as a test management solution, alternatives, & how teams that use Jira manage their testing.