Sharing domain knowledge across Test Teams based in multiple locations

[Claire]

Does anyone have experience of knowledge sharing across multiple test teams in different time zones?!

I’m looking at setting up a small subset of testers with domain knowledge to create and share information that would be useful for chain testing across multiple applications.

Current Limitations:
Test Teams based in 7 countries with a timezone difference of 10 hours between the most easterly and westerly team
Six out of the seven locations specialize in domain knowledge on the same set of (front-end) applications, slight difference in versions, each have this own instance with some customizations
One of the teams specializes in domain knowledge on back-end applications

The knowledge needs to be documented/mindmapped/drawn/wiki’d from the ground up.

My thinking is to start with tracing the end-to-end process with something small e.g. ‘Existing customer modifies their email address’ Then document the impact of this change end-to-end across our multiple applications. Build the knowledge base from a functional perspective. Timebox each knowledge share session to 30 mins max and try to use skype as the testers will be based in difference locations.

If anyone has advice on how to start the process, tooling, quick wins, what not to do….from personal experience i would be very grateful!!!

Thanks,

Claire

[Michael]

This is a very difficult problem, but I think you’ve already considered a number of good suggestions.

One more to offer: I visited with a team recently that had an interesting approach. One of their deliverables for each new feature is a short video—just a couple of minutes, typically—that describes the feature and how to use it. This involved a person (let’s call him Matt) preparing a screen recording that usually captured him walking through a task that the feature afforded. This had at least two valuable effects. First, Matt would stumble over bugs and problems as he attempted to perform the task; these stumbles would turn into bug reports and feature refinements. Second, it provided a kind of tutorial by which other groups in the company could learn something about using the feature. For some people at least, that’s a more engaging way to learn than reading about it.

Be careful about “the knowledge needs to be documented…”. I don’t see agency in that sentence. The knowledge doesn’t need to be documented; some people may need the knowledge to be documented. Here’s a more high-falutin’ but more accurate way of putting it: the knowledge probably needs to be institutionalized.

Perhaps the knowledge needs to be documented; or maybe the knowledge is so important that it must be embedded in a human mind. That is, a person should have the knowledge internalized and memorized, ready to use it without recourse to looking it up. That is “relational tacit knowledge”, as Harry Collins would put it.

Perhaps it should be embedded in a human body, capable of being done automatically. Think of juggling, shifting the gears on a car with manual transmission, or touch typing. Harry would call this “somatic tacit knowledge”. Somatic tacit knowledge is hard to describe in some senses and impossible to describe in others. I can document my somatic tacit knowledge, but you won’t learn how to do it by reading. You’ll need practice and feedback of some kind to learn it.

Perhaps the knowledge should be embedded in the culture or the society—that is, “the way we do things around here”. This is “collective tacit knowledge”. That too cannot be documented very well, since it’s always in flux and subject to the social relationships between individuals and groups. Collective tacit knowledge gets developed when people work together. It apparently depends on the kinds of social cues and observations that people enact in the moment while they’re in each other’s company; doing stuff together.

So, to the greatest degree possible, try to supplement the documentation and the online stuff with visits. Now, companies often protest that it’s “too expensive” to do that, paying attention to the cost without paying attention to the value of doing it and the risk of not doing it. But when people don’t work together, it’s easy for them to work apart.

Hope this helps…

—Michael B.

[mergan]

Although our scenario was a lot less complicated than yours, I’m certain that aspects of our approach can be applied to your situation. We had teams based in 3 locations (3 different companies – one primary client and two supplier teams) with a 3.5 hour time difference between the teams and a total of around 30 people involved in setting up an automation competency, which was meant to support the efforts of an existing manual test team (yes, we had separate manual test and automation teams, for a variety of legacy reasons).

One of the first actions we took was to set up a rotational roster to ensure that every member of the two offshore teams traveled onsite (to the primary location) and spent 2-3 weeks getting on good terms with the primary team. Aside from the ramp-up process getting a kick start, this was essential in breaking down communication barriers (even though everyone spoke some level of English) and any other barriers that are usually apparent when working with remote teams or with people you’ve never met. We also put together a training pack which was delivered to the visiting team members on each visit, so that it was refined on successive visits and was taken back with returning team members in case they needed a refresher at any point. We tried to make sure that different people presented the training so that the material was not tied to a specific author. This ranged from simple information (getting started, FAQs, etc.) that we didn’t want people to get stuck with, to much more complicated aspects delving into our technology stack and how it was put together. The reason for doing this was that we wanted people to feel that anyone could contribute to the foundational technology if they were interested enough and spent enough time getting familiar with it. A positive side effect was that we started receiving feedback on our core framework that exposed bugs which we’d been blind to previously. Of course, there is a cost implication, as Michael pointed out, but the savings realized in getting a team to function coherently across time zones is much larger than any once-off costs.

In terms of tooling, I don’t know whether you have anything in place or whether you have budget available but my view is pretty strongly in favour of getting the best tools your money can buy. That isn’t to say that you need to spend big money on the tools, just that you can’t really cut corners on this aspect when it comes to facilitating collaboration across time zones and locations. I’ve implemented large-scale ALM solutions twice in my career so that’s definitely something I believe in and can vouch for in terms of value add. That is usually a long road though, because it affects everyone in the product life cycle and is usually not very cheap for the good solutions. However, depending on your budget, you could start off small looking simply at getting a decent tool set up to manage your issues and tasks and build from there. In terms of recommending tools, I’ve worked with JIRA for issue tracking and I’m quite a fan of it. I don’t think it’s really sufficient when you start to look at your entire application lifecycle though – in those cases, my preference is for the IBM Jazz solution. It is available in a free version for teams less than 10 members but it’s pretty expensive for an enterprise roll-out (you get what you pay for though, it’s a really slick tool chain). Without a tool-based infrastructure for collaboration, my guess is things are going to be difficult to sustain and track.

With regards to the actual documentation, I’m not really a fan of heavy documents that have a high overhead in terms of maintenance. However, if you are going to document your system, I think you are better off getting parts of your team to create a document and getting other parts of your team to try to use the document to do something useful. As they run into difficulties in interpretation, they can update the document and hand it over to the next team to try to interpret it as well. This way, you should have several eyes on the same document and hopefully a more easily understandable set of documents in the end. With an ALM tool, you’ll get the opportunity to implement your documentation within the tool so its much more up-to-date than conventional MS Office docs so I really would recommend looking into that. You can also document links and impacts between related features so that changes in the features can be seen for their impact across the entire system.

There’s a lot more to consider but I hope these points give you some food for thought…

Mergan

[Author]

Posts