The UnFix Model

Written by   on   in ,   with No comments

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:

0 Comments:

Post a Comment