Whose responsibility is it to encourage/ensure knowledge flow across Agile teams?

Question

I am working with larger and larger organizations adopting Agile. One discussion recently has kept me thinking about a challenge I hadn't been paying attention to heretofore. That is, how do we create approaches, working agreements, and technologies for knowledge flow across teams? I don't want to push "standards". I do want to make team-level knowledge move outside the team. I'm torn about whether to find a "push" approach (i.e. here is all the latest "stuff" we've seen) or a "pull" approach (i.e. if you are interested, we've collected a lot of information.) Ideas?

I had an idea spring to mind yesterday. Wouldn't it be great to have an internal StackExchange!? Thoughts for or against such an approach within an organization?

I'm still looking for something more specific. If we can't capture persistent knowledge a la StackExchange, what can we do? This can be larger than Agile. I just happen to be most curious about Agile knowledge flow given the sense of pulling emergent practices versus pushing prescriptions.

Answer 1

If we focus on whose responsibility it is to share knowledge/experience the answer is: everyone's.

Actually, no matter how big, or small, the company is -- you can't have just one role responsible for sharing their experience or facilitating such exchange among teams.

It's more about company culture: you either support open communication, transparency and information sharing or you prefer secrets, gossips and treating information as scarce resource. In the former case you don't need anyone being formally responsible for knowledge sharing; in the latter making anyone responsible for that won't work anyway.

So while it should be everyone's responsibility to ensure knowledge flow I'd point management, especially senior management, as a special group here as these are people who are most responsible for building company culture. If CEO and CSO treat every deal the company works on as a secret, why do they expect people down the ladder would behave differently with their knowledge, whatever it might be?

Answer 2

We run regular 'Brown Bag' sessions where the company provides lunch (usually Pizza, nom nom) and people from teams can come and present cool new stuff they are working on. Topics have included MVC, Facebook API, Deming's red bead experiment, dependency injection and so on, as well as more specific session on particular projects people are working on.

These help share new engineering practices and ideas across the teams and the free lunch usually guarantees a good attendance. It's a reasonable balance between push and pull - people aren't forced to attend but it provides a structured way for people to find out more about what their colleagues are working on.

We also run communities of practice amongst the different disciplines (Dev, QA, BA, ScrumMaster). These tend to be more focused on detail than the brown bags, e.g. informing devs of major changes that have been made to systems that everyone needs to be aware of. More info on Mike Cohn's blog on that, in the article cultivate communities of practice.

Another point of knowledge transfer is 'Scrum of Scrums' which a member of each team attends once a week. The intent is to keep other teams appraised of who is working on what to avoid conflicts/dependencies. It's not as effective as it perhaps should be, something we need to look at.

An initiative we've started recently is a fortnightly award called 'Achievements in Agile' where teams can win a prize (usually a night out or toys like Nerf guns) for stuff like trying innovative process improvements. This is peer nominated which means teams need to actively promote what they are doing.

Teams also invite members of other teams to showcases etc.

Finally, we're a pretty social bunch so there is usually a decent amount of discussion in the pub about what is great (or not) about what we're working on at the moment!