More Aspects of Agile Communities of Practice

This is a follow up article to my article about An Agile Community of Practice Starter Kit.  I wanted to share some details on other aspects of CoP’s.

Scope and Nature of a CoP

The scope of an Agile CoP can be of varying sizes and types. The most typical are (most frequent, to less frequent): Organization wide, Localized to a set of teams(Train, Product Group, Nexus, etc), Geographical location, and Organizational department. Organization wide CoP’s tend to be more educational and inspirational in the theme of their activities, while CoP’s localized to a set of teams tend to be very operational in nature. But truth be told, a single CoP can have all 3 of these themes in flight at any one time, only one of those themes in flight, or they could evolve from one to the other, etc.

Educational themed events include webinars and other similar education events, and even providing access and funding for people to attend training or conferences in the community interest. Another educational themed event could be a book club or a study group for achieving industry certifications.

Inspirational themed events includes meetings and other events that are meant to inspire people in the community interest. Some examples:

• An event to inspire attendees to develop a set of skills in the community interest
  “We’re looking for employees who are interested in being Scrum Masters”.
• An event to inspire community members by allowing attendees to be inspired by the success stories from others who have skills in the community interest.
  • “In today’s session, we’ll have 3 Product Owners talk about the very different ways the 3 of them go about Product Backlog Refinement, and all 3 ways are highly successful for their respective teams. We’ll wrap up with how the principles for all 3 are the same, even though the practices are quite different.”
• An event to inspire community members towards personal development in their community interest.
  • “In today’s session, we’re going to talk about a myriad of ways to develop yourself personally as a programmer, as well as some examples to give to your reporting manager so these ways can be included in your quarterly talent development goals. We’d also like to hear some of your ideas on this topic!”

Operational themed events include meetings where inflight product development work or impediments are being discussed. Some examples:

• Scrum of Scrums
• Scrum Master Sync (this and Scrum of Scrums are actually different)
• Nexus Daily Scrum
• Product Owner Sync
• Meta Scrum
• Program Increment Planning (yes, this is actually a very operational Community of Practice if you think about it!)
• Internal Open Source Component Rollout (Internal Open Source Communities are a great way to preserve shared code without having to use component teams)
• Internal Open Source Component Brainstorm Session
• Architecture Advancement Meeting
• Tiger Teams (these are usually short lived Communities)

Work efforts as a result of Community Improvement Backlog Items

One thing to keep in mind about operationally themed events and communities is that all work on the system/product under development still happens on Scrum Teams. Think about production code. If production code is to be written as a result of a Community effort, a Scrum Team must do that as part of their Product Backlog and/or Sprint Backlog. Any other type of work or improvement that doesn’t require production code can be done in a group of motivated like minded community members, or can also be done as part of a team’s Sprint Backlog. As long as it’s not production code, you have total flexibility in how you organize that non production code work.

Regardless of their scope or theme of events, CoP’s should have regularly scheduled retrospectives, regularly scheduled public meetings, and probably also need regularly scheduled private meetings(usually limited to role-players only, but could be other sets of people). As I said in my /CoP starter kit article, a CoP should also have a bunch of Community Working Agreements, a Community Improvement Backlog(CIB), and official communication mechanisms(formal and informal). All of those things still apply of course, regardless of the scope of a Community.

Roles

Community Coordinators(CC)

The coordinators act as the organizers of the CoP, and the main facilitators. One of the principles of a CoP is that you want to build an organization that is more bottom up than top down. Many organizations are coming from strong top down hierarchies. As such, the coordinators must come from the Scrum Dev Teams. You definitely want 2 of them to ensure continuity, and in case they get themselves on the critical path on their Scrum Team or take vacation, etc. At first, they could serve a 3 month term, but once the CoP has been in existence for about a year, you could experiment with a longer term if the community decided to change that agreement. Ideally, at least one of them is more junior, and there is no requirement that the CC be deeply skilled in the community interest. (Remember, there is a different role for skill depth: the SME’s) We’re focused more on people who will inspire community involvement and will responsibly handle community logistics/coordination (aka “social butterflies” and “workhorses”).

