The FAST Framework

Written by   on   in , , ,   with No comments

FAST is the acronym for Fluid Scaling Technology. Fluid Scaling Technology combines OpenSpace Technology1 and Open Allocation to create a  lightweight, simple-to-understand, and simple-to-master method for organizing people around work - that scales.

Where and When to use FAST

  • FAST is ideally suited for business environments or challenges that show complexity, rapid change, or where there is a need for innovation. 
  • FAST is ideal for software development, product development, and agile at scale - because of their typically complex nature. 
  • FAST is applicable to most complex collaborative endeavors and is not limited to just the software domain.
  • FAST is built on fluid (re)teaming rather than static teams to maximize adaptability.
  • FAST is the same process at the small through to the large scale.
  • FAST is not built on Scrum. Instead, FAST is built on OpenSpace Technology.
  • FAST operates as a pure complex system
    • FAST also accommodates complicated and simple work.

FAST Roles

  • Product Manager. 
    • This role is not one of authority and command but more inspiration. 
    • Motivation, encouragement, communicating a clear vision, recommunicating the vision often, direction setting, standard-setting, providing feedback, and modern product management.
  • Team Members: 
    • A T-shaped team player committed to delivery, collaboration, communication, listening, continuous learning, and personal mastery.
    • Generalizing specialists.
  • Team Steward:
    • Natural leadership role where a Team Member has chosen to steward some work in a Value Cycle. 
    • Just as teams are fluid in FAST, team stewardship is fluid and not static.
  • Feature Steward (Optional):
    • As teams are not static in FAST, it can make sense for at least one person to stay with a feature/opportunity/outcome to see it all the way through to completion. 
    • Provide continuity across Value Cycles and serve as a point of contact for stakeholders. 
    • It is not required to work continuously on the feature they are stewarding, only to have a continuous understanding of the work.

