The Lean Coffee Meeting

Lean Coffee is structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. 

Step by Step

  • Step 1. Set up a Personal Kanban
    • It keeps the items to discuss, what we are currently discussing, and the discussed columns. 
    • This provides a structure for the conversation. 
    • People all get pads of post-it notes and a pen. 
  • Step 2. Brainstorm Topics.
    • They then start to add their topics for conversation into the "to discuss" column. 
    • These can be literally whatever people want to discuss or follow a theme. 
    • Right now, we want to encourage as many unique ideas as we can.
  • Step 3. Pitch Your Topics.
    • When the ideas start to reach a certain point (and you’ll be the best judge of when that is), each topic gets a 1 to 2-sentence introduction. 
    • This way people know what to vote for.
  • Step 4. Prioritize What to Discuss.
    • Each participant gets two votes. 
    • You can vote twice for the same thing or for two different topics. 
    • Simply put a dot on the sticky you are interested in. Tally the dots. 
  • Step 5. Manage the Flow of the Conversation.
    • Then you are ready to have a conversation.
  • Step 6. Identify Next Steps.
    • Record actions, ideas, and next steps.

References

Share:

The UnFix Model


What unFIX is Not

  • The unFIX model is NOT a framework. There is nothing essential in unFIX. Everything is optional. A better description would be a pattern library.
  • The unFIX model offers NO processes. The purpose of unFIX is to cover only organization design patterns and organizational structure. It is easy to find great advice for processes from many other sources.
  • The unFIX model is NOT for IT only. 
  • The unFIX model is NOT top-down. unFIX suggests a bottom-up approach. You cannot build something large. You must begin with something small.
  • The unFIX model is NOT a replacement. There are plenty of good things in other models and frameworks that should not be thrown away. We just hope that, with unFIX, you will unfix the bad parts and keep all the good bits.

The audience for unFIX is small to medium-sized businesses, not limited to software but it can be scaled up.

The Base (Tribe, Clan, Business Unit)

All Crews operate from a Base of between a handful to a few hundred people.

  • This Base has a number of Crews of the seven standard Crew types organized around one or more value streams.
  • The Base acts like a fully grown, independent business.
  • It contains all the necessary skills to design, develop, and deliver products, from Design Thinking to DevOps and Lean Startup to Lean Manufacturing.

Every person has a Base. It is their home.

  • The Base offers its people a sense of purpose, belonging, and recognition.
  • It provides comfort, personal safety, connectedness, a shared culture, shared toolsets, and career opportunities for all its workers.

Ideally, the Base covers a customer domain, not a technical domain.

  • It is similar to a tribe in the Spotify model and an Agile Release Train (ART) in the Scaled Agile Framework (SAFe). However, cadence and synchronization of work are optional.
  • A critical job of the Base is to continuously reorganize itself depending on the needs of the customer experience.
  • When the architecture needs to change, the organization needs to change.
  • Therefore, the Base does everything it can to support its Crews in remaining flexible.
  • This includes taking care of minimum standards and rules across all Crews so that reteaming is as painless as possible.

Crews (Team, Squad, Pod, Cell)

A Crew is a team that usually consists of three to seven people. 

  • The optimum team size is five. 
  • Team members are mostly dedicated to their Crew, but it’s okay if they reserve a small part of their week for work on a Forum (see below). 
  • In a regular business, most Crews should probably be Value Stream Crews. 
  • Crews can be any of the seven standard types.
  • These self-organizing, cross-functional teams manage their own meetings (planning, check-in, review, and retros); they manage their own documentation and releases, and they may operate according to a team agreement that defines team identity, shared rules, and more. 

There are seven kinds of Crews:

There are several team options:

  • Steady Team (high permanence, low permeability). The team is long-lived, and team membership changes rarely (e.g.: product team).
  • Dynamic Team (high permanence, high permeability). The team itself is long-lived, but team membership changes frequently (e.g. a call center).
  • Mission Team (low permanence, low permeability). The team itself is short-lived, but team membership changes rarely (e.g. rescue team, project teams).
  • Liquid Team (low permanence, high permeability). The team itself is short-lived, and team members also change frequently (e.g. film crew or construction crew).