When you are bootstrapping the community, give some attention to trying to find a couple of good choices for the initial CC’s, and if they agree to take the role, it is theirs! After the bootstrap, going forward, elections are held halfway into the term of the current position holder so that a nice transition of responsibilities can happen. CC’s should give special consideration to the fact that someone else will likely hold their role soon, and that someone else might completely change direction from the practice or style that you preferred when you were the position holder. To the extent possible, any community formality of any kind should be kept lightweight, easy to transition, and likely to have a long life. This helps ensure smooth continuity rather than volatility in how the community operates. To the extent possible, the CC’s should encourage bottom up self organization of the community. They should also obtain feedback from the community, but if guardrails or executive decisions are needed, the CC’s have the final say over all other positions in this community. Also worth noting that this community likely operates in a wider context (usually a company/org), so all company policies and company leadership roles must be respected or the community faces the prospect of being shut down. The community should feel free to (respectfully!) challenge the status quo of the wider context to increase value delivery, but only respectfully and diplomatically. Bottom up self organization does not mean your community “runs” the company. Role playing note: While not encouraged, only one of the CC’s may hold another position in the same community, and when they play dual roles, they must always clarify which role their input is originating from.

Management Sponsor(MS)

The management sponsor helps get funding and other logistics approved for the community. Ideally, but not absolutely required, the MS is a fairly high up leader in the organization that oversees the community interest. This role is also optional, as a strong community in an organization that empowers communities might not even need a management sponsor.

Artifacts

Community Working Agreements

Your community will likely have some “Community Working Agreements”

Example CWA’s: (We agree that…)

1. The community has 2 “Community coordinators”(CC) who serve 3 month terms.
   [The CC role’s mission is to incubate and inspire self organizing improvement efforts that further the “community interest.” They generally do this via ensuring that logistics flow smoothly and that benefits(improvement value) from “individuals and interactions” are maximized in the community.]
2. CC’s must also be Scrum Dev Team members.
3. It is strongly discouraged to have a CC who resides on more than one Scrum Team. (too much multi-tasking, and residing on two Scrum Dev Teams is weak Scrum practice anyway)
4. Elections for all positions are held half way into the current term to help provide continuity and orderly transition to the new position holders in the community.
5. A maximum of one CC can also hold another position/role in our community.

Hopefully you now have a better picture of some other aspects around CoP’s.

An Agile Community of Practice Starter Kit

As I describe in my article An Agile Architecture Community of Practice, a very mature Community of Practice has mechanisms that represent that the community has come to agree upon, over a long period of time.  Those standards and working agreements need to mature over time as well…but what if you’re starting a new Community of Practice(CoP) from scratch and you’re NOT mature yet?  Where do you start?

To me, the healthy starter kit for a CoP is comprised of the following:

• The Community forms around an ” improvement interest” or effort that spans across multiple teams(Release Train, Product Group, Nexus, etc), that is scoped according to improvement domain, and also possibly according to organizational domain, geographic domain, and or product(system under development) domain.
• Roles: The following positions or roles need to be initially filled:
  • Community Agile Coach
    • fulfilled by an Agile Coach (and/or Scrum Master), absolutely required position, also good to have a “backup” at all times as well.
  • 2 Community Coordinators
    • Both of these coordinators must come from Scrum Development Teams*
      • * Exception:  if the community “improvement interest” is a topic whose “home base” is not on a Scrum Dev Team, then this requirement is waived.  For instance:  Scrum Master CoP, Agile Manager CoP, Agile Executive CoP, are not home based in Scrum Development Teams
      • The coordinators are responsible for ensuring the “communication mechanisms” below are bringing maximum value to the community.
  • 2-4 Subject Matter Experts
    • These people are the people that are most passionate about the subject that the community is formed around.  They typically already share their knowledge across their teams and/or organizations, and are looked up to widely across the Scrum Teams/and or org.  Ideally they come from Scrum Teams, but this is not a hard requirement, and sometimes difficult to fulfill in orgs that are relatively new to Agile.
  • 1 Management Supporter(optional)
    • This is optional, and should only be fulfilled if you can find someone with good Agile behavior(preferably someone with at least one Scrum or Scaled Scrum/Agile certification, preferably both), and communicate to this person that, in the community, they MUST act as a servant leader to the community, and must let the other roles run the community without too much influence or direction coming from the Management Supporter.  The management supporter might be more directive outside the community activities, but not through the community mechanisms.
