17. February, 2020

CoDe Café

By Lars Kruse

CoDe Café

The Full-Day CoDe Café is facilitated learning with peers and experts in cosy, relaxed ambience. It builds on the principles of situated-learning which defies traditional class-room training and emphasize actual learning over mere knowledge transfer. The CoDe Cafés strive to build communities of peers.

The purpose of the CoDe Café is to sustain learning in a community context - or even to establish such a community, if it doesn’t exist already.

This synopsis describes a specific format of this code café in a future setup.

Each instance of a Code Café is described in 5 Co’s:

  • The Concept
  • The Context
  • The Content
  • The Community
  • The Contributors

The Concept

The CoDe Café is bread from Situated learning which is a learning concept originally unfolded by Jean Lave and Etienne Wenger in 1991 in “Situated Learning. Legitimate peripheral participation”. It’s related to ”Constructivism” - the epistemological concept that learners construct knowledge - often credited to psychologist Jean Piaget. I first encountered this approach to learning when I studied Communication Theory at Uni back in the early 1990’ies through Donald Schoen and his book “The Reflective Practitioner” from 1989. As such the concepts which forms the pillars of the Code Café also has an undisputed reference to the concept of “Design Thinking” with its focus on problem framing and solution-focused thinking. And it’s worth emphasizing the relationship with Lean principles amplifying learning through continuous improvement, kaizen, value stream optimization and an overall holistic view of the situation at hand.

The name CoDe Café is deliberately spelled in CamelCase: with a capital C and a Capital D in CoDe. Although the CoDe Café concept was originally developed as an advanced type of hackathon inspired by the World Café conference/workshop format the word “code” is not referring to code in the meaning of a computer programming language, but to the term “Continuous Delivery” which is widely used in modern software development lingo, and which encapsulates two of the most prominent principles in Lean thinking: “Decide as late as possible” and “Deliver as fast as possible”

The Context

The context refers to the situation in situated learning. But it also refers to the café; the physical surroundings and ambience in which the learning takes place, as well as the actual collaboration tool stack that is used to enable the communication before, during and after the café.

The situation is constituted by a group of people, who have the same goal; to eventually master some technique, tool, approach or technology, and the means to achieve the goal is to apply whatever in question to a real problem.

The ambition to work on a real problem - as opposed to a simulated training situation - requires that the participants gets a voice early in the process and a chance to articulate and explore - exactly what is a real problem?

The café is a room or place that can accommodate the participants throughout the entire day, functions like:

  • Breakfast buffet
  • Lunch (sandwiches or salads)
  • Dinner (three course, gourmet dinner, with wine and informal leisure talks)
  • Shared screens (Projector)
  • Whiteboards (or flip-overs or similar)
  • Breakout rooms or -sections for groups of 3-5 people
  • Breaks

It could actually be a full day occupation of a real commercial/public café, we have done that several times, or it could be some kind of private room restaurant or conference facility.

The collaboration tool stack should be simple and easy to use, yet effective and efficient.

A requirement would be some kind of Kanban board style planning program:

  • GitHub/ZenHub
  • Azure DevOps Boards
  • Trello

The board is used to organize the CoDe Café. The purpose of the board is to capture, describe, prioritize, estimate, log, organize and progress stories or problems. It’s main use is before and during the CoDe Café - and in-between café, if the intent is to run a consecutive series of CoDe Cafés

To support the Community, that we’re forming or extending we need a chat tool - could be one of:

  • Mattermost
  • Slack
  • Rocket.chat
  • Microsoft Teams

The chat tool is to encourage community members to stay connected and continue joint learning, sparring and collaboration after the CoDe Café is over. But also for community leaders to have an established channel to communicate community initiatives.

If the knowledge domain of the CoDe Café is one of code - this time actually referring to a computer programming language - then the tool stack also includes a cloud hosted developer organisation with support for git repositories - could be one of:

  • GitHub
  • GitLab
  • Azure DevOps
  • Bitbucket