The best teaming option depends on how the benefits and drawbacks of each pattern play out for your organization

The Forum (Chapter, Guild, Council, or CoP)

All value stream work happens in the Crews, but some things within the Base need to be coordinated along functional lines. A Forum is a group consisting of people from various Crews. 

  • Its primary purpose is for like-minded workers to get together, talk, and make decisions together
  • There could be a DevOps Forum, a UX Forum, a Growth Hackers Forum, etc. 
  • In traditional organizations, the Project Management Office (PMO) could be turned into a Forum.
  • In agile companies, the Product Managers could have their own Forum
  • The Chiefs of the Base might decide which Forums are needed because some Forums play an essential role in the organization's structure.

Chiefs can delegate work to Forums, such as standardization, templates, toolsets, infrastructure, personal development, cross-team coordination, and so on. 

  • They can expect each worker in the Base to be a member of at least one Forum and to participate in the conversations and decisions that matter for their functional areas. 
  • The role of Forums is to be the connective tissue between the Crews.
  • The purpose of a Forum is for people in similar roles to agree on how the work is done within the Base in a self-organized way so that dynamic reteaming is as painless as possible.

Some examples of Forums:

The Turfs (Area, Territory)

The Turfs are areas cultivated and protected by the same people. It could be a codebase, a product area, a machine, a house, or a town district that one group of people collectively takes care of.

  • The Turf is an area of concern with a clearly defined boundary.
  • There is clarity of ownership and responsibilities regarding the Turf.
  • The Turf is not too large; people are able to maintain and cultivate it.
  • The Turf is not too small; it offers enough challenge and motivation.

The Turf has significant relevance because of the maintenance drag. If the Turf that a group of people is responsible for gets too large, they will struggle to maintain it. 

The Captain (Team Lead)

There is a need for one Crew member to act as its Captain.

  • This person is the primary contact for the outside world, and she has final responsibility for whatever happens on the journey. 
  • A Crew can have a few additional roles, such as Product Lead, Tech Lead, etc. Depending on the product and its dependencies on the outside world, different Crew members can manage other communication channels. 
  • In fact, each Crew member could be a "lead" in some area. 
  • The link with the Base (see below) is the Captain.
  • Captains can be appointed, or they can be elected. 
  • However, the Captain never has line management responsibility on a Crew. 
    • The Captain does NOT discuss career development, compensation, or promotions with her crew members. 
    • Either way, she is the manager of the journey, not the Crew members!

The Chiefs (Management Team)

The Chiefs have line management responsibility for everyone in their Base. They are, literally, the management team

  • Depending on how the Chiefs divide the roles, each of them would have between three to twenty direct reports. 
  • Typically, all back-end developers would report to a Chief Technology, and all UX people might report to a Chief Product, and so on. But context should dictate what is reasonable.
  • The Base has a stable management reporting structure, no matter what happens with the Crews. People could hop from Crew to Crew five times per year, and nobody would ever change their manager.
  • Only the Chiefs are responsible for recruitment, compensation, promotions, and so on. 
  • They can delegate the value streams to the Captains of Crews and functional alignment to the Chairs of Forums (see below).

The Chair (Moderator)

The Chair is the manager of the Forum and NOT the manager of the people.

  • The person who moderates a Forum has responsibility for the workings of the Forum. 
  • He is not the manager of the people who participate in the Forum. 
  • It is a part-time job, typically taken up by someone with some seniority in the Base. 

The unFIX model is not a matrix organization. 

  • Different Crew members participate in different Forums, and they may have different Chiefs as managers. 
  • The Chiefs always work on the same Governance Crew. The managers have the same objectives. 
  • When there’s a conflict on a Crew, it can escalate to only one management team! Goodbye matrix.