• Artifacts: The following artifacts are required:
  • Community Improvement Backlog
    • Unlike the Product Backlog in Scrum, this Community Improvement  Backlog (CIB) contains Community Backlog Items (CBI’s) that only represent “improvements” in the community’s “improvement interest.”  There may be Product Backlog Items that represent work on the Product under development that come out of a community’s efforts, but those will land on a particular Scrum Team’s plate(even if the item applies across several teams).  Remember, bring the work to the (already existing) Scrum Teams and put it on the Product Backlog!  The CB only holds community improvement ideas, not product development work.
    • Obviously, this artifact only needs a couple of items on it to start.
  • Community Working Agreements
    • Agreements about how your community will operate.  (This is the CoP version of  the “Team Working Agreements” in Agile)  The people who fulfill the above roles(the “role players”) are responsible for ensuring this happens.  Many of the other things listed here in this blog post could be your starter set for CWA’s(Roles, Artifacts, Events, Communication Mechanisms).
    • TWA #1 should be something like “In everything we do as a Community, we try to honor the Agile Manifesto.  So, we value individuals & interactions over processes and tools, we value responding to change over following a plan, and we value executing improvement experiments over endless theoretical discussion and “analysis paralysis” about how to go about improving.”
• Events:
  • Meetings at least 3X a month, including at least one meeting open to the public. (Some meetings are best held more privately among the role players in the community, to help coordinate all efforts, public and private)
• Communication Mechanisms:  The following comm mechanisms should be established from the beginning.  The Community Coordinators are responsible for ensuring maximum value is continuously obtained from these comm mechanisms.
  • Synchronous “push” communication for spontaneous collaboration:
    • If everyone is highly co-located, then the mechanism is “Talk to each other”
    • If not, then this mechanism is something like an “always on” videoconferencing system, but also could be a chat room (think Slack or HipChat)
    • Email is a very poor form of this mechanism, but if you can’t get something like the above, then an email list may be the best you can do right now.  (IF that is the case “Find a better Synchronous Communication mechanism” should be high in your community’s improvement backlog)
  • Asynchronous “collaborative” communication for longer lived communications
    • A wiki (something like a Confluence or MediaWiki)
      •  At a minimum, your wiki (and it’s sub pages) should document
        • Your Community’s mission/interest
        • Your CB or a link to your CB (possibly kept in another tool, but a wiki is ok for this purpose too)
        • Your CWA’s
        • The description of the current position holders
        • Info about how to get onboarded to your community’s communication mechanisms.
    • Last resort:  If you can’t get a wiki, an “opaque” document repository mechanism (such as Sharepoint, Google Docs, Dropbox or your code repository)  can be used to keep documents that the community can use, store, and access.
    • (optional) A “work board” for more tactical coordination and possibly the Community Improvement Backlog.  (Something like Trello, a wiki, or your favorite Agile life cycle tool if you can get your company to give you a separate project area for your efforts)  If you can’t quickly get this, this might be a CBI.

The above is the basic starter set to get a Community of Practice started.  Something not mentioned above is the intended audience for the community.  The community is led by the role players, BUT the beneficiaries and implementers of the improvements are generally the “grass roots” members of the community, such as members of your Scrum Development teams.  Said another way, there is a vital implicit role in a Community of Practice, that of  the “target audience” for the community’s efforts.  When the community has “public” meetings, or other communications sent via public communication channels, the target audience benefits greatly from the improvements made by the community.

For me, there are always at least 3 CoP’s that are needed in every environment where multiple Scrum or Agile teams work together closely on a product (aka system under development).

