Cross-Function Collaboration

One of my greatest decisions ever (in my view, anyway) was on a project I managed a few years back.

Under pressure, and no time to waste – sounds familiar, I know – all we could do is produce more bugs. I asked the test team lead to assign testers to developers, to sit with them on their development machine to go over the different scenarios in the software. This was not even on a proper build – just to see that at least in high level, things worked as expected.

Soon enough builds got stable, bug count lowered, and the developers got out of the “babysitting” mentality into “we’re doing a better job” mentality.

I can’t take full credit for this (I was more of a persistent catalyst), but this method is currently being employed in another project by another team. Same pressure (maybe bigger), but at least they are starting to stabilize.

This is painful at the beginning. Apart from having a babysitter (which is sending a message of “I don’t trust you” if miscommunicated, which I’ve done), the process raises bugs early, in front of the developer’s face. So if not done properly,

But more communication is better, and flagging issues sooner is better. It will work for them, as long as they keep going like this. Good luck!

2 comments on “Cross-Function Collaboration”

  1. Derk-Jan de Grood Reply

    Hi Gil,
    I like your post. Short and a clear experience. In a way its nothing new, but you did it and made a difference and that is great. I remember a project were dev was throwing builds over the wall (this was the 90-ties, we still had walls in the office) to the test team, and we asked them to demo it worked before it was handed over. Very often they discovered during the demo that it did not work. It’s kind of similar, but you took it a bit further.
    Did you get much resistance, how did you overcome this. Did it work for all developers, did you make special matches in assigning testers to the specific developers. If you’d like, please elaborate on it. We want to know.


    • Gil Zilberfeld Reply

      Thanks for the comment Derk-Jan!
      There was some resistance, but not a lot. It really went quickly from “I don’t like babysitting” to “I’d like to deliver something good”. Team pressure worked in my favor, once the tide started to turn, and developers even started testers to look at their work before the checked code in. One of the things that worked is the persistence to continue doing it, and the unfortunate past of broken builds.

      I think it was the test lead who started pairing, and the rest of the testers followed. Pairing was based on functionality (there was both common language, and both wanted the feature to work), so I didn’t need to match the “right people” it just happened.

      The testers were in separate rooms from the developers, but not that far apart, so they visited the developers a lot during the day.

      Hope that helps,

Leave A Reply

Your email address will not be published. Required fields are marked *