Hello awesome people! First of all, thank you so much for joining our MoT Spain meetup today! We had tons of fun (even if we were nervous hehe) and your questions made the meetup really enriching.
Who attended the meetup:
17% Devs
66% Testers
17% Other
I’ll post all the questions here so that Daniel Mondria (speaker) and the community can answer them. Daniel Mondria’s slides: Dev+QA not and odd couple.pdf (996.4 KB)
These are my sketchnotes in case someone finds them useful:
In order to work this way, you should have a (or close to) 1:1 relationship between the number of QAs and Devs. How do you work if this relationship is 1:5 or even bigger? (Question asked by Jose Apuy)
Nice presentation. On top of everything covered, have you considered creating a “threesome” involving PO for improving quality of requirements definition and understanding? (Question asked by Sergi Miso)
Would it be better to pair experienced QA & Devs together or would it help to pair junior QA with experienced Devs so that overall team knowledge improves? (Question asked by Kamalesh Kalarickal)
Pairing all day is hard. 100% agreed. However, the idea of this is to always pair when you are working on a story. You can take as many breaks as needed, or work by yourself on something that’s not related to the project. When working on a story (either developing or testing it) we should be pairing.
It’s key to get an ally and start the collaboration with that person. When results start to work, look for a third person, as hopefully now 2 people should be looking actively for this. And so on. Little by little, everyone will join as the team gets used to work like this and results are good.
If there’s a strong opposition to the pairing, I’d encourage to work as a team in both Mob Testing and Mob Programming. That may help everyone getting more used to collaborate with each other and facilitate the pairing
I don’t expect that ratio to be 1:1. In fact, in my last project, the ratio was 10:1.
The idea is to start pairing a DEV and a QA and keep rotating. This way, little by little, all DEVs will get used to pairing with QAs.
In my case, the DEVs were already pairing, which of course simplifies this. However, if they don’t do, we should advice developers to pair with themselves. This way, they’ll get more used to pairing and make pairing with a QA easier
Start with 1 story by having it tested by a DEV+QA pair. Then let’s do the same with another DEV, and so on.
Once all DEVs have paired in testing a story with a QA, let’s do a sprint where all stories will be tested like this, DEV+QA. And if it works, maintain this (from then on, all stories are tested not only by QA, but also by DEVs).
At this point, DEVs should be able to test stories by themselves, so the QA should not be strictly needed for the testing
Once testing is always done by DEV+QA pair or DEVs (without QAs), start getting involved in the coding.
Sure!
However, there’s an extra challenge with this, us most of us were not used to remote work before.
If you want to try it now, I propose following the same technique I proposed for the previous question from you (one story, keep repeating, and then all sprint stories)
You are absolutely right. Pairing with the PO or BA, is key, as this will help to have clearer ACs, making both development and testing simpler.
However, I’ve left this as out of scope for this talk, as I was focusing in the collaboration between DEVs and QAs.
I believe the PO/BA should work closely not only with QA, but also with DEVs, to make sure stories are clear at all levels.
Whether you follow some formal 3 Amigos or something else, is up to your team to decide.
I think the important part is to have the developer that’s best at teaching to pair with the QAs when focusing on coding.
And the other way around, QA who’s best at teaching to pair for focus on testing.
The other member of the pair is not so important, but the person who has more knowledge in the area we are focusing on (DEV if code, QA if test), should be the best one from the team at explaining.
Not a formal one, no.
However, from my experience I think team happiness will increase due to these factors:
1st QAs will stop being bottlenecks, which will make their work easier
No testing bottleneck will remove blockers and increase the feedfback loop about the stories
Once new methodology fully stablished, I believe fewer bugs will be raised. Why? Because the team will be able to put more time on the testing area (more people available for it) and testing automation will be also agreed with QAs (so it should be more complete). For sure less bugs will also improve team happiness
I don’t think we should go so far as saying this will be the future of IT
However, I believe agile teams should embrace this approach. This idea helps to spread the quality between the team, raises skills from everyone, and increases collaboration at all levels within the team, which I think is key.
In my opinion, Agile teams will slowly flow towards this. So the sooner you do it, the better for you