1. Agile Architecture Community of Practice
2. Agile Testing Community of Practice
3. Cross Team coordination Community of Practice (This one often already exists in your scaling framework, such as Scrum of Scrums, Nexus Daily Scrum, Nexus Integration Team, System Team, and there are many other examples)
   1. These practices are really just narrow CoP’s that focus on “Coordinating the flow of work to maximize the value delivery of frequent software releases”

At this point, you may be asking yourself “Why this many roles and structure just to get started?”  Here’s the reason:  Until you have the “minimum viable practice” in place, you should not start a Community of Practice.  You are creating a C-O-M-M-U-N-I-T-Y.  With any fewer than the above roles, artifacts, events, and communication mechanisms fulfilled, you won’t likely have a chance of creating a long running effort that is sustainable, productive, and beneficial over a longer period of time.  If you can’t convince the above handful of people to take a leadership role, then you have more work to do and more support to gather before starting.

For some more info on CoP’s, see this follow on article:  More Aspects of Agile Communities of Practice

The emphasis for your community should always be on “executing improvements” over having endless “how we run the community” process discussions or “how we should go about improvement X” discussions.  Remember, “individuals and interactions over processes and tools.”  🙂

 

An Agile Architecture Community of Practice

Note:  The format of this article did not transfer over well from the previous site, so this pdf version might be much easier to read and distribute.

Background

We often coach organizations on scaling Scrum, where 4-12 Scrum Teams are working on the same Product or a set of closely related Products (Applications, Systems, etc). We often get asked how things like Architecture and other multi-team related concerns are handled in a scaled Scrum approach. In Agile practice, handling these multi-team concerns is usually handled via a mechanism called a “Community of Practice”. Below is an example of a moderately mature community, based on a compilation of ideas that we have seen work well in the field. Note also that a TeamSet should always have more than one “Community of Practice”,and new ones should be formed and dissolved as needed.

For more info on Communities of Practice, see An Agile Community of Practice Starter Kit

Caveats about the example below:

1. We use the term “TeamSet” below to refer to a set of teams, the 4-12 mentioned above, working on a Product or set of closely related Products. Obviously the more high impact the architectual initiatives, the more formality of process you will likely need. So, if your set of closely related Products is not that closely related, then this community should be less formal and less broadly applicable in its decisions. The converse of this is also likely true.
2. The below example is that this shows more of an “ideal end state” — your org will likely have to take a few steps of organizational change before you can get here. But try to get as far as you can on step 1 — you might surprise yourself.
3. We have probably added more formality and more documentation below than would be typical in a real life, highly Agile, community of practice. We do so here primarily for illustrative learning purposes, to give you more ideas than are truly needed (i.e. so you can pick and choose what work in your context). In real life, the community would likely be less formal.
4. This example is for Architecture, but this same kind of approach easily fits other types of CoP’s: Agile CoP, Scrum CoP, Scrum Master CoP, Product Owner CoP, DevOps CoP, Programming CoP, Automated Testing CoP, UX CoP, SAFe CoP, RTE CoP, Nexus CoP, LeSS CoP, etc. [ONE MORE REMINDER: Your CoP should have the minimum amount of formality necessary, and to the extent possible, should operate bottom up.]

---

The Aegis Architecture Community of Practice

Our Charter Statement: We all work on a set of closely related products, collectively known as Aegis. This community organized around ensuring that the highest Architectural concerns that have a high impact on Aegis are efficiently and effectively addressed. Please note that this community focuses only on the highest Architectural concerns.

In Scope: The set of teams (TeamSet) that this community encompasses are: Stingray, 49’ers, Falcon, Journey, Explorers, Red October, Phoenix, and Hawking. The main “in scope” topic is high Architectural concerns, though the dividing line between “high” and “not high” is not always black and white. As you look below, hopefully the mechanisms we have in place will give you the idea of where that line is usually drawn.