Scaling Up

Dozens of Bases can collaborate in a League.

  • Within a League, they might form Clusters (similar to people forming Crews). 
  • Some Bases could self-organize into a Value Stream Cluster, others into a Facilitation Cluster, a Platform Cluster, a Capability Cluster, etc. 
  • The League has its own management team (Governance Cluster) and is organized around co-dependent value streams or related customer experiences.

Similarly, cross-Base coordination can be handled in Assemblies (similar to people coordinating their work in Forums). 

  • These Assemblies are voluntary structures that enable the representatives from Bases to coordinate ways of working across the borders of a single Base.

We can even go another level up and say that dozens of Leagues might form a Crowd

  • The Leagues could self-organize and collaborate in Coalitions and coordinate their work in Congresses. 
  • Again, all earlier patterns repeat at the higher levels which makes the unFIX model self-similar across all scales. It is a fractal model.

Others

References

Share:

Meetings Distractions

Check-in

A check-in is a simple go-around that occurs at the beginning of a meeting. People are invited to share their moods and briefly identify anything that might affect their participation. Check-ins allow people to tell each other what they are facing, in a way that informs without being intrusive.

  1. Introduce the check-in and say "What mood are you in? any context is fine, work-related or not" and explain "Let's give each person space to check in without comments". 
    • In essence "Here's how it feels to be me today"
  2. Ask for a volunteer to go first and ask this person to say "I'm done/Pass" when they have finished.
  3. If someone interrupts, politely interject and say"Sorry, excuse me, this is not a time for a conversation. Let's give each other space to check in without a comment"
  4. When everybody has checked in, you might optionally acknowledge a theme you've just heard. "It seems many of you ... [reassure any support from the meeting agenda or setting to help with the theme]"

Checking helps to be patient someone is having a bad day, and to transition from outside of the meeting to the inside of the meeting. It's a solid investment in the long-term development of trust.

Handling Out-of-context Distractions

Current events sometimes interfere with a group's ability to concentrate. Realistically the presence of a serious distraction will lower a group's efficiency regardless of what group members are officially allowed to talk about. This activity gives people the chance to spend a well-structured period of time talking about what's really on their minds. After a round of expressing themselves, they are better able to concentrate.

  1. Say "I notice we're having a hard time concentrating on this subject, and I'm aware that Z is on a lot of people's minds. Could we step back and speak for a few minutes talking about Z?".
  2. Make an agreement with the group to proceed.
  3. Make a reaction round with the question "What are people feeling about the event?" and get everybody the opportunity to express it.
  4. Make a suggestion for a transition: "What if we spend a few more minutes in this conversation, then take a break and return to the main topic after the break?"

Stepping out of the Content

Meetings sometimes get bogged down for reasons that aren't clear.

  1. Describe what you are observing. "This morning everyone agreed not to interrupt while they are speaking. Yet this afternoon many people are talking over one another. I am also noticing some other signs of stress, such as X, Y, Z"
  2. Ask for validation: "Is anyone also noticing this?" or "Are others seeing something similar?"
  3. Encourage reflection "What reaction are people having to this?" or "What thoughts and feelings are coming up for you?" or "Does anyone have a sense of what this is about?"
  4. Encourage and draw out different perspectives. Don't try to solve a bring people to a shared agreement.
  5. When people seem ready to return to the original topic, ask "Before we go back to our original topic, are there any final reactions to what has just been said?"
  6. Optional: call for a short break to let the planner(s) reconsider the agenda.

Continuous improvement

  1. Hang two sheets of paper. Title one page "Strengths" and the other "Improvable".
  2. Ask somebody to someone to call out strength and. Then Ask someone else to call out an improvable. Build the two lists simultaneously.
  3. Encourage participants to speak frankly in the spirit of constructive learning.
  4. While the lists are being made, the ground rule of suspending judgment is in effect - no defending, explaining, or apologizing.

References

Share: