1

Where I work we follow a scaled agile process based on scrum which we've changed to suit our culture and needs. One thing I feel we are missing are guilds to allow the free flow of information between members of a community of interest.

I'd like to setup a guild for Software Engineers however most information I've found has guilds set-up around narrow topics (e.g.: front end, performance, automation). Given the size of our technical workforce (300ish with 1/3 being software engineers) I fear that picking such specific topics we will have guilds which are too small and hence defeats the purpose of getting people to cross-pollinate/share widely.

So my question is, what is a typical guild size and a corollary question is should the scope of a guild be adjusted to achieve this size?

4
  • I think the point of having specificity in a guild is to ensure that everyone attending is capable of participating. An engineer who lacks knowledge in say Jenkins knows that showing up to the Jenkins guild will doubtlessly help fill them in on Jenkins (very engaging). Where as an Automation guild while more general, may be currently focusing on Cake (maybe this is interesting but definitely frustrated about the lack of Jenkins). Similarly an expert in Jenkins will be happy helping out with Jenkins, but possibly out of their depth with other automation technologies. – Kain0_0 Jan 28 '20 at 22:56
  • Thanks for that @Kain0_0 I get what you are saying (thought I slightly disagree) but the problem with applying this approach where I work is that we would have too many small guilds in my opinion. What is too small, what is too big? That's really my question :) – hhafez Jan 28 '20 at 23:02
  • 2
    Why do you feel that you need to manage this? If a guild contains just 3 people but it allows those three people to forge strong internal support structures how is that not beneficial. Similarly a guild might have every single engineer sharing say clean coding practices, how is that not beneficial? When a guild stops being beneficial, the engineers will stop participating in it. They have better things to do. – Kain0_0 Jan 28 '20 at 23:23
  • Basic layout: 1 Guildmaster (can only master one guild), guildmaster gets x hrs/wk for guild business, a webspace, budget per participant. Everyone gets x bankable hrs/wk to participate in guild events (meetings/workshops/presentations/etc...). Guild minimum size is 1. No Max cap. The cost to business has a cap as there can only be one guild per engineer. The total guild budgets is at most $y per engineer as it is based on participation, and each engineer only has x hrs to spend in any guild. Leave the rest to the engineers to figure out. Perhaps offer a decent rate for hiring rooms. – Kain0_0 Jan 28 '20 at 23:28
5

The term "guild" appears to originate in discussions about the method used at Spotify. The Scaled Agile Framework refers to this concept as a "Community of Practice", but this term isn't unique to SAFe - it was originally proposed in 1991 and is not unique to software development.

Given your organization size of ~300 with ~100 of them being software engineers, it feels like a "software engineering" guild or community of practice would be too large. If you want to build meaningful relationships among the participants, consider Dunbar's number - the idea is that people can only maintain about 150 stable relationships, and you'd probably be pushing these cognitive limits if you consider a person's relationships outside of work, the team that they participate on, and the community of practice.

If you don't want to necessarily build relationships, I'd wonder if developing a community of practice would be appropriate. Things like lunch-and-learns with topics that may cross-cut roles may be appropriate, for example, but there may be other options.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.