Out of Scope: Practices related to Programming, Design and other concerns are generally left to others (Other communities and/or the Scrum teams themselves to self organize and solve). Test and Build automation is left to others. The Director of Software Dev hires and chooses the LA (Lead Architect), so that is out of scope for our community. Our Arch CoP only covers the teams in the Aegis TeamSet, so for Arch issues that are decided at the corporate level, you will need to talk to the EAG (Enterprise Architecture Group, not a CoP yet. 😦 ). Our Lead Architect has good communication with the EAG, but anyone should feel free to go the EAG for the appropriate services(just loop the Lead Architect in as well). Typically we form a working group from this CoP to go and talk to the EAG for any requests.

---

(In the sections below, note that we have specifically named them “Individuals”, “Interactions”, “Processes”, “Tools” to relate to the Agile Manifesto, valuing “Individuals and Interactions over Processes and Tools”.)

Individuals

Community Leadership			Home Scrum Team
Community Coordinators (CC)	Jill Hutchins, Henry Nguyen		Stingray, Falcon
Agile Coach	Jeff Schwaber (Liaison to Scrum Master CoP)		Falcon
Management Contact	Ellie Swanson		n/a, Director of Software Dev
Lead Architect(LA) 90% allocated to community 10% allocated to Scrum Team	Ian Robison		Journey
Community Architects(CA) 50% allocated to community 50% allocated to Scrum Team
	Phillip Smith		Explorers
	Brijesh Singh		Hawking
	Jill Hutchins		Stringray
	Henry Nguyen (Liaison to Tech Excellence COP)		Falcon
Community Members
Architecture Team Reps(ATR) 10% allocated to community 90% allocated to Scrum Team
	Sheila Hill		Stingray
	Carlos Diego		49’ers
	Rachel Story		Falcon
	Chris Bradford		Journey
	(open) (interim- Phillip Smith)		Explorers
	Adam Gideon		Red October
	Adrienne Maxhouse		Phoenix
	Sandesh Mokkarala		Hawking
General Member (GM)
	All people above are also considered GM’s
	Anyone interested!
	Melissa Hayden (Liaison to Testing CoP)

Role Definitions
Community Coordinators	This role is to be a servant leader to guide the community on what initiatives and other efforts to focus on. This role also helps provide leadership on which decisions are truly of high enough concern to warrant formality and process via the community. The only requirements for this role are that the person has the appropriate architecture knowledge and must have 3 months of experience in the role of ATR and/or CA prior to serving. The Lead Architect cannot be a coordinator (this helps prevent command and control hierarchical leadership — and respects self organization of the community). The coordinators are elected every 6 months.
Agile Coach	This role is to be a servant leader to guide the community on how to respect the Agile Manifesto, the Scrum Guide, and in general, the “Community of Practice” approach to self organization. This person is expected to be an experienced senior Scrum Master or Agile Coach. The requirements for this role are: 1 year of experience as a Scrum Master or Agile Coach, 2 Agile/Scrum certifications, and at least 3 months of participation as a General Member in this community prior to serving. This person will also need to be able to spend ~20% of their time playing this role. The Agile Coach is elected every 6 months.
Management Contact	This is senior management role from the Dev Org, cannot be a first line dev manager. Currently the Director of Software Dev plays this role. This contact is used to secure funding, facilities, and other logistical approvals needed for the community to hold its events. This person does not usually spend much time interacting with the community.
Lead Architect	This person is hired by the Director of Software Dev to be the Lead Architect for the TeamSet and for the community. This person participates heavily in the community and has some decision making power (see “Process” below). The requirements for this role are determined by the Director of Software Dev. Cannot be the Community Coordinator (see that role description for more info)
Community Architect	This person spends around 50% of their time on community initiatives. They are expected to be good communicators, accessible, and have the appropriate architecture knowledge. The only requirements for this role are that the person has the appropriate architecture knowledge and must have 3 months of experience in the role of ATR and/or CA prior to serving.
Architectural Team Rep	This person spends around 10% of their time on community initiatives. This usually revolves around being a communication radiator for their Home Scrum Team and ensuring that all relevant community communication gets shared with their home Scrum Team. This person will also often help with architectural initiatives that their Scrum Team is sponsoring. This should never be considered a gate or bottleneck role — i.e. anyone on any Scrum Team can interact with the community without having to go through (or get approval from) their ATR.
General Member	Anyone who has an interest in architecture can participate in the public activities, meetings, and communication mechanisms of this community. In order to vote for the approval of CWA’s or in approval meetings, the person should have significant knowledge of the subject at hand, and have materially participated in 3 months worth of immediately prior community activities. It is strongly recommended that you recuse yourself from votes any time you do not meet these pre-requisites, OR any time you don’t have a strong opinion on the thing being voted on.
Liaison	The community has various volunteer liaisons to other parts of the organization, generally to other CoP’s. These people help us identify synnergies and conflicts of scope between this community and the other communities. This is a pretty informal position, and any General Member is free to provide the same kind of information — it’s just that these people volunteer to definitely keep an ear to the ground between the two communities.

CWA’s re: Individuals

(CWA’s = Community Working Agreements)

1. In everything we do, we try to honor Scrum(as defined in the Scrum Guide) and Agile (as defined in the Agile Manifesto). Because we have not yet chosen a scaled Scrum approach, we simply extend many of the ideas of the Scrum Guide and Agile Manifesto to our entire Community and TeamSet.
2. The table and information above includes information that is also effectively CWA’s.
3. Because we believe in the Agile value statement of valuing “Individuals and Interactions over Processes and Tools” and “Responding to Change over Following a Plan”, don’t ever be afraid to get some architects together in an ad hoc way to solve an architectural challenge — we can always retrofit those actions to our processes and tools later.
4. Unless otherwise indicated, the use of the term “architect” refers to the LA, CA’s, and ATR’s (i.e. does not refer to GM’s).
5. The architect titles above are completely independent from your job title and career path. The above titles are bestowed by the community (except for the LA, who is hired by the Director of Software Dev). This community makes no claim over the management or career path domains of the company. We are simply a self organizing community that co-exists with the rest of the organization.
6. Every architect belongs to and works on a Scrum Team. In their Scrum team, they hold no special authority or title on their team other than “Scrum Dev Team member, ” regardless of their title in this community.
7. Being a GM of the community is voluntary, with one exception: each Scrum team must choose and have an ATR with the appropriate skills, who is not an LA or CA.
8. All new CWA’s(re: Individuals or any other topic) must be approved by a “fist of 3” by the entire community. For all new CWA’s that have a heavy impact beyond the community, a forum must be held where all Scrum team members from the TeamSet can give feedback prior to approval.
9. There is always a Scrum team sponsor for each initiative, even if there is only a subset of the team working on the initiative.
10. We strongly prefer bottom up initiation of all architectural initiatives, coming from the teams. Initiatives need not come from the architects, but the ATR for that sponsoring team must be involved and be highly informed of the initiative.
11. The general time allocation expected of architects is listed in the chart above. Of course, there are exceptions at times. At any one given moment, an architect might have to choose between focusing on helping their team or helping their community. In that moment, the architect is expected to consult with others on which focus yields the most value for the entire TeamSet. Sometimes this means focusing on community efforts, and sometimes it means focusing on team efforts. Try to choose wisely in that moment.
12. Coordinators can fulfill the role of either a CA or an ATR while also fulfilling the coordinator role, but this is not a requirement.
    1. Note above that an ATR cannot fulfill the role of ATR AND [CA or LA] at the same time, but an ATR could be an ATR and a coordinator at the same time.

---

Interactions

Communication Mechanisms
	Ad hoc conversations and informal meetings — we encourage these the most! We encourage involving your ATR or CA when needed.
	This Wiki
	“Roughly” Monthly Public Meetings
	Occasional ad hoc public meetings when needed (includes educational meetings, approval meetings, etc)
	Group Chat (HipChat)
	Email List
	Occasional Private Meetings (Primarily only open to the LA, CA’s, ATR’s, and specially invited guests)
	ATR’s are responsible for communicating the important outcomes of all of the above to their respective teams.
	Architectural elements of the TeamSet Definition of Done
	Scrum Team “Code Based Tools” pages
