My ex-client went through a very similar thing. When I started, QA wasn't invited to walkthroughs, project meetings, sprint planning, daily stand-ups, etc., and developers were estimating the time for QA! Genuinely couldn't believe it.

The problem was, QA (being the ultimate gatekeepers of quality) were just seen as obstacles rather than valued members of the team.

Our initial argument was that it might take development one day to produce a fix, but it might take QA four days to test it - QA is the experts, the time required for testing shouldn't be left to anyone else.

So, we came to an agreement that we were able to join stand-ups, sprint planning and retrospectives as observers... which just meant we'd sit in the corner and not get involved.

The business realised they had no genuine visibility of how long it'll take project work or fixes to be delivered. They only knew how long it would take to develop. There was learning and understanding required from development (and the Project Manager) but, slowly, they started asking QA for input and advice because we were there - in sight, in mind. We also highlighted the cost of finding defects early on (PM's tend to recognise the benefit when cost-saving is involved!) and did a presentation on the importance of raising defects, even in static testing. The developers just needed to know that raising tickets against their work wasn't personal.

After a few weeks, QA being involved became second nature to them.

Anyway... when I left, QA was part of the development team and invited to everything (even when we thought it was too early!) and, although our time assigned to the developer, it was definitely progress and our throughput was recognised! We were active participants in all meetings, and the development team considered our input as constructive.

TL;DR: Request to observe the discussions you're being left out of. Over time, you'll be involved.

As an aside (and apologies for the essay), not tracking your time separately might work in your favour because the business can't ask where your effort is going. This is dangerous for them, but not so bad for you if you fancy a relaxed day or two ;)

My ex-client went through a very similar thing. When I started, QA weren't invited to walkthroughs, project meetings, sprint planning, daily stand-ups, etc., and developers were estimating the time for QA! Genuinely couldn't believe it.

The problem was, QA (being the ultimate gatekeepers of quality) were just seen as obstacles rather than valued members of the team.

Our initial argument was that it might take development one day to produce a fix, but it might take QA four days to test it - QA are the experts, the time required for testing shouldn't be left to anyone else.

So, we came to an agreement that we were able to join stand-ups, sprint planning and retrospectives as observers... which just meant we'd sit in the corner and not get involved.

The business realised they had no genuine visibility of how long it'll take project work or fixes to be delivered. They only knew how long it would take to develop. There was a learning and understanding required from development (and the Project Manager) but, slowly, they started asking QA for input and advice because we were there - in sight, in mind. We also highlighted the cost of finding defects early on (PM's tend to recognise the benefit when cost-saving is involved!) and did a presentation on the importance of raising defects, even in static testing. The developers just needed to know that raising tickets against their work wasn't personal.

After a few weeks, QA being involved became second nature to them.

Anyway... when I left, QA were part of the development team and invited to everything (even when we thought it was too early!) and, although our time assigned to the developer, it was definitely progress and our throughput was recognised! We were active participants in all meetings, and the development team considered our input as constructive.

TL;DR: Request to observe the discussions you're being left out of. Over time, you'll be involved.

As an aside (and apologies for the essay), not tracking your time separately might work in your favour because the business can't ask where your effort is going. This is dangerous for them, but not so bad for you if you fancy a relaxed day or two ;)

My ex-client went through a very similar thing. When I started, QA weren't invited to walkthroughs, project meetings, sprint planning, daily stand-ups, etc., and developers were estimating the time for QA! Genuinely couldn't believe it.

The problem was, QA (being the ultimate gatekeepers of quality) were just seen as obstacles rather than valued members of the team.

Our initial argument was that it might take development one day to produce a fix, but it might take QA four days to test it - QA are the experts, the time required for testing shouldn't be left to anyone else.

So, we came to an agreement that we were able to join stand-ups, sprint planning and retrospectives as observers... which just meant we'd sit in the corner and not get involved.

The business realised they had no genuine visibility of how long it'll take project work or fixes to be delivered. They only knew how long it would take to develop. There was a learning and understanding required from development (and the Project Manager) but, slowly, they started asking QA for input and advice because we were there - in sight, in mind. We also highlighted the cost of finding defects early on (PM's tend to recognise the benefit when cost-saving is involved!) and did a presentation on the importance of raising defects, even in static testing. The developers just needed to know that raising tickets against their work wasn't personal.

After a few weeks, QA being involved became second nature to them.

Anyway... when I left, QA were part of the development team and invited to everything (even when we thought it was too early!) and, although our time assigned to the developer, it was definitely progress and our throughput was recognised! We were active participants in all meetings, and the development team considered our input as constructive.

TL;DR: Request to observe the discussions you're being left out of. Over time, you'll be involved.

As an aside (and apologies for the essay), not tracking your time separately might work in your favour because the business can't ask where your effort is going. This is dangerous for them, but not so bad for you if you fancy a relaxed day or two ;)

My ex-client went through a very similar thing. When I started, QA wasn't invited to walkthroughs, project meetings, sprint planning, daily stand-ups, etc., and developers were estimating the time for QA! Genuinely couldn't believe it.

The problem was, QA (being the ultimate gatekeepers of quality) were just seen as obstacles rather than valued members of the team.

Our initial argument was that it might take development one day to produce a fix, but it might take QA four days to test it - QA is the experts, the time required for testing shouldn't be left to anyone else.

So, we came to an agreement that we were able to join stand-ups, sprint planning and retrospectives as observers... which just meant we'd sit in the corner and not get involved.

The business realised they had no genuine visibility of how long it'll take project work or fixes to be delivered. They only knew how long it would take to develop. There was learning and understanding required from development (and the Project Manager) but, slowly, they started asking QA for input and advice because we were there - in sight, in mind. We also highlighted the cost of finding defects early on (PM's tend to recognise the benefit when cost-saving is involved!) and did a presentation on the importance of raising defects, even in static testing. The developers just needed to know that raising tickets against their work wasn't personal.

After a few weeks, QA being involved became second nature to them.

Anyway... when I left, QA was part of the development team and invited to everything (even when we thought it was too early!) and, although our time assigned to the developer, it was definitely progress and our throughput was recognised! We were active participants in all meetings, and the development team considered our input as constructive.

TL;DR: Request to observe the discussions you're being left out of. Over time, you'll be involved.

As an aside (and apologies for the essay), not tracking your time separately might work in your favour because the business can't ask where your effort is going. This is dangerous for them, but not so bad for you if you fancy a relaxed day or two ;)