I was invited by @LeadDev organisation to be a part of a webinar where we had a panel discussion on “Building a better testing culture“. I was elated to be a part of this great group pf panelists alongside Thayse Onofrio from Thoughtworks and Marcus Merrell from Saucelabs. We had a spirited and interesting discussion and shared some meaningful ideas on the topic. I would also like to thank our host Amanda Sopkin for her really on-the-nail questions and for directing the conversation, and our organiser Olivia Christian for inviting me and for her support throughout the event!
The webinar panel was live, lasted for 45 minutes and then we had some time for Q&A. There were some great questions and discussions over the LeadDev slack channel as well.
Here is a bit more insight into the event-
The world of software testing is changing under the pressure of ‘speed to market’. The pressure to quickly get products to market means we are starting to see a significant shift towards automated tests during development. This will likely cause socio-technical complexities for orgs and teams currently involved in testing.
In order to be successful through these changes, orgs will need to have a clear strategy and processes in place that will ensure testing is a vital part of the delivery process. In this new age of testing, how can engineering leaders prevent pitfalls such as friction between teams, a culture of blame, and outdated processes?
In this panel, we examined how shift affects traditional testing set-ups, covering what a healthy testing culture looks like and how to avoid the anti-patterns that lead to uncommunicative teams and project bottlenecks. We explored how engineering teams can best work together and how to encourage a shared vision of quality and the importance of efficient and effective tests.
Define clear roles and responsibilities for quality and testing in your org
Encourage QA to be seen as necessary, rather than inhibiting release times
Understand which tests to automate, and which to not
LeadDev is a community of software engineering leaders that come together to learn and get inspired on all things team, tech, process, and personal development.
LeadDev has become an essential destination for anyone in tech and engineering who wants to scale themselves and create impact. They provide a range of content that includes articles, thematic content series, video talks and panel discussions, written and delivered by the best voices in engineering.You can register a free LeadDev.com account to gain access to our free engineering leadership content, free online events and our weekly email newsletter.
I am thrilled to be a part of this amazing group of panelists and chat about building amazing teams and a great team culture in this new age of testing. We will be covering what a healthy testing culture looks like and how to avoid the anti-patterns that lead to uncommunicative teams and project bottlenecks!
To top it all, this is a free event!! So, you can register a free LeadDev.com account to secure your place. Not only this, your account will give you access to our free engineering leadership content, free online events and our weekly email newsletter.
Register here now to attend this awesome event and become a part of this amazing LeadDev Community!
This chapter is dedicated to talking about organisational problems with agile adoption, mostly from a cultural point of view- how people perceive changes, how they work, giving up control and also taking charge. It is a very comprehensive description of many problems we see on a daily basis at our work and in teams struggling with agile transformation.
Points to remember and Quotable Quotes
Agile teams are best suites for organisations that allow independent thinking.
Fear is a powerful emotion, and if not addressed, it can jeopardize the transition into agile
Testers who don’t change their approach to testing have a hard time working closely with the rest of the development team
If the organisation culture is to push towards release without caring for quality, the teams will face an uphill battle in working in agile
Companies where testers assume the role of ‘Quality Police’ will also have a challenge since teams will not buy-into the idea of building quality in, as they are accustomed to badgering it in later.
If your organisation focuses on learning, it will encourage continuous process improvement and will likely adopt agile much more quickly.
Testers need time and training, like everyone else learning to work in agile
To help testers adjust, you may need to bring in an experienced agile testing coach to act as a mentor and a teacher.
Agile focuses on working at a sustainable pace, all the time. In contrast to the ‘fast and furious’ testing done at the end of release cycles in traditional projects (often amounting to overtime). In agile, if overtime is required, it is an exception, and that too for the whole team and not just the testers.
In agile, the relationship between the customer and the development team is more a partnership than a vendor-supplier relationship.
Even if an entire company adopts agile, some teams make the transition more successfully than others.
About Introducing Change-
“Expect and Accept Chaos as you implement Agile Processes.”
Find the areas of most pain, determine what practices will solve the problem so that you can get some immediate progress out of the chaos.
The critical success factor is whether the team takes ownership and has the ability to customise its approach
Celebrate success- Acknowledgement is important if you want a change to stick.
Rather than managing the team’s activities at a low level, managers of agile teams focus on removing obstacles so that team members can do their best work
“Agile development might seem fast-paced, but the change can seem glacial”
“Beware of the Quality Police mentality— Be a collaborator, not an enforcer“
The highlight of this chapter for me was reading the ‘Testers Bill of Rights’
I had not heard about this before , so reading this was pretty cool, and for sure fundamental to any tester’s life. Check it out-
Agile teams are constantly running toward goals, requiring constant planning, monitoring, and re-planning. Metrics can help support these efforts by providing useful information about the health and progress of the project.
There are a few common metrics we use in agile teams: sprint burndown charts, release burnup charts, team velocity. They’re common because they communicate practical information, but they’re not the only metrics we can employ.
In my recent articles for TestRail blog, I described 3 Uncommon metrics you can easily create that will be very useful for your agile team. I also wrote about 3 Metrics that are not useful and you must stop using now!
Metrics are supposed to help and support an agile team by providing useful information about the health and progress of their project. But not all metrics are always beneficial. Going overboard with them can sometimes cause more harm than good.
In this post I have described three metrics that can impede your agile team instead of motivating you.
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.
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–>