Communication Contact	To get connected to our communication mechanisms, ask your ATR who to talk to.

CWA’s re: Interactions

1. In everything we do, we try to honor Scrum(as defined in the Scrum Guide) and Agile (as defined in the Agile Manifesto). Because we have not yet chosen a scaled Scrum approach, we simply extend many of the ideas of the Scrum Guide and Agile Manifesto to our entire Community and TeamSet.
2. The table above includes information that is also effectively CWA’s.
3. Because we believe in the Agile value statement of valuing “Individuals and Interactions over Processes and Tools” and “Responding to Change over Following a Plan”, don’t ever be afraid to get some architects together in an ad hoc way to solve an architectural challenge — we can always retrofit those actions to our processes and tools later.
4. In all of our architecture discussions and initiatives, we agree to use Agile Emergent Architecture.
5. Our community maintains a wiki for any communication where light documentation seems like a good communication mechanism. This page is just one of our pages. See our home page for lots more stuff.
6. Any person in the TeamSet can contact their ATR or a CA for help, collaboration, mentoring, or whatever is needed. It is NOT required to go through your ATR for every architecture interaction. We generally discourage direct communication with the LA unless you are working on an initiative with that person. The person is VERY busy. Your ATR or CA will involve the LA if that is needed.
7. Each Scrum Team must keep an updated “Code Based Tools”(CBT) page connected to their team wiki. Only include tools that your team regularly uses and/or has significant experience with. The purpose of this CBT page is to spread knowledge to the entire TeamSet about which tools are in use, and which teams have knowledge of those tools. On the CBT page, the team must include 2 categories of tools and info:
   1. CBT’s that they use that are expressly approved by the Arch Community Tool Matrix.
      1. For each 3rd party library, please specify the exact library and versions in use, why the library is being used(it’s purpose), known scope of use(product, module, class, etc), and how widespread is its use (low, medium, high).
   2. CBT’s that they have not been expressly approved by the Arch Community Tool Matrix. (Note that this is not considered bad usage — not all tools are in the scope of our community)
      1. please specify the exact tool and versions in use, why the library is being used(it’s purpose), known scope of use(product, module, class, etc) and how widespread is its use (low, medium, high).
8. In all of our communication mechanisms, we try very hard to be specific about topics of discussion and whether they are they “in scope for the community”– or not?
   1. For instance, using our communication mechanisms to just get general ad hoc architectural or even design/implementation/technical help is perfectly fine, but say something like “This is really more in scope for just our team, but we could really use some help on — who can help us with that?”
   2. If you’re not sure whether a topic is in scope for the community, just ask the community for help in determining that!
   3. Obviously, if you realize that a topic is in scope for a different community, by all means, please use that community’s communication mechanisms instead of ours.

---

Processes

Processes
	Architecture Tools Approval Process (ATAP) (tools, frameworks, arch approaches, etc)
	Election of Community Leaders
	Quarterly Retrospectives

CWA’s re: Processes