Potentially with accompanying setups on related or supporting services (e.g. Circle CI, Docker, Cloud infrastructure providers…)


The Content

The content is the problem, or the problem-framing, or the domain of knowledge, in other words it’s the subject of the learning - the technology, approach, method or tool that the CoDe Café should facilitate learning about.

Through a series of interviews or questionnaires prior to the CoDe Café, each participant has been approached and encouraged to give a contribution to what might constitute one or more real-life problems or challenges as seen from their perspective.

This is an important part of the preparation, and an important part of why a CoDe Café is different from traditional education. The facilitators and masters/experts of the CoDe Café are expected to be so skilled, that they can facilitate or contribute to the solution of any domain related problem.

The CoDe Café is a workshop, that shall generate immediately actionably value to the participants. Each participant should be able to state something like: _”before the CoDe Café, I wasn’t able to do , but after the CoDe Café I had leaned how to do it myself”._

The focus is on learning - not knowledge.

That’s why the content is not structured in chapters around what the instructors knows - but rather what the participants defined as problems and therefore need to learn.

Throughout the day the CoDe Café will utilize different methods, exemplified by, but not limited to:

  • Lean Coffee - A meeting technique that’s useful to run a well organized meeting, that doesn’t have an agenda to begin with.
  • Kaizen Blitz - A short intense gathering, that generates immediate reflections and feedback on a concrete process, flow or solution with the specific purpose of optimizing the process in questions.
  • Paired or mob development - A technique developed in the context of computer programming (paired programming), but rephrased to refer to development in general, indicating that the process can be utilized in other domains as well. One person is the driver, the other is the navigator. If the setup has more than two people, it’s called a mob in which case the others are observers. All roles swap at timed intervals.
  • Show - Tell - Do - A lay-up to group work. An expert or ekvilibrist shows a concept, the audience is expected to lean back and enjoy the show which is supposed to be entertaining and impressive - a show of mastery. After the show comes the tell. This is the part where the magician reveals step-by-step how the magic, wasn’t really magic after all. After that the audience forms groups where each group is expected to do the same thing - together. The time ration between show, tell and do should be something like 5%-15%-80%
  • Dojos - Useful for exploring different approaches to same-problem scenarios. Dojo is referring to the training rooms of Karate, where the Katas are rehearsed over and over again. Conceptually the participants are asked to do the same kata or exercise over and over again, several times, but changing the parameters of the kata in each run, like utilizing different tools, technologies to achieve the same thing.
  • World Cafe - facilitated discussions in smaller groups, each seated around a café-table.. Each table has a different topic. Each group will discuss for a limited amount of time and then capture the content and take-aways of the discussion - after each round the participants will mingle, and sit with new groups at new tables, repeat as many rounds as there are tables, eventually everyone will have been seated at each table. After all sessions have been executed run a joint round of reflections.
  • Witnessing - A practice adopted from narrative therapy and coaching. Useful to establish new perspectives on issues and challenges. A coach/master has a dialog with a coachee/participant, the topic of the conversation is brought up by the coachee as a specific problem that needs coaching.. The rest of the group is witnessing the dialog. After the coach session each witness is asked to contribute: What expressions were used (literally)? Which values and skills seem to be the drivers of the coachee? What images and metaphors can you use to describe the capabilities of the coachee? In which way does the story of the coachee resonate with you? What do you feel like doing?
  • Roundtable - The roundtable is literally a round table, so wide that it seats 12 people (2.5 meters across). It has an HD projector mounted above it, so that the center of the table can be used for presentations. Through the utilization of a real-time gaming engine we have developed an application that allows for different kinds of augmented presentations. The roundtable is ideal for quite spectacular and eventful dinner seatings, but even as a workshop table, that allows for roundtable sessions (everyone gets to speak or present).

All of the above mentioned techniques strive to provide learning through problem solving as well as insights through dialog, specifically to the problems and challenges the participants defined themselves.

The Community

