This blog post will take you through the importance of making sure everyone in all our teams is equally involved. What I mean by this, is Backend and Frontend Developers, QA Engineers / Testers, Business Analysts and Product Owners.
The main topic here is to make sure members of the QA team are involved from the very start when discussing a new idea, project or product. Testing and Quality Assurance are sometimes a contentious area; requirements tend to have holes. We can prevent this from happening by being part of a team from the very beginning, where we can remove ambiguities and assumptions.
According to the PMI 37% of projects fail due to inaccurate requirements and assumptions, this is not a small percentage. If we all work as a happy family and get every individual team member involved for vital meetings, these assumptions can then be discussed upfront and everyone’s voice gets heard. Now I know this can be time consuming, but if we use up this time now, we save a lot of money rather than thinking of this assumption once the implementation is live.
Previously, when teams used to adopt the waterfall process, Testers would only get to know the project towards the very end of the delivery lifecycle. Therefore, raising bugs or defects to fix problems in the code, could be very expensive; and not being involved from the very start means issues that could have been resolved sooner, get pushed back and potentially result in costly delays.
In this blog post I will talk about all the interesting and important bits that each team should consider for their QA members and how to have a happy agile family. I will also be asking Giles why ‘Quality’ is an important part of the agile lifecycle. Giles Lindsay is a former Chief Technology Officer and is now CEO of Agile Delta Consulting and I (Laveena Ramchandani) am a Senior Tester.
Something I admire and 100% agree with, is that testing should form part of every stage possible in the software development life cycle (SDLC):
Why is this important?
As Giles mentions to me, quality is everywhere from idea to value.
“Quality is a requirement throughout all phases of an agile delivery lifecycle”:
The Inception phase:
“In the Inception phase we, as a team, initiate the endeavour in a streamlined manner. This includes initial planning and modelling, obtaining funding and forming the team with all the right members involved. In addition to this we obtain agreement regarding the vision with the primary stakeholders.”
The Construction phase:
“In the Construction phase, we develop a consumable solution in a collaborative and incremental manner. The team requests feedback regularly and acts on it accordingly.”
The Transition phase:
“In the Transition phase we release/deploy the solution to stakeholders with continuous deployment strategies. Ideally releases/deployments happen at the point where a new minimum business increment (MBI) has been developed.”
A question for you: ‘Why do you hire a QA Engineer/Tester as part of your team’?
One little misconception many people have told me is that the QA team looks for bugs, even though bugs are not a bad thing entirely. We would rather find them sooner rather than later! But we need to understand what GOOD looks like. How do we make sure we achieve something that is GOOD?
That is what we do, but as a team, not just ourselves. Now to do it as a team we all need to be on the same page. This means making sure QA Engineers/Testers are involved in any meeting which might give us information about the upcoming requirements/implementations. Even a nugget of information shared by Giles, helps us understand how to test things better.
“QA teams are sometimes considered our virtual clients. They are not necessarily always involved with things like software architecture, design patterns and system performance. This means they often look at the end-product more than its construction. They empathise more with the end user.”
“QA’s different focus means that the teams have members with divergent thinking. The QA team often spot assumptions that are being made in the inception and construction phases. Teams can then go and find out whether these assumptions are true and useful or false, with the risk of leading us down the wrong path.”
The QA team tends to be part of some meetings but not all. Now the question is WHY NOT? We need to avoid as many knowledge silos as possible. The value a QA team can bring, is uniquely different to what any other team brings.
When we are all together, we have a great team, but it’s vital to have QA Engineers/Testers present. Avoid and remove any friction in this area. As a team all of us should be in the bubble together, and not leave some members outside of the knowledge bubble. We are all working towards the quality of the product we are creating. Someone once asked me who is responsible for the quality of the product, I happily responded saying “the entire team”.
After having a chat with Giles, he mentioned once that he didn’t see an invite for the Head of QA to a meeting, it may sometimes seem “argh it’s not important to involve the Head of QA at a budget meeting”, but you never know what a Head of QA might come up with!
Have you adapted to the Agile processes as a team?
Are you an agile team? What does this mean to you? Are you completely following agile processes? Have the team members adjusted with the change? Have you all adopted an agile mindset? I would suggest adding the 3 amigos session as much possible during the project, as this is another agile feature that helps in understanding requirements better.
What might you do if you don’t feel happy?
We spend a lot of hours working with our work family. Sometimes it is happy, sometimes it’s too much work and rushing to deliver. There can be times where you may even feel left out. Do not worry at all, all you need to do is be vocal, make sure your thoughts are heard and you can be more involved with everyone. Some of the tips that I’d like to suggest are:
- Speaking up is key
- Mentioning at your stand ups that you would like to be involved
- Attending grooming/planning sessions
- Pairing up with product owners, to get more knowledge of the requirements
Also, sometimes one has so many meetings already, that team members decide that “ok we will only invite those who are required”, whilst the rest can get on with deliverables. This is completely fine, but there may be small nuggets that could potentially be missed. Yes, it is known that meetings do take up a lot of time and sometimes we have days where we were just engaged in meetings and that’s it. But we were all in it together :)
Conclusion
We spend much of the week working with our colleagues, it’s like having a work family. As Testers and Quality Assurance members of the team, let us aim to be in most meetings possible which count.
It can at times be a lot of meetings, but you never know you might mention something useful in the discussion or even learn something vital too. If this is something that is not happening in your team currently, prompt it and find some good ways of being part of these meetings. Let’s be agile, let’s be a happy family. Let’s try and be like the spears family.