1. In everything we do, we try to honor Scrum(as defined in the Scrum Guide) and Agile (as defined in the Agile Manifesto). Because we have not yet chosen a scaled Scrum approach, we simply extend many of the ideas of the Scrum Guide and Agile Manifesto to our entire Community and TeamSet.
2. The table above includes information that is also effectively CWA’s.
3. Because we believe in the Agile value statement of valuing “Individuals and Interactions over Processes and Tools” and “Responding to Change over Following a Plan”, don’t ever be afraid to get some architects together in an ad hoc way to solve an architectural challenge — we can always retrofit those actions to our processes and tools later.
4. We use the term “Tools” fairly broadly, to include essentially all architectural initiatives that require community approval or coordination.
5. Community retrospectives are held at least once each quarter, and at least within the 2 weeks prior to a new community leadership election. At this time, we often review our CWA’s and Charter Statement to ensure we are in alignment.
6. Every 6 months, an election is held to select the CC’s, CA’s, and Agile Coach.
7. All architectural initiatives must include an “independent usage plan” that describes how future users of the initiative can be quickly educated on the tool/approach such that they will not be heavily dependent on tribal knowledge by a small number of people. This often includes light documentation as well as video recordings of education sessions for the initiative. Decreasing this type of “key person” risk enhances our Agility and ability to respond to change in the future.
8. The ATAP is documented in detail elsewhere, but here is a summary:
   1. A Scrum Team suggests sponsoring an initiative to be approved as an experiment or as a tool, initiative, or decision that is approved for widespread community use.
      1. We encourage the teams, as much as possible, to sponsor initiatives of their own choosing. I..e we prefer they initiate.
         1. In rarer cases, sometimes the CA’s or LA will ask a team to sponsor, but the decision is up to the Scrum Team.
   2. An approval meeting is scheduled (giving the team time to be prepared). Sometimes this is done in regular monthly meetings, sometimes scheduled ad hoc.
   3. The Scrum Team makes review material available 1 week prior to the approval meeting for voting members to review prior to the approval meeting.
   4. The Scrum Team presents to the community.
   5. The community votes with a fist of five, where at least a fist of 3 is required of all approved voters. If a fist of 3 cannot be obtained, a “unity group” is formed to discuss further and/or come up with a compromise within 2 weeks, including those strongly in favor, as well as any that are a fist of 2 or lower(the dissenters). If the unity group can agree with in 2 weeks, then the voted is considered approved. If they cannot agree, then the LA makes the decision to approve or disapprove as a last resort.
   6. If approved, the community then documents the new tool as “approved for experiment” or “approved for use” and is added to the tool matrix. (see below)

---

Tools

Tools Matrix

Tool/Initiative Name		Being Proposed	Approved For Experiment	Approved For Use	Deprecated	Sunsetted
Logging Framework – SLF4J (v3.4, v4.0.1)				X
Programming Language: Java (23.4 or above)				X
Dependency Injection Framework: InjectorSpace 3.2 or above (Home Grown)				X
Dependency Injection Framework: InjectorSpace 3.1					X
Dependency Injection Framework: InjectorSpace 3.0 or below						X
Architectural Pattern/Domain Logic: Domain Model				X
Architectural Pattern/Domain Logic: Service Layer				X
Database: Oracle 23i or above				X
Deployment Platforms: ???
Other various open source libraries: Must be GPL-3.0 or EPL-1.0 license.				X
Programming Language: Scala (12 or above)			X
Architectural Pattern: Microservices (will likely be limited in scope, as only valuable in certain contexts)		X
Persistence Framework: Hibernate (54 or above)				X
Architectural Pattern: Monolith applications				X
Peer Review: Scrum Team must have documented procedures for peer reviews.				X
… (author note — there would likely be many more items in a real CoP — these are just examples)

Note that the TeamSet Definition of Done requires that all 3rd party tools that are code based (Libraries, code frameworks, Development Environments, etc) be represented on the above Tool Matrix.

The items below have at one time been considered out of scope for the Architectural Community.

Out of Scope Matrix

>

CWA’s re: Tools

1. In everything we do, we try to honor Scrum(as defined in the Scrum Guide) and Agile (as defined in the Agile Manifesto). Because we have not yet chosen a scaled Scrum approach, we simply extend many of the ideas of the Scrum Guide and Agile Manifesto to our entire Community and TeamSet.
2. The table above includes information that is also effectively CWA’s.
3. Because we believe in the Agile value statement of valuing “Individuals and Interactions over Processes and Tools” and “Responding to Change over Following a Plan”, don’t ever be afraid to get some architects together in an ad hoc way to solve an architectural challenge — we can always retrofit those actions to our processes and tools later.
4. We use the term “Tools” fairly broadly, to include essentially all architectural initiatives that require community approval or coordination.
5. We don’t yet have any more special CWA’s on the Tools topic — most of what we record here is in the tool Matrix above.
6. These tools have been considered to be “out of scope” for this community: Agile ALM Tool, Wiki Tool Choice, Test Driven Development, Peer review procedures, Test Automation techniques, Build Automation techniques, process compliance.

 

[TODO: Make Tables appear better]