The community represents the knowledge to which the learning applies. It’s formed by an arbitrarily large group of people, connected by a common interest in the domain.

The community is defined by the behaviour, events and actions that are performed. A silent community is essentially just a bunch of people, that doesn’t do anything - unless the community generates noise, it isn’t really a community.

A community needs a voice, and it needs to be facilitated, in Open Source tradition we sometimes refer to A Benevolent Dictator (BD) Governance Model - specifically referring to how one of the most successful and productive communities in the world succeed to stay productive: The Linux project.

A prerequisite for engaging and facilitating people is that they are connected and reachable - that is why we need a tool like Mattermost, Slack (or even LinkedIn of Facebook in the lack of better).

In a community, the participants should have a natural incentive to stay included in the community; they get access to “the wisdom of the crowd” to ask and answer questions regarding the domain is sometimes enough, but in young immature communities, which may even be geographically scattered it can be a real challenge by it self, to form and nurture a community to be self-sustained.

Techniques to build the community could be occasional meetings, like meet-ups, drink-ups, online “office hours” (regularly scheduled video room - or chat room meetings led by the BD of the community).

If the community has a beneficiary (sponsor) then organizing free or cheap community events where trusted lieutenants (also refers to the Benevolent Dictator Governance Model) and devotees get to meet hang-arounds and prospects. The purpose it to put faces on a crowd of “the usual suspects” that will eventually form relations, friendships, working relations, initiatives in the context of the community.

Which in turn will strengthen it.

The Contributors

The group of people and companies who initially put something into either the Community (the actions that act like glue to the coherence in the domain ), the Content (the Problem), the Context (the learning) or the Concept (in this case the CoDe Café concept).

For each CoDe Café you should Identify:

  • The beneficiary (the sponsor or the owner of the community)
  • The Facilitators (the owners of the concept and the content)
  • The providers (the venue, the catering, the equipment, the accommodation etc.)
  • The experts or masters (Benevolent Dictators and Trusted Lieutenants)
  • The community (personas, named individuals, groups of potentials, groups of similars)
  • The participants (participating in actual CoDe Cafés)


As mentioned, The CoDe Café concept was bread from a combination of a hackathon and a World Café - two pre-existing - but completely unrelated - concepts.

We first executed a CoDe Café in the context of a developer’s conference (Jenkins Community) I took the initiative to organize. As organizers we would like to invite to a pre-conference meetup where we would like to hack code, but with the intended goal to establish learning and without a specific agenda to meet on - facilitating the learning, rather than defining it. A workshop format lending from the World Café format.

Since the first introduction to the Jenkins Community it was executed multiple (20+) times, continuously improving and optimizing based on participant feedback and strengthening of particular learning aspects.

At some point the CoDe Café concept was expanded into the concept of a CoDe Camp - the same conceptual idea, but extended to a two-day event, and the café concept extended to a refugium with, dinner, lunch, breakfast, training, presenting and socializing all located at a conference-hotel with focus on the ambience of the place: in natural surroundings, checking out of the high-paced metropolitan surroundings.

The CoDe Camp concept was executed at more than 10 occasions both as an half-yearly internal conference format in a 50+ employees consultancy bureau scattered across 7 different geographical locations in three countries. And in an almost similar format to gather the CoDe Alliance, an informal alliance of ≈15 companies, who met half-yearly to develop common roadmaps to joint exploration and joint development of Continuous Delivery and DevOps related tools, extensions, features, methods and concepts.

As part of the same evolution, the concept was brought forward to a CoDe Academy - a four-day intense, hands-on training programme offered pro-bono to students in computer science related studies. It was executed at some of the most prestigious Universities in Copenhagen, Trondheim, Aarhus, Odense, Oslo, Gothenburg. The purpose was to introduce the Domain Knowledge of Continuous Delivery, programmable infrastructure and DevOps to computer science students, based on the analysis that these disciplines were not part of their university curriculums.


Sign up to our Profeed and receive news and information about our latest events, or if you can't wait, sign up for our event right away!

Profeed Events