FAST Artifacts

  • Product Map – The Big Picture.
    • It's an extension of Jeff Patton's Story Mapping (Patton). The difference is that a Product Map focuses on high-level elements only, e.g. bets, capabilities, opportunities, aspects, desired outcomes, business goals, initiatives, themes, and features.
    • It's s a way to visualize what the Collective is doing as a whole. The map shows progress at a high level by the ratio of started, not started, and done.
    • Finer-grained details of high-level items are represented in Discovery Trees.
  • Discovery Trees – Thinking Big While Working Small.
    • Whenever work starts on a high-level item, create a Discovery Tree. A Discovery Tree represents the complexity of work while giving context to work items.
    • Break down work to understand, discover, or plan. But only just enough and just in time. 
    • As work recursively gets broken down from a high-level item into smaller subcomponents, a structure of branch and leaf nodes reveals itself.
    • The current progress toward node completion is evident by the ratio of nodes started, not started, or completed (or removing completed nodes from the tree).
  • Marketplace Board.
    • It visually represents a marketplace of work for a Value Cycle. 
    • The board shows what is happening in the current Value Cycle and who is on which team. (The FAST Marketplace Board borrows from OpenSpace's Bulletin Board.)
    • Each column on the Marketplace Board might represent a physical collaboration area. 
    • To constrain work in progress (WIP), limit the number of places available in the Marketplace.
    • On the board, this might mean restricting or removing columns.
  • Collective Agreements – How We Self-manage
    • It's a living document that describes the rules and mechanics of self-management within the Collective. Collective Agreements create and protect harmony and psychological safety. At a minimum, it should include: 
      • How do we make decisions?
      • How do we resolve conflict?
      • How do we change the Collective's Agreements?
      • Where do we keep the Agreements?

FAST Meeting

The FAST Meeting is the only event in FAST and it is facilitated by the FAST Product Manager. The current Value Cycle is declared closed, and the next starts.

  • Phase 1: Closing the Current Value Cycle.
    • Collective Synchronisation via Show and Tell. A representative from each team briefly summarises their team's work in the last Value Cycle, highlighting value delivered and discoveries made. It includes concise demonstrations if helpful.
    • Once all teams have completed their show and tell, the Value Cycle is closed.
    • Clear the Marketplace Board in readiness to repopulate again in the next Value Cycle.
  • Phase 2: Starting the Next Value Cycle. 
    • Reiterate Vision and Set Direction
    • Each FAST Meeting is an opportunity for the Product Manager to align, rally, and reinspire the Collective by reiterating the product vision, mission(s), and purpose. In addition, the Product Manager may choose to set priorities or direction for the Value Cycle. 
    • The Product Map can be a useful visual aid for this, and why having it on permanent display in the forum is recommended. 
  • Phase 3: Emerging Work & Self-selecting into Teams.
    • Create and Open the Marketplace.
    • Any Member can stand up in front of the Collective and declare their intent to steward a goal. The goal may be related to priorities just announced. Or not.
    • Once volunteers have stopped coming forward to steward work or the WIP limit has been reached, the Marketplace is declared open.
    • Collective Members then self-select into whichever team they feel they can contribute the most value to, or learn and grow the most from. 
    • Members go to the Marketplace Board and put their names into the slot associated with the goal they are interested in working on for that cycle.
    • Teams might be a component, feature, discovery team, or other, dependent on the work.
    • Teams have the autonomy to do whatever they feel is the best and right thing needed to add value.
  • Announcements (Optional). 
    • The Collective being gathered is an opportunity to make announcements. Announcements may be unrelated to work in the Value Cycle but are still relevant to the Collective.
  • Starting Work - Resolve Dependencies, Architect, Design, Plan, and Collaborate.
    • The dynamically formed teams now go to their chosen development area and plan. Each team tasks out their work and agrees on how they will collaborate. Should a team identify that they are likely to clash with another team or have dependencies, they meet with the other team(s) and discuss. To resolve dependencies or clashes, they might:
      • Merge.
      • Pick up some other work.
      • Have a design discussion, then plan if and how to divide labor.
      • Resolving dependencies this way can happen at any point in the cycle.

FAST Cadence and Flow

  • Synchronize the Collective to a shared understanding (via show and tell).
  • The pause between cycles is a sensing point to adjust teams, or work items should a better fit make sense. What was discovered in the last cycle? Has our understanding of the work or customer changed? Did any metrics change? Etc.
  • Revisit the purpose and vision of the product and company. Repetition, repetition... 
  • Cycles are not time boxes. Sign-off can happen at any point. Therefore, continuous delivery/deployment is a compatible natural fit and highly recommended for FAST.

FAST Adoption

FAST is a method that works on a small scale, large scale, and everything in between. It is the same process throughout, with only a few minor differences. A Collective is typically responsible for only one product or value stream in its entirety, but multiple products for a Collective are feasible. In the case of multiple products, the Product Manager can be singular or plural.
  • Small-scale FAST – Fewer Than 14 People. 
    • Use small-scale FAST when a Team has (roughly) fewer than fourteen people. 
    • Small-scale FAST can replace/supersede Scrum.
    • The collaboration units that Collective breaks into are smaller than in large-scale FAST. 
    • The smallest collaboration unit in small-scale FAST is two people, and pair programming is recommended when two. 
    • Mob Programming (Pearl) works well for collaboration units larger than two people.
  • Large-scale FAST – 14 to 200 People. 
    • Large-scale FAST is for a Collective of around fourteen or more people.
    • Collaboration units are typical agile software team sizes, e.g. 3-13 people.
    • Once a Collective grows too far past Dunbar's number (150), split and spin off a new Collective.
  • FAST Portfolio describes multiple Collectives. 
    • Working in this mode, FAST Product Managers meet for portfolio discussions.

FAST in Enterprise

  • FAST can integrate with other enterprise methods such as BOSSA nova, FLEX, and SAFe.

FAST Continuous Improvement.

  • FAST is not prescriptive on methods for implementing the principle of reflect and tune.
  • Each Collective should experiment and discover what works best. Some ideas and options:
    • Form a FAST Guild that meets on cadence to reflect and tune.
    • Host regular OpenSpace Events for the Collective with the theme Reflect and Tune.
    • Add a Turn Up the Good section to the FAST Meeting.

References

Share:

0 Comments:

Post a Comment